**** BEGIN LOGGING AT Fri Sep 18 14:26:43 2020 **** BEGIN LOGGING AT Fri Sep 18 14:31:50 2020 Sep 18 14:40:42 anyone know if the bugr report happens through bugzilla or a mailing list? Sep 18 14:44:23 shan1: its expected you open a bug in bugzilla Sep 18 14:44:36 and then send a patch! ;) Sep 18 14:45:10 yes, it depends where the issue is. meta-oe stuff would be the mailing list and not the bugzilla as the bugzilla basically only covers oe-core/bitbake Sep 18 14:45:24 devtool is on bugzilla right? Sep 18 14:45:27 * zeddii goes back to his yocto project summit CFP hackery. Sep 18 14:47:47 shan1: its an oe-core tool, so ye Sep 18 14:47:49 yes Sep 18 14:48:13 as zeddii says, patches are very welcome, we don't have many people working on bugs atm sadly **** ENDING LOGGING AT Fri Sep 18 14:50:49 2020 **** BEGIN LOGGING AT Fri Sep 18 14:50:49 2020 **** BEGIN LOGGING AT Fri Sep 18 14:51:33 2020 Sep 18 14:56:04 Heya... What strategies do you guys have for splitting build directories, downloads and sstate-cache dirs? I've got maybe 5-10 target machines that I build over a few different Yocto versions. I kind of feel like keeping separate download and sstate cache dirs per major yocto release makes sense. However what about build dirs? One per CPU type, assuming the same yocto version and that no major different component differences? Or Sep 18 14:56:04 should I literally keep it to one build per target machine ever? Sep 18 14:56:59 I can't seem to find anything about the intended way of doing things for anything more than building one target at a time and I'm sure lots of people must do multiple builds...? Sep 18 15:00:42 pev: DL_DIR can be shared between all, SSTATE_DIR probably makes sense per release series. build directories are safe for multiple machines, not multiple distro configs though Sep 18 15:01:32 you can safely put all sstate in one too, I've just found it easier to keep separate for deletion **** BEGIN LOGGING AT Fri Sep 18 15:04:07 2020 Sep 18 15:05:50 @zeddi I am willing to submit a patch, where is the source code and where should I be looking for `devtool` scripts? **** BEGIN LOGGING AT Fri Sep 18 15:10:43 2020 Sep 18 15:11:27 RP: If you don't mind sanity checking, would the following look like it makes sense? https://pastebin.com/Caksb6N7 **** BEGIN LOGGING AT Fri Sep 18 15:13:49 2020 Sep 18 15:38:42 pev: its ok, but I'd combine stuff personally. sstate should not break over different releases, its just a convenience thing that I end up splitting them Sep 18 15:38:43 Hi, I'm trying to automatically load the spidev kernel module on boot. I've added KERNEL_MODULE_AUTOLOAD += "spidev" into my .conf file and now there is a /etc/modules-load.d/spidev.conf file with spidev in there. But for some reason it doesn't load on boot. If i use insmod or modprobe it is loaded just fine. Is there anything else I have to do? It Sep 18 15:38:44 seems like its ignoring the /etc/module-load.d/ conf files. **** BEGIN LOGGING AT Fri Sep 18 15:49:59 2020 Sep 18 15:57:15 pev: We share sstate and DL_DIR across all our "products" but each product has it's own build directory. We have about ~50 products across 5 different yocto version (2.1 - 3.1) **** BEGIN LOGGING AT Fri Sep 18 16:08:05 2020 Sep 18 16:26:55 Jebee: perhaps it has dependency on other modules, check the error logs since KERNEL_MODULE_AUTOLOAD will add it to module-load time which might be early in boot. Sep 18 16:28:17 khem: there should be an error in dmesg correct? Sep 18 16:28:18 RP: Copy that, thanks. At the moment I want to keep DL_DIR cache split as we can use it to package and distribute along side release for offline build but yeah, combining sstate I dont see as so compelling bar needing to delete occasionally. I still feel like I really should wipe it (or not reference) before doing formal release builds though... Sep 18 16:28:42 JPEW: Thanks... Even 'products' that share same CPU / reference design? Sep 18 16:29:21 JPEW: I mean I think separation is what comes naturally to me, but struggle to work out how Yocto expects me to behave..! Sep 18 16:30:21 Ya, we separate each product because there are "product specific" recipe changes (although, I don't personally *like* that) Sep 18 16:30:46 Since sstate is shared between all products, it makes it fast to build a similar product b/c most of it pulls from sstate Sep 18 16:31:54 It's also easier to have the consistent rule that all products have their own directory than try to codify a mechanism where the could share :) Sep 18 16:37:57 Jebee: yes or on journal if you use systemd Sep 18 16:39:29 pev: you can create a source mirror ( outside dl_dir) and rsync your dl_dir to it, then you can do clean production builds with clean dl_dir **** BEGIN LOGGING AT Fri Sep 18 16:42:12 2020 Sep 18 16:43:24 RP: looking at test_gdb_hardlink_debug are there more msgs coming from gdbtest() ? I dont see much in logs Sep 18 16:43:37 AssertionError: GDB /usr/bin/hello1 failed Sep 18 16:44:53 other's might know if there's a newer reference than that. Sep 18 16:44:58 oops Sep 18 16:45:02 history and enter! Sep 18 16:45:08 ignore the stutter Sep 18 16:46:13 RP: I was expecting some logs from gdbtest() function since it seems to print stuff before returning False on error Sep 18 16:47:28 khem: good question Sep 18 16:49:23 RP: got back to running the qemumips with the altcfg and my initial timing to about 19 seconds, still seems faster Sep 18 16:49:59 sgw: does sound faster. Wonder how... Sep 18 16:52:18 khem: if you look earlier in the logs there is some stuff there Sep 18 16:52:24 rather than the summary at the end Sep 18 17:04:43 headscratcher of the day. if I copy the busybox recipe exactly, rename it to busybox-foo, adjust ${S} and that's it .. it blows up on Werorr. but yet the original doesn't Sep 18 17:19:00 zeddii: some CFLAGS_pn-busybox hidden somewhere ? Sep 18 17:19:39 zeddi: poky/meta/conf/distro/include/security_flags.inc:SECURITY_STRINGFORMAT_pn-busybox = "" Sep 18 17:21:11 heheheh. that's one of the things i'm trying to patch out of the Makefiles. Sep 18 17:21:20 and yes, of course. that wouldn't match my new name. Sep 18 17:32:18 * xicopitz[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/hSIRWaQKHZSUEVQcLezvWexw/message.txt > **** BEGIN LOGGING AT Fri Sep 18 18:00:14 2020 Sep 18 18:01:43 RP: I was reading through your system/nice patch, I wonder if we have entropy generation problem on builders Sep 18 18:01:48 RP: see https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation Sep 18 18:02:06 RP: have you oberved these failures on a particular distro ? Sep 18 18:03:15 RP: maybe installing haveged on the builders could atleast validate if this is the issue Sep 18 18:03:41 or perhaps see if kernels on builders are using CONFIG_RANDOM_TRUST_CPU Sep 18 18:05:57 khem: we're specifically pointing the virtio rng at /dev/urandom so it has a free source of random data Sep 18 18:06:20 khem: we did once have entropy issues but this doesn't look like it to me Sep 18 18:06:36 khem: the gdb failures are <<< run_serial(): command timed out after 60 seconds without output >>> - i.e. the serial commands are timing out Sep 18 18:06:44 I commented in the bug Sep 18 18:17:55 RP: yeah it seem hello1 debug hangs Sep 18 18:18:26 khem: I suspect its just a slow to boot image :/ Sep 18 18:18:30 RP: I would still like to see haveged experiment if we can easily **** BEGIN LOGGING AT Fri Sep 18 18:20:28 2020 Sep 18 18:20:33 RP: is qemu loaded with other stuff when hello1 is being run in gdb I wonder Sep 18 18:20:38 khem: no, the symptoms are not. For example look at the systemd boot chart Joshua put in the bug - shows heavy CPU usage by openssh continually. Sep 18 18:20:48 if it were blocked on entropy it would stutter Sep 18 18:21:07 also, the getty isn't blocked on the ssh daemon coming up Sep 18 18:21:18 is bootchart on ml somewhere ? Sep 18 18:21:25 its just the ssh keygen pinches the cpu cycles Sep 18 18:21:49 khem: its attached to https://bugzilla.yoctoproject.org/show_bug.cgi?id=13646 Sep 18 18:22:09 and do we see it with dropbear in same fashion Sep 18 18:22:16 khem: no, qemu shouldn't be. but it is freshly booted when running the gdb test Sep 18 18:22:39 khem: we don't see it with dropbear, I suspect as its keygen is less cpu sensitive **** BEGIN LOGGING AT Fri Sep 18 18:24:41 2020 Sep 18 18:26:15 run-postinsts.service takes 26s so ssh-keygen waits for that to finish hmm Sep 18 18:27:03 khem: but the logind which is blocking things isn't waiting on the keygen Sep 18 18:29:09 right, it waits on post-installs though Sep 18 18:39:03 RP: here is what I see for qemumips on my machine https://hastebin.com/iquwefurat.css Sep 18 18:39:26 2.642s dropbearkey.service Sep 18 18:39:41 now let me try with openssh as well Sep 18 18:40:20 this is minimal image btw **** BEGIN LOGGING AT Fri Sep 18 18:49:37 2020 Sep 18 18:56:24 RP: I was wondering if we should do socket activation for ssh instead Sep 18 18:56:40 that atleast will defer the first time key generation Sep 18 18:56:57 untill 1st ssh connection Sep 18 19:16:47 I have a vendor-provided buildroot bsp (which builds U-Boot, a kernel Image, and a rootfs) that I want to convert to yocto. I can see from googling that people have done this before, but I haven't seen much in the way of guidance. Sep 18 19:16:55 Any resources for making the transition? Sep 18 19:26:18 khem: we do socket activation don't we? Sep 18 19:26:50 khem: the issues we're seeing are with pam enabled with systemd Sep 18 19:50:08 bluelightning_: i'm trying to get devtool to create a recipe with a version number in the recipe name instead of recipe_git.bb Sep 18 19:50:41 bluelightning_: it looks like recipetool supports that with the -o|--outfile option Sep 18 19:51:00 bluelightning_: but there's no pass-through from "devtool add"? Sep 18 19:52:03 when i see "_git.bb" in a recipe name, i tend to assume it's an autorev recipe. is that a silly assumption? Sep 18 20:06:33 RP: with pam I am seeing 56.963s sshdgenkeys.service but dropbear is better 22.184s dropbearkey.service Sep 18 20:07:07 the previous numbers I gave were with musl Sep 18 20:12:05 khem: right, that sounds more like what we were seeing too Sep 18 20:12:34 khem: with a 60s timeout on the getty logging in, it was sometimes hitting the timeout, sometimes not Sep 18 20:12:35 perhaps we should use dropbear exclusively on mips images Sep 18 20:12:46 khem: well, we just increase the timeout Sep 18 20:13:03 most of mips users are using dropbear Sep 18 20:13:13 same for arm/ppc perhaps Sep 18 20:13:57 Is there no HW RNG on MIPS? Sep 18 20:14:08 there is Sep 18 20:14:09 There is on most ARM chips, I guess, so enabling that would help? Sep 18 20:14:16 we are talking qemu here Sep 18 20:14:20 Ah, I see. **** BEGIN LOGGING AT Fri Sep 18 20:16:31 2020 **** BEGIN LOGGING AT Fri Sep 18 20:21:25 2020 Sep 18 20:21:29 RP: but pam/systemd/musl combo is pretty fast I wonder why Sep 18 20:21:59 2.642s vs 22.184s Sep 18 20:23:13 RP: in real world I think no one generate the sshkeys on fly, so another solution could be to add pregenerated keys to qemu images Sep 18 20:26:08 does generating them while flying count ? Sep 18 20:27:32 Only if you drop physical dices from more than 1000 ft to generate them. Sep 18 20:27:43 s/dices/dice/ Sep 18 20:36:06 khem: interesting, I keep wondering why pam is so slow :/ Sep 18 20:38:10 khem: didn't musl systemd disable some things? **** BEGIN LOGGING AT Fri Sep 18 20:49:22 2020 Sep 18 20:59:36 I am porting a buildroot BSP/distro to yocto. I thought I'd start with U-Boot; I was able to get a recipe which causes yocto to build the same source tree that Build Root uses. Sep 18 21:00:59 However, buildroot doesn't just build the tree; it has a pre-build command that concatenates two U-Boot configuration files together `cat module.conf baseboard.conf > actual_uboot_defconfig' Sep 18 21:01:04 I' Sep 18 21:01:14 I'm trying to determine how to best replicate this in yocto Sep 18 21:01:35 I'm guessing yocto won't let me cd uboot/config and start modifying files in the source tree Sep 18 21:02:25 So I COULD use a patch to the vendor's uboot repo that merges the configuration I'm intersted in and supplies it as config/myproject_deconfig Sep 18 21:03:14 however, the vendor may well update the original configurations and I want to be able to access them by bumping my SRCREV without having to regenerate the patch Sep 18 21:04:43 Also, it seems like I should probably have a meta-module layer and a meta-baseboard layer; each one would override its respective variable in the meta-vender-core layer, then meta-vendor-core would be responsible for performing the concatenation step Sep 18 21:05:13 That would be the most extensible path (in case I have to work with different modules or baseboards from the vendor in the future) Sep 18 21:16:26 ecdhe: yocto would allow you to do that, you can modify for example the do_configure function on the recipe, or prepend to it to concatenate those two files Sep 18 21:19:56 ecdhe: you can look at the libpcap or nfs-utils recipe for an example, those two both modify a file before building the source code Sep 18 21:21:10 sakoman: Would the recent patches to the cve-db recipe make sense to backport to dunfell? (the ones sent right after you backported some of them) Sep 18 21:21:28 sakoman: specifically the one that avoids using anonymous python **** BEGIN LOGGING AT Fri Sep 18 21:23:15 2020 Sep 18 21:23:51 I'm just about to release 3.1.3, so I won't take them till after that Sep 18 21:24:22 I don't like last minute changes, they usually bite me :-) Sep 18 21:28:13 sakoman: I did get a failure after the ones you already pulled, I'm currently testing the new ones, but I do think moving stuff out of the anon python was a good idea Sep 18 21:28:21 sakoman: sure, sounds good, thanks Sep 18 21:29:12 alejandrohs: Is it a serious failure? Sep 18 21:29:29 Something I should revert before releasing? Sep 18 21:29:59 thanks alejandrohs Sep 18 21:43:58 sakoman: same as before, failed on the race condition Sep 18 21:44:27 alejandrohs: OK, so not a new failure? Sep 18 21:45:02 If that's the case, then no need to revert anything **** BEGIN LOGGING AT Fri Sep 18 21:52:14 2020 **** BEGIN LOGGING AT Fri Sep 18 21:56:12 2020 **** BEGIN LOGGING AT Fri Sep 18 22:03:31 2020 **** BEGIN LOGGING AT Fri Sep 18 22:10:50 2020 **** BEGIN LOGGING AT Fri Sep 18 22:47:00 2020 Sep 18 23:20:01 RP: yeah it disables gshadow I wonder if that does it **** BEGIN LOGGING AT Fri Sep 18 23:57:36 2020