**** BEGIN LOGGING AT Fri Mar 27 02:59:57 2020 Mar 27 06:33:50 New news from stackoverflow: sosreport shows no valid plugins were enabled Mar 27 07:05:23 Good morning yocto community! Mar 27 07:05:45 While updating from warrior to dunfell, I despair of bitbaking libcryptopp_6.1.0.bb (https://github.com/chrusel/meta-chruselcrypto/blob/master/recipes-crypto/cryptopp/libcryptopp_6.1.0.bb). With poky today's master, I get "WARNING: libcryptopp-6.1.0-r0 do_package: KeyError in ./package/usr/lib/libcryptopp.so.6", then bitbake throws the Exception: Mar 27 07:05:45 KeyError: 'getpwuid(): uid not found: 1107'. (1107 is the uid of the current user, i.e. me)Bitbake runs natively on a Ubuntu 18.04 machine. I appreciate every hint, link, statement, opinion, ... ! Mar 27 07:13:35 https://github.com/chrusel/meta-chruselcrypto/blob/master/recipes-crypto/cryptopp/libcryptopp_6.1.0.bb Mar 27 07:14:58 The first link was misinterpreted by freenode ;-) -.- Mar 27 09:12:20 how to download the buildtools tarball to build master? https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#downloading-a-pre-built-buildtools-tarball points to http://downloads.yoctoproject.org/releases/yocto/yocto-3.1/buildtools/ which fails with "404 Not Found" Mar 27 09:26:39 ah, 3.1 buildtools aren't there yet so I will try zeus 3.0 one since http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/buildtools/ exists Mar 27 10:05:16 Morning. I have a bit of a weird issue, probably because I'm doing something weird. I'm moving from krogoth->thud, however I want to keep u-boot at the point krogoth is. To do this I've done a bbappend and changed the source branch. This seems to work fine. However when I try and build the fw-utils with that same approach I seem to get the tools compiled for x86 not cross-compiled for arm. Mar 27 10:05:29 Anything obvious in there I should be checking/doing? Mar 27 10:07:35 JoeR: can't you just take the whole old recipe and fix things if broken? There are usually changes in recipes to accomodate new SW versions, so if you take those modifications and try to apply it on the build process of an old version? Mar 27 10:08:08 That's the thing, I was hoping to keep the new recipe as the old recipe has issues within the new thud environment. Mar 27 10:08:16 Both ways I'm sort of damned. Mar 27 10:08:51 What's weird is that I can't really see anything different between krogoth and thud for the fw-utils recipe or supporting classes. Mar 27 10:08:56 It feels like it should work. Mar 27 10:08:57 JoeR: probably because YP changed from common sysroot to per-reipce sysroot? Mar 27 10:09:06 Ahh OK. Mar 27 10:09:14 (for why the old recipe does not work) Mar 27 10:09:52 It seems so odd that the approach works for the entirety of the uboot build, just not for the two damned userspace tools. Mar 27 10:10:35 JoeR: I remember some issues in U-Boot source code for scripts wrt wrong toolchain, but that's very recent and I don't have pointers unfortunately. But definitely end of last year or beginning of this one. Mar 27 10:11:11 (also why thud? it's EOL already?) Mar 27 10:11:15 I've seen things online that claim this was definitely broken prior to 2017, but the 2016 recipe does work in krogoth and there appear to be no exciting work-arounds. Mar 27 10:11:36 Thud was the most recent supported by NXP at the point this work was started. Mar 27 10:13:33 FWIW, this fw-utils was recently changed http://layers.openembedded.org/layerindex/recipe/117794/ Mar 27 10:13:46 Cheers, I'll see if that gives me any clues. Mar 27 10:14:03 hopefully that's possible to backport without too much hassle Mar 27 10:14:26 otherwise... why not take u-boot-fw-utils recipe for your fw-utils instead of the ones from your old U-Boot? Mar 27 10:14:36 (just asking, might miss some context) Mar 27 10:15:20 I assumed that the tools are tied to the version of uboot. Given that they are interpreting the format of the env data. Mar 27 10:15:39 http://layers.openembedded.org/layerindex/recipe/89641/ Mar 27 10:15:51 * qschulz shrugs Mar 27 10:15:58 Dunno. I'll see. Mar 27 10:16:34 The only reason I never uboot forward was that it seems to have undergone a LOT of change. So none of my patches apply, some subsystems aren't even there any more, the config is different etc. Mar 27 10:16:50 I didn't need a new bootloader, so didn't want the rework cost. Mar 27 10:18:01 JoeR: IMHO, there is little benefit from upgrading u-boot and too much risk (bricked board) so I concur Mar 27 10:18:20 try u-boot-fw-utils and see if it works okay Mar 27 10:18:27 that could be your easy way out of this Mar 27 10:18:27 Will do. Mar 27 10:19:09 As I say, I had assumed that there was a tight dependency between the fw utils and the version of uboot. From the links you've given that doesn't seem to be the case. Mar 27 10:19:35 JoeR: it could have been the case, but it's not anymore AFAICT from libuboot-env reason of existence :) Mar 27 10:19:45 Indeed. Mar 27 10:19:56 Thanks! Mar 27 10:42:19 Hi all out there! While updating from warrior to dunfell, I despair of bitbaking https://github.com/chrusel/meta-chruselcrypto/blob/master/recipes-crypto/cryptopp/libcryptopp_6.1.0.bb With poky today's master, I get "WARNING: libcryptopp-6.1.0-r0 do_package: KeyError in ./package/usr/lib/libcryptopp.so.6", then bitbake throws the Exception: Mar 27 10:42:20 KeyError: 'getpwuid(): uid not found: 1107'. (1107 is the uid of the current user, i.e. me)Bitbake runs natively on a Ubuntu 18.04 machine. I appreciate every hint, link, statement, opinion, ... ! Mar 27 11:00:46 Chrusel: maybe you need to fully wipe sstate cache Mar 27 11:03:22 mcfrisk: I already bitbake libcryptopp -c cleansstate - problem still remains Mar 27 11:05:46 Chrusel: no, wipe the full sstate cache when updating yocto releases. There are things which may not get recompiled, pseudo etc, which may cause issues like that. Mar 27 11:10:22 mcfrisk: I'll give it a try. Thanks for that hint. Mar 27 11:37:23 RP, the reference to GLIBC_GENERATE_LOCALES in the python code in meta/classes/libc-package.bbclass, does bitbake detect changes to that variable, or will that need to be described explicitly somewhere ? Mar 27 12:03:28 Hello yoctoistas! I have a rather strange dependency issue. I'd appreciate if someone had a look at this issue of mine: https://stackoverflow.com/questions/60885606/bitbake-recipe-compiles-but-cannot-be-included-into-image Mar 27 12:04:57 New news from stackoverflow: bitbake recipe compiles but cannot be included into image Mar 27 12:06:28 "git.freescale.com[0: 192.88.156.202]: errno=Connection refused ". Seems to be a common issue, anyone knows mirrors/can fix it? Mar 27 12:08:44 this is what i'm/the beast is trying to fetch: git://git.freescale.com/ppc/sdk/linux.git;nobranch=1 Mar 27 12:24:58 Found the stupid mistake Mar 27 12:25:00 I mistakenly had the C dependency added to the python runtime dependencies (RDEPENDS) which, of course, is nonsense. Mar 27 12:35:04 New news from stackoverflow: QtCreator Static Analyzer is failing on yocto "gnu/stubs-soft.h" is missing Mar 27 12:39:18 kroon: I'd have thought it should detecte it Mar 27 12:39:32 RP, yeah Mar 27 13:50:54 o/ Mar 27 14:05:55 oh, glibc-locale is not even being built. no wonder GLIBC_GENERATE_LOCALES isnt causing any rebuilds Mar 27 14:07:27 pwd Mar 27 14:14:40 Hi, can anyone help me how to create a custom yocto image? Or do i need to write a Task for this? Mar 27 14:15:42 0 Mar 27 14:21:58 Guest5223: define custom image Mar 27 14:22:08 every recipe that inherits the image class is a custom image Mar 27 14:22:21 Guest5223: https://www.youtube.com/watch?v=nqHylLP2NmA Mar 27 14:22:39 (and most videos in there, in order in preference :) ) Mar 27 14:22:58 rburton i already have. I inherit core-image Mar 27 14:23:06 voila, custom image Mar 27 14:23:17 So that was my guess, that i may need to redefine or add a task to that? Mar 27 14:23:25 again, what do you want to do Mar 27 14:24:30 I want to create a 128Mb Ubi with one ubifs . Kernel and dtb should be in /boot on the same volume Mar 27 14:24:44 wic is what you want Mar 27 14:25:09 wic handles ubifs? Mar 27 14:30:29 i can create the image with IMAGE_FSTYPES += " ubi ubifs multiubi" This creates ubifs file which i @ Mar 27 14:30:36 'flashed' manually. it worked. Mar 27 14:31:04 but anyway, now that i know where to put it, i can solve it. Have a nice weekend Mar 27 15:35:23 I'm running into an issue where when I add a line to a recipe I'm building, it doesn't take effect. But adding it to my conf/local.conf does Mar 27 15:35:37 New news from stackoverflow: SysV Init killall5 does not wake up after sleep 5 Mar 27 15:36:18 I.e. in the recipe: `INSANE_SKIP_${PN}_append = "already-stripped"` does nothing. But `INSANE_SKIP_pkg-name_append = "already-stripped"` in conf/local.conf applies Mar 27 15:36:42 I ran `bitbake -e pkg-name` and PN is set correctly Mar 27 15:36:56 nhartman: is there a leading space before already-stripped? Mar 27 15:37:00 because append doesn't add it Mar 27 15:37:11 and parse order can result in different things happening Mar 27 15:37:32 if you're already running -e, look at the value of INSANE_SKIP when its set in the recipe :) Mar 27 15:37:35 Ahh. That is possibly it, thanks Mar 27 15:40:12 Hmmmn. Same issue unfortunately Mar 27 15:40:22 well, what is INSANE_SKIP set to Mar 27 15:41:51 Hmmmm Mar 27 15:41:53 bitbake -e k3s | grep ^INSANE_SKIP Mar 27 15:41:55 Nothing apparently Mar 27 15:43:38 hello world hope everyone is doing well Mar 27 15:44:08 nhartman: are you writing a recipe to simply package the binary of k3s? Mar 27 15:44:46 Yes Mar 27 15:45:01 you'll be wrestling the build system less if you actually built it Mar 27 15:45:15 rburton: that’s a different story, I already have a in progress recipe for that Mar 27 15:45:17 also a recipe to actually build it would be acceptable in meta-virtualisation so you can share it Mar 27 15:45:43 but the factoring of k8s, microk8s and k3s is non-trivial at the moment :D Mar 27 15:46:22 nhartman: fwiw there are plenty of recipes that just do INSANE_SKIP_${PN} += "dev-so already-stripped" in the recipe themsleves Mar 27 15:46:48 zeddii: yeah i'm not suggesting it would be easy :) Mar 27 15:47:17 well thats it. i'm done for. i sent a patch for autoconf. Mar 27 15:47:55 later! Mar 27 15:49:56 i have a question regarding encodings.... when running python from yocto it complains "Warning: sys.stdout.encoding is set to ANSI_X3.4-1968, so Unicode output may fail. Check your LANG and PYTHONIOENCODING environment settings." ??? i cant seem to find very much dealing with this other then changing code within the py file. systemd and superviserd Mar 27 15:49:56 both seem affected as well. any suggestions? Mar 27 16:02:26 Sorry for the repeat, but I'm really stuck. I asked this question yesterday here and on the mailing list but got no response. I'm having trouble defining a downgrade of lvm2 in Zeus. It looks like a bug to me; but need guidance troubleshooting. See https://gist.github.com/mabnhdev/fe1efed09b4c0159a394bdbae54f3fa9 for details. Mar 27 16:07:01 did you add PREFERRED_VERSION_lvm2=? Mar 27 16:08:22 rpi3_poky_newb Yes both PREFERRED_VERSION_lvm2 and PREFERRED_VERSION_libdevmapper. Both are components of lvm2. Mar 27 16:09:22 PREFERRED_VERSION_lvm2=2.02.171 needs to be defined somewhere Mar 27 16:10:51 rpi3_poky_newb Yes - it is defined in my conf file. You can see it at the top of my gist. Mar 27 16:11:12 oh ya cleanall then Mar 27 16:11:36 i ran into this too. there is an override Mar 27 16:11:50 but its not reccommend Mar 27 16:11:59 @rpi3_poky_newb Tried that too. Fresh sandbox. Fresh cache. Mar 27 16:13:29 rpi3_poky_newb AFAIK, this should work. It has always worked for me in the past (upgrades and downgrades in general, not specifically lvm2). Mar 27 16:16:52 rpi3_poky_newb What's the override? I'd like to at least give it a try. I'm getting further in the weeds. Right now, my workaround is to copy lvm2 and libdevmapper packages from my old Sumo build. Mar 27 16:52:52 <[Sno]> on a system with ro-nfs root I get Mar 27 16:52:52 <[Sno]> Starting rpcbind daemon...done. Mar 27 16:52:53 <[Sno]> /etc/init.d/rc: /etc/rc5.d/S15mountnfs.sh: line 70: service: not found Mar 27 16:52:53 <[Sno]> Starting rpcbind...Mounting remote filesystems... Mar 27 16:52:53 <[Sno]> mount.nfs: rpc.statd is not running but is required for remote locking. Mar 27 16:52:53 <[Sno]> mount.nfs: Either use '-o nolock' to keep locks local, or start statd. Mar 27 16:53:28 <[Sno]> seems to be introduce by commit c9fc9110be33fe0f24bc3a7c242b584a4ca33e04 Mar 27 16:56:23 Okay. I even tried PREFERRED_VERSION_lvm2_forcevariable and still no luck. Mar 27 17:58:23 <[Sno]> RP: https://salsa.debian.org/debian/init-system-helpers seems to provide service for non-systemd distributions Mar 27 17:59:37 <[Sno]> mountnfs.sh is using service - so either mountnfs should use something else or depend on virtual/init-system-helpers, shouldn't it? Mar 27 18:00:37 [Sno]: I don't have the context to answer that offhand Mar 27 18:01:08 <[Sno]> RP: a few lines above ... on sysvinit distro on NFS ... Mar 27 18:01:56 [Sno]: ah, yes, probably a missing depends Mar 27 18:02:07 <[Sno]> no hurry - it's broken since Fri May 25 10:48:08 2018 (commit c9fc9110be33fe0f24bc3a7c242b584a4ca33e04) Mar 27 18:03:08 <[Sno]> since I'm not that deep into it ... looks to me providing /usr/sbin/service for sysvinit (or openrc etc. ...) Mar 27 18:04:12 <[Sno]> how sane is it to put that to poky - since it's moving to systemd - or maybe move sysvinit to something like an external meta-sysinit? Mar 27 18:07:11 <[Sno]> RP: khem: something like https://github.com/meta-layer/meta-sysinit - maybe below meta-openembedded like meta-networking ? Mar 27 18:13:33 [Sno]: we're not dropping sysvinit any time soon Mar 27 18:14:00 <[Sno]> RP: so OE-core is sane Mar 27 18:15:39 OE-Core is a model of sanity :) Mar 27 18:16:04 * RP tries not choke laughing Mar 27 18:16:49 we do have an insane class : ) Mar 27 18:17:47 * armpit yes core is very sane compared to the classic days Mar 27 18:19:12 <[Sno]> maybe that's a joke a non-native-speaker won't understand so easy ... Mar 27 18:44:23 [Sno], it is a play on words Mar 27 18:45:04 <[Sno]> armpit: I assumed that - but my english isn't good enough :( Mar 27 18:50:34 hey all looking for help with pythons encoding...any tips or pointers wpuld be nice Mar 27 20:36:38 New news from stackoverflow: Yocto Test Image Task for QEMU Fails inside Docker Host Container Mar 27 20:39:54 RP: you picked wrong binutils patch Mar 27 22:33:29 RP: this is the right patch https://lists.openembedded.org/g/openembedded-core/topic/patch_binutils_pregenerate/72553705?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,72553705 Mar 27 22:35:13 one in master-next as of now is wrong one we should not apply it Mar 28 01:07:26 New news from stackoverflow: Point releases vs milestone releases in Yocto **** ENDING LOGGING AT Sat Mar 28 02:59:59 2020