**** BEGIN LOGGING AT Wed Jun 19 02:59:57 2019 Jun 19 05:27:11 <__dan> Hi guys. Two questions please: It is not immediately obvious to me from yocto web pages if (1) yocto can build package variants from the same recipe, for example firefox and firefox-wayland and and if it supports subpacakges (ex: mylib package and mylib devel ) Jun 19 05:31:01 __dan: variants of a package are possible, yet not at the same time (we call that PACKAGECONFIGS), and having a recipe produce multiple packages is even the default (its called package splitting) Jun 19 05:33:41 <__dan> LetoThe2nd: Thank you. Please, what do you mean with "at the same time". Not possible to have them installed in the image in the same time, or impossible to generate 2 binary variant packages ? Jun 19 05:36:05 __dan: hum. you better start out be defining what you mean by "variants" then. Jun 19 05:39:40 __dan: the key thing to understand is: one(1!) recipe basically compiles one(1!) upstream source tree and packages is. so, if you want the source to be compiled twice (2x!) for one specific distribution, you would technically need two distinct recipes - which on the other hand could probably share a lot through an include or such Jun 19 05:39:54 <__dan> LetoThe2nd: Having one recipe wich generates 2 packages for the same utility, with wildly different compilation / linking flags. Having the system use only one recipe greatly lessens mentenance of the recipe/port in cause. Most frameworks deal with this having 2 or more rexipes/ports , and while it works, you have to remember to maintain all the variants . In my contried forefox example, 2 packages of Jun 19 05:40:00 <__dan> firefox are generated , one supporting X and one Xorg Jun 19 05:40:02 <__dan> sorry wayland Jun 19 05:40:54 __dan: the point is, does it actually make sense to have all this available *at the same time*, in the same generated image? in that case, you need two recipes Jun 19 05:41:33 in that case, factor out all commons into an include. primetime example here is gcc Jun 19 05:41:38 <__dan> thanks Jun 19 05:42:26 yet if you only need two wildly different configurations for distinct images, then its packageconfigs. those are meant to do exactly that: set wildly varying compilation flags. Jun 19 05:42:27 <__dan> that would work from netenance pov , and thats why im interesting in. Jun 19 05:42:50 <__dan> I apreciate your time Jun 19 05:42:55 <__dan> thak you Jun 19 05:43:21 have fun Jun 19 05:44:08 <__dan> Yes, I dont need them pn the same image. Jun 19 05:44:20 <__dan> got the ideea Jun 19 10:53:07 I have wrote one bb recipe to fetch some nodejs packages, I have only one rule just copy some files. No compilation required. S = "${WORKDIR}/node-gyp-${PV}" followed by do_install { cp -R ${S}/* ${D}{libdir} }. Variable S and D points to same directory. How to make sure D points only to target rootfs. Jun 19 11:10:39 kanavin: sounds like alimon is having 'fun' with the change to cmake in apt 1.4.X, not sure if you have any insight there? Jun 19 11:10:59 (bug #13398) Jun 19 11:11:00 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13398 normal, Medium+, 2.8 M2, limon.anibal, NEW , apt, apt-native should be upgraded to 1.8.2 Jun 19 11:45:01 rburton: getting gd-pixbuf and glib-2.0 ptest failures again: https://autobuilder.yocto.io/pub/non-release/20190618-9/testresults/testresult-report.txt Jun 19 11:45:21 i think i fixed a glib one yesterday, lets see if its on that list Jun 19 11:45:54 still getting nonsense like ptestresult.python3.test_doctest_main_issue4197__test.test_zipimport_support.ZipSupportTests__..._Expected_line_File_"/var/volatile/tmp/tmpewgso1a5/script.py",_line_2,_in___main__.Test in the report :( Jun 19 11:46:44 if you have a setup ready to go, try picking glib-2.0: fix host path appearing in gsocketclient-slow test script Jun 19 11:47:04 rburton: I'll include it in the next test run, thanks Jun 19 11:47:33 rburton: nobody has filed a bug for that nonsense :( Jun 19 11:48:28 hm thought i did Jun 19 11:48:39 because i root-caused where it was coming from Jun 19 11:48:46 nuts Jun 19 11:48:47 The dbus test failure "ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device" is odd :/ Jun 19 11:50:50 RP: #13408 Jun 19 11:51:07 rburton: thanks Jun 19 11:51:08 remind me how to get the full console log of that ptest run and i'll chase down the exact situation again Jun 19 11:51:21 * RP filed 13049 for dbus timeout Jun 19 11:51:48 rburton: look in the directory for that report Jun 19 11:51:56 rburton: click on /qemux86-64-ptest/ then the log Jun 19 11:52:07 thanks Jun 19 11:52:16 argh mime type isn't text/* Jun 19 11:52:40 rburton: file a bug for halstead, bet we could fix that Jun 19 11:53:01 * RP shrugs, at least there are logs :) Jun 19 11:53:11 yeah having the logs is great Jun 19 11:53:18 mine type is just useful Jun 19 11:53:26 one step at a time Jun 19 11:54:21 sure Jun 19 12:10:59 the py fails are false positives, the matching is bad Jun 19 12:11:10 to be fair the output is terrible Jun 19 12:11:36 we should run the tests in -w Jun 19 12:11:47 hm i think i sent a patch for that, which broke something else Jun 19 12:12:08 shall try again Jun 19 12:16:49 rburton: right, we had to revert that Jun 19 12:17:06 probaby because -w output is entirely diffeerent to -w Jun 19 12:17:11 erm, one of those should be -v Jun 19 12:17:42 rburton: I think we ended up with no pass/fail info, so yes Jun 19 12:17:49 happy to have a working patch :) Jun 19 12:20:04 pass/fail is overrated ;) Jun 19 12:23:29 RP: where is the code that parses a line like "FAIL: foo bar"? Jun 19 12:23:40 resulttool? Jun 19 12:32:28 so i obviously don't understand this piece enough Jun 19 12:33:03 python3's run-ptest run the test suite and turns log output to PASS: foo or FAIL: foo Jun 19 12:33:14 then something happens Jun 19 12:33:55 and then we get resulttool saying ptestresult.python3.test_doctest_main_issue4197__test.test_zipimport_support.ZipSupportTests__..._Expected_line_File_"/var/volatile/tmp/tmpewgso1a5/script.py",_line_2,_in___main__.Test Jun 19 12:34:14 where is the parsing happening? Jun 19 12:37:04 rburton: lib/oeqa/utils/logparser.py Jun 19 12:37:08 rburton: iirc Jun 19 13:06:53 rburton: Ah, I just found that gsocketclient-slow bug in my reproducible testing; thanks for fixing that Jun 19 13:07:44 JPEW: I was wondering if it would help that :) Jun 19 13:12:59 RP: I don't think I'm going to dive into the PGO on python right now (I'd rather get to the point of being able to turn on the QA test); I turned it off for reprodicible builds and raised a bug. Jun 19 13:36:02 JPEW: fair enough Jun 19 15:08:48 does anyone know where bitbake handles FOO_ (with override being one of OVERRIDES)? Jun 19 15:09:05 RP: so the log parse thing is that the log parse does r"FAIL:(.+)" and group(1) is the test name Jun 19 15:09:15 RP: i propose to replace with ^FAIL:([^(]+) Jun 19 15:09:35 stop at the first ( Jun 19 15:12:01 I've discovered a pretty interesting behaviour. When MACHINEOVERRIDES is e.g. "foo:Bar:baz", you can actually do FOO_append_Bar = "meh" but not FOO_Bar = "moo". The latter creates a new variable called FOO_Bar instead of overriding FOO Jun 19 15:12:23 rburton: seems potentially reasonable Jun 19 15:13:05 qschulz: I think overrides need to be lowercase Jun 19 15:13:53 qschulz: you might find lib/bb/tests/data.py interesting Jun 19 15:14:11 qschulz: overrides are handled in lib/bb/data.py and data_smart.py Jun 19 15:14:49 yeah overrides are enforced lowercase now Jun 19 15:15:00 RP: i can send a quick patch, should not break too much Jun 19 15:15:20 rburton: are you going to help clean up the not too much breakage? :) Jun 19 15:15:52 rburton: there isn't going to be much of it ;-) Jun 19 15:16:01 hehe Jun 19 15:16:03 lets see Jun 19 15:16:48 rburton: have you looked over the ptest log and seen how many test results have "(" in? Jun 19 15:17:15 rburton: we can probably quantify this Jun 19 15:18:46 feels like my laptop is about to die again, top patch on mut if you happen to have something to throw it at Jun 19 15:18:54 kanavin: any tips on which of your patches depend on the others. Looks like I can't just revert dnf upgrade Jun 19 15:19:30 if you rip out dnf rip out librepo just in case Jun 19 15:20:21 RP: I think dnf itself is enough, as it needs a newer libdnf, which I am just now confirming (and newer dnf needs not-yet-released version of rpm) Jun 19 15:20:28 *newer libdnf Jun 19 15:20:43 kanavin: I tried dnf, it broke Jun 19 15:21:07 rburton: how come FOO_append_Bar works but not FOO_Bar then? Bar is still not all lowercase :) Jun 19 15:21:08 RP: you tried dropping dnf? Jun 19 15:21:21 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/954 which has dnf dropped, error is non-specific Jun 19 15:21:41 qschulz: bug, the lowercase isn't 100% enforced :/ Jun 19 15:22:44 rburton: my worry is test results becoming merged. Does the code catch two with the same name? Jun 19 15:23:56 This would be less painful if the autobuilder didn't half lock up when I stop builds Jun 19 15:26:19 * RP tries removing librepo too Jun 19 15:27:48 RP: I have to say though that I tested on thud, not master so it might be enforced correctly since then Jun 19 15:28:02 qschulz: I happen to know its not :/ Jun 19 15:28:12 well, strongly suspect Jun 19 15:28:53 RP: that last error is a strange cmake fluke, where it wasn't able to establish the major version of the python interpreter Jun 19 15:29:07 RP: and can't reproduce that here :( Jun 19 15:29:49 kanavin: strange flukes are not my favourite thing today. We'll see how librepo missing does Jun 19 15:33:11 kanavin: tiny went green this time which suggests we're past dnf issues Jun 19 15:34:56 RP: I don't mind deferring the entire dnf stack Jun 19 15:37:09 kanavin: we can try librepo again when you have a fix for the first dnf issue? Jun 19 15:40:52 the first dnf issue is that it needs a newer libdnf. And a newer libdnf needs a version of rpm that is currently in beta. Jun 19 15:40:58 RP: ^ Jun 19 15:41:26 kanavin: ah, right Jun 19 15:41:37 of course dnf wouldn't say that at build time, and fails only at runtime :( my bad for not trying to use it to make an actual image Jun 19 15:42:02 it's basically all fedora's components, and they upgrade them in lockstep more or less Jun 19 15:43:21 kanavin: ok. I can try adding librepo back to another build later Jun 19 15:45:57 RP: sure, apologies for not testing this better. I kind of just took AUH patches :) Jun 19 15:46:05 with dnf that is a risky step Jun 19 15:48:43 kanavin: I think we've been here before too :/ Jun 19 15:49:11 kanavin: its good we're able to track upstreams more closely Jun 19 15:52:05 RP: btw, the newer rpm has my parallelisation work merged :) Jun 19 15:52:24 and they also added parallelisation to other bits of it, not sure if it helps us Jun 19 15:53:04 kanavin: I saw movement on some patches, that is nice to see :) Jun 19 15:53:19 kanavin: very cool and fewer patches to worry about :) Jun 19 15:53:41 kanavin: the perl issue has been fixed upstream so will be dropable in the next point release hopefully too Jun 19 16:00:22 RP: yep, if I have a bit of time, I want to start working on that rpm update Jun 19 16:11:32 hmm, openssh has a missing dependency on libxcrypt Jun 19 16:12:28 raises some questions about indirect dependencies Jun 19 16:53:56 JPEW: that fix makes multiconfig so much more sane speed wise :) Jun 19 17:05:46 #13412 should be an interesting one to fix. Its causing quite a bottleneck in my builds Jun 19 17:29:43 anyone here familiar with the BitBakeServer? Jun 19 17:31:44 it tries to bind a socket to a local file, this will fail if the build tree is on a mounted volume in a virtual machine. Jun 19 17:33:25 bulle112200: I wrote that code... Jun 19 17:33:43 bulle112200: it means that a given build tree is correctly associated with a specific server Jun 19 17:34:25 I guess it could be done a number of ways but that one didn't seem to have any serious drawbacks at the time Jun 19 17:43:19 RP: Ya. I still wish mc parsing was faster when you have *lots* of layers Jun 19 18:20:08 bulle112200: it fails if the mount can't handle sockets. the build directory needs to handle sockets :) Jun 19 18:43:45 hello, I'm trying to use multiconfig, but the variables (like MACHINE) are not used in the build configuration, with bitbake -e I can see that MACHINE is set from the multiconfig file correctly Jun 19 18:43:56 any ideas how to continue debugging this? Jun 19 18:47:01 rburton yes, but I wonder why that is, a parallels mount macos -> ubuntu should support socket afaik Jun 19 19:33:31 bulle112200: try creating a socket and see Jun 19 19:35:39 rburton did it manually and for sure it doesn't work. more of a VM question, but any clues? Jun 19 19:35:56 create a proper file system to do the builds in Jun 19 19:36:11 what would be nice is if bitbake created the socked FD's somewhere else Jun 19 19:36:36 the socket is in the build directory because its a per-build-directory service Jun 19 19:45:57 i guess we could hash the build path and stash the socket in /var/run/bitbake.pathhash or something Jun 19 20:00:46 I think that would be great as it simplifies when running builds in VM's, docker, vagrant and such Jun 19 20:01:53 personally I don't want my VM to have any keys, git configs etc. I run this from my Mac, then only expose what's needed to the linux build image by mounting the relevant directory that wants to be built Jun 19 20:35:04 RP: ^ thoughts? Jun 19 20:35:36 then again every single work directory will need a fifo in too, i wonder if those work on the docker cripplefs Jun 19 20:45:06 rburton: I suspect this is the tip of a whole set of problems and I'm not sure I particularly want to play whack-a-mole or complicate bitbake by starting to poke into /var/run Jun 19 21:36:42 moto-timo: we need to add the new perl module to the list of ptests in conf/distro/include btw Jun 19 21:36:51 * RP meant to quickly do that Jun 19 22:27:29 New news from stackoverflow: How to initialize Bluetooth in a startup script with Yocto Poky Linux Jun 20 01:17:40 Hi all, I'm trying to figure how to incorporate our current code base into a yocto build Jun 20 01:17:54 Its a big monorepo and I only need to build certain binaries out of it Jun 20 01:18:27 I figured out how to SRC_URI the files into a directory then run_oemake Jun 20 01:18:58 but I may need to reuse those files sourced many times Jun 20 01:19:31 Its possible I'm trying to optimize too much but it seems silly if I have many small applications built that I'd need the source that many times Jun 20 01:19:57 Sources roots may solve it but I don't understand the concept well enough to even use that Jun 20 01:20:07 Sorry sysroot Jun 20 02:58:04 New news from stackoverflow: Bitbake: poky Branch Warrior Failing binutils-native do_compile **** ENDING LOGGING AT Thu Jun 20 03:00:00 2019