**** BEGIN LOGGING AT Tue Sep 03 03:01:04 2019 Sep 03 05:04:36 New news from stackoverflow: Cannot login Yocto qemux86-64 Sep 03 06:28:28 Is there any given/supported way in Yocto to specify multiple partitions? I would for example like to separate the root file system and have it read-only, and keep a second partition which is r/w (and also pull a few packages into that partition). Sep 03 06:30:28 iceaway2: should all be done through wic, AFAIK Sep 03 06:44:16 its not even 9am and i already want to break something. Sep 03 06:44:35 samba+waf are such a massive PITA Sep 03 06:50:23 good morning Sep 03 06:51:08 mckoan: disagreed. Sep 03 06:55:01 LetoThe2nd: Cool, I've seen wic mentioned in the docs somewhere. Will look it up! Sep 03 06:56:06 iceaway2: As LetoThe2nd say, this can be done using the wic image format. You then need to use a WKS_FILE that looks something like this: https://pastebin.com/jEpE37Gy Sep 03 06:57:25 That example is for a raspberry pi image. The interesting part is that "part /" excludes data/ and then "part /data" is created to contain what was excluded from "part /" Sep 03 06:58:13 just because we are talking about WIC, how would be possible to set the permission of a partition to a specific user? Sep 03 06:59:00 I also use IMAGE_FEATURE += "read-only-rootfs" to get a read-only root Sep 03 07:51:32 erbo: thanks! Sep 03 08:47:59 nrossi: to wrap up yesterdays samba topic: bumping from 4.4.2 to 4.4.5 which is present in morty already did solve the problem, and a further bump to 4.4.16 went mostly effortless too. Sep 03 09:07:06 * alessioigor waves all Sep 03 09:07:08 Is Anuj Mittal here? I have a regression (from my point of view) in wic with commit (7365a605ae5aa1207a9a06604c8189cd422ac604) committed by jwessel. Sep 03 09:08:24 alessioigor: may be best to email them and the list Sep 03 09:08:40 RP: Ok thanks Sep 03 09:09:43 kanavin_: starting to suspect the qemu hangs were the mips vga change :( Sep 03 09:09:57 kanavin_: trying to see if I can prove it Sep 03 09:10:33 (evidence so far is all the failed builds have that commit, either from next or master) Sep 03 09:31:23 kanavin_: could be something like a bug in the console blanking - only triggers on longer running images Sep 03 09:40:46 kanavin_: its not that, just locked up with cirrus :/ Sep 03 09:50:59 kanavin_: next question, was it the larger amount of memory? Sep 03 10:06:14 hi all Sep 03 10:07:15 tgoodwin: I tried your suggestion of some days ago (sorry for the delay) to change partition owner on a partition created using .wks Sep 03 10:08:18 tgoodwin: you suggested to use IMAGE_PREPROCESS_COMMAND_append, but unfortunately it does not fit for my needs: it works on files in rootfs Sep 03 10:09:09 tgoodwin: but I need to change the partition ownership, and partition will be created by wic after rootfs processing Sep 03 10:09:53 tgoodwin: Anyway thank you again :) Sep 03 10:12:03 About this topic, I found wic parameter --mkfs-extraopts, so I could pass root_owner param to partition creation process Sep 03 10:13:34 Has anyone tried it? Could be a choice or there are more elegant ways? (BTW with this approach I have to pass default ext4 parameters Sep 03 10:14:22 defined in wic process, to not loose them: seems that --mkfs-extraopts overwrites default params) Sep 03 10:29:33 RP: are the hangs only on mips? Then the cirrus change shouldn't be the cause, as qemu mips actually still defaults to cirrus (my commit msg was wrong in that). Also, I tihnk the amount of RAM hasn't actually changed, it had 256M before as well. Sep 03 10:35:27 New news from stackoverflow: Bitbake: How to build a specific python3 recipe Sep 03 10:41:58 kanavin_: we have 512 due to opengl now Sep 03 10:43:00 kanavin_: hangs are only mips Sep 03 10:46:02 kanavin_: limiting to 256 did allow the tests to pass. Not enough data to be confirmation but looking likely Sep 03 10:50:42 RP: right, maybe mips always has to be restricted to 256M, although this as well seems wrong Sep 03 10:53:10 kanavin_: I'm not saying its right, I just need to know where the regression is from Sep 03 10:54:20 kanavin_: if we know its the memory that changes how we can try and reproduce and fix it Sep 03 11:00:33 ms_k: considering how all the "EXTRA" variables work in bitbake, I would have assumed that flag would append too. Maybe submit a patch to see what the community thinks? Sep 03 11:01:29 and sorry to hear about the ownership change not working. I'm surprised that didn't work. Perhaps an init or system service to check ownership and re-apply on first boot? Sep 03 11:58:09 tgoodwin: Oh, I didn't use EXTRA_IMAGECMD, I used directly --mkfs-extraopts in .wks file. I'm going to do a try with EXTRA_IMAGECMD Sep 03 11:59:44 tgoodwin: Don't worry, no problem. From what I understand the IMAGE_[PRE-POST]PROCESS_COMMAND scripts works on created rootfs, that is Sep 03 12:01:26 contained in a directory. From this rootfs wic takes files to populate specified partitions, based on --source and --rootfs-dir variables Sep 03 12:24:50 ms_k: right, but if I remember wic's flow, it uses mkfs with a special "-d" option to populate the new partition using the contents path you specified. So if you exclude a subpath of your rootfs and then create a separate WKS line for creating that partition with the contents...I think you'll be okay. Sep 03 12:24:55 Hi, trying to build some stuff with warrior and gcc7, using the linaro layers since gcc7 was removed from warrior. Sep 03 12:24:59 Hi, I'm trying to create a new recipe based on a private nodejs repo but that image also depends on a private npm registry and devtool add is failing since it cannot find the package nin the npm registry, how can I add the registry when performing the devtool add? Sep 03 12:25:11 I'm doing this because nvidia stuff only works with gcc7 and fails with 8, and I need to remain binary compatible. Sep 03 12:25:24 ms_k: take a look at this: poky/scripts/lib/wic/canned-wks/efi-bootdisk.wks.in Sep 03 12:25:53 maybe this is the wrong place to ask about this, since it seems like a linaro layer problem. Let me look there first. Sep 03 12:27:13 ms_k: FWIW if there is an autoconf-style parsing of wks.in files, I haven't found it in the source code. I stumbled across that file last week when crafting my wic LVM2 patch. Sep 03 12:42:30 tgoodwin: yes, I'm doing this, but additional partition stills owned by root:root. In my wks.in I have two entries: Sep 03 12:43:07 tgoodwin: part / --source rootfs --exclude-path=mydir/ .... Sep 03 12:43:40 tgoodwin: part /mydir --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/mydir .... Sep 03 12:44:31 If you check your image's rootfs (in workdir), is rootfs/mydir owned by the expected user? Sep 03 13:00:35 RP: I have a bit of cycles now, so if there's something I can help with, let me know Sep 03 13:23:14 I'm running my builds with CROPS, but the default poky-container doesn't have the ncurses headers (nor libs, I guess), so there's no menuconfig. Is there a different container I could use that only adds ncurses? Sep 03 13:27:46 jofr: We use https://github.com/garmin/pyrex Sep 03 13:35:50 tgoodwin: yes, rootfs/mydir is owned by user 1000:1000, as expected (recipe that creates and populates this dir also set its ownership) Sep 03 13:35:59 New news from stackoverflow: No mouse cursor in Qt EGLFS on Yocto Sep 03 13:36:06 JPEW: Thanks! Sep 03 13:37:13 jofr: np. I wrote most of it, so if you have any problems, let me know. Sep 03 13:41:23 <__angelo> hi, building a kernel 4.14 sdk, yocto is telling me there are no linux-header for 4.14. It's building anyway so i suppose it wopuld choose 4.9 or 4.17. Is it ok ? Sep 03 13:46:44 Does anyone know if Randy Witt is around? Sep 03 13:48:48 I think that we're witt-less. Sep 03 14:00:07 bummer Sep 03 14:06:09 Hi, can we have a nodejs package get dependencies from a private npm registry? Sep 03 14:18:12 does anyone know of a C or C++ API to the smart package manager? Sep 03 14:18:34 i'd like to programmatically check for updates, install, upgrade, etc. Sep 03 14:19:00 i've been googling around and haven't found anything yet Sep 03 15:01:39 YPTM: Joshua Watt here Sep 03 15:03:08 YPTM: Also Zach Booth and Dustin Bain Sep 03 15:04:41 YPTM: Scott Murray is on Sep 03 15:04:48 YPTM: Randy and Trevor are on the call. Sep 03 15:08:08 YPTM: Denys is on Sep 03 15:12:43 * zeddii just joined the TPTM. a bit late, but here. Sep 03 15:16:26 ouch rootfs assembly on qemumips64, some nasty dnf shared library error. Sep 03 15:16:34 that's going to slow down my kprobes debug :D Sep 03 15:19:35 has anyone seen this dnf error before ? Sep 03 15:19:39 https://pastebin.com/gVvJtKar Sep 03 15:20:00 it only showed up on qemumips64 for me, which is unfortunately, since that is the arch I need to build and test at the moment. Sep 03 15:20:58 $ file /opt/bruce/poky/build/tmp/work/qemumips64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/dnf Sep 03 15:20:58 zeddii, I do not remember seeing this Sep 03 15:21:28 I'll try a bunch of cleanalls, etc, and see if I can get it to wheeze back to life. Sep 03 15:21:44 switch to ipkg? Sep 03 15:22:34 yah. I have one builder on ipg the other on rpm. I'll fire up the same build on the ipkg one (it's slower) and hopefully end up with something to debug. Sep 03 15:23:04 if you run that dnf by hand, what happens? Sep 03 15:23:42 hi folks, how do i set the compiler verision used to compile *native* packages? it seems to use whatever cc is on the host Sep 03 15:23:53 kanavin_: FWIW autobuilder confirmed it seems to be memory size breaking the tests Sep 03 15:24:32 milloni: yes, that's how it works Sep 03 15:24:49 milloni: if you want it to use something else, set it up and tweak your $PATH before bitbake'ing Sep 03 15:25:07 interesting .. Sep 03 15:25:13 ModuleNotFoundError: No module named 'dnf' Sep 03 15:25:20 yet, it works on all the rest of my qemu builds. Sep 03 15:25:47 is dnf a python script? Sep 03 15:25:56 sounds like something wasn't populated Sep 03 15:26:16 tlwoerner: does it actually use "cc" or "gcc" or something else? if cc i can probably use debian's update-alternatives Sep 03 15:26:57 tlwoerner, apparently. I've never looked at the dnf host parts before, I see scripts wrapping binaries, wrapping scripts. Sep 03 15:26:57 milloni: i either use update-alternatives, or i use a container Sep 03 15:27:00 RP: good that this is confirmed, although it's a bizarre one indeed Sep 03 15:27:34 tlwoerner: perfect, if you use a container, didn't you run into a problem where bitbake complained that you can't run it as root? Sep 03 15:27:53 milloni: just set BUILD_CC and friends if you want to use a different host compile Sep 03 15:28:06 rburton: nice Sep 03 15:28:20 i'll try that Sep 03 15:28:21 and if you use a container just don't be root in it, easy Sep 03 15:29:53 systemd 243 update: https://github.com/systemd/systemd/blob/master/NEWS Sep 03 15:29:56 milloni: right, i setup a "bitbake" user ;-) Sep 03 15:31:40 seems easy enough Sep 03 15:31:44 milloni: currently i can work with any of: master, warrior, thud, and sumo natively. if i need to work with anything older i need to use a container. this is all due to the host's gcc Sep 03 15:32:21 yeah - it seeems to be a good practice in 2019 to have a container for consistency anyway Sep 03 15:33:13 milloni: the CROPS containers set a non-root user -- https://github.com/crops/poky-container Sep 03 15:34:07 oh that's an interesting project, i'll take a look Sep 03 15:34:14 https://hub.docker.com/u/crops/ Sep 03 15:34:45 those containers are rebuilt every week automatically, so they get updates to packages from the distros Sep 03 15:34:53 kanavin_: out of curiosity, would it be as simple to add support for regexp in PRIVATE_LIBS as adding support for PRIVATE_LIBS_ALL? with the regexp, e.g. *.so* would have the same meaning as PRIVATE_LIBS_ALL and we still have the ability to "privatize" a bunch of libraries named more or less the same Sep 03 15:34:55 moto-timo: i hadn't thought of that, i thought the CROPS stuff was for the case where you had a developer who wanted to work with OE but wasn't using linux as a development host Sep 03 15:35:35 tlwoerner: that was always part of the goal, but it has been heavily used for Linux host builds since the inception Sep 03 15:35:37 zeddii: down the rabbit hole... Sep 03 15:36:20 tlwoerner: in fact the current implementation was created because of a need to catch rare failures in builds (1 in 10,0000) on a linux host Sep 03 15:37:16 the mac and windows capability is an added benefit :) Sep 03 15:37:48 moto-timo: nice! Sep 03 15:39:57 qschulz, sure, that would be a separate commit though. Does python have a built in thingy for that style of regexp? Sep 03 15:40:17 e.g. where . is a literal dot character, and not 'any character' like regular regexps have it Sep 03 15:40:42 kanavin_: well, if we have regexp support for PRIVATE_LIBS, PRIVATE_LIBS_ALL does not make much sense does it? Sep 03 15:41:14 kanavin_: let's have a look at how regexp are handled for FILES_ variables Sep 03 15:41:41 qschulz, sure, you can just put * in there Sep 03 15:44:31 qschulz, fnmatch.fnmatch(filename, pattern) should do the trick Sep 03 15:44:58 kanavin_: AFAICT, for FILES_ glob is used Sep 03 15:45:26 interesting. Sep 03 15:45:43 I am seeing the missing libsolv on qemumips64 and I noticed this on a forced rebuild of dnf Sep 03 15:45:47 WARNING: dnf-native-4.2.2-r0 do_prepare_recipe_sysroot: Manifest /opt/bruce/poky/build/tmp/sstate-control/manifest-x86_64-libsolv-native.populate_sysroot not found in x86_64 (variant '')? Sep 03 15:46:08 but unfortunately ... I'm still just grepping the sources for hits :D Sep 03 15:46:13 kanavin_: maybe you could even call files_from_filevars directly? Sep 03 15:47:19 mmmm.. not so much, it's including dirs and symlinks, not very clean, but something to start from maybe :) Sep 03 15:48:11 qschulz, we don't need to touch the actual filesystem at all Sep 03 15:48:24 we have the soname, and the list of private sonames Sep 03 15:48:25 kanavin_: ah yes true Sep 03 15:48:56 then yeah, fnmatch :) Sep 03 15:48:57 so if the list becomes a list of private wildcards, it needs to iterate the list instead of just doing 'soname in list' but otherwise not too complicated Sep 03 15:55:26 zeddii: that is rather strange. It means libsolv disappeared from your system and that is backed up by the failures yet why would that happen? Sep 03 15:55:41 zeddii: A cleansstate on libsolv-native should fix that Sep 03 15:55:46 "fix" Sep 03 15:58:10 part Sep 03 15:59:14 * armpit bang.. gcc 8.3 gone Sep 03 16:03:49 woop woop hash equivs Sep 03 16:04:15 touched a glibc patch that doesn't change generated code, it did the right thing and went straight to image building Sep 03 16:07:59 awesome Sep 03 16:09:48 rburton: what did you do ? changes comment in .bb ? Sep 03 16:09:58 or comment in patch Sep 03 16:11:47 RP: indeed. that fixed it. I can't say how or why it happened either. but thanks for the tip!! Sep 03 16:12:25 khem: comment in patch header Sep 03 16:15:06 rburton: its lovely when it works! Sep 03 16:15:12 yes Sep 03 16:15:20 still a bit verbose, can we rip out some of the notes? Sep 03 16:15:28 rburton: not until it stablises Sep 03 16:15:41 rburton: its impossible to debug if it fails without those Sep 03 16:16:08 rburton: ok cool, in step two it would be cool to integrate https://github.com/lvc into OE and start calculating API finerprints and go a step further detecting that its a shared library and no APIs versions changed so no need to rebuild everything except glibc even when code is changed Sep 03 16:16:25 khem: the hooks are there Sep 03 16:18:15 yeah that would be neat Sep 03 16:18:52 damn. no kprobes message on my qemumips64 boot. Sep 03 16:18:55 * zeddii digs more Sep 03 16:19:04 zeddii: was it 5.2? Sep 03 16:19:17 yah. Sep 03 16:19:24 maybe my kernel config is different. checking that. Sep 03 16:19:27 oot@qemumips64:~# uname -a Sep 03 16:19:27 Linux qemumips64 5.2.10-yocto-standard #1 SMP PREEMPT Tue Sep 3 13:03:23 UTC 2019 mips64 mips64 mips64 GNU/Linux Sep 03 16:19:27 root@qemumips64:~# dmesg | grep -i kprobes Sep 03 16:19:27 root@qemumips64:~# Sep 03 16:21:04 zeddii: you may need to run some command to trigger the dmesg log Sep 03 16:21:24 heh. was just mining down to see what might have been run. will try that angle. Sep 03 16:35:18 zeddii: just mailed you some qemumips kernel backtraces. Not sure if they're related to our memory issue or not Sep 03 16:35:52 cool. will have a look. I was just clickign through the steps on the one you sent in email and hadn’t located where the kprobes one came from, but I’ll keep looking. Sep 03 16:36:26 zeddii: I'd guess the stap test? Sep 03 16:37:07 yah. that’s the only thing I saw as well, but yes, stap uses probes to setup. so it may just be fix stap, fix ‘em all. I was wondering if there was an individual test, but didn’t find one. Sep 03 16:40:45 zeddii: I wonder if I've transcribed that list incorrectly. The qemumips64 link in that email shows it doesn't build stap Sep 03 16:41:05 zeddii: qemuarm64 definitely has the parselogs one Sep 03 16:41:32 zeddii: when I fix the qemumips hang, that also has the stap compile failuew FWIW Sep 03 16:41:37 let me double check what I clicked on. maybe it wasn’t qemumips64, since I definitely saw stap in it. Sep 03 16:42:08 zeddii: there are two kinds of failure, stap test fails with a compile issue or parselogs fails with a kprobes one Sep 03 16:42:50 zeddii: sorry if I've mixed them up :/ Sep 03 16:43:20 yah. this one https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/987/steps/8/logs/step1c is definitely qemumips64 stap build failure. no kprobes. I’ll click on another one for the kprobes and try to find it. Sep 03 16:44:56 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/987 Sep 03 16:45:44 ahah. I see it. I swear I just checked another qemuarm64 and it had the stap build failure. Sep 03 16:46:00 I’ll switch my second builder to that. Sep 03 17:58:17 https://pastebin.com/raw/Ww8tW7eR <-- how can I go about debugging this? That's the extent of the log that I can find. Sep 03 18:03:43 fullstop: /home/nvidia/yocto/git/poky/build/tmp/work/aarch64-poky-linux/busybox/1.30.1-r0/temp/run.do_configure.13358 and check where this sed is Sep 03 18:04:36 qschulz: can I run that script directly or does some environment need to be set first? Sep 03 18:06:15 okay, I can. Is there a template which this is built from? Sep 03 18:06:27 sed -i 's|||g' /home/nvidia/yocto/git/poky/build/tmp/work/aarch64-poky-linux/busybox/1.30.1-r0/busybox-1.30.1/.config Sep 03 18:09:02 Hi, my organization has developed a framework for integration-testing our embedded Linux system using User-Mode Linux (ARCH=um) support in the kernel. Is it possible to build a UML kernel with Yocto? Sep 03 18:21:04 I dont think we have done that explcitly in project but architecture is certainly able to extend into this direction Sep 03 18:23:20 I'm not sure where the `ARCH` parameter can be passed into a kernel recipe (based on `kernel` and linux-yocto) Sep 03 18:35:14 you probabably need to start from tunes Sep 03 18:47:19 Ahh, thanks Sep 03 19:16:05 fullstop: yes, from the recipes. Try to find everything where a do_configure is set for busybox (busybox_1.30.1.bb*, busybox_*.bbappend and look in the inherit, include, require files or classes as well, I don't think there is a proper way to find out which file is modifying tasks) Sep 03 19:19:37 wow, this is going to be fun. Sep 03 19:19:58 I saw "disable networking applets" in the configure script, but I've not been able to find that in my tree yet. Sep 03 20:27:48 khem: apparently the make target for a UML kernel has to be `linux`, not `Image` -- do I just set `KERNEL_IMAGETYPE = "linux"`? Sep 03 20:29:31 zeddii: any luck? Sep 03 20:41:44 RP: thanks for quick merge of those 2 bitbake changes, should I send them for warrior and thud branches as well, what do you think? Sep 03 20:42:48 JaMa: it probably doesn't hurt... Sep 03 20:43:01 ok, thanks Sep 03 20:44:37 RP: nothing. I was able to build systemtap for all the qemu platforms, so I don't have the compile error. working on runtime testing now. Sep 03 20:54:39 zeddii: I think its on target compilation of the runtime fot stap fwiw Sep 03 20:55:00 zeddii: I have a local reproducer so I'll try upgrading systemtap Sep 03 20:56:17 my mips64 is starting a target test now. Sep 03 20:56:38 I had a huge build from scratch to do + the slower emulation. Sep 03 21:03:21 RP thanks for the quick turn around regarding babeltrace. I should have replied earlier but had other stuff on my plate. Sep 03 21:05:51 psrcode: thanks for pointing it out. Glad we could just drop it from -next too! Sep 03 21:16:31 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/680 is a bit odd - reproducibile build failure :/ Sep 03 21:16:44 JPEW: looks like a race issue? Sep 03 21:17:33 is there a recipe for littlevGL? Sep 03 21:20:56 nrossi: the test tags looks great at first read, thanks! Sep 03 21:22:02 RP: I have a hard time believing the results from build 666 aren't lying to me ;) Error log isn't really helpful there is it Sep 03 21:22:35 JPEW: look at the full log from step2d Sep 03 21:22:55 RP: Ah Sep 03 21:22:59 JPEW: think of it as a hint which step to look at Sep 03 21:25:04 RP: That does look like a race... Sep 03 21:25:42 RP: there is still that issue with local PRserv started together with bitbake and immediately terminated (and causing connections to it closing unexpectedly with warnings), should I look into this or is local PRserv no longer supported and I should look how to modify my builds instead? Sep 03 21:26:08 JaMa: we have no other replacement for prserv Sep 03 21:26:40 and autobuilder doesn't use it (am I the only one seeing those warnings)? Sep 03 21:26:54 JaMa: autobuilder does not use prserv atm Sep 03 21:27:09 It did but not effectively and it was breaking sstate so I turned it off Sep 03 21:29:57 ok, will try to figure out how to use hashserv to see how to fix PRserv without breaking hashserv (returning one line where it was fixes PRserv, but don't know what effect that has on hashserv) Sep 03 21:30:26 Looks like it's racing with do_deploy_source_date_epoch Sep 03 21:30:54 JaMa: right, I'm just overloaded atm and haven't got to that yet :( Sep 03 21:33:31 Ah... the implementation of sstate-plaindirs is... interesting... and race prone Sep 03 21:35:55 JPEW: I think I had to tweak pkackagedata due to that recently :/ Sep 03 21:36:53 RP: Ya. In the short term we might be able to remove the usage of sstate-plaindirs from reproducible_build.bbclass and force it to copy the file, but that's weird in the long run. sstate-plaindirs *should* work Sep 03 21:37:18 JPEW: I haven't looked at what its doing so hard to comment :/ Sep 03 21:40:20 RP: I'll raise a bug Sep 03 21:41:20 JPEW: thanks Sep 03 21:41:55 * RP just hotwired nrossi's toolchain testsuite tests to the autobuilder so lets see what happens Sep 03 21:42:18 zeddii: I threw a systemtap upgrade in for fun too Sep 03 21:47:25 ok, cool. I'm cobbling together the right packages. my minimal build (to save time) was missing a few things. Sep 03 21:47:30 that'll teach me :D Sep 03 22:17:12 zeddii: according to my local test, systemtap master doesn't fix the stap compile during test failure Sep 03 22:21:30 zeddii: its as if its just missing a #include Sep 03 22:27:37 well. I'm a moron and forgot to bake systemtap into my image, so I'm watching it build again :D **** BEGIN LOGGING AT Wed Sep 04 01:08:23 2019 **** ENDING LOGGING AT Wed Sep 04 03:00:01 2019