**** BEGIN LOGGING AT Tue Jan 19 02:59:58 2016 Jan 19 13:23:35 http://lists.openembedded.org/pipermail/openembedded-devel/2016-January/105305.html Jan 19 13:23:46 Ah, that is why I missed the fail email :) Jan 19 13:32:35 why? Jan 19 13:33:02 no RE: so likely eye parsing didn't see it Jan 19 13:33:12 no worries Jan 19 13:33:23 pipermail doesn't show re: Jan 19 13:33:46 good point Jan 19 13:33:55 welll, something was broken with my brain Jan 19 13:34:07 but it was sent with re: and correct Reply-To: Jan 19 13:34:35 http://patchwork.openembedded.org/patch/110603/ Jan 19 13:34:50 https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg45732.html Jan 19 13:35:44 * JaMa passed sanity check :P Jan 19 13:36:01 :) Jan 19 13:57:34 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) Jan 19 14:09:05 mago__: I get the same with https://github.com, but IIRC it was using hosts wget which was more strict not bitbake fetcher Jan 19 14:09:59 does it show: OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Jan 19 14:10:05 when ? Jan 19 14:14:45 ah Jan 19 14:14:51 I need to build qt5 :) Jan 19 14:16:44 welcome to the club Jan 19 14:16:59 hot cpus for free! Jan 19 14:17:01 is it in core now? Jan 19 14:17:10 nope and won't be Jan 19 14:17:14 I can't see the thrift issue Jan 19 14:17:28 did you build qtbase before thrift? Jan 19 14:17:41 if not, then it can hardly autodetect it :) Jan 19 14:17:46 I ahve qt4 stuff around Jan 19 14:17:51 yeah Jan 19 14:18:07 need to hun t around Jan 19 14:18:25 isn't there disable knob like for qt4? Jan 19 14:18:55 I'm willing to run it through jenkins for you to test it if you add the disable Jan 19 14:19:27 yeah, that is what I am hunting Jan 19 14:20:11 I'm trying to fetch linux-yocto-4.4 today.. yesterday I run out of patience after 8 hours Jan 19 14:29:00 THis is new? Jan 19 14:29:02 WARNING: QA Issue: thrift rdepends on glib-2.0, but it isn't a build dependency? [build-deps] Jan 19 14:29:52 dunno as i haven't compiled it at all Jan 19 14:35:12 Is the daisy branch still taking backport requests or am I a bit too far behind the times? Jan 19 14:35:47 paulbarker, best bet is email maintainers Jan 19 14:36:15 Crofton|work: will do Jan 19 14:41:43 paulbarker: safe changes already applied in newer releases should be approved Jan 19 14:41:56 but you're too far behind for sure :) Jan 19 14:43:29 We were on dylan until about a week ago. Unfortunately daisy is the most recent branch we can move to due to $VENDOR Jan 19 14:43:58 Hopefully fido at some point in the next few months Jan 19 14:45:53 JaMa, georgem is asking about his bash completion patches, how can we check on them? Jan 19 14:46:43 georgem, they are still new here: http://patchwork.openembedded.org/project/oe/list/ Jan 19 14:46:59 ah marked RFC Jan 19 14:47:04 Crofton|work, thanks Jan 19 14:47:27 they should be harmless changes? Jan 19 14:48:51 Crofton|work: georgem: lets see how oe-core will react, I'm fine with this part for meta-oe Jan 19 14:49:27 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. Jan 19 14:49:32 paulbarker: I feel your pain, we were on dylan also until few months ago when we upgraded to dizzy Jan 19 14:50:34 If you think it's fine then they should be fine to accept Jan 19 14:53:11 No rush, it just seemed maybe it was going to fall through the cracks. Jan 19 14:53:48 georgem, crack falling is an issue Jan 19 14:54:14 there should be a patchwork talk at fosdem, so that will be interesting Jan 19 14:54:20 cool Jan 19 14:59:52 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 :) Jan 19 15:04:31 JaMa: no, my error is slightly different, it says: abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Jan 19 15:10:39 did you change wget version on your host? Jan 19 15:10:44 it's worth trying to upgrade it Jan 19 15:38:14 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 Jan 19 15:40:03 thriftv3 sent, disables QT5 (I hope) and fixes QA warning Jan 19 15:54:09 mago_: i think you just need to look at the logging.getLogger() lines in the source Jan 19 15:54:14 oh, there's bitbake -D *facepalm* Jan 19 15:54:27 -D is extremely verbose, though, since it's all logging domians Jan 19 15:54:40 that said, i'm not sure --log-domains even works properly anymore, i doubt it gets much use Jan 19 15:55:12 okay, i tried looking in the bitbake manual but it never mentions --log-domains except in the copy of bitbake --help Jan 19 17:00:24 is there a way to replace one item in SRC_URI using an override, without ruining the rest of SRC_URI? Jan 19 17:00:32 (using a bbappend) Jan 19 17:00:44 not with an override, no, but you could do it programmatically with anonymous python Jan 19 17:01:21 i.e. python () { src_uri = d.getVar("SRC_URI", True).replace("http://foo", "http://bar"); d.setVar("SRC_URI", " ".join(src_uri)) } or something Jan 19 17:01:42 ah, great. And all anonymous functions run before bitbake considers variable values? Jan 19 17:02:13 they're run at the end of parsing, which is before any tasks are run or scheduled or anything Jan 19 17:02:26 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 Jan 19 17:02:50 ah, that will work also. Jan 19 17:02:52 thanks Jan 19 17:03:02 np Jan 19 17:27:39 should we replace udev 182 with eudev? Jan 19 17:44:18 yey, linux-yocto-4.4.git fetched and it took only 2 days! Jan 19 17:44:56 :D Jan 19 17:44:56 * JaMa wondering why it's twice as big as other linux-yocto repos Jan 19 17:44:57 986964 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-3.19.git Jan 19 17:44:58 1022940 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.1.git Jan 19 17:44:58 1269560 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-dev.git Jan 19 17:44:58 2382760 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.4.git Jan 19 18:02:37 JaMa: that sounds a bit too big Jan 19 18:02:49 I wonder what changed Jan 19 18:02:59 zeddii must be informed Jan 19 18:06:58 he is Canadian, so he will be polite about it Jan 19 18:15:32 what about those cross canadians though? Jan 19 18:15:36 * bluelightning ducks Jan 19 18:26:18 lols Jan 19 18:26:55 the good thing about those people that only hang in #yocto is we can make fun of them here Jan 19 21:32:48 Crofton|work: hey now, stop teasing the canadians ;) Jan 19 22:43:32 seriously, does anyone have a eudev recipe? Jan 19 22:43:37 or has everyone moved to systemd? Jan 19 22:45:17 surely it won't have diverged too far from udev, won't our existing recipes be fairly easy to adapt? **** ENDING LOGGING AT Wed Jan 20 02:59:59 2016