**** BEGIN LOGGING AT Tue Mar 03 02:59:59 2020 Mar 03 06:58:54 khem: can you remind me of the setup which shows those file ownership failures? Its a docker container? Mar 03 06:59:13 khem: which OS running within which OS? Mar 03 07:20:29 its docker yes, running debian10 Mar 03 07:47:40 good morning Mar 03 08:56:40 Hi everyone, first thanks to PinkSnake, LetoThe2nd and others who helped me yesterday. Made some great progress since yesterday. I wrote my first couple of receipes and successfully included them into my image. Mar 03 08:58:16 Now, I'm stuck at a layer using pypi to install scipy. the python-scipy.inc looks like this (pretty standard): Mar 03 08:58:25 SUMMARY = "comprehensive password hashing framework supporting over 30 schemes"DESCRIPTION = "Scientific computing"PYPI_PACKAGE = "scipy"LICENSE = "BSD"LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=011ccf01b7e0590d9435a864fc6a4d2b"SRC_URI[md5sum] = "3a97689656f33f67614000459ec08585"SRC_URI[sha256sum] = Mar 03 08:58:25 "dee1bbf3a6c8f73b6b218cb28eed8dd13347ea2f87d572ce19b289d6fd3fbc59"RDEPENDS_${PN} += "\ ${PYTHON_PN}-numpy \" Mar 03 08:58:40 smurray: sadly it doesn't seem to have helped, its still failing intermittently :( Mar 03 08:58:45 hmpf... well, pretty standard Mar 03 08:59:28 the issie is at do_configure: `setup.py clean` is not supported, use one of the following instead: Mar 03 08:59:40 ` Mar 03 08:59:56 ` - git clean -xdf (cleans all files)` Mar 03 09:00:37 Hi @emrius could you please format your copy/paste plz :-) Mar 03 09:00:49 Ok, apart from the irc copy-paste fu** up it can be said that something goes south during `do_configure` Mar 03 09:01:10 How to copy paste multiline code? Mar 03 09:02:48 Test (sorry): ``` - `git clean -xdf` (cleans all files) - `git clean -Xdf` (cleans all version``` Mar 03 09:03:04 Test (sorry): ``` - git clean -xdf (cleans all files) - git clean -Xdf (cleans all version``` Mar 03 09:06:01 Is there no way to get around pastebin?!! Mar 03 09:07:23 ```SUMMARY = "comprehensive password hashing framework supporting over 30 \nschemes"DESCRIPTION = "Scientific computing"``` Mar 03 09:07:40 ```SUMMARY = "comprehensive password hashing framework supporting over 30 \n schemes"DESCRIPTION = "Scientific computing"``` Mar 03 09:08:13 seriously?! no line breaks not even through \n? Mar 03 09:08:39 ```SUMMARY = "comprehensive password hashing framework supporting over 30 schemes" \nDESCRIPTION = "Scientific computing"``` Mar 03 09:09:17 Ok, I'll stop spaming but this seems horrifically impractical to me! Mar 03 09:09:22 https://paste2.org/J4neIwY9 Mar 03 09:10:17 Back to the topic: Do I need to overwrite `do_configure` for installation of scipy through pip ? If yes, how should I approach this? Mar 03 09:13:17 PinkSnake dod you have a hint how to proceed? Mar 03 09:14:39 New news from stackoverflow: Bitbake fails at do_rootfs : none of the providers can be installed Mar 03 09:15:21 I have a yocto scenario where I need to run a binary with sudo command. Can anyone help ? Mar 03 09:21:31 Ok, found out: missing dependency on `distutils Mar 03 09:21:35 Ok, found out: missing dependency on `distutils` Mar 03 09:21:56 A right, no "arrow-up, correct, return" Mar 03 09:22:02 ;) Mar 03 09:27:00 emrius: ;) Mar 03 09:57:08 Hey me again O:3 Mar 03 09:57:38 So, I posted a question on stackoverflow using the #yocto tag but I didn't see the notfication here. Mar 03 09:57:40 https://stackoverflow.com/questions/60504526/why-does-yocto-scipy-recipe-require-python3-explicitly-set-how Mar 03 09:57:53 Ah hang on, it was `yocti` right? Mar 03 09:58:19 Anyhow, any hint on SO would be highly appreciated :) Mar 03 09:58:34 Or here... Mar 03 10:14:51 New news from stackoverflow: Why does yocto scipy recipe require python3 explicitly set? How? Mar 03 12:37:46 hm, there are commits in the poky krogoth branch ahead of krogoth-15.0.3 Mar 03 12:38:02 but krogoth-15.0.0.3 is supposed to be the latest? Mar 03 12:38:05 whats going on here? Mar 03 12:38:20 i assume there's no active development on the krogoth branch Mar 03 12:38:44 (by "the latest" above i mean the latest krogoth) Mar 03 12:49:34 Hi guys, any of you have insights or tutorials on how to deploy an angular application on a Yocto image? Mar 03 12:50:35 My idea was to bbappend nginx and install a zipped file containing all the "compiled" angular artifacts to whatever/www Mar 03 12:51:50 kriive: if you need to do some npm/yarn build/bundling, i'd check poky/meta/classes/npm.bbclass Mar 03 12:51:53 kriive: just package it into a seperate recipe and RDEPEND on nginx Mar 03 12:53:43 kriive: it depends a bit on the fetch/build stages you need, there it might vary between just packaging externally produced artifacts to a full blown recipe that is based on something like npm.bbclass Mar 03 12:54:08 kriive: see also https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#packaging-externally-produced-binaries Mar 03 12:56:31 milloni: I suspect we had some changes post release which were worth merging Mar 03 12:57:24 wouldn't that warrant a new release though? it seems strange to merge changes to a release branch and then not do the actual release Mar 03 12:57:42 i suppose a lot of users go by tags and they'll miss those changes Mar 03 12:58:15 milloni: tags are so 2010s Mar 03 12:58:37 milloni: We encourage people to use branches, not tags Mar 03 12:58:43 all the cool kids are on git revs these days. Mar 03 12:58:45 ok Mar 03 12:58:53 milloni: I suspect its minor stuff like docs tweaks or something Mar 03 12:59:05 there's at least one cve fix in there... Mar 03 12:59:27 milloni: hmm :/ Mar 03 12:59:37 oh well Mar 03 13:00:11 On that subject, is it always safe to pull latest commits if using a version branch (e.g. "warrior") ? I had been using tags on the asumption that they provide a more tested platform Mar 03 13:00:27 meego: depends on your definition of "safe" Mar 03 13:01:42 LetoThe2nd: i'm aiming to stay with the rest of the herd as much as possible :) Mar 03 13:02:45 meego: we try to only merge tested things onto stable branches Mar 03 13:15:04 smurray: I think I found another issue and sent a fix Mar 03 13:29:51 meego: thank you I'll look into it Mar 03 13:30:25 LetoThe2nd: and thank you too Mar 03 13:59:36 RP: my apologies, I should have noticed that; I figured it would have After set that way already, and it didn't fail in my testing Mar 03 14:01:45 smurray: np, I was a little disappointed with the sea of red this morning but hopefully got it now! I appreciate the help Mar 03 14:02:12 RP: no worries Mar 03 14:06:05 RP: The YAML dep is optional... but the more I use YAML the more I realize it (annoyinly) is one of the better ways to describe structured user configuration Mar 03 14:06:21 JSON is just such a pain to write by hand Mar 03 14:07:10 JPEW: really? Mar 03 14:07:35 LetoThe2nd: Which part :) Mar 03 14:09:04 the pain with json? to me its really one of the most easily writable and readable formats (proper linefeeds and indentation assumed) Mar 03 14:11:16 LetoThe2nd: Right, so I'll clarify: For user maintained configuration files, I think YAML is easier than JSON. JSON isn't hard to read, but the parser is really strict with commas and such, so it's much harder to sit down and write a properly formatted JSON file the first time than YAML (IMO) Mar 03 14:11:37 JPEW: ah. Mar 03 14:11:42 might be a point to that. Mar 03 14:11:50 Also, JSON's lack of comments really becomes a problem (for user config files) Mar 03 14:11:56 I agree, I usually use something to check json syntax after I write it by hand Mar 03 14:12:38 For data exchange and serialization, JSON is by far the better format :) Mar 03 14:44:28 What news websites/blogs do you follow for embedded-related news ? I've already discovered LWN & Phoronix for software, but I haven't yet found much yet on the hardware side. Mar 03 14:45:44 New news from stackoverflow: Got an error while copying unpacked files from workdir to ${D} Mar 03 14:50:41 JSON is a disaster for human-editable Mar 03 14:50:58 wrong quotes wrong comma no comments STUPID HUMAN Mar 03 14:51:33 meego: linuxdevices has reasonable stuff Mar 03 14:51:43 phoronix is pretty lame tbh Mar 03 14:52:13 yeah json sucks for manual editing. toml or yaml are better Mar 03 14:52:16 * kergoth yawns Mar 03 14:52:53 rburton: thanks. I'll check it out right awway. Agreed re: phoronix, the comments section in particular is a toxic wasteland Mar 03 14:53:11 Hi all, someone here could tell me how to install a prebuilt library ? I got an issue during the rootfs process ( nothing provide my lib :( ) Mar 03 14:53:30 PinkSnake: make a recipe to put the prebuilt library in a package Mar 03 14:53:47 and then hope that library paths, dependencies, abi requirements and so on are all compatible Mar 03 14:54:06 and finally curse whoever made you integrate a prebuilt library Mar 03 14:55:06 rburton I don't understand what you mean :S I just want to install a prebuilt mylib.so, Yocto is able to bluid all packages depends on this lib, the issue is during image rootfs construction Mar 03 14:57:20 hard to debug mystery errors Mar 03 14:58:03 prebuilt libraries very scary Mar 03 14:58:11 rburton: Oh, the time I've wasted looking at the disassembly from a pre-compiled library trying to deciper what it's doing :( Mar 03 15:00:11 Yes but the lib is not mine ^^ Mar 03 15:02:51 PinkSnake: A log might help; the recipe providing the prebuilt library would be even more helpful :) Mar 03 15:05:45 @JPWE It's a simple do_install function --> nothing provides my-lib needed by app-x5487-1.0+229804905e-r0.aarch64 Mar 03 15:05:47 I root for ini config files Mar 03 15:06:20 Not all that hipster stuff like JSON and YAML Mar 03 15:07:02 JPEW: the comments piece is a valid point I guess Mar 03 15:07:25 JPEW: I just fear adding more options into the mix :/ Mar 03 15:07:36 PinkSnake: "simple" and "I just want" and yet it does not work :) Mar 03 15:08:10 PinkSnake: check where the lib is installed. It's most likely in -dev package if it's not versioned (.so and not .so.x.y.z) Mar 03 15:08:28 check all the warnings you got when compilingt the recipe Mar 03 15:08:41 but you're not giving us enough info unfortunately Mar 03 15:12:45 qschulz https://pastebin.com/hXWYaYkN simple recipe Mar 03 15:13:14 PinkSnake: do_package_qa[noexec] = "1" :'D Mar 03 15:13:21 @qsch xD Mar 03 15:13:30 how are you supposed to detect the qa issues if you silence them :) Mar 03 15:14:28 (btw, you're most likely interested in the bin_package bbclass if nothing actually gets compiled but just installed) Mar 03 15:14:45 remove the noexec for do_package_qa and check what are the error messages Mar 03 15:15:08 qschulz I disable all i can when i search my issue ^^ thx a lot for bin_package bbclass i will take a look :) Mar 03 15:16:03 PinkSnake: a simple recipe has only the do_install for a pre-built binary/lib, the recipe you've sent is already tweaked and no comments to explain why some lines are needed Mar 03 15:17:38 qschulz all varibale are in mega manual :) Mar 03 15:21:59 PinkSnake: you're shooting yourself in the foot if you're not commenting (at least in the git commit log) why you need to silence some warnings or need to do some tricks. I've helped as much as I can now without more info, good luck. Mar 03 15:22:56 qschulz Come on, don't sulk. I removed most of comment before got to pastebin ;) Mar 03 15:23:45 qschulz issue is solved by **INSANE_SKIP_${PN} = "ldflags already-stripped" ** to inhibit warnings about files being stripped Mar 03 15:26:37 PinkSnake: rerun bitbake your-recipe-name after you've commented out do_package_qa[noexec] Mar 03 15:27:12 I think you might need to add libblahblah to FILES_${PN}, maybe? Mar 03 15:27:35 kriive FILES_${PN} = "${libdir}/*.so.* ${includedir}/*" was already in place :S Mar 03 15:29:16 PinkSnake: that is not enough. Though SOLIBS = ".so" should make lib.so part of FILES_${PN} Mar 03 15:29:55 PinkSnake: I'm sorry if I'm late to the party, but which errors did you receive? Mar 03 15:30:41 kriive: nothing provides my-lib needed by app-x5487-1.0+229804905e-r0.aarch64 Mar 03 15:31:13 qschulz Thx https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries Mar 03 15:32:37 PinkSnake: did you set COMPATIBLE_HOST? Can't find it in your pastebin Mar 03 15:33:12 im getting [Errno 110] Connection timed out when trying to build yocto autobuilder on docker. has anyone encounter this before? Mar 03 15:33:49 NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/2.8/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab Mar 03 15:33:49 Initialising tasks...WARNING: Error contacting Hash Equivalence Server typhoon.yocto.io:8686: [Errno 110] Connection timed out Mar 03 15:34:19 matthewzmd: You probably want to either disable hashequiv or make it use a local one instead of the autobuilder Mar 03 15:34:57 how can i do that? Mar 03 15:36:55 Is there a recommended way how to install initramfs into a rootfs? We experimented with a separate recipe and with tasks after do_rootfs both seems a bit hacky... Mar 03 15:45:53 matthewzmd: set BB_HASHSERVE = "auto" in local.conf Mar 03 15:46:11 JPEW: Yes, i found it. Thank you! Mar 03 15:46:26 matthewzmd: That should be the default actually; I'm guessing you copied the AB config value accidentally Mar 03 15:47:12 JPEW: hmm. All I did a fresh git clone from https://git.yoctoproject.org/git/yocto-autobuilder-helper Mar 03 15:47:29 matthewzmd: Right, the autobuilder defaults :) Mar 03 15:48:31 IIRC, The default in oe-core is "auto", the autobuilder default will be typhoon.yocto.io Mar 03 15:54:32 YPTM: armin is waiting Mar 03 15:55:46 YPTM: trevorW is also waiting Mar 03 15:57:25 YPTM: David here Mar 03 15:57:42 tlwoerner, try tw-eh : ) Mar 03 16:00:28 YPTM: Scott M is on Mar 03 16:01:54 YPTM: Joshua Watt here Mar 03 16:22:25 YPTM meeting notes: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit Mar 03 16:29:41 To support my angular based package I ended up doing this: https://pastebin.com/Fp9Z7Lbq Mar 03 16:30:06 It feels a lot hacky, what do you suggest I should improve or which shortcomings do you see Mar 03 16:30:36 I tried to use npm.bbappend but couldn't make it work Mar 03 16:30:43 npm.bbclass sorry Mar 03 16:32:56 BTW https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#New_Releases_process just points to empty page https://wiki.yoctoproject.org/wiki/Yocto_Project_Release_Process, (because of trailing comma) Mar 03 16:34:01 JaMa: are you on the call? Mar 03 16:34:10 tlwoerner: yes Mar 03 16:34:55 armpit: looks like you've updated the wiki recently, I don't have edit rights, can you fix https://wiki.yoctoproject.org/wiki/index.php?title=Stable_Release_and_LTS&diff=70479&oldid=70474 ? Mar 03 16:36:45 https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance also has https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS, link with comma Mar 03 16:39:24 JPEW: <--- Mar 03 16:39:26 JPEW: tgamblin Mar 03 16:40:38 RP: I was building in docker with ubuntu 18.04 until recently and wasn't seeing the host-user-contamination issue khem was fixing now, so either it was introduced recently (like last 2 months) or I wasn't able to reproduce in docker (I will retest with latest master under docker now) Mar 03 16:43:44 RP: I was finally able to reproduce the issues with kernel artifacts naming pull request you've reported from autobuilder (for me it failed during "oe-selftest --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirroring.test_yocto_source_mirror -T machine -T toolchain-user -T toolchain-system -j 15" which took almost whole day to finish, so I'm trying to find something faster to reproduce it Mar 03 16:43:50 as well, is it already too late for this in 3.1 or should I try to hurry and respin the pull request? Mar 03 16:48:23 RP: yes, I'm in call, just mutted, because kids are a bit loud today Mar 03 16:48:31 ok, fair enough Mar 03 16:55:16 JaMa, done Mar 03 17:00:45 armpit: thanks! Mar 03 17:02:24 np Mar 03 17:04:23 the call notes say "RP: yes, tsc recommendation is 3.0 will have 9 months (not 6 or 12)." and https://wiki.yoctoproject.org/wiki/index.php?title=Stable_Release_and_LTS says "Stable releases are maintained for seven months" (twice), which one should be fixed? Or is 3.0 special that it will be 9 and e.g. 3.2 will be 7 months? Mar 03 17:06:25 JaMa, the extra month allows for a last dot release after the previous release it released Mar 03 17:06:33 we can not do two at the same time Mar 03 17:07:08 or we go with 5 months Mar 03 17:07:59 the 1 year releases really are lasting 16 months just to get one last dot release out Mar 03 17:08:18 I understand why 7 months, 9 != 7 Mar 03 17:09:14 9 months because zeus was out before we defined LTS so we are easing folks into the new scheme Mar 03 17:12:08 yes, zeus is special.. and we have not updated docs. We still need to send out a message to the mailing lists about Mar 03 17:12:08 thanks, that's what I was asking Mar 03 17:12:40 BTW, any reason for keeping thud in maintained versions? I don't think there's gonna be another dot release right? To me this means it's not maintained anymore but I may have forgotten something in my reasoning process :) Mar 03 17:13:58 https://wiki.yoctoproject.org/wiki/index.php?title=Stable_Release_and_LTS still has two links with trailing comma "Kernel cadence" and "Poky releases" Mar 03 17:14:24 I used to do that and even mark things as EOL but now there is a YP TSC, I need to follow a more formal process. its is not defined yet Mar 03 17:14:43 JaMa, will fix shortly Mar 03 17:15:23 all this documenting and keeping docs up to date take time Mar 03 17:16:40 armpit: I think JaMa volunteers to update the docs... :) Mar 03 17:16:45 : thank you for the minutes Mar 03 17:16:57 dreyna: no prob! Mar 03 17:16:59 I foolishly stepped into trying to keep the stable branch doc updated Mar 03 17:17:03 * tlwoerner hopes the notes are coherent Mar 03 17:17:12 yes! Mar 03 17:17:27 denix: luckily I don't have permissions to do that Mar 03 17:17:31 if others would like to review the notes and verify the points that'd be great, shoot me an IRC if you see anything missing or needs fixing Mar 03 17:17:49 Shot You ? Mar 03 17:18:11 * tlwoerner ducks Mar 03 17:18:23 tlwoerner: notes look good to me, thanks Mar 03 17:18:45 tlwoerner: well there is few typos mucl -> musl Mar 03 17:18:46 I read "shoot me", being in America Mar 03 17:18:54 opps! s/shoot me/shoot me a note/g ;-) Mar 03 17:19:28 and I can't spell at all Mar 03 17:19:51 armpit: i forgot the "a note" part, lol Mar 03 17:20:58 what's the codename for 3.1? Mar 03 17:21:08 dunfell Mar 03 17:21:08 milloni: https://wiki.yoctoproject.org/wiki/Releases Mar 03 17:21:11 thanks Mar 03 17:22:35 armpit: thanks for wiki fixes Mar 03 18:15:14 RP: a system reboot after reboot of build machine and now docker build cant reproduce the problem :( pseudo has managed to make docker inconsistent Mar 03 18:15:38 khem: gah :( Mar 03 18:16:06 RP: but looking at the fixes I think they should be applied Mar 03 18:16:28 khem: The implication is changing every cp command in the codebase Mar 03 18:16:38 khem: I want a good reason/understanding before we commit to that Mar 03 18:16:47 so my docker setup uses same user ID as that of my docker host Mar 03 18:16:56 I wonder if in some case the ID changes Mar 03 18:17:33 JPEW: you wanted to discuss a YP bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13815)? Mar 03 18:17:34 Bug 13815: normal, Medium+, 3.1 M4, trevor.gamblin, NEW , Reproducibility test failure occurs for deb even if package_deb is not set Mar 03 18:18:06 tgamblin: JPEW was wondering if you tried to reproduce the perl module issue using the reproducibiity selftest? Mar 03 18:19:16 tgamblin: Correct. You should be able to easily modify the reproducible build OEQA test to build just that recipe Mar 03 18:19:22 RP: cp is not preserving mode,perms unless told to do so Mar 03 18:19:48 RP: JPEW: oh, yeah. I've been running reproducibility for my coreutils patch but I don't see the libmodule-build-perl errors anymore Mar 03 18:20:22 tgamblin: oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds after setting the perl module name as images= in that test Mar 03 18:20:47 khem: but it should be deterministic Mar 03 18:21:14 khem: Do you have your Dockerfile sources? Mar 03 18:27:33 * tgamblin spins up a few reproducibility test runs Mar 03 18:33:09 I get `ERROR - Build directory /projects/poky/build-st already exists, aborting` every time I run oe-selftest... is the expectation that the user has to delete that every time now? Mar 03 18:34:05 khem: just curious, what are you using for filesystem access in Docker? Wondering if it might be some overlayfs issue or the like that's being tickled Mar 03 18:35:24 I am on f2fs Mar 03 18:35:31 and ext4 Mar 03 18:35:48 tmp is on ext4 Mar 03 18:36:05 JPEW: pass -j 1 Mar 03 18:36:39 JPEW: Its a bug in my recent code changes. Its leaving the non -j builddir around for no good reason except the code changes forgot to account for it Mar 03 18:38:16 RP: That fixed it. Thanks! Mar 03 18:38:45 JPEW: "fixed" ;-) Mar 03 18:40:31 Ah, right, it's toaster that's still using addDefaultlogFilter(), not devtool and tinfoil Mar 03 18:40:43 RP: familiar with this? https://github.com/franzflasch/REM Mar 03 18:41:06 I was thinking about Yocto-like systems for micros, but it looks like someone's already started one Mar 03 18:42:05 tgamblin: not seen that before, interesting Mar 03 18:43:23 JPEW https://github.com/YoeDistro/docker-yoe-build/blob/buster/Dockerfile Mar 03 18:43:54 tgamblin: I actually have recipes for AVR microcontrollers! Mar 03 18:44:26 including ones which which build an AVR target compiler that runs on arm, built on x86 :) Mar 03 18:44:56 (I have some Pis with AVRs connected over SPI) Mar 03 18:45:28 RP: do you have those hosted on GitHub or elsewhere? Mar 03 18:45:51 tgamblin: just local unfortunately Mar 03 18:45:55 khem: FWIW, we had a ton of trouble with using --user and docker in Pyrex Mar 03 18:46:01 tgamblin: its all a bit hacked together Mar 03 18:47:05 RP: Ah, understandable. If you ever post it somewhere, let me know Mar 03 18:47:16 JPEW so yoo run as root ? Mar 03 18:47:34 tgamblin: will do, I should sort them out. There are some fun things there Mar 03 18:48:07 khem: We start as root and switch the the required used in an initialization script: https://github.com/garmin/pyrex/blob/master/image/entry.py Mar 03 18:49:09 s/used/user/ Mar 03 18:50:33 khem: Also, see https://github.com/garmin/pyrex/blob/master/image/cleanup.py which makes sure pseudo dumps its in memory database to disk before the container gets killed off (b/c that caused all sorts of contamination issues also) Mar 03 18:51:30 RP: JPEW: still not seeing the libmodule-build-perl error with reproducibility. Given that I don't see that, and I do see reproducibility complain about PACKAGE_CLASSES = "package_ipk" instead of PACKAGE_CLASSES = "package_ipk package_deb", I wonder if my environment is somehow suspect... Mar 03 18:53:08 tgamblin: Given our past history with perl I would be entirely unsuprised if that one crops up again, but the pacakge_deb does seem like it might be something on your end... would still be nice to know what Mar 03 18:53:55 JPEW: I dont think I have seen much issues that need to be handled frankly and --user works ok too, except for running tests in emulator where it needs sudo access, I wish all tests could run using slirp then we dont need any sudo stuff at all Mar 03 18:55:37 khem: the pseudo being killed off problem is a real issue and potentially could cause what you saw Mar 03 18:56:17 hmmm yeah thats possible Mar 03 18:56:23 tgamblin: I started a reproducibility test locally just for interest Mar 03 18:58:23 khem: There is some way to make pseudo exit as soon as the last client disconnects.... I don't think it does good things for performance, but it's easy to try to see if thats the problem. Mar 03 18:58:28 Can't recall how ATM Mar 03 19:08:44 khem: Maybe add "-S" to FAKEROOTCMD? Mar 03 19:16:34 Hmm, there's no oe-selftest for toaster? Mar 03 19:26:10 JPEW: no, sadly no automated testing we can run :( Mar 03 19:27:39 Hey everyone, I'm trying to create a recipe for a python .whl file, manually you could do pip3 install https://....somename.whl but inherit pypi didn't seem to act as I expected. My source filename exists in the temp with [name].whl but I think pypi is actually expecting tar.gz to pip install - how can I fix this? Mar 03 19:29:26 RP: khem: I've also rebuilt all 3 (dbus-test strace boost) in docker with 18.04 (both on host and inside container) and didn't get any host-user-contamination issues Mar 03 19:45:34 JaMa: What container setup are you using? Mar 03 20:04:11 Hmmm... hitting another issue, I've enabled fortran in my local conf but do_configure for gcc-runtime (ver 9.2) throws an error that -V and -qversion are unsupported, I understand they got merged into -v. Not sure how to fix this.... Mar 03 20:05:42 JPEW: Hmm, what would be required to use a custom docker image with pyrex? That is, what does it expect out of the docker image to be able to do its job? Mar 03 20:17:46 kergoth: I think you mostly need the parts in this section https://github.com/garmin/pyrex/blob/master/image/Dockerfile#L525 through line 552 Mar 03 20:17:51 Not necessarily all of them Mar 03 20:18:44 kergoth: We publish the "-base" images in case someone wants to do this Mar 03 20:18:47 couldn't that be handled by bind mounting the pyrex path rather than copying it all in, thereby reducing the pyrex-specifics needed in the docker image? Mar 03 20:19:10 would still need the entrypoint though Mar 03 20:19:31 we're requiring a specific distro and version here Mar 03 20:19:51 kergoth: Yes, it could. I've though about doing that, but haven't decided if it's a good idea Mar 03 20:20:00 What distro/version? Mar 03 20:20:11 debian 10 Mar 03 20:20:39 Ah. That one seems popular :) Mar 03 20:22:02 shrug, not my call :) Mar 03 20:26:09 kergoth: It should be possible. The easiest would be to add it to our existing Dockerfile so we can publish the images, but I realize that's not great for a lot of reasons. Mar 03 20:30:43 RP: the dlm issue I was mentioning is reproducible and the reason is that Makefile is using cp -a see https://pagure.io/dlm/blob/master/f/libdlm/Makefile#_128 Mar 03 20:31:16 so using cp -a is definitely need to change Mar 03 20:33:26 kergoth: docker has a --entrypoint argument; between that and a bind mount it might very well be possible to use a generic image Mar 03 20:41:34 khem: right, cp -a is a different thing **** BEGIN LOGGING AT Tue Mar 03 21:03:40 2020 Mar 03 21:11:26 tgamblin: I reproduced the problem and a whole lot more :( Mar 03 21:11:55 RP: right thats what is case with atleast dbus-test Mar 03 21:12:03 RP: Hmm, wonder why I can't see it. What else fell out? Mar 03 21:12:48 tgamblin: libc locale issues Mar 03 21:13:11 tgamblin: are you somehow forcing an sstate cache for both builds? Mar 03 21:14:42 RP: Not that I can see. I retried it recently on my Fedora builder (which I've never run the test on before), and it still passes just fine for me Mar 03 21:18:25 tgamblin: after the repro test completes you have two build directories Mar 03 21:18:32 RP, do we throaty back the number of cores in each worker? Mar 03 21:18:49 tgamblin: have a look in them and look at ./usr/lib/libmodule-build-perl/ptest/_build/build_params in the libmodule-build-perl ptest package Mar 03 21:19:03 if so, should we open up a worker ? Mar 03 21:19:15 tgamblin: you should see the build path encoded into _added_to_INC, base_dir and other places Mar 03 21:19:39 RP: I have my normal build folder, and another build-st folder Mar 03 21:19:46 armpit: I don''t understand Mar 03 21:19:46 JPEW: nothing special, very basic Dockerfile I've created long time ago (before crops existed or at least I wasn't aware of that) and since then I'm just updating which ubuntu release to start from Mar 03 21:20:01 tgamblin: in build-st there should be two tmp dirs? Mar 03 21:20:15 don't we use -J16 instead of all threads Mar 03 21:20:35 could we use 32 ? Mar 03 21:20:55 armpit: We do limit the number of parallel make threads, yes Mar 03 21:21:08 armpit: what problem are we trying to solve? Mar 03 21:21:41 RP: I only see one tmp-glibc :/ Mar 03 21:21:42 maybe we are dealing with a race condition Mar 03 21:21:58 armpit: each worker has three builds running in parallel so make is lower to try not to overload the machines Mar 03 21:22:28 tgamblin: build-st/reproducibleA and build-st/reproducibleB ? Mar 03 21:23:23 RP: Negative. I haven't seen either of those paths being created by reproducibility in a while Mar 03 21:23:33 tgamblin: well, that is your issue Mar 03 21:24:29 tgamblin: note the bit where that tests sets TMPDIR = "{tmpdir}" Mar 03 21:24:44 tgamblin: for reasons unknown its having no effect in your build Mar 03 21:24:57 a bit like the PACKAGE_CLASS bit Mar 03 21:25:10 RP: hmm ok. I'll have a look Mar 03 21:25:18 * tgamblin is wondering if maybe it has something to do with the tmux session Mar 03 21:25:29 tgamblin: if that happens it only has one build directory and hence they will be identical :/ Mar 03 21:28:52 RP: Guess I shouldn't've been trusting that part to be coming out OK :P Mar 03 21:29:52 tgamblin: I'm just guessing but there is something odd going on here Mar 03 21:40:28 RP: yeah, I'm looking around in my environments to see if there's anything common between the two build hosts that I could've tweaked to be causing this Mar 03 21:40:40 Might have to try a container Mar 03 21:42:14 One of said build hosts isn't maintained by me, so if it's something I've done specifically, someone else and/or a container should see the expected behavior Mar 03 21:45:15 zeddii: have you tried building docker-moby with http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=f770151b3ff0938bea4972abdd1ee7f6cbc3a074 ? or only docker-ce? Mar 03 21:45:52 zeddii: docker-moby now fails with exec: "arm-linux-gnueabihf-gcc": executable file not found in $PATH Mar 03 21:45:59 tgamblin: is this in a standard poky checkout or standard oe-core or something else? Mar 03 21:46:12 tgamblin: I very much doubt its something external Mar 03 21:46:17 RP: standard oe-core Mar 03 21:46:26 RP: I'm going to get someone else at WR to try a build to be sure **** BEGIN LOGGING AT Tue Mar 03 22:17:31 2020 Mar 03 22:27:18 RP: I updated http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/logging with the autobuilder config file that captures hashequiv messages and lowering the default hashequiv logging level so they don't appear on the console Mar 03 22:28:32 Looks like it's working pretty well, except for the VERBOSE logging level show up a "Level 19" :) Mar 03 22:28:40 But I know how to fix that **** BEGIN LOGGING AT Tue Mar 03 22:49:40 2020 Mar 03 22:55:35 Hello... I get this error ERROR: Task do_create_manifest in /poky/meta/recipes-devtools/python/python3_3.7.4.bb depends upon non-existent task do_patch in poky/meta/recipes-devtools/python/python3_3.7.4.bbERROR: Command execution failed: 1 Mar 03 22:55:44 This happens on all bitbake commands Mar 03 22:56:02 I do not understand where did it come from Mar 03 22:56:09 It used to work properly Mar 03 22:56:34 do_patch exists in the python recipe. it sounds like you have something funky in your local environment Mar 03 22:56:34 I added oe-meta-go layer and also was trying to add python..but do not know what went wrong Mar 03 22:56:48 kergoth yes Mar 03 22:56:58 how do I remove python3 from build process Mar 03 22:57:25 because none of bitbake commands work as this is the first error and it exis\ts Mar 03 22:57:27 exits Mar 03 23:00:21 JPEW: sounds good Mar 03 23:00:41 * RP is going to step away from the computer for a bit, likely tomorrow evening. Need a break... Mar 03 23:02:58 Hello, I am trying to structure recipes to build packages with two dimensions of input. One dimension is the 'customer', the other dimension is the 'target image.' For example, I have custA, custB, and custC I want to create packages for trgtA and trgtB. The end result I want are the following packages: custA-trgtA, custA-trgtB, custB-trgtA, custB-trgtB, custC-trgtA, custC-trgtB. Can I do this reasonably without creating individual Mar 03 23:02:59 recipes for each package? For example by having recipes for each customer which inherit classes for each target? Mar 03 23:05:49 bitbake throws this error everytime and therefore all of my compilation has stopped Mar 03 23:20:41 Hi sorry for my internet blip, no chance someone had input on my question in the interim, is there? Mar 03 23:38:07 mccc: I would rather see what can be common between these and maybe use packageconfig feature to have these differences captures Mar 03 23:38:38 last option would be where all combinations are different recipes Mar 03 23:39:21 you could also view it as distro per customer then it will become easier Mar 03 23:43:26 Hi thanks khem, indeed most of the mechanics are identical per customer besides the name and location of configuration files, eg. custA uses useradd to create "cust_a_user" and drop "file://cust_a/service.conf" to "/home/cust_a_user/service.conf" Mar 03 23:46:24 Hello... I m looking for help on below Mar 03 23:46:40 Everytime I run bitbake, after the build configuration is printed, I get this error Mar 03 23:46:46 ERROR: Task do_create_manifest in /poky/meta/recipes-devtools/python/python3_3.7.4.bb depends upon non-existent task do_patch in poky/meta/recipes-devtools/python/python3_3.7.4.bbERROR: Command execution failed: 1 Mar 03 23:47:07 how to I salvage / rectify my local build environment Mar 03 23:47:20 I m not able to do anything Mar 03 23:47:45 khem would you have any insight in to this? Mar 03 23:47:55 A problem I'm running in to is the following. If I create a single recipe per user and have it include a class (trgtA.bbclass) per target which adds FILES_${PN}-trgtA for that target, then I seemingly cannot place a file in the same location for two targets. Eg. I could not have /home/cust_a_user/service.conf on target A specified by trgtA.bbclass and have a different /home/cust_a_user/service.conf on target B specified by trgtB.bbclass. Mar 03 23:49:18 (where I would have trgtA-image include all of custA-trgtA, custB-trgtA, custC-trgtA and have trgtB-image include custA-trgtB, etc) Mar 03 23:49:20 they wouldn't be able to install in the same image, and would conflict in bitbake's package data. two packages can't provide the same file unless it's marked as a config file in CONFFILES Mar 03 23:49:33 if you don't build them both in the same build dir it won't be a problem Mar 03 23:49:57 there are ways around it, but probably best to keep them isolated to separate builds and/or distros Mar 03 23:50:17 kiwi_29: is this master or zeus release, Mar 03 23:50:42 zeus Mar 03 23:50:47 khem Mar 03 23:51:03 ok and whats your build host distro Mar 03 23:51:30 kergoth: in my case I would like to install them in separate images created by the same distro (my-service-distro). Mar 03 23:51:46 mcc, kergoth I think one approach is to divide the customer specific piece into a package of its own something like custX-conf Mar 03 23:51:58 good idea Mar 03 23:52:08 khem : host is ubuntu 18.04.4 LTS Mar 03 23:52:28 kiwi_29: ok, any local changes ? Mar 03 23:52:48 IRC sucks with multithreaded conversations, wish we used something modern Mar 03 23:53:02 I added oe-meta-go layer Mar 03 23:53:24 and also had tried to use devtool to install python and python3 on target Mar 03 23:53:50 I believe this started happening after I used devtool modify python3 Mar 03 23:54:13 then I tried to instal python3 on target using devtool deploy Mar 03 23:54:20 ok, did you try to delete tmp/ Mar 03 23:54:29 no Mar 03 23:54:36 should I fully delete tmp? Mar 03 23:54:40 yes Mar 03 23:54:46 khem: I hear you I'll just do the username prefix thin ;). Do you mean something like custA-conf.bb? How does that square with wanting to install different files for a single customer to the same location in different packages? That is, custA-conf.bb specifies the package custA-trgtA.deb installs /home/cust_a_user/service.conf and installs a completely different service.conf in custA-trgtB.deb for /home/cust_a_user/service.conf? Mar 03 23:54:53 rebuild is fast since it will use sstate Mar 03 23:55:32 trying now Mar 03 23:55:40 mccc: kergoth just mentioned, we cant have same file be provided by different recipes in same image Mar 03 23:56:19 khem: but I would install them in different images. That is, trgtA-image.bb installs custA-trgtA and trgtB-image.bb installs custA-trgtB. Mar 03 23:56:45 khem I get the same error even after deleting tmp folder Mar 03 23:57:03 mccc: perhaps possible, but you have to make these two deb use RCONFLICT or something Mar 03 23:57:22 kiwi_29: ok then perhaps do devtool reset python3 ? Mar 03 23:57:31 and see if that helps Mar 03 23:57:52 I did it ..but let me try again Mar 03 23:58:16 gives me same error on devtool reset too Mar 03 23:58:54 is there a way to get rid of cache...I dont mind spending an hour for everything to compile again from scratch Mar 03 23:59:02 already wasted few hours on this issue :( Mar 03 23:59:36 khem: Is it possible though, since the recipe would share a $D amongst all of the packages it builds? Mar 04 00:01:17 khem: Can my single recipe install in to multiple $Ds and create packages from those separate $Ds? Mar 04 00:05:53 kiwi_29: can you check if you have some bbappends for python3 in workspace/ dir Mar 04 00:06:08 yes..was just going to mention that Mar 04 00:06:10 there are ! Mar 04 00:06:29 how should I deal with them Mar 04 00:06:49 ok just rename workspace/ to workspace1 for tests Mar 04 00:06:53 and see if that helps Mar 04 00:08:01 I had issues when I removed or renamed workspace directory in past.. Mar 04 00:08:11 just did it now and sure enought bitbake does not work Mar 04 00:08:28 I then did bitbake-layers show-layers and it lists workspace directory as one of the layers Mar 04 00:08:28 mccc: are you just doing debs and not full images ? technically yes its possible I think to do some munging like this but package QA might catch it Mar 04 00:08:50 just touch workspace Mar 04 00:09:21 its added to bblayers.conf thats why its complaining, perhaps I should have asked to delete it from there Mar 04 00:09:48 I can do bitbake-layers remove-layer workspace ? Mar 04 00:09:55 or have empty workspace dir Mar 04 00:10:15 khem: I am building full images, the idea is trgtA-image would include custA-trgtA, custB-trgtA, etc, and trgtB-image would include custA-trgtB, custB-trgtB, etc. I'm thinking I should look in to do_package to see if I can have it use a subdirectory of $D depending on which package it's building. Mar 04 00:13:06 khem... I deleted workspace folder by mistake..and got more errors...but then I went ahead and deleted workspace reference from bblayers.conf and atleast the distro is compiling again ! Mar 04 00:13:18 thanks ! Mar 04 00:13:25 lets c if this whole thing compiles again Mar 04 00:14:04 basically devtool reset did not fully reset then... and the append files where screwing things up? Mar 04 00:14:23 yeah its possible Mar 04 00:14:41 the whole issue started by me adding oe-meta-go to add go based programs. Mar 04 00:14:53 these go programs are not running on my target which is also x86_64 Mar 04 00:15:26 I created a recipe and compiled go programs and deployed to target but I again get same error "No such file or diretory" Mar 04 00:15:36 I believe you had mentioned to use multilib support? Mar 04 00:15:49 kiwi_29: with zeus golang is in oe-core Mar 04 00:16:04 perhaps you do not need oe-meta-go Mar 04 00:16:28 I see..let me check Mar 04 00:16:46 but regardless... I was able to generate a binary out of yocto build Mar 04 00:16:56 and when deployed it on target I get "No such file or directory" Mar 04 00:23:49 I'm currently looking through do_split_packages and "7.22.3.1 Making Sure the Packaging is Done" in the mega manual. Mar 04 00:40:19 I think what I need to do is create a recipe for each target (trgtA.bb, trgtB.bb), have each of those include a list of my customers (customers.inc which has CUSTOMERS = "custA custB"), loop over those customers in the target recipes do_install, and then use do_split_packages to split the target recipe into multiple packages per customer. **** ENDING LOGGING AT Wed Mar 04 02:59:57 2020