| 00:08.16 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 00:28.08 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 00:33.12 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 00:42.14 | *** join/#oe t0mmy_ (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 00:42.25 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 00:42.46 | khem | Crofton|work: is QT5 on radar for GNURadio ? |
| 00:44.56 | Crofton|work | yes, although much beatin will be required |
| 00:46.54 | khem | ok |
| 00:49.01 | bluelightning | khem: "it look like put all junk here" - well, that is kind of what we've been doing with meta-oe... |
| 00:49.37 | khem | bluelightning: do you mean meta-oe ? |
| 00:49.54 | khem | meta-openembedded as repo is well organised |
| 00:50.17 | bluelightning | I meant meta-oe the layer |
| 00:50.19 | khem | ideally meta-oe should dissipate into other layers |
| 00:50.31 | khem | I agree |
| 00:50.45 | bluelightning | yep, that would be the preferred outcome for me as well |
| 00:50.58 | bluelightning | obviously it's hard to find categories for everything (and interested maintainers) |
| 00:51.13 | khem | however, its work |
| 00:51.17 | Crofton|work | but meta-qt4 shoudl go away at some point |
| 00:51.35 | Crofton|work | at least in my case :0 |
| 00:52.02 | Crofton|work | the end game is layers with one recipes, which we want to avoid |
| 00:52.50 | bluelightning | if you were to go to the point of absurdity yes ;) |
| 00:53.06 | bluelightning | but that wouldn't make any sense |
| 00:53.44 | Crofton|work | :) |
| 00:56.04 | khem | Crofton|work: there always will be overrides |
| 00:56.30 | khem | its understood you dont want to parse 700 new recipes to get 1 into your project |
| 00:56.36 | *** join/#oe t0mmy_ (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 01:17.02 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 01:29.52 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 01:30.24 | khem | bluelightning: I am trying to test out devtool workflow as a novice :) |
| 01:30.37 | bluelightning | khem: great - how is that going? |
| 01:31.10 | khem | bluelightning: so here is what I did |
| 01:31.12 | khem | devtool create-workspace ~/hacking |
| 01:31.26 | khem | devtool status |
| 01:31.39 | khem | NOTE: No recipes currently in your workspace - you can use "devtool modify" to work on an existing recipe or "devtool add" to add a new one |
| 01:31.46 | khem | devtool modify fbset |
| 01:31.54 | khem | ERROR: directory /home/ubuntu/hacking/sources/fbset does not exist or not a directory (specify -x to extract source from recipe) |
| 01:32.21 | khem | so there seems to be a inconsistency |
| 01:32.28 | khem | in what Note says |
| 01:32.58 | khem | it should also include extract step somewhere |
| 01:33.01 | bluelightning | devtool modify expects source to exist already, unless you use -x (which you need to in this case) |
| 01:33.15 | bluelightning | upon reflection I think I should have made that the default behaviour |
| 01:33.35 | khem | exactly my point |
| 01:35.04 | khem | it should check if src is not extracted |
| 01:35.12 | khem | the do so |
| 01:35.38 | bluelightning | also, FYI, no need to use devtool create-workspace unless you don't like the default path |
| 01:36.23 | khem | bluelightning: yes, I am playing proxy on behalf of others :) |
| 01:36.42 | khem | I have made changes using devtool in past with no issues |
| 01:37.22 | bluelightning | ah ok I see |
| 01:37.42 | bluelightning | so beyond changing the default behaviour of devtool modify do you have other suggestions? |
| 01:37.48 | khem | so once I set up with -x say |
| 01:38.07 | khem | the I can use bitbake or devtool to orchestrate the build right ? |
| 01:38.55 | bluelightning | yes |
| 01:41.10 | khem | another small issue I see is that temp/ folder is still in TMPDIR |
| 01:41.33 | khem | if now I have to look at compile logs |
| 01:42.38 | khem | so I can not cd into the newly set workspace and find everything in there |
| 01:43.16 | bluelightning | hmm, ok... we could set up some symlinks |
| 01:44.30 | kergoth | I'd like to see externalsrc move WORKDIR or T relative to S :) |
| 01:44.37 | kergoth | in general, for devtool & otherwise |
| 01:48.04 | bluelightning | if we're going to move anything we might as well move the WORKDIR I suppose |
| 01:49.20 | khem` | no may be just symlink it |
| 01:50.20 | khem` | the run.do_* script are independent of where they are run |
| 01:54.25 | khem | bluelightning: another nice-to-have would be to not require <recipe name> in all cmds if there is only 1 package being worked-on |
| 01:54.42 | khem | or something like devtool workon <recipe> cmd |
| 01:55.13 | khem | and then devtool would insert the <recipe-name> whereever its required |
| 01:56.26 | bluelightning | hmm... possibly; I wouldn't want people to get confused about the context they were in though |
| 01:57.09 | bluelightning | I can appreciate typing it out every time is tedious |
| 01:57.28 | bluelightning | I was hoping to alleviate that through bash completion - there is a bug open to implement that |
| 01:57.28 | kergoth | If you want something like that, I'd add an env var it obeys, and possibly add a sourced shell script to provide functions to manipuate it |
| 01:57.35 | kergoth | not unlike virtualenv and pyenv and the like |
| 01:57.42 | kergoth | shrugs |
| 01:58.00 | kergoth | then the context could be easily added to the prompt |
| 01:58.15 | bluelightning | that would be another alternative yes |
| 01:59.09 | kergoth | could add an env var to recipetool for the layer too, that's another case where you have to keep passing it even if you're doing all your work in your own layer |
| 01:59.18 | kergoth | end up with a lot of positional arguments |
| 02:03.30 | khem | bluelightning: another nice-to-have is that when we use update-recipe, then it should prioritize PN-PV recipe |
| 02:03.50 | khem | err I mean PN-PV dir to house patch over PN |
| 02:04.36 | bluelightning | I guess I went with convention on that one, we tend to use PN more often than PN-PV |
| 02:04.49 | bluelightning | some of these things could also be implemented as a config file option |
| 02:05.04 | bluelightning | just depends on whether it's preference vs. the right behaviour |
| 02:05.45 | khem | bluelightning: I guess its not must |
| 02:06.01 | khem | since its placing a patch in a valid dir anyway |
| 02:06.18 | khem | and usually we have 1 version of packages now a days |
| 02:06.22 | bluelightning | I did think about perhaps looking at where most of the existing files in SRC_URI were and using that dir instead of always using PN |
| 02:06.23 | khem | so not a big deal |
| 02:06.58 | khem | bluelightning: there seems to be no general logic that can be cleanly assumed |
| 02:07.09 | bluelightning | unfortunately not in this case |
| 02:07.38 | bluelightning | I'm all for making the tools smarter where there is though, naturally |
| 02:09.20 | khem | someone should write a frontend to drive devtool from eclipse :) |
| 02:10.02 | bluelightning | it's definitely been discussed, I'm not sure when it will happen, but it's on the cards |
| 02:10.48 | bluelightning | at least, some folks here at Intel would like to see it implemented |
| 02:11.46 | *** join/#oe darkschneider (~gab@93-32-51-166.ip32.fastwebnet.it) |
| 02:13.04 | khem | bluelightning: when doing recipe-update it would also be nice to emit a note saying that you are still plugged into externalsrc if you are done then do something |
| 02:13.54 | bluelightning | right yes, at the back of my mind I've been a little bit uncomfortable with how it leaves you at that point |
| 02:15.13 | khem | and sync cmd bails our without srctree mentioned on cmdline |
| 02:15.28 | khem | that could be changed to default to workspace |
| 02:15.45 | bluelightning | yes, sync was a bit loosely implemented |
| 02:16.23 | khem | think of recipes with no patches for OE |
| 02:16.26 | bluelightning | it has to do with whether or not it's supposed to be used with recipes in the workspace... it wasn't firmly decided |
| 02:16.28 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 02:17.00 | khem | may be sync-src |
| 02:17.00 | bluelightning | there's also the issue of devtool update-recipe after devtool-add... it works just fine, but unlike with the devtool modify the recipe is still in the workspace and you need to do another step to move it out to your own layer, you can't just do devtool reset at that point |
| 02:17.04 | khem | is better option |
| 02:17.22 | kergoth | Slightly OT, but I was thinking earlier about adding a recipetool option or command to create a recipe with no source specified -- that is, just write a template to the layer and let me edit it, a recipe equivalent of newappend, would that be of use to anyone? |
| 02:18.43 | khem | kergoth: what does it buy ? |
| 02:18.53 | bluelightning | not sure... I can't see myself using such a thing - I'd rather have the tool fill in as much as it can, even if that only amounts to LIC_FILES_CHKSUM it's saved me some work |
| 02:21.24 | khem | bluelightning: I will play with upgrade cmd tomorrow |
| 02:21.49 | bluelightning | khem: ok... I haven't had a lot of feedback on it so I don't know how many people have used it up to now |
| 02:23.49 | khem | bluelightning: undeploy-target and deploy-target will undeploy-target recover the old versions ? |
| 02:24.00 | bluelightning | I'm afraid not |
| 02:24.13 | khem | hmm then whats the purpose of this option |
| 02:24.50 | bluelightning | removing all traces of files it deployed |
| 02:25.13 | khem | so say I am debugging fbset |
| 02:25.24 | khem | and I deployed the one I built with my changes |
| 02:25.30 | khem | it worked ok |
| 02:25.36 | khem | and I undeployed it |
| 02:25.45 | khem | now it fbset gone from target ? |
| 02:25.48 | bluelightning | yep |
| 02:25.52 | bluelightning | if we were to implement a solution that did so wouldn't you need to keep a stack of old files rather than just one set, assuming that you can repeatedly deploy? |
| 02:26.07 | khem | hmm |
| 02:26.20 | bluelightning | maybe not, maybe we just keep the first set |
| 02:26.32 | khem | so undeploy should be masked then since it will leave the target in bad state |
| 02:26.43 | bluelightning | masked how? |
| 02:26.59 | khem | thinking of a lab scenario |
| 02:27.27 | khem | a target may be used by more than 1 developer or same dev debugging two different problems |
| 02:28.00 | khem | bluelightning: do not remove the packages from target |
| 02:28.07 | khem | when undeploy is done |
| 02:28.31 | bluelightning | undeploy wouldn't do anything then |
| 02:28.43 | bluelightning | if it's to put anything back there needs to be something to actually put back |
| 02:29.06 | bluelightning | I'm all for improving this but we need to come up with behaviour that practically works |
| 02:29.57 | khem | so it should create a overlay |
| 02:30.08 | khem | during deploy |
| 02:30.20 | khem | anyfile its replacing. Make a copy of it |
| 02:30.29 | khem | may be in same folder tree |
| 02:30.32 | khem | structure |
| 02:30.41 | khem | say under /devtool/ |
| 02:30.47 | bluelightning | what if space is at a premium on the device? |
| 02:30.47 | khem | on rootfs |
| 02:31.26 | bluelightning | I guess we would have to check space first and complain, and provide an option to not preserve |
| 02:31.34 | khem | yeah |
| 02:35.29 | khem | you need that anyway |
| 02:35.36 | khem | because new binary may be bigger in size |
| 02:35.46 | khem | or bigger due to debug info being not stripped |
| 02:35.48 | khem | and so on |
| 02:37.21 | kergoth | khem: primarily recipes which are either meta or which provide scripts, and therefore have no external sources to analyze |
| 02:37.29 | kergoth | but admittedly that might not be that common a case |
| 02:38.44 | khem | kergoth: right |
| 02:52.06 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 02:59.32 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 03:51.41 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 04:06.54 | *** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net) |
| 04:09.47 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 04:25.55 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 04:57.11 | *** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net) |
| 05:28.39 | *** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net) |
| 05:42.17 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 06:35.03 | *** join/#oe noobkit (~Nerazim@77.30.201.223) |
| 07:45.37 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:46.08 | *** join/#oe stefan_schmidt (~stefan@pD9F785F3.dip0.t-ipconnect.de) |
| 07:52.16 | *** join/#oe joshuagl (~joshuagl@192.198.151.45) |
| 07:53.42 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-jufexmceotlfuzwn) |
| 07:56.59 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 08:03.01 | *** join/#oe joshuagl (~joshuagl@192.198.151.43) |
| 08:12.09 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 08:14.06 | *** join/#oe belen (~Adium@134.134.139.76) |
| 08:16.27 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 08:16.50 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:32.24 | *** join/#oe belen (~Adium@134.134.139.76) |
| 08:33.38 | *** join/#oe ant_work (~ant__@host17-63-dynamic.24-79-r.retail.telecomitalia.it) |
| 08:36.05 | *** join/#oe jku (jku@nat/intel/x-krktnclbeocuvdhn) |
| 08:42.43 | *** join/#oe belen (~Adium@134.134.139.76) |
| 08:53.40 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 09:05.29 | *** join/#oe morphis (~morphis@2001:67c:1560:a003:2018:f74e:e655:ad68) |
| 09:06.04 | *** join/#oe maxin1 (~maxin@2001:998:22:0:19b8:ad81:2e33:ee57) |
| 09:09.06 | *** join/#oe joshuagl (joshuagl@nat/intel/x-ontdxrqjcafkpadh) |
| 09:13.18 | *** join/#oe belen (~Adium@134.134.139.76) |
| 09:27.41 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:30.06 | *** join/#oe felipe (~felipe@81.145.202.106) |
| 09:45.04 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 09:45.33 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 09:47.10 | *** join/#oe morphis (~morphis@2001:67c:1560:a003:2018:f74e:e655:ad68) |
| 09:48.36 | *** join/#oe captainigloo (~captainig@ks389014.kimsufi.com) |
| 10:11.16 | *** join/#oe belen (~Adium@134.134.139.72) |
| 10:27.10 | *** join/#oe fray (~mhatle@192.40.192.95) |
| 10:30.08 | *** join/#oe ldnunes (~ldnunes_@177.127.4.194) |
| 10:36.41 | *** join/#oe joshuagl (joshuagl@nat/intel/x-upcislsmywxtjtfm) |
| 10:38.43 | *** join/#oe berton (~fabio@177.127.4.194) |
| 10:49.01 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 11:03.35 | *** join/#oe morphis (morphis@nat/canonical/x-qbcxbrsbykkjsuqf) |
| 11:03.59 | *** join/#oe belen (Adium@nat/intel/x-aevwngutolomopyt) |
| 11:19.38 | *** join/#oe edbart (~ebartosh@192.198.151.44) |
| 11:39.50 | *** join/#oe edbart1 (~ebartosh@192.198.151.44) |
| 11:48.07 | *** join/#oe belen1 (Adium@nat/intel/x-odhqnsbpqjvllpjz) |
| 11:57.13 | *** join/#oe belen (~Adium@134.134.139.74) |
| 12:05.47 | *** join/#oe joshuagl (~joshuagl@192.198.151.44) |
| 12:29.41 | *** join/#oe tsramos (~tsramos@192.55.55.37) |
| 12:40.22 | *** join/#oe joshuagl (joshuagl@nat/intel/x-ttqcifzfuqghpqvi) |
| 13:08.17 | *** join/#oe edbart (ebartosh@nat/intel/x-bcxqlymgqtposqdo) |
| 13:18.00 | *** join/#oe morphis (~morphis@2001:67c:1560:a003:c49c:aae2:5de0:43c0) |
| 13:23.34 | Crofton|work | http://lists.openembedded.org/pipermail/openembedded-devel/2016-January/105305.html |
| 13:23.46 | Crofton|work | Ah, that is why I missed the fail email :) |
| 13:32.34 | JaMa | why? |
| 13:33.01 | Crofton|work | no RE: so likely eye parsing didn't see it |
| 13:33.12 | Crofton|work | no worries |
| 13:33.23 | JaMa | pipermail doesn't show re: |
| 13:33.45 | Crofton|work | good point |
| 13:33.54 | Crofton|work | welll, something was broken with my brain |
| 13:34.07 | JaMa | but it was sent with re: and correct Reply-To: |
| 13:34.34 | JaMa | http://patchwork.openembedded.org/patch/110603/ |
| 13:34.39 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 13:34.50 | JaMa | https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg45732.html |
| 13:35.43 | JaMa | passed sanity check :P |
| 13:36.01 | Crofton|work | :) |
| 13:41.51 | *** join/#oe noobkit (~Nerazim@77.30.201.223) |
| 13:48.45 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 13:56.03 | *** join/#oe jonathanmaw_ (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 13:57.33 | mago__ | since i moved to jethro and the 1.28 bitbake, i'm getting SSL: CERTIFICATE_VERIFY_FAILED during fetch for a recipe that worked fine in Fido. Did the fetcher get more strict in jethro? If I look at the URL in my browser, it seem to think the certificate is OK (it's from bitbucket.org) |
| 13:58.06 | *** join/#oe joshuagl (~joshuagl@192.198.151.43) |
| 14:04.25 | *** join/#oe edbart1 (ebartosh@nat/intel/x-iknclitmqaoziqft) |
| 14:09.05 | JaMa | mago__: I get the same with https://github.com, but IIRC it was using hosts wget which was more strict not bitbake fetcher |
| 14:09.59 | JaMa | does it show: OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure |
| 14:10.05 | JaMa | when ? |
| 14:14.44 | Crofton|work | ah |
| 14:14.51 | Crofton|work | I need to build qt5 :) |
| 14:16.44 | JaMa | welcome to the club |
| 14:16.58 | JaMa | hot cpus for free! |
| 14:17.00 | Crofton|work | is it in core now? |
| 14:17.10 | JaMa | nope and won't be |
| 14:17.14 | Crofton|work | I can't see the thrift issue |
| 14:17.28 | JaMa | did you build qtbase before thrift? |
| 14:17.41 | JaMa | if not, then it can hardly autodetect it :) |
| 14:17.46 | Crofton|work | I ahve qt4 stuff around |
| 14:17.51 | Crofton|work | yeah |
| 14:18.07 | Crofton|work | need to hun t around |
| 14:18.24 | JaMa | isn't there disable knob like for qt4? |
| 14:18.55 | JaMa | I'm willing to run it through jenkins for you to test it if you add the disable |
| 14:19.27 | Crofton|work | yeah, that is what I am hunting |
| 14:20.10 | JaMa | I'm trying to fetch linux-yocto-4.4 today.. yesterday I run out of patience after 8 hours |
| 14:21.25 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 14:29.00 | Crofton|work | THis is new? |
| 14:29.02 | Crofton|work | WARNING: QA Issue: thrift rdepends on glib-2.0, but it isn't a build dependency? [build-deps] |
| 14:29.52 | JaMa | dunno as i haven't compiled it at all |
| 14:35.11 | paulbarker | Is the daisy branch still taking backport requests or am I a bit too far behind the times? |
| 14:35.47 | Crofton|work | paulbarker, best bet is email maintainers |
| 14:36.14 | paulbarker | Crofton|work: will do |
| 14:41.42 | JaMa | paulbarker: safe changes already applied in newer releases should be approved |
| 14:41.56 | JaMa | but you're too far behind for sure :) |
| 14:43.29 | paulbarker | We were on dylan until about a week ago. Unfortunately daisy is the most recent branch we can move to due to $VENDOR |
| 14:43.58 | paulbarker | Hopefully fido at some point in the next few months |
| 14:45.53 | Crofton|work | JaMa, georgem is asking about his bash completion patches, how can we check on them? |
| 14:45.59 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 14:46.43 | Crofton|work | georgem, they are still new here: http://patchwork.openembedded.org/project/oe/list/ |
| 14:46.59 | Crofton|work | ah marked RFC |
| 14:47.04 | georgem | Crofton|work, thanks |
| 14:47.27 | Crofton|work | they should be harmless changes? |
| 14:48.50 | JaMa | Crofton|work: georgem: lets see how oe-core will react, I'm fine with this part for meta-oe |
| 14:49.27 | georgem | Crofton|work, JaMa. pretty much but I figured it might be good to put a little collective thought into it. Right now bash-completion subpackages vary by recipe as to what they RDEPEND. I figured a brief discussion on whether RDEPENDS on bash-completion was correct was in order. |
| 14:49.32 | JaMa | paulbarker: I feel your pain, we were on dylan also until few months ago when we upgraded to dizzy |
| 14:50.35 | georgem | If you think it's fine then they should be fine to accept |
| 14:53.12 | georgem | No rush, it just seemed maybe it was going to fall through the cracks. |
| 14:53.48 | Crofton|work | georgem, crack falling is an issue |
| 14:54.14 | Crofton|work | there should be a patchwork talk at fosdem, so that will be interesting |
| 14:54.20 | georgem | cool |
| 14:59.52 | georgem | mdp, I know that was probably a troll but thanks for the link anyway I watched the entire video. Fortunately I think I already maintain a healthy level of paranoia and OCD over what I send to mailing lists :) |
| 15:00.31 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 15:03.44 | *** join/#oe noobkit (~Nerazim@77.30.201.223) |
| 15:04.31 | mago__ | JaMa: no, my error is slightly different, it says: abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) |
| 15:10.39 | JaMa | did you change wget version on your host? |
| 15:10.44 | JaMa | it's worth trying to upgrade it |
| 15:14.26 | *** join/#oe paulg (~paulg@128.224.252.2) |
| 15:15.53 | *** join/#oe belen (~Adium@134.134.139.76) |
| 15:16.19 | *** join/#oe mago_ (~mago@88.131.56.168) |
| 15:22.25 | *** join/#oe edbart (~ebartosh@192.198.151.43) |
| 15:22.53 | *** join/#oe belen (~Adium@134.134.139.72) |
| 15:38.13 | mago_ | how do i know what logdomains i can pass to bitbake --log-domains? i want to enable logger.debug() output for lib/bb/fetch2/__init__.py |
| 15:40.03 | Crofton|work | thriftv3 sent, disables QT5 (I hope) and fixes QA warning |
| 15:54.08 | kergoth | mago_: i think you just need to look at the logging.getLogger() lines in the source |
| 15:54.14 | mago_ | oh, there's bitbake -D *facepalm* |
| 15:54.27 | kergoth | -D is extremely verbose, though, since it's all logging domians |
| 15:54.40 | kergoth | that said, i'm not sure --log-domains even works properly anymore, i doubt it gets much use |
| 15:55.12 | mago_ | okay, i tried looking in the bitbake manual but it never mentions --log-domains except in the copy of bitbake --help |
| 15:59.52 | *** join/#oe morphis (~morphis@2001:67c:1560:8007::aac:c152) |
| 16:51.35 | *** join/#oe bluelightning (~paul@2406:e007:44a7:1:5e51:4fff:febb:401d) |
| 16:51.36 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 16:55.12 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 17:00.24 | mago_ | is there a way to replace one item in SRC_URI using an override, without ruining the rest of SRC_URI? |
| 17:00.32 | mago_ | (using a bbappend) |
| 17:00.44 | kergoth | not with an override, no, but you could do it programmatically with anonymous python |
| 17:01.21 | kergoth | i.e. python () { src_uri = d.getVar("SRC_URI", True).replace("http://foo", "http://bar"); d.setVar("SRC_URI", " ".join(src_uri)) } or something |
| 17:01.42 | mago_ | ah, great. And all anonymous functions run before bitbake considers variable values? |
| 17:02.13 | kergoth | they're run at the end of parsing, which is before any tasks are run or scheduled or anything |
| 17:02.26 | kergoth | you could use an override to *remove* something from SRC_URI, and then use that override as well to append it, but of course that would change the SRC_URI ordering. if taht's okay, you could do that instead |
| 17:02.50 | mago_ | ah, that will work also. |
| 17:02.52 | mago_ | thanks |
| 17:03.01 | kergoth | np |
| 17:27.39 | rburton | should we replace udev 182 with eudev? |
| 17:33.22 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 17:40.23 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 17:44.18 | JaMa | yey, linux-yocto-4.4.git fetched and it took only 2 days! |
| 17:44.55 | bencoh | :D |
| 17:44.56 | JaMa | wondering why it's twice as big as other linux-yocto repos |
| 17:44.57 | JaMa | 986964 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-3.19.git |
| 17:44.57 | JaMa | 1022940 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.1.git |
| 17:44.57 | JaMa | 1269560 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-dev.git |
| 17:44.57 | JaMa | 2382760 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.4.git |
| 17:58.46 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 17:58.48 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 18:00.37 | *** join/#oe belen (~Adium@134.134.139.77) |
| 18:02.37 | khem` | JaMa: that sounds a bit too big |
| 18:02.48 | khem` | I wonder what changed |
| 18:02.59 | khem` | zeddii must be informed |
| 18:06.58 | Crofton|work | he is Canadian, so he will be polite about it |
| 18:15.15 | *** join/#oe darkschneider (~gab@93-32-51-166.ip32.fastwebnet.it) |
| 18:15.32 | bluelightning | what about those cross canadians though? |
| 18:15.35 | bluelightning | ducks |
| 18:25.27 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 18:26.17 | Crofton|work | lols |
| 18:26.55 | Crofton|work | the good thing about those people that only hang in #yocto is we can make fun of them here |
| 18:31.46 | *** join/#oe maxin1 (~maxin@dsl-espbrasgw1-50de2e-158.dhcp.inet.fi) |
| 18:36.18 | *** join/#oe abelloni (~abelloni@2a01:e35:8bf1:a7c0:a288:b4ff:fe25:8918) |
| 18:41.16 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 18:51.33 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:05.04 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 19:22.22 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 19:41.52 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 19:43.25 | *** join/#oe paulg_ (~paulg@209.29.74.150) |
| 19:48.17 | *** join/#oe tsramos (~tsramos@134.134.139.70) |
| 19:54.34 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 19:56.25 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 19:59.56 | *** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-hhpbdlznjzlowdal) |
| 20:22.00 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 20:34.57 | *** join/#oe morphis (~morphis@5.148.53.5) |
| 20:42.15 | *** join/#oe RagBal (~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 20:42.50 | *** join/#oe Rootert (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 21:04.41 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 21:16.09 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 21:24.47 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 21:31.30 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 21:32.47 | wmat | Crofton|work: hey now, stop teasing the canadians ;) |
| 21:36.54 | *** join/#oe maxin1 (~maxin@dsl-espbrasgw1-50de2e-158.dhcp.inet.fi) |
| 21:39.28 | *** join/#oe ohama (ohama@cicolina.org) |
| 21:55.47 | *** join/#oe jku (~jku@212-149-207-214.bb.dnainternet.fi) |
| 22:06.51 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 22:07.02 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 22:20.10 | *** join/#oe bluelightning_ (~paul@240.22.255.123.dynamic.snap.net.nz) |
| 22:20.11 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 22:43.32 | rburton | seriously, does anyone have a eudev recipe? |
| 22:43.37 | rburton | or has everyone moved to systemd? |
| 22:45.17 | bluelightning_ | surely it won't have diverged too far from udev, won't our existing recipes be fairly easy to adapt? |
| 22:51.15 | *** join/#oe SoylentYellow (~SoylentYe@207-114-172-147.static.twtelecom.net) |
| 23:02.57 | *** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net) |
| 23:04.06 | *** join/#oe ant_home (~ant__@host48-23-dynamic.14-87-r.retail.telecomitalia.it) |