**** BEGIN LOGGING AT Mon Feb 22 02:59:57 2021 Feb 22 03:52:17 zeddii: I have updated the patch at https://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/qemuppc64le now keyboard/mouse work too Feb 22 03:54:02 I can have a look at it on Monday. I'll pull in the config, and let you know. Feb 22 04:46:38 ok Feb 22 07:53:25 yo dudX Feb 22 08:10:02 * mckoan is preparing for a YP training week Feb 22 08:24:43 hello guys ! Feb 22 08:25:13 which is the best place to put some entries in /etc/modprobe.d ? Is it the kernel recipe ? Feb 22 08:58:54 good morning gents, is anyone aware of a global bitbake flag similar to gcc's -Werror ? Feb 22 08:59:44 hello when I add user in local.conf I relaunch bitbake core-image-base but it doesn't regenerate image wic.bz2 Feb 22 09:00:25 we want our daily build pipeline to fail if the yocto build spits out any warnings during the whole build Feb 22 09:26:34 mbulut: I'm not sure there is one. If you look at the code in lib/bb/ui/knotty.py at the end, the "if warnings", it would be easy to add though Feb 22 09:27:12 mckoan: have fun! :) Feb 22 09:30:41 gillesm: "when i add user"? Feb 22 09:53:28 LetoThe2nd, yes or when I customize the image without compilation need ... Feb 22 09:53:39 but with image regeneration need Feb 22 09:54:02 gillesm: well i guess you're messing up yocto chant #1. recipe data is local, config data is global. Feb 22 09:55:05 gillesm: so: users shall be added through recipes. there are examples for that, start with those. and: an image recipe cannot affect other recipes, hence the "customization" might or might not work as you expect. Feb 22 09:56:04 my question is how can I regnerate the image ? Feb 22 09:56:18 gillesm: bitbake image :) Feb 22 09:56:38 gillesm: if that does not trigger the rebuild, then you've done something wrong. Feb 22 09:56:40 it doesnt generae wic.nz2 ... Feb 22 09:56:51 bz2 Feb 22 09:57:01 then find out why it doesn't. Feb 22 09:57:19 gillesm: what exactly are you changing to add this user? Feb 22 09:57:29 the local.conf file Feb 22 09:57:49 gillesm: right, but how, which variables? Feb 22 09:59:04 INHERIT += "extrausers" Feb 22 09:59:04 EXTRA_USERS_PARAMS += "useradd -P totototo guest;" Feb 22 09:59:07 gillesm: see https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd Feb 22 10:01:20 ok I understand .. I need to make a receipe... Feb 22 10:01:23 tanks Feb 22 10:05:20 * LetoThe2nd resists the urge to give the nervous look and say "Where?" Feb 22 10:13:13 RP: thx! Feb 22 10:31:24 RP: looking ... haven't see that one yet in my builds. Reading the recipes nothing catches my eye. Feb 22 10:37:52 dl9pf: I don't understand the warnings, its very strange Feb 22 10:39:56 ok, will try a build for these two packages Feb 22 10:45:04 dl9pf: I'm seeing locally with different recipes :( Feb 22 10:45:52 texinfo-dummy-native, gettext-minimal-native, base-files, dwarfsrcfiles, initscripts, shadow-sysroot, shadow-securetty Feb 22 10:46:28 hmm, thats random. Feb 22 10:54:37 dl9pf: you mean 4? Feb 22 10:55:02 42 actually Feb 22 10:55:37 onpe Feb 22 10:55:45 *nope, even. see: https://xkcd.com/221/ Feb 22 12:09:28 Just when you think you've fixed a reproducibility issue, it turns out there is more than one :( Feb 22 12:19:40 RP: believe it or not, i'm currently kind of getting hooked on TDD Feb 22 12:20:37 LetoThe2nd: the game? Feb 22 12:20:54 RP: Test Driven Development Feb 22 12:22:11 RP: btw, current cpu availability crazyness: had to order 2x7752s for build server instead of 2x7702s Feb 22 12:23:30 LetoThe2nd: the testing stuff does make a big difference after a while Feb 22 12:24:15 LetoThe2nd: nice cpus :) Feb 22 12:24:47 RP: yeah hopefully. the problem with the approaches that the cool kids use these days are though that they require a somewhat short round trip Feb 22 13:58:44 woop woop Feb 22 13:58:59 https://www.irccloud.com/pastebin/OEQGmHv8/ Feb 22 13:59:00 dl9pf: I have partial insight into that warning, bb.warn("SOURCE_DATE_EPOCH value from sstate '%s' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '%s'" % (s, SOURCE_DATE_EPOCH_FALLBACK)) Feb 22 13:59:20 dl9pf: "NameError: name 'SOURCE_DATE_EPOCH_FALLBACK' is not defined" is definitely true there, there is a bug in that line Feb 22 13:59:41 rburton: nice :) Feb 22 14:00:04 mad props to dorinda for getting debuginfod to work Feb 22 14:00:29 rburton: looking forward to seeing it in action! Feb 22 14:00:36 dorinda: nice work! Feb 22 14:00:39 dorinda: \m/ Feb 22 14:00:41 a couple of PACKAGECONFIG tweaks and DEBUGINFO_URLS=http://192.168.7.1:8002 in local.conf and your qemu will automatically grab the symbols from the host Feb 22 14:00:57 very nice Feb 22 14:01:59 :) thank you all, with great support from Ross. Feb 22 14:02:15 Proof that it worked https://www.irccloud.com/pastebin/q7cebroM/ Feb 22 14:02:26 rburton: experimental feature for 3.3? :) Feb 22 14:02:40 yeah should be able to land the last few bits Feb 22 14:03:11 RP: aah ... d.getVar missing ... Feb 22 14:04:06 you read that 10 times and don't see the issue Feb 22 14:05:51 dl9pf: nah never happend to me. i can't read. Feb 22 14:06:42 dl9pf: indeed, I was trying to trace back the code until I realised Feb 22 14:08:53 8) Feb 22 14:10:06 dl9pf: of course the question next is why is SDE 0 for those recipes Feb 22 14:10:23 dl9pf: but at least that is a more specific question Feb 22 14:12:35 dl9pf: looks like the SDE file is coming from sstate so perhaps its a cache invalidation issue Feb 22 14:14:57 RP: the SDE 0 is b/c the SDE txt file was retrieved from existing sstate-cache with 0 Feb 22 14:15:21 we either need to invalidate (essentially all old sstate) or replace the 0 Feb 22 14:16:14 dl9pf: I'm wondering why we don't see more sstate coming in like that Feb 22 14:16:25 good question Feb 22 14:16:31 i don't know the answer Feb 22 14:17:32 i expected it to be a lot when using the AB sstate ... thus the replacement, b/c we might not want to invalidate all sstate (or at least that task). Feb 22 14:17:46 Can I .bbappend a recipe that is already .bbappended by somebody else? Or is it undefined behavior? Say my bsp uses yocto-linux by appending it, and in my image layer I want to .bbappend it again, e.g. to set `KERNEL_MODULE_AUTOLOAD`. Can I do that? Feb 22 14:18:12 jonesv[m]: you can do multiple appends. Feb 22 14:18:17 jonesv[m]: appends stack in a defined order Feb 22 14:18:31 RP: ... which kind of leaves out the fun. Feb 22 14:18:49 LetoThe2nd: we can do without that kind of fun ;-) Feb 22 14:19:04 * RP remembers the build determinism issues based on order of files on disk Feb 22 14:19:38 RP: hum, if your build is deterministic even with randomized append order then its a sign of properly laid out metadata. lets do this! Feb 22 14:23:52 How is the order defined? Feb 22 14:24:12 RP, dl9pf IIRC SOURCE_DATE_EPOCH is excluded from sstate hash calculation Feb 22 14:25:07 Is it related to the order in which the layers are declared? I guess there cannot be two .bbappends for the same recipe in the same layer, can it? Feb 22 14:25:33 The idea is that one SOURCE_DATE_EPOCH is as good as another, so don't make it part of the hash (which, obviously is not true for rpm SDE=0) Feb 22 14:26:15 RP, LetoThe2nd: https://salsa.debian.org/reproducible-builds/disorderfs Feb 22 14:26:45 see, i knew it :) Feb 22 14:28:11 JPEW: its interesting as it does find SOURCE_DATE_EPOCH_FALLBACK so the hash should have changed. I think its a weird effect of hashequiv which is preserving the SDE=0 file even when its using the fallback Feb 22 14:30:14 we still read back 0, just change it when found. don't know whats the best strategy w/o invalidating task hashes Feb 22 14:31:37 I'm a little suprised it didn't already invalidate all the hashes since you did "export" on SOURCE_DATE_EPOCH_FALLBACK.... but that's probably where hashequiv comes in Feb 22 14:33:01 LetoThe2nd: I *suspect* we already get some metadata ordering testing just by testing on multiple build hosts Feb 22 14:33:17 As least on the AB Feb 22 14:33:52 I have patches to add disorderfs support... but we'd need to be careful that it doesn't slow down the build Feb 22 14:38:15 JPEW: I am a bit worried about the side effects from hashequiv like this :/ Feb 22 14:39:33 jonesv[m]: BBFILES and layer priorities determine the order. You can have multiple appends in a single layer potentially although you'd have to wonder why you'd do that Feb 22 14:40:30 JPEW: with metadata bitbake is quite careful internally about doing things in a specific order and to be deterministic about it Feb 22 14:40:45 RP: wondering if the order in whcih bbappends from the same layer are applied is deterministic? Feb 22 14:41:16 qschulz: I remember working on it to ensure it is Feb 22 14:41:42 JPEW: already wrote earlier - i'm currently lookinto into the TDD approach for dayjob application development, and its an interesting take on things. can't help wondering how knowledge could be transferred to the YP world. Feb 22 14:44:13 LetoThe2nd: Ya! I'm all about automated tests. I've been working on doing CI + on-target tests with labgrid Feb 22 14:44:48 JPEW: :) Feb 22 14:45:25 I currently have it setup so that I can build the latest master of all the layers I care about for my Pi-like boards and do CI testing on them Feb 22 14:45:58 My tests right now are pretty trivial "does it boot" tests, but even those have already found a few bugs :) Feb 22 14:48:16 I'm actually more examining the mindset. e.g. 1) write failing test 2) make test pass 3) refactor 4) go to 1) Feb 22 14:49:45 but that really works if you can do try-test cycles real quick, in a couple of seconds. Feb 22 14:50:12 LetoThe2nd: Ya, that can be really hard with on-target testing Feb 22 14:51:16 LetoThe2nd: Maybe I'm weird, but I get *really* happy when there is a patch with more test code changes than the actual bug took to fix :) Feb 22 14:52:12 JPEW: then i'm probably weirder because i envy those who can properly document and write tests. its kind of a thing i've never learned properly and now its backfiring. Feb 22 14:52:30 Hm who was asking about Arm workstations last week... Feb 22 14:52:42 https://store.avantek.co.uk/ampere-altra-64bit-arm-workstation.html is graviton2-speed Feb 22 14:53:19 JPEW: the "does it boot test" is key, I remember the job when we had YP do that automatically Feb 22 15:17:05 can you tell me if the skeleton recipe have to be inherit or copied and modified ? Feb 22 15:17:33 hello.I have some bash scripts and systemd services I want to install in my image. How do I make the correct structure so to add them with devtool add ? Feb 22 15:19:20 maybe the question is how do I make a correctly structered tarball out of my git repo? Feb 22 15:27:48 Is anyone aware of a layer to support Android style read only rootfs (i.e symlinking core package state files from /etc to /data/etc) ? Feb 22 15:34:59 kayterina: not sure to understand the question exactly. What's wrong with `devtool add `? it supports git repos Feb 22 15:41:33 gillesm: copied Feb 22 15:42:50 sakoman: Not a layer, but we do that ad-hoc with tmpfiles Feb 22 15:43:40 JPEW: ah, so any changes are wiped on next boot? Feb 22 15:44:09 No, bind mount or symlinks to a persistent partition Feb 22 15:44:29 Well, depends on the file I guess, some are temporary Feb 22 15:45:12 JPEW: indeed, lots of special cases. is any of that work public? Feb 22 15:45:39 I hate re-inventing the wheel :-) Feb 22 15:45:56 sakoman: No, sorry. It's pretty layout specific so it wouldn't be too much help anyway Feb 22 15:46:14 yes it supports, but with my repo it didn't put aything in /workspace/sources like it does if I add for example faad2.we have a private git where I upload my code. I did devtool add Feb 22 15:46:40 JPEW: I was afraid of that! Feb 22 15:49:58 kayterina: for tarballs, best practices dictate there is only one directory at the root of the tarball which is named ${PN}-${PV}, which then contains the whole source code Feb 22 15:50:41 you have the option to name it the way you want, but ${PN}-${PV} is a good name because it is what `S` defaults to so you don't have to change it Feb 22 15:50:42 sakoman: Ya, sorry. Not much help other than "yes this is possible!". We run a R/O squashfs as our root file system :) Feb 22 15:51:53 JPEW: This client has quite a complex image with many layers, so this is going to be quite tedious :-( Feb 22 15:52:00 ok.thaks Feb 22 16:05:19 is any of yocto based on linaro? Feb 22 16:07:49 hmm many layers, I have one project with 62 though most have just one/two recipes and so many due to git repo permission scheme... Feb 22 16:08:02 sigh, gerrit Feb 22 16:27:00 sakoman: the painful thing with the symlink approach is needing to patch various things that explicitly use O_NOFOLLOW on open. mount binding or using overlayfs is more appealing to me now just because it avoids that Feb 22 16:34:38 smurray: the volatile-binds recipe sets up services for a specified list of bind mounts to make certian areas writable, with a variable to control that, and if the path being mounted over already contains files and the writable path doesn't, it'll copy the existing contents over Feb 22 16:34:51 of course, there are other options, such as overlay filesystems, too Feb 22 16:35:06 https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/volatile-binds/volatile-binds.bb Feb 22 16:36:47 kergoth: right, I've even used that before ;) Feb 22 16:38:21 can easily tweak a .wks to add a user data partition and then mount to that rather than volatile paths. *shrug* Feb 22 16:38:27 i agree symlinks suck though :) Feb 22 16:38:53 an overlay fs is more convenient, but historically they haven't always been well supported Feb 22 16:39:14 that changed once all the container stuff needed it Feb 22 16:40:50 true Feb 22 16:52:46 smurray: kergoth: I'm trying to convince them that symlinks aren't the best option :-) Feb 22 16:53:09 sakoman: good luck :) Feb 22 16:54:17 kergoth: and to make matters more interesting they want to switch to a read-only rootfs just a few days before a release! Feb 22 16:57:14 sakoman: lol Feb 22 16:58:48 lol and read-only rootfs needs to be weeks or months before release.. not a few days.. Feb 22 16:59:00 hahah Feb 22 16:59:22 yeah, r/o is a lot of drudgery. recipe A breaks on r/o, add a bind, recipe B breaks on r/o, tweak a config file, rinse, repeat Feb 22 17:07:10 kergoth: i am interested in generating my own linux sdk for a special processor. does yocto provide any of the low-level source code (e.g., usb drivers) or must i provide them from something like linaro? Feb 22 17:07:39 assume the processor is arm-based Feb 22 17:08:16 the linux kernel has a ton of drivers built in, and that's what we build. whether the stock upstream kernel will work or whether you need to use a bsp layer provided by someone else or by the manufacturer will depend on you rhardware Feb 22 17:08:20 see the layer index Feb 22 17:08:32 http://layers.openembedded.org/layerindex/branch/master/machines/ Feb 22 17:08:48 http://layers.openembedded.org/layerindex/branch/master/machines/?q=&browse=1 Feb 22 17:11:54 anyone to tell me if FILES_lib${PN} is a good idea or not wrt multilib and other fun kinds of BBCLASSEXTEND for example?? Feb 22 17:12:36 RP: maybe ^? Feb 22 17:15:34 ah yes, the "where exactly do i need to shove ${MLPREFIX}?" question.. Feb 22 17:15:37 :) Feb 22 17:16:25 kergoth: I don't know exactly when ${PN} is expanded and gets its prefix :/ Feb 22 17:16:49 and I remember there were issues with that (that was fixed by RP in dunfell IIRC) Feb 22 17:17:49 * RP has blanks that from memory Feb 22 17:18:21 sorry for bringing up those multilib nightmares again :D Feb 22 17:21:38 qschulz: I think expansion happens after PN is changed so its probably a bad idea Feb 22 17:22:12 lib${PN} is a bad idea.. you want lib${BPN}.. I think Feb 22 17:22:40 if you use bpn instead of pn you'll probably also need ${MLPREFIX} in that case Feb 22 17:22:42 ${PN} is modified fairly early to: ${MLPREFIX}=${BPN} Feb 22 17:22:46 ${MLPREFIX}lib${BPN} or something Feb 22 17:22:57 unless i'm missing something, which is possible Feb 22 17:23:03 i never remember that processing order.. Feb 22 17:23:04 kergoth, thats the part I can't remember, if you need to handle the mlprefix yourself or if it gets added automatically Feb 22 17:23:16 kergoth: we've changed it several times Feb 22 17:23:38 kergoth and ya, if it's not automatic -- what you had is the right format Feb 22 17:23:42 qschulz: i'd just test it and use bitbake -e to make sure things are what you expect in each context.. Feb 22 17:24:06 get a multilib configured qemux86-64 and add bbclassextend and test all 3 variants Feb 22 17:24:44 kergoth: yeah but sometimes you forget corner cases and it's for a recipe for inclusion in meta-oe IIUC my colleague :) Feb 22 17:24:52 thanks all :) Feb 22 17:24:56 true. have fun :) Feb 22 17:42:13 khem: if you bump your meta SRCREV to this; https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?h=yocto-5.10&id=5beca08578eee2d36a948503deda957bd50a2f73 you should still be able to build and boot your ppc64 qemu. Feb 22 17:57:29 Is there some magic variable which allows me to add kernel arguments to /boot/extlinux/extlinux.conf? Feb 22 17:59:45 manuel1985: that's one of those "it depends" questions. If you're using the support from uboot-extlinux-config.bbclass, UBOOT_EXTLINUX_KERNEL_ARGS would do it. If you're using the extlinux.conf generation in wic, AFAIK you need to do it in the .wks file Feb 22 18:01:55 smurray: Thanks! Will try it. Feb 22 18:25:28 manuel1985: UBOOT_EXTLINUX_KERNEL_ARGS += from the machine definition works fine (but not from an image recipe, be careful) Feb 22 18:28:46 vdl: in my case, the machine configuration file requires an .inc file which requires another .inc file which sets it with "UBOOT_EXTLINUX_KERNEL_ARGS ?=". So I should rather use UBOOT_EXTLINUX_KERNEL_ARGS_append rather than UBOOT_EXTLINUX_KERNEL_ARGS += from my local.conf, shouldn't I? Feb 22 18:30:23 manuel1985: you'll have to try this, I'm always confused about _append = " foo" vs += "foo", sorry. Feb 22 18:31:15 vdl: I'm fairly sure this is why they initially came up with the whole _append concept. Will try. Thanks in any case! Feb 22 18:31:16 manuel1985: If you want to keep the values that are set using UBOOT_EXTLINUX_KERNEL_ARGS ?= "...", then you should use UBOOT_EXTLINUX_KERNEL_ARGS_append. Using UBOOT_EXTLINUX_KERNEL_ARGS += would ignore any values set using ?= Feb 22 18:32:05 Saur: Great, good to have it confirmed. :) Thanks! Feb 22 18:36:03 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1838/steps/15/logs/stdio - looks new - scheduling while atomic too :/ Feb 22 18:42:36 RP: I can start a qemux86-64 build here and see if I get the same thing. Feb 22 18:46:07 zeddii: I doubt it reproduces as there were other builds active. Just unusual to see scheduling while atomic Feb 22 18:46:14 that is bad Feb 22 18:46:25 and makes a change from rcu timeouts Feb 22 18:49:30 yah. that's harder to trigger. since it really stalled for a long time, or some race was exposed. Feb 22 18:49:49 I fixed that warning on qemux86 boot though. i'll send it along tomorrow with some other minor changes. Feb 22 19:00:48 zeddii just introduces random sleeping-while-atomic issues to see if anyone is paying attention. Feb 22 19:07:30 heh. Feb 22 19:08:17 the worst part, is I can't even bisect to see if anything has been done in particular with that locking. Altough, from my poking at MSI interrupts to fix the 32bit boot, there's a LOT of tweaking in the code you'd expect to not change much. Feb 22 19:12:02 zeddii do you still include the Intel, knee cap the kernel in 48 hours patch? Feb 22 19:15:27 fray: removed it May 2020. Feb 22 19:16:10 HAHAHA couldn't find a maintainer? Feb 22 19:16:27 The patch written for a lawyer.. lol Feb 22 19:17:40 kergoth: i see - thank you. Feb 22 19:19:08 so the "bsp" (board support package) contains drivers that either aren't provided by the kernel or which need to be replaced (e.g., due to custom processor/peripherals)? Feb 22 19:19:20 does the kernal include u-boot, or is that provided by the bsp? Feb 22 19:19:29 yates: The BSP Feb 22 19:19:44 JPEW: ok, good Feb 22 19:25:06 is there something to get kind of a "diff" between two images? Feb 22 19:27:59 vdl: diffoscope? Feb 22 19:31:02 buildhistory ? Feb 22 19:31:34 JPEW: let say you want to build an overlayfs image or btrfs or something containing just the diff files. e.g. image A contains a+b, image B contains a+b+c, the "diff image" would only contain "c" files. Feb 22 19:36:45 vdl: Ah, I don't know of any way to do that (short of actually constructing the file system that way "live" using overlayfs) Feb 22 19:42:21 JPEW: that'd be neat actually to provide custom small updates mechanism Feb 22 19:46:19 vdl JPEW, would populating an image by hand using the pkg viable ? Feb 22 19:46:52 I have no idea Feb 22 19:50:43 aleblanc: it would be mostly error-prone. Feb 22 19:51:38 vdl maybe Feb 22 20:05:26 zeddii: cool. Updated the recipe locally, lets see. btw I was seeing a warning about CONFIG_POWER4 option not being recognised. I think it should be removed from defconfig for qemuppc64 Feb 22 20:06:05 I can take a peek at that. Feb 22 20:06:38 I can't figure out why I'm the only person not able to build btrfs-tools right now, so I can't actually assemble an image to test anything Feb 22 20:07:31 cool. right now I have core-image-minimal passing -ctestimage and also core-image-sato building and booting, there is one issue with diplay where fonts are garbled but otherwise its looking ok Feb 22 20:15:29 vdl: I believe there's some stuff in non-core layers for generating the difference between two images for ostree based updaters, but it likely would take some rework to do what you describe Feb 22 20:20:52 zeddii: here is exact msg https://paste.ubuntu.com/p/mGPTfdMP8Z/ Feb 22 20:32:39 hi how can I set a root password by recipe? Feb 22 20:34:58 gillesm: You probably want to look at the extrausers bbclass. Feb 22 20:40:26 saur ok thanks:) Feb 22 20:45:17 gillesm: For example, you can use something like this after you inherit extrausers in an image recipe: EXTRA_USERS_PARAMS += "usermod -p '' root; " Feb 22 20:46:12 Saur yes I know that in local.conf but I am learning how to put it in recipe ... Feb 22 21:22:06 I've been fighting w/ kernel-fitimage the last couple of days on dunfell w/ i.mx8 and a flavor of the community version.  It seems to me that if INITRAMFS_IMAGE_BUNDLE = "1", that the fitImage should _not_ contain a separate ramdisk entry?  Ie, do_assemble_fitimage_initramfs() should call fitimage_assemble w/ a 0 instead of 1 (ramdisk count) Feb 22 21:23:21 otherwise, the boot hangs at Starting Kernel... but if if boot the fitImage (non-ramdisk version)  the kernel boots fine -- so I know the kernel is good. Feb 22 21:32:34 JPEW: any idea why RPM would seem to hang diffoscope? :/ Feb 22 21:36:04 RP: Nope. Do you know if it's I/O bound, CPU bound, or just stuck? Feb 22 21:36:41 is it trying to extract and inspect the contents? some of the diff tools have enough understanding to extract the cpio and compare the contents Feb 22 21:36:45 JPEW: its using 100% cpu of a single core and never seems to complete Feb 22 21:37:06 RP: Weird Feb 22 21:37:13 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/23/steps/13/logs/stdio Feb 22 21:38:05 55124 pokybui+ 20 0 409428 78116 7900 R 100.0 0.1 738:02.39 nativepython3 Feb 22 21:38:11 RP: Hmm, should not take 12 hours for 2 packages Feb 22 21:38:53 JPEW: right :/ Feb 22 21:40:11 JPEW: its looping in python somewhere, strace shows nothing, gdb shows its in python Feb 22 21:40:27 * RP doesn't have py-bt on that host Feb 22 21:41:10 RP: Can you grab the packages? We can run diffoscope locally to see if it reproduces Feb 22 21:41:24 fray: Ya, diffoscope is supposed to be able to do that Feb 22 21:41:48 JPEW: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210222-4dslwe0b/packages/ :) Feb 22 21:42:04 I suspect rpm diffing with diffoscope may not be getting terribly much attention since Fedora kinda (temporarily?) gave up reproducible builds Feb 22 21:42:58 JPEW: I have a patch in master-next for that difference btw so I know the cause Feb 22 21:46:33 RP: Well, it seems to be reproducible Feb 22 21:48:30 JPEW: our diffoscope or a local different one? Feb 22 21:48:39 The one on my desktop Feb 22 21:48:56 JPEW: nice to have something which is reproducibile for a change :D Feb 22 21:59:48 diff [A/B]rsync.rpm worked locally with diffoscope v154 Feb 22 22:01:31 it does go into readelf and objdump to diff the 2 ... Feb 22 22:01:50 Hmm, it looks like it's getting hung up with the HTML output specifically Feb 22 22:03:14 dl9pf: I think the SDE stuff is getting hung up as you're not writing the fallback value into the SDE file Feb 22 22:03:14 Ya, it's a *huge* diff, and I'm guessing the HTML output is triggering some pathological case Feb 22 22:03:17 https://usercontent.irccloud-cdn.com/file/HwMcODlL/rpm.diffoscope.html.tar.bz2 Feb 22 22:03:42 dl9pf: combine this with hashequiv and I can see how it would get confused Feb 22 22:03:59 on diffoscope ? Feb 22 22:04:06 now I'm confused ... Feb 22 22:04:23 dl9pf: Ah.. I wonder if we need the python rpm module Feb 22 22:04:40 ok, then how should we deal with the 'old' (aka wrong) value being extracted from sstate-cache ? Feb 22 22:04:44 dl9pf: I'm talking crossed porpoises, sorry :) Feb 22 22:04:56 My diffoscope is only comparing the rpms in can't go into them (probably like the AB) Feb 22 22:04:57 dl9pf: I have a tweak to your patch in mind Feb 22 22:05:51 whoops, wic --fstype doesn't support f2fs Feb 22 22:10:49 JPEW: yeah, got python3-rpm installed locally ... so the desktop-diffoscope has it Feb 22 22:11:00 might want that for the autobuilder as well Feb 22 22:12:05 dl9pf, RP: Yep, just verified that it works once python3-rpm is installed Feb 22 22:12:13 Need to figure out how to package that in OE Feb 22 22:12:38 * JPEW has to go cook supper Feb 22 22:21:17 JPEW, dl9pf: In the interests of getting the working for now, I think I may add --exclude *.rpm Feb 22 22:21:47 python3-rpm is part of the rpm package Feb 22 22:24:56 hello, is scissors line supported in patch submitting on oe-core? Feb 22 22:25:17 so we'd need python3-rpm-native ? give it a shot before we exclude maybe ? Feb 22 22:39:52 dl9pf, RP: Yep. Got it. Patch coming Feb 22 23:03:29 JPEW: thanks, beat me to it. Thanks for the debugging, I really wasn't getting my mind onto that one today Feb 22 23:04:17 JPEW, dl9pf: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=8ecc50a0a2bdc4edad48c717e7935d0d337084c6 is what I'm thinking may fix SDE Feb 22 23:11:08 can anyone think of anything more than sstate that could corrupt a build of btrfs tools ? I switched from qemux86 in debugging the warning on boot, to qemux86-64 and btrfs tools blows up in a way that can't possibly be anything but something broken on my machine. Feb 22 23:11:44 I've been broken all afternoon and am out of ideas. The only touch on the package is anuj's minor version bump, and reverting that was a no-op. Feb 22 23:12:03 https://pastebin.com/nz4qR07U Feb 22 23:12:20 setuptools has been, and still is, in the depends, etc. Feb 22 23:14:38 zeddii: I'm sure I saw this Feb 22 23:15:22 I've searched the native sysroot, and I can't find any trace of setuptools, but I may not be looking for it properly. Feb 22 23:15:29 zeddii: oh, but it was caused by insanity locally which you couldn't have. You don't have any of my t222 branch I assume? Feb 22 23:15:56 no. but I have my own fair share of local insanity, but none that should cause this. Feb 22 23:16:09 it Feb 22 23:16:33 zeddii: in my case I had some code go crazy and it was deleting the contents of the sysroot so python3-setuptools-native was empty in the sysroot Feb 22 23:16:56 ahah. nasty. I looked for *setuptools* in the recipe sysroot and found nothing. Feb 22 23:17:21 zeddii: have a look at what python3-setuptools-native's contents is Feb 22 23:17:34 zeddii: sysroot-components/ is a good place to look Feb 22 23:19:27 and that's right in the recipe-sysroot-native, right ? I see no sign of any of it. which of course leads to that error. Maybe I should be doing a cleanall on python-native, it may have been somehow corrupted. I had some horrible networking and other issues today. Feb 22 23:20:10 * zeddii tries that Feb 22 23:22:20 zeddii: TMPDIR/sysroot-components/x86_64/python3-setuptools-native Feb 22 23:25:38 hah. I'm not sure how I didn't know about that. Feb 22 23:25:44 and that directory is empty. hmm. Feb 22 23:27:49 cleaning that specifically. something very wrong has happened. Feb 22 23:27:56 zeddii: that sounds very suspicious... Feb 22 23:28:18 zeddii: sysroot-components is where everything is hardlinked from to for recipe-sysroot and recipe-sysroot-native Feb 22 23:28:47 Its nice nobody actually has to care about the details, maybe I got something right :) Feb 22 23:29:15 indeed. The list of things that have broken, that shouldn't be possible, today is shocking. And I don't mean oe/yocto build related. Everything from wifi dying, to DNS being wrong on half my machines, to a server in the office going nuts (and now I have to go in) .. so none of this is surprising to me now. Feb 22 23:29:41 I got zero progress on anything, I just debugged "stuff that shouldn't break" and infrastructure. Feb 22 23:29:44 ahhhh. Monday. Feb 22 23:30:19 zeddii: I'm also having one of those days :/ Feb 22 23:34:29 and it's late for you! I have a bit more time to be annoyed. I cleaned the -native and rebuilt it, I see it in the provider now. but it still went boom in btrfs-tools. None of this is normal, I'll just rm -rf it overnight. Feb 23 00:23:44 never underestimate the magic of "nuke and pave". Feb 23 00:41:06 I have a 5.4 kernel where I applied a patch from 5.6 which brings in dmabuf heaps. The patch exports a uapi header include/uapi/linux/dma-heap.h. I am trying to write an application that uses dmabuf. It is able to find #include but not #include (this file is introduced in the patch) Feb 23 01:06:29 does anyone know how Freescale built their BSP for the i.MX6? Feb 23 01:06:35 is it based on linaro? Feb 23 01:08:21 JPEW, kergoth? Feb 23 02:45:57 yates: AFAIK for at least the last couple of years they've based their meta-fsl-bsp-release and now meta-imx based BSP releases on top of meta-freescale Feb 23 02:57:09 smurray: i see Feb 23 03:00:05 isn't there a git repo of the yocto layers **** ENDING LOGGING AT Tue Feb 23 03:00:05 2021