**** BEGIN LOGGING AT Tue Apr 28 02:59:59 2020 Apr 28 03:05:45 * paulg wonders how yocti search decided to re-broadcast that post here on IRC. Apr 28 03:06:34 aha. OP mentioned "yocto" Apr 28 03:07:30 guessed as much. Apr 28 03:08:26 "I'm working on a yocto platform with..." Apr 28 03:08:26 I'm working on a yocto platform with Apr 28 03:08:51 cut and paste fail... :-/ Apr 28 05:37:10 New news from stackoverflow: didn't pass LDFLAGS? [ldflags] Apr 28 07:40:12 just out of curiosity, is anyone else getting this: Apr 28 07:40:21 fatal: unable to access 'https://git.yoctoproject.org/git/meta-intel/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Apr 28 07:52:06 Even though "mysymlink" is listed under the regular (not dbg/dev) list of `oe-pkgdata-util list-pkg-files -p `, in the final image that symlink is missing. Why??? Apr 28 07:52:45 ak@linux-f9zs:~/development> git clone https://git.yoctoproject.org/git/meta-intel Apr 28 07:52:45 Cloning into 'meta-intel'... Apr 28 07:52:45 fatal: unable to access 'https://git.yoctoproject.org/git/meta-intel/': SSL certificate problem: certificate has expired Apr 28 07:52:51 halstead: ^^^ Apr 28 07:53:50 kanavin_home: thanks for checking alex Apr 28 08:10:43 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/893 is a second run of your patches Apr 28 08:11:04 kanavin_home: ububtu1604 segfault is an issue but there are some others Apr 28 08:11:23 kanavin_home: that is with libinput removed Apr 28 08:15:57 https certificate of https://git.yoctoproject.org/ is expired? Apr 28 08:17:32 vermaete, for me too. It expired on 4/28/2020, 8:51:54 AM (Central European Summer Time) Apr 28 08:18:01 vermaete: yeah, looks like it Apr 28 08:29:35 hi everyone. i have a quick question about runqemu that i need help with. how do i connect the vm to the local network using tap0? Apr 28 08:29:58 ssl certificate issue has been reported above by kanavin_home to halstead, the one in charge :) Different timezones, so we'll need to wait :) Apr 28 08:33:21 RP: thanks. I think there's maybe 2 or 3 issues in there, will take a look Apr 28 08:33:55 Hi, I have one question that I answered some dayes ago, but after it I became offline and.... Apr 28 08:35:09 is there any way in yocto to set temporary partition size staticly ?? for example I have devtmpfd /dev by 208 MB ,I know these partitions created dynamically in Ram. but I want change it Apr 28 08:35:37 is there any way in yocto for Image, or olny I must do it in Linux OS ?? Apr 28 08:36:20 devtmpfs and tmpfs partition created in ram has more space, then my rootfs has only 15 MB Apr 28 08:36:46 Have you ever encountered an error with quilt not being found while building an image? Apr 28 08:37:53 NO! I build Image ithout any Errors Apr 28 08:38:42 I'm trying to build core-image-base for genericx86-64, I have quilt installed by apt, Ubuntu 18.04.4 Apr 28 08:39:17 exactly that Apr 28 08:39:34 "/bin/sh: quilt: command not found" Apr 28 08:42:07 @barty i think you could use git instead with PATCHTOOL Apr 28 08:44:25 ok, thats kinda helpful Apr 28 08:44:25 ty Apr 28 08:44:52 most recipes have quilt as default Apr 28 08:48:35 Moh3N: there is an IRC archive for this channel :) https://www.yoctoproject.org/irc/%23yocto.2020-03-06.log.html should be helpful in some way :) Apr 28 08:49:03 so you can check if someone answered to your question (though usually we don't asnwer if someone is disconnected) Apr 28 08:49:55 barty: you should not use quilt from your HOST Apr 28 08:51:22 barty: idk why something requires quilt but you can add quilt-native to DEPENDS and it should be available for that component Apr 28 08:54:20 kanavin_home: looks like they improved conflicting directory code in rpm and we're now hitting it somehow :/ Apr 28 08:55:39 kanavin_home: I don't understand why it happens in some builds and not others though Apr 28 08:57:49 RP: yeah, there are three distinct errors: Apr 28 08:57:49 error: unpacking of archive failed on file /var/volatile/log/journal: cpio: mkdir failed - Inappropriate ioctl for device Apr 28 08:57:49 error: unpacking of archive failed on file /var/log: cpio: File from package already exists as a directory in system Apr 28 08:57:49 error: unpacking of archive failed on file /var/spool/mail: cpio: mkdir failed - Inappropriate ioctl for device Apr 28 08:58:03 I am just now creating a build to reproduce locally Apr 28 09:11:26 kanavin_home: the mingw issue is because its trying to build GL for windows Apr 28 09:12:37 RP: right. I'll rework that patchset anyway to use 'virgl' DISTRO_FEATURE, and them make sure it's not enabled in mingw. Apr 28 09:23:20 I'm having trouble cloning various layers. Anything the matter in the world, or is my problem my own? Apr 28 09:29:00 JoeR: certificate issues? Apr 28 09:29:12 Yeah Apr 28 09:29:31 Ancient server its on that doesn't get updated much. So it could well be my own issue. Apr 28 09:29:40 Just thought I'd double check. Apr 28 09:30:31 qschulz thank you, I check it. I want ti=o solve my problem in Yocto ! if it is possible Apr 28 09:30:47 is there any way in yocto to set temporary partition size staticly ?? for example I have devtmpfd /dev by 208 MB ,I know these partitions created dynamically in Ram. but I want change itis there any way in yocto for Image, or olny I must do it in Linux OS ??devtmpfs and tmpfs partition created in ram has more space, then my rootfs has only 15 MB Apr 28 09:31:16 Even though "mysymlink" is listed under the regular (not dbg/dev) list of `oe-pkgdata-util list-pkg-files -p `, in the final image that symlink is missing. Why??? rburton - Maybe you will be the savior? Apr 28 09:33:06 is that package *in the image* though Apr 28 09:33:17 yes Apr 28 09:34:13 like I said yesterday, there are 2 files, one is a library and the second is a symlink to that library. The library is copied to `/lib` directory, but the symlink is not Apr 28 09:34:30 dunno Apr 28 09:34:37 sharing the actual recipe might be useful Apr 28 09:34:51 I changed the names of the library and the symlink to .so.1/.so.1.1 extension Apr 28 09:35:15 s Apr 28 09:38:31 rburton: https://pastebin.com/tRhYXCj4 Apr 28 09:38:58 inside the output.tar archive there are the 2 files I mentioned before Apr 28 09:39:00 nacknick: don't make up versions if the library isn't versioned Apr 28 09:39:26 What do mean "is not versioned"? Apr 28 09:39:36 RP: Is there anything up or anything I should do? You mentioned certs, which is exactly my issue... Apr 28 09:39:54 If I won't version it, the ".so" files won't be copied Apr 28 09:40:12 nacknick: ok stepping back. do you own the library or is it a 3rd party library Apr 28 09:40:41 JoeR: I think some certs on our git server have expired. Our admin is asleep atm so it will be around 8 hours before we sort that Apr 28 09:41:07 I own the library, but the package is not mine. I added the function to an existing recipe of an existing package Apr 28 09:41:19 I created the library file Apr 28 09:41:56 RP: Thanks. I'll sit on it for a bit then :-) Apr 28 09:42:20 nacknick: so why all the crazy with tarballs. why don't you just build the library in its own recipe like normal? Apr 28 09:44:47 RP: I was not able to reproduce dnf failures on Ubuntu 18.04. Which means it's probably distro specific failures and there may be host contamination going on. Let's look again on which distros it failed. Apr 28 09:45:33 RP: awww, it did fail on ubuntu 18.04 :-/ Apr 28 09:46:29 kanavin_home: the pattern doesn't make sense :/ Apr 28 09:47:22 rburton: Because it is not possible in that case. I can't tell the whole story, but in short, the library should work with the binary file of the package. Let's say I have a package "gzip". I took it, did some stuff and now I have "gzip.patched" that should refer to "mylib" (that I have created as well). Is that make sense? Apr 28 09:48:49 RP: it's not impossible that one of the workers produces 'broken' rpms and the rest get them through cache Apr 28 09:49:28 kanavin_home: but then it would fail all over? Apr 28 09:51:41 RP: let me look closer again at where things failed, and whether the failing packages came from cache Apr 28 09:57:03 kanavin_home: I worry rpm's install order isn't entirely deterministic :/ Apr 28 09:57:25 kanavin_home: comparing your local working build log with the failed log to see if the ordering is the same? Apr 28 09:58:01 nacknick15: very hard to debug without actual working examples. double check the package actually contains what you expect. double check the file is actually being installed. read the rootfs log and see if it spits out any warnings. Apr 28 10:05:44 Hello, anybody aware about the letsencrypt certificate for the git.yoctoproject.org domain expired today? Apr 28 10:18:44 RP: right, that could be the case. let me try to dig in this direction too. Apr 28 10:20:47 Are you aware that the certificate on https://git.yoctoproject.org/ has expired? Apr 28 10:23:23 psaavedra: yup Apr 28 10:23:29 larsjep: yup Apr 28 10:24:50 ok, great. Apr 28 11:03:37 RP: compared the logs, the order is the same Apr 28 11:19:58 kanavin_home: I guess that is good but doesn't help Apr 28 11:22:47 kanavin_home: I wonder what happens if you pull the packages from the autobuilder for base-files/shadow and try using them injected into your build Apr 28 11:23:04 kanavin_home: I'm sure you have plenty of ideas to explore, just thinking out loud Apr 28 11:25:33 RP: I m trying another thing now. One way it seems to fail is building two SDKs in a row for the same image, but changing SDKMACHINE. Apr 28 11:36:41 kanavin_home: hmm, right. And it should use the same target packages for both Apr 28 11:37:21 yeah, maybe dnf trips over the rootfs that is preserved from previous populate_sdk. will find out in a minute. Apr 28 11:38:01 note that this happens in plain image builds too, but I think the reason is the same (if it is the reason) Apr 28 12:03:16 RP: I have reproduced! Apr 28 12:14:39 kanavin_home: great! That should help a lot! Apr 28 12:26:07 kanavin_home: I have an answer regarding patch-wrapper in quilt btw Apr 28 12:26:15 kanavin_home: well, part of one Apr 28 12:26:49 kanavin_home: note that do_compile_ptest does "make bin/patch-wrapper", then installs it to /usr/lib/quilt/ptest/bin/ Apr 28 12:27:01 kanavin_home: I'm guessing it sometimes works and sometimes doesn't due to PATH issues Apr 28 12:36:57 Hi Channel, ... To fulfill a contract, I should provide all used sources (without history) of a build. Is there anything prepared under Yocto? Important would be the point "without history". Apr 28 12:37:57 the archiver class is designed to satisfy upstream sources requirements Apr 28 12:38:18 and obviously a copy of your layer if needed Apr 28 12:38:46 rburton: Okay thanks. I will look into this! Apr 28 12:49:08 kanavin_home: the runner always ensures its in the correct directory and it looks like there is no code to explicitly do that so perhaps its just different ways of running it? Apr 28 12:49:23 (fix being to be specific about the CWD in the script) Apr 28 12:50:29 RP: I am pulling my hair, I did a cleansstate, and the issue no longer seems to appear. There is a very particular sequence that triggered it and I can't remember :( Apr 28 12:54:01 rburton: Thanks. Exactly what I wanted. Apr 28 12:59:32 kanavin_home: I hate it when that happens :/ Apr 28 12:59:45 kanavin_home: it does at least limit the potential causes Apr 28 13:04:53 RP: I got it back \0/ Apr 28 13:05:08 now I will be extra careful to not erase anything :) Apr 28 13:05:45 kanavin_home: once you can reproduce it at will, you're usually 80% of the way to fixing it Apr 28 13:07:12 RP: I'm still unsure what the exact sequence is, but circulating between configurations 5,6,7 in qa-extras2 and default one did the trick Apr 28 13:11:04 kanavin_home: I'd probably pick a new directory and see if I could script the sequence to reproduce, then minimise it Apr 28 13:11:19 kanavin_home: or just figure out why it fails as that could shed light Apr 28 13:12:43 RP: dnf seems to be writing (and thus creating) to /var/log before the package that creates /var/log as a symlink is installed Apr 28 13:13:53 kanavin_home: hmm, 'fun' Apr 28 13:33:19 kanavin_home: is there a bug ID for what you're working on? writing to /var/log before a /var/log symlink is installed sounds not unlike what a couple of my defects are the result of Apr 28 13:50:13 I run `oe-pkgdata-util find-path bzip2recover` to find its package name. I get `bzip2`. But I can't find any binary that called `bzip2recover` under `bzip2` building directory (work/raspberrypi3/bzip2/...) - Why is that and where can I find the relevant binary file? Apr 28 13:53:54 nacknick: do you have rm_work enabled? Apr 28 13:54:36 qschulz: can you explain please what does it mean and how to check it? Apr 28 14:02:03 nacknick, bitbake -e bzip2 | grep ^INHERIT= | grep rm_work Apr 28 14:03:12 kroon: provides nothing Apr 28 14:03:12 nacknick, having it enabled will delete redundant build artifacts Apr 28 14:03:50 qschulz kroon: Is this related to "native" and "not-native" packages? Apr 28 14:03:53 tgamblin: I am working on upgrading the rpm/dnf/libdnf stack. There is no separate bug for it. Apr 28 14:08:10 RP: patch for base-files dnf failure sent. This appears to be a race, between lock creation code and package installation. Apr 28 14:10:43 Hi, we do have several recipes which use AUTOREV, this is great for integration testing, but for release not so much. Now I was thinkin of creating a CI job which fetches the rev, adds them to the recipes and commits them. Ideally this would reuse bitbake infrastructure... Anybody done something like this? Good/bad idea? Apr 28 14:12:54 kanavin_home: nice find, thanks. Missing Upstream-Status though ;-) Apr 28 14:13:49 oh. will add and resend Apr 28 14:14:24 kanavin_home: thanks, sorry to be a pain :) Apr 28 14:17:34 Anyone else run into intermittent problem with cve-checker failing, because multiple builds are running, and both try to get a lock on the CVE database (in shared downloads folder)? Apr 28 14:19:00 Hi Apr 28 14:19:59 It seems the yoctoproject.org certificates is expired. Did you know if yocto team is already working to renew it? Apr 28 14:20:15 ykrons: yes, should be fixed in the next few hours Apr 28 14:20:37 ok, thanks for the feedback and quick fix Apr 28 14:32:37 nacknick: no, INHERIT set to rm_work is a way to delete temp files when the recipe has been successfully built and packaged, it lowers the required space on your host to build an image Apr 28 14:33:19 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-rm-work Apr 28 14:34:04 qschulz this is what I get: `INHERIT=" reproducible_build_simple package_ipk buildhistory buildstats image-mklibs debian devshell sstate license buildstats-summary webos_base remove-libtool image-buildinfo icecc blacklist sanity"` Apr 28 14:34:04 so if you're checking your recipes by looking into its WORKDIR but you have rm_work enabled, you will not go far :) Apr 28 14:34:41 nacknick: no rm_work so should be good Apr 28 14:35:41 Any other reason why there is no "image" directory and no binary file? Apr 28 14:37:09 nacknick: did you clean the workdir/tmpdir recently but not the sstate-cache? Apr 28 14:37:35 qschulz: טקד Apr 28 14:37:39 qschulz: yes Apr 28 14:38:04 nacknick: there you go then :) everything is taken from the sstate-cache, so most of the WORKDIR of the recipe won't be "reinstalled" Apr 28 14:38:35 So how to fix it? Should I remove sstate-cache? Apr 28 14:38:49 nacknick: it's not broken, so you don't need to fix it Apr 28 14:39:17 But I need all the executable files :| Apr 28 14:39:26 bzip2recover as well Apr 28 14:39:33 nacknick: when, where, how? Apr 28 14:39:47 why would you need to get the binaries from the WORKDIR? Apr 28 14:39:49 now, under "image" dir Apr 28 14:40:01 because I want to patch them Apr 28 14:40:11 I modify them Apr 28 14:40:30 patch them within the recipe Apr 28 14:40:37 can't Apr 28 14:40:45 what do you mean you can't? Apr 28 14:40:51 you do a bbappend in worst case Apr 28 14:41:18 I need to send bzip2recover to remote server and to get a replaced one Apr 28 14:41:23 patched one Apr 28 14:41:28 can't do it locally Apr 28 14:42:02 nacknick: can the recipe send bzip2recover to your remote server? Apr 28 14:42:16 yes. this is what it does in other recipes Apr 28 14:42:42 but I can't find bzip2recover Apr 28 14:42:44 file Apr 28 14:42:57 you have a recipe that produces this bzip2recover right? Apr 28 14:43:07 yes. should be Apr 28 14:43:13 it's built in Apr 28 14:43:20 well, patch this recipe to send the bzip2recover to the remote server? Apr 28 14:43:31 with a bbappend? Apr 28 14:43:33 yes. this is what i'm doing Apr 28 14:43:46 nacknick: ok, at least we're on the same page Apr 28 14:44:02 but specifically bzip2recover file, can't be found in the work dir Apr 28 14:44:11 so I have nothing to send to the remote server Apr 28 14:44:24 nacknick: in which task is the non patched binary created? Apr 28 14:44:49 I think it's different between recipes Apr 28 14:45:24 for this one specifically Apr 28 14:45:47 https://pastebin.com/MdXTnpV6 Apr 28 14:46:47 nacknick: /me shrugs Apr 28 14:46:58 you don't know? Apr 28 14:47:38 worst case scenario, you can have a do_install_append() and there you take the binary from ${D} send it to your remote server and reinstall it into ${D} Apr 28 14:48:05 maybe it's smarter to have it in a do_install_prepend() and take it from ${B}, I don't know Apr 28 14:48:07 qschulz This is exactly what I'm doing for all other binaries Apr 28 14:48:19 ${D} I mean Apr 28 14:48:25 nacknick: then I fail to see what's the issue? Apr 28 14:48:55 bzip2recover, in contrary to other binary files of other packages, is just missing! Apr 28 14:49:06 It does not exist in the build directory Apr 28 14:49:58 I don't have even "image" directory under: `bzip2/1.0.6-r5` Apr 28 14:50:12 Now it's clear? Apr 28 14:50:33 nacknick: no :) image was created the last time do_install needed to be run, it hasn't run since then Apr 28 14:50:51 are you trying to find the path to bzip2recover? Apr 28 14:51:06 yes Apr 28 14:51:31 But I ran `bitbake bzip2 -c cleansstate` - does not it force to rebuilt it? Apr 28 14:51:39 it does Apr 28 14:51:54 so I still has no "image" dir Apr 28 14:51:55 well, you need to rebuild bzip2 afterwards but yes Apr 28 14:52:01 of course Apr 28 14:52:47 you do have packages and package-split directories at least? Apr 28 14:52:51 So even after cleaning and rebuild it - I have no binary file called bzip2recover Apr 28 14:53:08 yes I do Apr 28 14:53:43 look there then, but still weird than there is no image directory Apr 28 14:55:56 qschulz you're right I could find bzip2recover under "package" dir Apr 28 14:56:31 does it mean I can modify it (send to the remote server and replace it) and get it in the final image? Apr 28 14:59:34 a better approach would be to have a do_package function that just sweeps $bindir $libdir and patches everything Apr 28 15:01:06 rburton is there do_package_append? because I can't overwrite 3rd party recipe's do_package Apr 28 15:01:19 you can _append everything but i explicitly didn't say append Apr 28 15:01:49 rburton so you suggest to overwrite the existing do_package task Apr 28 15:02:11 do_package basically calls PACKAGEFUNCS Apr 28 15:02:24 prepend to that Apr 28 15:03:09 then just walk $D$bindir $D$libdir etc swapping binaries Apr 28 15:03:44 as a class thats probably about 20 lines of python Apr 28 15:04:34 rburton: 1) I don't know how to call PACKAGEFUNCS. 2) If some recipe overwrite do_package by itself, I'm not sure it's smart to overwrite it again with my code Apr 28 15:04:49 look in package.bbclass for PACKAGEFUNCS Apr 28 15:05:25 (pretty sure i explained how i'd implement this some months ago) Apr 28 15:05:54 I think I did what you said. Back then you said with install_append Apr 28 15:05:55 alternatively add a task between install and package Apr 28 15:07:02 like install_append? Apr 28 15:07:08 no Apr 28 15:07:22 addtask signbinaries after do_install before do_package Apr 28 15:07:46 Why does it matter? Apr 28 15:08:19 because its neater and lets you isolate code changes, Apr 28 15:09:07 New news from stackoverflow: Is there a way to run Jenkins with Docker as non-root user? Apr 28 15:09:16 I'm not sure I understand your second reason Apr 28 15:09:40 in what way is altering binaries that have been installed a tweak to the recipe's install function Apr 28 15:09:42 its not Apr 28 15:09:45 you're changing the binaries Apr 28 15:09:58 nacknick: the directory in which bzip2recover is does not matter, you just interested in the path in the system so you can get the file from ${D}/path/to/bzip2recover (or maybe something different than ${D} if in another task than do_install, but to be checked of course) Apr 28 15:10:57 rburton: Anyway, like I said, my problem now is that there are packages that are missing "image" directory. So it does not matter if I'm looking for that dir with "install_append" or "signbinaries" Apr 28 15:11:21 incorrect Apr 28 15:11:32 why? Apr 28 15:11:42 if you're running in code after do_install has run there will be the image directory Apr 28 15:12:02 if you're diving around in a terminal then you need to be sure you've ran the tasks yourself Apr 28 15:12:22 so you said it's been deleted? I can't find any deletion command in the recipe Apr 28 15:12:26 nacknick: whatever is in workdir shouldn't matter if the resulting binary is ok. It's just a workdir, so I wouldn't worry much if "image" is missing because if the task actually is successful and does what it's supposed to do, who cares if some temporary intermediary directory is not there at the end of a recipe build? Apr 28 15:12:39 what he said Apr 28 15:13:06 the recipe doesn't control creation or deletion of $D, it just populates it during do_install Apr 28 15:14:08 nacknick: there is a cleandirs flag for tasks which removes directories before it's run, so it does not have to be an explicit call to "rm". Apr 28 15:14:22 qschulz: it matters to me because I want to replace a lot of binaries automatically, so I have to know where the files reside Apr 28 15:14:27 in $D Apr 28 15:14:59 $D has a lot of subdirs Apr 28 15:15:03 nacknick: can't you just write in your recipe to get your file from ${D}/path/to/bzip2recover and test? Apr 28 15:15:48 the certificate seems to be renewed Apr 28 15:15:51 you know where bzip2recover is, from package-split directory (and if you really want to know, you uncompress the bzip2 package in TMPDIR/deploy//bzip2* Apr 28 15:16:05 really want to know => really want to be sure Apr 28 15:16:15 I can, I just want to make it easier and more clear. If "image" dir is not always there, and "package" is, I prefer to replace the content of "package" dir allways Apr 28 15:16:36 nacknick: packages is created from the content of image AFAIK Apr 28 15:17:11 nacknick: do you know the difference between image/ and package/? Apr 28 15:17:14 so if image never exists, you have bigger problems than just not being able to find your file Apr 28 15:17:21 hi everyone. i have an issue when making an initramfs image where if i put "KERNEL_IMAGETYPES_append = " Image" Apr 28 15:17:27 qschulz: no. I don't Apr 28 15:17:34 rburton: ** Apr 28 15:17:43 into my local config then the initramfs image include the kernel in /boot, but i do not need this. Apr 28 15:17:45 nacknick: so why do you prefer to patch package/ instead of image/ Apr 28 15:18:05 if i remove the extra KERNEL_IMAGETYPES (which i need) then it doesn't put it into /boot Apr 28 15:18:13 Because the binary file I'm looking for is there and there is no "image" dir Apr 28 15:18:29 then you're looking in a partial build tree Apr 28 15:18:39 stop looking in tmp and actually code something generic Apr 28 15:18:58 such as..? Apr 28 15:19:16 nacknick: the point rburton was trying to make in advising you to create a class was so that you just define a task, put it in the right place in the task hierarchy, use some variable to give a glob or a path to the binaries you want to patch and in the recipes you need to patch, you inherit this class and set the variable correctly. Very neat, no duplicated code ever Apr 28 15:19:28 I want to replace files so this will influence the final image, you know... Apr 28 15:19:34 rburton: hopefully I summed up correctly what you wanted to say ^ Apr 28 15:19:46 yes thanks qschulz :) Apr 28 15:19:55 first question: are you patching everything or just some files Apr 28 15:20:59 qschulz, kanavin_home, RP, certificate issues have been sorted. Apr 28 15:21:10 does anyone have any tips on how to exclude kernel images from /boot? Apr 28 15:21:16 rburton: only some files from a pretty big list Apr 28 15:21:45 halstead: \o/ thx Apr 28 15:21:57 nacknick: what qschulz is spot on then Apr 28 15:22:13 Now to make this not happen again. Apr 28 15:22:27 rburton: I wish I understand what he means and how to do it Apr 28 15:22:50 write class that has a task that reads a variable to know what files to patch Apr 28 15:22:58 inherit class in your distro Apr 28 15:23:03 set that variable in the recipes Apr 28 15:23:13 halstead: from my very amateur use case, I'm using caddy webserver which has automatic renewal of let's encrypt certs, so never have to bother checking. I think there is some cerberos or something like that to automate it yourself without caddy Apr 28 15:24:52 nacknick: and put the task before the packages are created. This rburton knows more about, PKGFUNCS he talked about? And since the package tasks anyway need ${D} I guess you can just take your file from ${D} in that task Apr 28 15:26:41 i prefer whole new tasks for something so dramatic as patching binaries like that Apr 28 15:27:35 rburton: qschulz: OK. Just what do you mean in "take your file from ${D}". Don't I need a full path to it? And even I find the original binary, where should I put the patched one? Apr 28 15:27:43 halstead: can you run certbot in cron on the various hosts? Apr 28 15:27:49 qschulz, Thanks for the tip. I'm using the cronjob recommended by the certbot team. But I split services running on one server across several so the automatic renewal failed. Apr 28 15:28:18 nacknick: if you wanted to do all binaries then https://pastebin.com/zKXXciye is just missing the actual swapping of binaries Apr 28 15:28:33 presumably you want the new file to have the same name as the original Apr 28 15:29:04 if you want a subset of files then as qschulz said, set a variable in the recipe Apr 28 15:29:17 opello, Yes. That's set up correctly now. And I'm updating monitors to alert on aging certs correctly. Apr 28 15:29:21 eg PATCH_THESE_FILES = "${bindir}/bzip2" Apr 28 15:29:38 the class can read that variable to get the filenames Apr 28 15:30:01 halstead: :) nice; i use aliases to have a single physical directory hold the challenge file and that seems to work well in my use case Apr 28 15:31:22 nacknick: ${D} is the full path to "image", so you just need to know relative to "image" where bzip2recover is. But it does not have to be relative to "image" because in 99% of the cases, it's the same path in package-split and in the final rootfs (the one you boot on your target platform) Apr 28 15:31:44 opello, I like that sort of configuration. When we have multiple domains on one server that's exactly how I do it. Apr 28 15:32:08 so relative to something representing the root of your rootfs at some point in time, but ${D} should do it Apr 28 15:32:57 rburton: and it it's a very specific and finite and final list of files (without globs), maybe even have the variable set in the distro so that nothing has to be done from the recipes? Apr 28 16:10:45 Morning folks, it's been a while! Apr 28 16:12:02 sgw: good evening o/ Apr 28 16:13:05 morning sgw! Apr 28 16:13:15 Hmm, has anyone created a layer & tcmode to use an external yocto sdk as an external toolchain yet? Apr 28 16:13:40 kergoth: last i heard that wasn't trivial for reasons i am unaware of Apr 28 16:14:30 I am wondering if there is a generic version of the kernel's shared_workdir? I have a project that creates multiple packages from a single git, I think these packages should be in separate recipes rather than a monolithic recipe Apr 28 16:14:30 Hmm. Would have to pull in the environment-setup to find the paths obviously.. beyond that i'm not sure what would prevent it. might have to give it a go Apr 28 16:15:21 rburton: afternoon! Love seeing those FB biking pics! Apr 28 16:15:37 sgw: gcc does it too but i think both replicate the logic. mirror what gcc-source does? Apr 28 16:15:51 Ah, I will go look there Apr 28 16:16:07 It's been a while since I have poked around OE and bitbake classes! Apr 28 16:33:27 sgw: Morning Sau! Apr 28 16:35:38 alejandrohs: Hi there! How's Seattle (I think) treating you? Apr 28 16:40:56 warning stupid question: is there a nice way to relocate the bitbake cache (recipe parsing)? CACHE has TMPDIR hardcoded :/ Apr 28 16:41:24 sgw: had to run away from there before the situation got worse haha, but doing great so far Apr 28 16:42:11 alejandrohs: where are you now then, back in MX? Glad to hear your healthy! Apr 28 16:42:12 (I basically have the tmpdir in a tmpfs, sstate-cache and dldir on SSD. But obviously sometimes I run out of RAM so I need to clean my tmpdir, but then the metadata cache is gone :D) Apr 28 16:43:33 qschulz: build dir in real disk, tmpdir in tmpfs Apr 28 16:44:25 RP: The folks I talked to at ELCE about licensing were involved in https://github.com/oss-review-toolkit/ort. They wanted to add Yocto integration. It's fell off my list due to everything else going on Apr 28 16:49:37 rburton: mmmmm that's what I have already I think. Though there is a heavy wrapper around oe-init-buildenv so maybe something's fucked up there. Apr 28 16:50:39 qschulz: my setup is build dir in ~/poky/build, local.set sets DL_DIR and SSTATE_DIR to ~/... and TMPDIR to /scratch/poky (which is tmpfs) Apr 28 16:50:52 bitbake cache is in build/cache/ Apr 28 16:51:05 morning bluelightning Apr 28 16:51:39 very early morning for bluelightning! Apr 28 16:51:58 morning rburton, sgw Apr 28 16:52:41 indeed, coming up on 5AM Apr 28 16:59:59 rburton: I thought I had something along those lines but there is definitely something wrong somewhere, I have a cache directory in both poky/build and /scratch/poky.... I'll investigate, no need to help further :) Thx! Apr 28 17:04:34 RP: is there any way to have multiconfig configurations enabled/loaded/limited per machine or per recipe? Apr 28 17:06:41 sgw: texas right now Apr 28 17:07:05 denix: can you elaborate? Apr 28 17:12:10 denix: per recipe doesn't make sense. I think you could do BBMULTICONFIG_ as override syntax Apr 28 17:12:27 denix: just guessing from memory mind Apr 28 17:13:36 RP: thanks, I'll try. is it safe to set BBMULTICONFIG in machine.conf? looks like BB_CURRENT_MC.conf gets loaded before machine.conf... Apr 28 17:14:55 denix: You are right, we had to do that as the multiconfig can set the MACHINE Apr 28 17:15:30 denix: although the base MACHINE could set the other mulitconfigs so it could work Apr 28 17:16:10 RP: heh, I rather need it in reverse - MACHINE setting MULTICONFIG Apr 28 17:16:43 rburton: About what you suggested. If I create my own task as you said, for what I need a class as well? Apr 28 17:17:10 nacknick: because otherwise you're writing a new task into every recipe Apr 28 17:17:23 ah ok Apr 28 17:18:17 RP: so, that BB_CURRENT_MC confused me a bit. that is conf/multiconfig/default.conf right? Is it set my bitbake itself? Apr 28 17:19:50 last question for today (I promise): I get a message `Files/directories were installed but not shipped in any package`. it happens only in a specific package, even though I do the same thing for several packages (adding mylib.so.1 to {D}/lib). Why does it happen? Apr 28 17:20:35 because the FILES don't match that filename Apr 28 17:20:37 I tried to add: `FILES_${PN}-lib="mylib.so.1"` - to the recipe. did not help Apr 28 17:20:51 are you not just swapping binaries directly? Apr 28 17:21:00 no. added a new one Apr 28 17:21:04 presumably the package doesn't have a PN-lib Apr 28 17:21:25 if there's a *new* file to be added, package that in its own recipe Apr 28 17:21:30 it does actually. it uses it in other place of the recipe Apr 28 17:21:32 denix: no, thats the one being used at the moment for that recipe, the taskdata objects are still separate, thats how it knows which one its using Apr 28 17:21:33 nacknick: That should be: FILES_${PN}-lib = "/lib/mylib.so.1" Apr 28 17:22:12 Saur: you're right. I used {base_libdir}mylib.so Apr 28 17:22:28 alejandrohs: ok, I guess I need to experiment some more... Apr 28 17:22:40 FILES_${PN}-lib = "${base_libdir}/mylib.so.1" Apr 28 17:23:01 denix: idk your use case but if it helps you can pass BBMULTICONFIG on layer.conf Apr 28 17:23:17 denix: and basically just could be activated if a dependency to it is found Apr 28 17:23:31 but again, not usre if thats what you want Apr 28 17:24:14 OK. never mind. I will keep trying... Apr 28 17:25:30 denix: and actually now that I remember, you can re-set MACHINE after it the machine.conf was parsed, and from there you can have several multiconfigs, thats how I implemented a multiarch system using a "single" MACHINE Apr 28 17:25:44 after it *parses* the machine.conf * Apr 28 17:25:49 alejandrohs: actually that's how I first done it, but then it is enabled for all my machines, but I only need to limit it to some Apr 28 17:26:19 denix: yeah that second option looks better Apr 28 17:26:31 I *HATE* ntp... why does it always take 30min to compile from scratch. Apr 28 17:26:33 denix: bitbake itself does set it, yes Apr 28 17:27:20 qschulz: ntp? or ltp? Apr 28 17:28:42 alejandrohs: so, I moved BBMULTICONFIG setting from layer.conf into individual machine.conf now - was just wondering if it was safe doing it from the ordering perspective (machine vs. multiconfig) Apr 28 17:31:16 denix: trying to find the code for that Apr 28 17:31:29 RP: thanks. so, this is a bit mind-twisting - effectively bitbake gets restarted for each additional mc:* call and it re-parses everything from scratch and keeps separate taskdata objects, as alejandrohs mentioned above... Apr 28 17:34:34 denix: IIRC the machine.conf will be parsed, you set BBMULTICONFIG there at the beginning so now it knows there are several multiconfigs, and then you re set MACHINE to the one you'll treat as default Apr 28 17:36:02 RP: ntp Apr 28 17:36:15 10min for configure, 10 for compile, 10 for install Apr 28 17:37:07 RP: in the makefile they are checking the dependencies as one would do for the configure step but also for compile and install for some reason /me shrugs Apr 28 17:47:35 denix: yeah thats how I did it, the only part missing is after re-setting the MACHINE, theres a require directive to the machine.conf that will be default Apr 28 17:58:47 alejandrohs, RP: hmm, so I had to separate TMPDIR per machine now and moved out DEPLOY_DIR to be shared. now I get conflicts when writing ca-certificates package in there. sstate-cache is also outside of TMPDIR - is there anything else I need to move so the package gets re-used? Apr 28 18:28:03 alejandrohs, RP: so, this seems to work per-machine, besides the above clash of common packages in deploy... Apr 28 19:04:58 qschulz: it sounds wrong :/ Apr 28 19:05:57 denix: the clash will depend on how you configure it and whether the elements are compatible or not Apr 28 19:11:51 RP: ca-certificates is noarch/all package. before, when DEPLOY_DIR was inside TMPDIR, different machines would re-use it. now TMPDIR is per-machine and DEPLOY_DIR + sstate-cache are outside - machines can no longer re-use noarch/all packages Apr 28 19:12:31 RP: nothing else in the config changed, besides separating TMPDIR due to multiconfig Apr 28 19:14:36 denix: why do you need to separate TMPDIR? Apr 28 19:14:56 denix: if the configs match, the sstate should be reused which suggests its not matching Apr 28 19:15:14 denix: compare the tmp/stamps files in the different TMPDIRs Apr 28 19:17:30 RP: ok, I can check stamps. the reason to separate TMPDIRs was based on our earlier discussion. e.g. multiconfigs use different TCLIBC, hence TMPDIR=tmp-${TCLIBC}. but ca-certificates does not depend on TCLIBC... Apr 28 19:18:54 denix: ok, I have to admit I don't know how well the system copes with different TCLIBC in the same tmpdir right now. I'd check the stamp files Apr 28 19:20:50 RP: I actually tried using the same TMPDIR initially and it would clash much sooner, somewhere in stamps, I believe... Apr 28 19:21:18 denix: I can imagine ways TCLIBC collides Apr 28 19:21:30 (sadly) Apr 28 19:31:58 khem: did you ever find the cause of the undefined _sysconfigdata issue? I'm not seeing it with prserv, but with devtool modify, and have your patch applied Apr 28 19:32:11 * kergoth backs up to 3.7 for now Apr 28 19:38:45 kergoth: 20.04? Apr 28 19:42:46 nope, but i do have 3.8 installed with pyenv Apr 28 19:42:59 so probably hitting the same issues, i'll check oe-core for commits i'm missing Apr 28 19:45:20 kergoth: what host distro? Apr 28 20:16:45 sgw: didn't see you earlier, was in meetings. Nice to see you here! :) Apr 28 20:18:08 RP: no worries, I drop in and out, but actually am doing some recipe work related to my current project, hope your doing well (or as well as can be in this wacky time) Apr 28 20:22:39 sgw: I'm ok thanks, just lonely. Hope you're ok, looked like you were enjoying the beer :) Apr 28 21:50:07 kergoth:I am not seeing it anymore Apr 28 21:53:16 RP:seeing openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_fetch) failed with exit code 'setscene whitelist' when building eSDK Apr 28 21:53:55 I dont even understand what "setscene whitelist" is for an exit code Apr 28 22:11:13 khem: I think that means it tried to rerun the pseudo build when it should have been locked in sstate Apr 28 22:11:22 that confused the system so it aborted Apr 28 22:11:42 this is the part where I said eSDK needs work in being more understandable Apr 28 22:33:02 OK, so perhaps something changed in sigs somewhere ? Apr 28 22:34:26 Hi, I have a big problem with temporary partition in ram(ram devision), because I have some tmpfs partition with 200 MB size and a rootfs with 15 MB size!! I want to decrease from temporary partitions and increase rootfs size Apr 28 22:34:38 can I do this in yocto ?? Apr 28 22:35:34 I want to do it one time for ever, can I define ram devision partitions in yocto ?? Apr 28 22:40:40 fedora32 vm created :) Apr 28 22:52:18 i686 or x86_64? Apr 28 22:52:40 arm thumb, 32 or 64 ? Apr 28 23:47:02 how I can add valgrind to my Image ? Apr 29 00:05:00 RP: sgw did anyone say beer? Apr 29 00:05:50 alejandrohs: homebrew! It's almost that time of day! Actually working on steaming some rice for a batch of sake! Apr 29 00:09:35 denix: I dont remember the exact details but yeah I think at some point just realized having separate TMPDIRs per TCLIBCs was just sane, and didnt get to the point where I had the ca-certs issue because of that Apr 29 00:09:55 sgw: Still have to try the homebrew one!, now I remember you mentioning it before Apr 29 00:10:25 first time i hear about homebrew sake tbh Apr 29 00:10:31 alejandrohs: quite strange you don't see ca-certs issue with separate TMPDIRs... Apr 29 00:10:33 your welcome here anytime after the world opens up again phyically distanced for a time Apr 29 00:10:48 sgw: where are you now? Apr 29 00:11:12 https://homebrewsake.com/ (actually an ex-Intel person manages the site!) Apr 29 00:12:06 denix: Still at Intel but working on a different distro project that is currently CentOS based, but we are looking at an OE/Bitbake alternative. Apr 29 00:12:25 sgw: clear? Apr 29 00:12:33 So I dropped back in to wave and cause trouble Apr 29 00:12:48 no not clear, StarlingX (starlingx.io) Apr 29 00:14:04 Edge Cloud stuff Apr 29 00:14:20 sgw: nice to see you again! :) Apr 29 00:14:58 Yeah, I miss hanging out with this crowd, much more active than our chat, I do pop in every so often! Apr 29 00:15:58 yeah, we definitely need another distro! care to convert your crowd to oe/yocto? :) Apr 29 00:17:11 Moh3N: IMAGE_INSTALL_append = " valgrind" in local.conf Apr 29 00:17:37 It's being worked on! Initial work is up already, but long way to go and needs some layer restructuring and an actual distro layer! Currently using poky as the base, but really should not. Apr 29 00:17:42 denix: whats the ca-certs issues Apr 29 00:18:03 khem: multiconfig related Apr 29 00:18:22 Sort of classic new distro move (base it on poky) Apr 29 00:18:26 denix: ok, so its newlib/glibc combo I believ ? Apr 29 00:18:41 sgw: nice! Apr 29 00:18:47 sgw: meta-centos Apr 29 00:18:59 Nooo! Apr 29 00:19:04 meta-starlingx Apr 29 00:19:09 ok meta-centos7 Apr 29 00:19:41 khem: yeah, kind of. separate TMPDIRs, but there's clash of ca-certs packages, which are noarch/all Apr 29 00:20:10 denix: yeah noarch bites quite a bit when you build multiple libcs Apr 29 00:20:38 I use to see this on OE builder quite often ( woth glibc/musl ) but it seems to be doing better lately Apr 29 00:20:49 but there are issues there I know Apr 29 00:21:23 khem: any ideas to get it sorted out? Apr 29 00:22:23 what error do you see, I usually see that its rebuilt due to a dependency being arch specific and used as RDEP instead of RRECOMMEND Apr 29 00:23:50 my fixes sometimes also included SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS see https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/conf/layer.conf#L54 Apr 29 00:24:53 khem: I'm trying to re-use the same deploy from multiconfig with separate TMPDIR due to TCLIBC and both of them build own ca-certs and they clash in do_write_ipk Apr 29 00:25:23 yeah in this case they are not allarch I am afraid Apr 29 00:26:21 what makes them not allarch? Apr 29 00:26:27 allarch should be common across multiconfigs too like multiarch Apr 29 00:26:35 usually a dependency perhaps Apr 29 00:27:03 I would check bitbake-diffsigs Apr 29 00:27:13 sgw: definitely up for that Apr 29 00:27:59 khem: hahaha meta-centos Apr 29 00:29:41 denix: I think once youre able to figure out why its happening we should file a bug to keep track of it, worst case scenario to state the scope that multiconfig supports Apr 29 00:32:03 denix: I run daily builds of glibc/newlib but dont share neither TMP nor DEPLOY Apr 29 00:32:47 one way to narrow it further is to build it for glibc and then build for musl and see if it ends up rebuilding, then the problem is generic otherwise, its multiconfig speicific Apr 29 00:33:21 alejandrohs: yeah, not sharing DEPLOY_DIR would work, but what if you need to re-use artifact binaries between them? Apr 29 00:33:54 using separate DEPLOY_DIR is hiding the problem. Apr 29 00:34:09 e..g if you were doing feeds it would show up Apr 29 00:34:37 khem: exactly Apr 29 00:35:49 denix: I do share them, but I have a sort of shared directory only with the artifacts, not ipks,rpms, etc Apr 29 00:36:00 I think if you share sstate it would be evident too, as the version will keep toggling Apr 29 00:36:31 denix: these are declared on the shared machine so the variable is on both datastores Apr 29 00:37:07 denix: not saying, your way shouldnt be possible thats just how I did it **** ENDING LOGGING AT Wed Apr 29 02:59:57 2020