**** BEGIN LOGGING AT Mon Mar 11 02:59:57 2019 Mar 11 08:04:56 good morning Mar 11 08:21:24 New news from stackoverflow: Circular dependencies issue with wic and fitImage+Initramfs Mar 11 09:02:04 Hi all, is there an appropriate option to run bitbake in a CI process and not get all the progress bars in the logs? Thanks! Mar 11 09:05:32 emilienh: bitbake -q not being helpful` Mar 11 09:05:34 ? Mar 11 09:09:03 with -q -q -q theres no progress bars anymore, just checked :) Mar 11 09:18:12 Thanks Leto I'm gonna try that Mar 11 09:24:28 I see with -q -q -q I'm not getting any output at all, which is not ideal either Mar 11 09:25:42 emilienh: AFAIK there was someting that bitbake tries to detect if the controlling terminal is interactive, and if it is not, there should be no bargraphs. but i could certainly be mixin up things here. Mar 11 09:26:04 emilienh: actually your best chance is to ask kergoth in the afternoon, i'd say Mar 11 09:28:19 So using a different shell to Run bitbake might do the trick then? I'll try that thank you! Mar 11 09:28:28 *might* Mar 11 09:28:39 all right :) Mar 11 09:28:40 no guarantees, might be me misremembering. Mar 11 09:29:02 no problem, thanks for the help! Mar 11 09:41:37 hello, what is the best practice to flash boards in mass production with Yocto generated images? During developement I use a wic image which contains several partitions, etc. Most partitions are empty during production and are filled with data later on Mar 11 09:42:06 The wic image, with an empty 30GB gets rather big. So writing it "raw" to an eMMC works, but takes a long time Mar 11 09:42:21 *empty partition of Mar 11 09:42:23 lfa: are you asking about which images to flahs, or which hardware to use, or what? Mar 11 09:42:49 mostly which images to flash, in an efficient way Mar 11 09:43:08 depends. Mar 11 09:43:10 I'm thinking of a combination of parted + writing just ext4 images instead of the whole wic image Mar 11 09:43:49 a common technique is to have some form of updater-system booted that can then operate on file level instead of partition level Mar 11 09:44:08 ubifs permits a hybrid form, with content replacing Mar 11 09:45:13 As "boot source" I would use TFTP+NFS during the flashing process Mar 11 09:45:33 certainly doable. Mar 11 09:46:23 LetoThe2nd: ok. so create partitions beforehand (e.g. with parted) and then file-based. sounds reasonable Mar 11 09:47:04 it an option. Mar 11 09:47:17 it depends soooo much on your hardware and project Mar 11 09:49:09 I mean... I would like to use the wic image because it just contains everything, but write a 30GB image which mostly contains zeros is rather inefficient Mar 11 09:54:43 Is it possible to access the partition information stored in a .wks file in my own image bbclass? I'm thinking about an image bbclass which generates a script for parted Mar 11 09:54:58 that way I would not need to duplicate the information in two locations Mar 11 09:55:46 hi. when using "addtask" where does Yocto write it? Mar 11 09:58:10 lfa: i believe wic can expand partitions as it writes, so your actual image is a lot smaller but 'wic write' can expand it Mar 11 09:58:17 lfa: alternatively, use bmap Mar 11 10:18:56 LetoThe2nd: I'm not only worried about image size, but the time it takes to write the big (expanded) image too Mar 11 10:19:03 will look at bmap though. Didn't know it and looks it's exactly what I need/want. Thanks! Mar 11 10:50:55 lfa: i believe if you build eg a wic.bmap you'll end up with a bmap file generated, and then you can use bmaptool to write it fast Mar 11 10:51:01 *maybe* wic write does that for you too Mar 11 10:57:13 ~. Mar 11 10:57:53 hrmph. Mar 11 12:07:38 so, i made a simple recipe that copies a bunch of html files to /srv/www on do_install(), and added it to CORE_IMAGE_EXTRA_INSTALL in the image recipe Mar 11 12:08:18 however if i cleanall my html recipe, baking the image does not invoke rebuilding it Mar 11 12:08:34 it keeps the old content Mar 11 12:08:50 wonder what could i be missing Mar 11 12:09:02 varjag: try -c cleansstate Mar 11 12:09:35 varjag: unless you give it some kind of versioning, bitbake does not really rebuild if it thinks nothing changed. Mar 11 12:09:58 k trying that.. Mar 11 12:10:02 varjag: and for change detection it looks at the recipe, not at the sources. no change in the recipe, no rebuild by default. Mar 11 12:10:06 it does seem to rebuild my other recipes in similar circumstances Mar 11 12:10:35 maybe i misremember, let's see Mar 11 12:11:22 ok cleansstate did the trick, thanks Mar 11 12:20:42 varjag: what is your SRC_URI Mar 11 12:24:00 rburton: my local git repo, srcrev set to autorev Mar 11 12:24:17 hm should be working Mar 11 12:27:42 ok, i had a space between 'SRCREV' and '=' Mar 11 12:29:26 but it shouldn't matter, right? Mar 11 12:29:39 "nothing else matters" (TM) Mar 11 12:29:45 Mar 11 12:41:59 varjag: if your issue is about AUTOREV, maybe this is for you https://lists.yoctoproject.org/pipermail/poky/2016-September/010666.html Mar 11 12:52:22 New news from stackoverflow: cannot execute any command using sudo on raspberry pi Mar 11 12:53:34 Jacen: thanks for the hint, am still fiddling around with it trying to see what it was about Mar 11 14:22:35 Hey all - I'm trying to check all the versions of a package that are available from the upstream provider Mar 11 14:22:51 So for example busybox - rather than just check for latest-version I'd like to see all available versions. Mar 11 14:23:32 Anyone know where devtool prunes out the old ones after scraping the page? I checked in recipetool's simplify_history but that doesn't seem to be getting run when I upgrade a package or check for latest version Mar 11 14:24:22 Striking7: well for any given state of the layerstack there is usually only one version of a given recipe available. Mar 11 14:24:46 Striking7: as version bumps in almost all cases replace the old version. Mar 11 14:25:29 Striking7: there's a couple of exceptions here and there, but generall the yocto release indirectly defines the version of the recipes it contains. Mar 11 14:25:48 LetoThe2nd - Yes, that's the problem I'm having here. My current use case requires that I upgrade to the *earliest* version of a package that fixes a specific CVE Mar 11 14:26:25 So if I can list available versions I can do that. It seems to be scraping all that info off upstream SRC_URI pages anyway and discarding it Mar 11 14:26:33 Striking7: That means that you have to add a custom layer that brings the desired version, and then explicitly select it with PREFERRED_VERSION Mar 11 14:26:33 Striking7: backporting the fix seems like an easier solution Mar 11 14:26:42 upgrading to random release may introduce more bugs Mar 11 14:27:04 I was wondering where that was happening, because then I can squirrel away all the intermediate versions and check against them, then use devtool upgrade -V VERSION_NUMBER to upgrade to a specific version Mar 11 14:27:31 rburton - this is something that needs to be automated. Mar 11 14:27:45 Striking7: automatic upgrade to random releases sound very exciting Mar 11 14:27:58 rburton - I understand the danger of that here, but it seems to be what my employer really really wants. Mar 11 14:28:05 the bitbake fetcher contains the logic for "guess what versions are available" Mar 11 14:28:20 have you tried option one of "that's a stupid idea" Mar 11 14:28:21 rburton automated execution of upgrades once decided upon by the user Mar 11 14:28:28 not just in the background happening willy nilly Mar 11 14:28:59 rburton - given that this is my 3rd day on the job, no I haven't. I don't have that kind of familiarity with the problem or the clout Mar 11 14:29:04 backport relevant cve fixes to the stable branch of oe that you're using, then everyone else gets the fixes and you don't get breakage from version bumps Mar 11 14:29:27 rburton until I've had a chance to get more intimately familiar with the situation, I have to assume they're not asking me to do something stupid, more that I just don't understand the problem fully yet Mar 11 14:30:11 rburton that's the problem. I/we aren't using any stable version of OE. Our *customers* are using thousands of different ones. Mar 11 14:30:47 This isn't just me maintaining my 1 distro happily. I'll be providing an admin tool for customers to auto-patch packages when fixes for specific CVEs pop up Mar 11 14:31:05 * rburton shudders Mar 11 14:31:35 Yeah. And if Yocto was the only platform we support that'd be one thing... Mar 11 14:31:41 * Striking7 sighs Mar 11 15:17:08 is there a reason why bitbake complains when it finds a bbappend without a corresponding bb? For instance I need a bbappend to fix an upstream recipe, but the layer I'm working on is shared by others that don't include the layer I'm fixing in my build. How would you deal with that? Mar 11 15:22:50 New news from stackoverflow: wlan usb stick on custom linux system appears to be working, but the outside world cannot see it Mar 11 15:23:18 dkc: got the same problem here! we use to add a BBMASK in all other layers but this is painfull to maintain multiple images, anytime we need to .bbappend a recipe for a specific product, we need to add a BBMASH for all others product image we have, don't know if there is a better way to do that :/ Mar 11 15:26:13 RP: are you aware of any trick for autotools project to configure,build and install for multiple python runtimes? http://gnu-automake.7480.n7.nabble.com/Supporting-multiple-python-runtimes-with-automake-td22816.html Mar 11 15:26:31 dkc, meow`: Look into the way other layers handle this. For meta-raspberrypi there is a dynamic-layers directory and some magic in layer.conf: https://github.com/agherzan/meta-raspberrypi/blob/master/conf/layer.conf#L27 Mar 11 15:27:02 lttng-ust and lttng-tools support botth python2 and python3 but need the PYTHON=xxx ./configure make, PYTHON=xxx3 ./configure make dance to support both version Mar 11 15:27:29 dkc, meow`: For meta-sancloud we just have a meta-sancloud-arago sub-layer which is only included when using the arago distro Mar 11 15:34:03 psrcode: packageconfig? default to py3, py2 for people who refuse to admit that py2 is dead. Mar 11 15:34:11 (a few recipes do that already) Mar 11 15:34:29 paulbarker: thanks you paul, i will take a deeper look Mar 11 15:35:36 rburton: okai, so should I create a recipe in the meta-python layer or add a "feature" in the lttng-ust recipe i.e: PACKAGECONFIG[python3-agent] = "--enable-python-agent PYTHON=python3, --disable-python-agent, python3-core" Mar 11 15:35:56 psrcode: add directly to oe-core Mar 11 15:36:08 rburton: okai thanks Mar 11 15:36:48 How can I set SRC_URI to copy a whole directory 1:1 (recursively, inclusive relative symlinks) to WORKDIR? Mar 11 15:36:57 paulbarker: okay thanks for the suggestions, in the end we always have to create a layer to host these bbappends and enable these "fix layers" only when the layer they're supposed to fix is enable Mar 11 15:37:06 Is there any chance to do do withouth using a tarball? Mar 11 15:41:01 rburton: while I have you, is there a way to specify a dependency on a package with a certain feature enabled? or should i use https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#dependencies#python-functions ? Mar 11 16:36:12 psrcode: no there isn't Mar 11 16:50:01 rburton: okai thanks Mar 11 16:53:11 New news from stackoverflow: Wi-Fi USB stick on custom linux system appears to be working, but the outside world cannot see it Mar 11 17:12:52 ... good answers to that already in comments Mar 11 21:06:21 Hi o/ Mar 11 21:08:03 I would like to know if image rootfs directory in built image WORKDIR is created with do_rootfs or there is other task wich creates filesystem under fakeroot ? Mar 11 21:08:44 yes, it's do_rootfs, and yes, it runs under fakeroot Mar 11 21:08:50 I'm trying figure out why dnf during rootfs creation fails due to not enough space on that rootfs directory Mar 11 21:09:45 sounds like the image space variables aren't sufficient for the packages being installed Mar 11 21:10:00 looks like IMAGE_ROOTFS_SIZE or extra space is not used Mar 11 21:11:34 I increased those variables but they are used much later than ${WORKDIR}/rootfs was created and package manager installas all packages Mar 11 21:19:58 kergoth: do You have any clues were to look for the issue with dnf ? or were to check. Mar 11 21:20:25 df under devshell doesn't provide any data Mar 11 21:21:36 I can't find any action which would suggest filesystem creation before package manager starts installing packages Mar 11 21:21:57 or size limits setting on it under pseudo Mar 11 21:36:27 RP: hopefully quick question, what's the method for getting bitbake changes backported (looking to backport gitsm fixes into thud)? Mar 11 22:56:37 winotu: what file system is the build host using? Mar 11 22:56:50 winotu: eg zfs/btrfs are good for filling up before df says they're full Mar 11 22:57:22 smurray: several people have asked about those. i would suggest asking fray too but he's not here Mar 11 22:59:56 rburton: yeah, I asked a few weeks back and he indicated it was on his TODO list but that he was swamped. AGL needs it pretty soon, so I can give it a try, but I don't follow how bitbake changes get backported with its lack of OE branches Mar 11 23:00:52 rburton: host uses ext4 Mar 11 23:01:12 but it's not full Mar 12 02:25:04 New news from stackoverflow: bazel 0.5.3 how to use cross-toolchain, for example, yocto sdk (aarch64) **** ENDING LOGGING AT Tue Mar 12 02:59:57 2019