**** BEGIN LOGGING AT Fri Aug 09 02:59:57 2019 Aug 09 03:04:09 New news from stackoverflow: Convert a tar.xz into a tar.gz in the deb package Aug 09 07:22:34 kernel Kconfig meta problem: Why https://pastebin.com/V9ekDuEQ Aug 09 07:58:50 hi everyone Aug 09 07:59:30 I have a question, is it possible to force a recipe to be rebuild if the image rootfs is rebuild as well ? Aug 09 08:00:18 to explain my need, when I do , I want to rebuild os-release recipe if do_rootfs is executed Aug 09 08:00:39 to have the DATETIME var in /etc/os-release of the rootfs Aug 09 08:03:17 amaury_d: that actually sounds more like you want a ROOTFS_POSTPROCESS_CMD, not an extended recipe. Aug 09 08:04:23 LetoThe2nd: yes I could do it via ROOTFS_POSTPROCESS_CMD Aug 09 08:04:57 but when I saw os-release recipe from poky/meta, I though it was designed for this use case Aug 09 08:05:25 amaury_d: it sepcifies the os_release, just like the name says. not the build date. Aug 09 08:05:30 particularly because of BUILD_ID ?= ${DATETIME} Aug 09 08:05:57 let me have a look :) Aug 09 08:08:48 amaury_d: hm, maybe it would even be enough to remove the vardepsexclude on DATETIME Aug 09 08:09:16 but in this case the image will be always rebuild ? Aug 09 08:09:55 I try to find the optimal way, to avoid having rebuild image if everything is up to date if possible Aug 09 08:10:22 hehe Aug 09 08:10:25 else, what is the syntax to remove DATETIME from vardepsexclude ? Aug 09 08:10:53 i can see what you want, but i don't think theres a neat way. just a postprocess cmd Aug 09 08:11:08 good question. Aug 09 08:11:22 RP: can you enlighten us if theres magic for this? Aug 09 08:12:09 in the manual, its specified that _remove does not work for flag syntax Aug 09 08:12:11 https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#variable-flag-syntax Aug 09 08:12:38 LetoThe2nd: I understand that this is a tricky problem :) Aug 09 08:13:20 if not possible, never mind I will rebuild image on every bitbake invocation Aug 09 08:13:54 its a totally valid question, i just don't have a good answer besides what i already wrote, sorry. Aug 09 08:14:40 In sumo branch if I include lib32-glibc in an image I get the following warning: Aug 09 08:14:56 WARNING: The postinstall intercept hook 'update_gio_module_cache-lib32' failed, details in /home/tamis/build_occe/tmp/work/intel_corei7_64-intel-linux/core-image-occe/1.0-r0/temp/log.do_rootfs Aug 09 08:14:56 valid ELF image for this architecture Aug 09 08:15:36 any ideas of how to fix that? Aug 09 08:16:02 LetoThe2nd: no problem, thank you for your help :) Aug 09 08:30:57 LetoThe2nd: I tried with a ROOTFS_POSTPROCESS_CMD, but I got "basehash value changed from ... The metadata is not deterministic and this needs to be fixed" Aug 09 08:31:15 maybe I should use nostamp on os-release recipe... Aug 09 08:31:17 hm Aug 09 08:39:14 I have built extensible SDK... I install it and should run devtool but it doesn't... however I have found out that every tool in eSDK/sysroots/x86_64/usr/bin depends on finding libraries in $SDKPATH (is set to /opt/...) Aug 09 08:39:33 thus if I then install the normal toolchain to /opt/... Aug 09 08:39:42 tools start to work... Aug 09 08:40:03 but for example devtool fails due to not being able to find argparse module... Aug 09 08:40:05 LetoThe2nd: I have decided to use do_compile[nostamp] = "1" in os-release Aug 09 08:40:17 it seems overkill but at least I'm sure the datetime of build is correct Aug 09 08:40:23 amaury_d: if it does the trick for you, all is well Aug 09 08:40:31 thanks for reporting back Aug 09 08:40:32 thank you for your help Aug 09 08:40:35 should I set SDKPATH variable or will this break eSDK? Aug 09 09:34:46 kanavin: around? One of the RDEPENDS changes seems to be making the g-i tests fail due to missing pkgutil :/ Aug 09 09:41:37 kanavin: actually I don't think its your patches and I can probably test a guess at the fix... Aug 09 10:43:28 RP: cheers, I am looking at mingw failure meanwhile. We might have to add another ugly-ish _mingw32_remove :( Aug 09 10:44:26 kanavin: "the mingw failure" Aug 09 10:44:52 gcc-cross-canadian has this to say: # Having anything auto depending on gcc-cross-sdk is a really bad idea... Aug 09 10:44:52 EXCLUDE_FROM_SHLIBS = "1" Aug 09 10:45:02 which doesn't exactly explain why Aug 09 10:45:24 kanavin: sorry, failed to transmit the tongue-in-cheek feeling over IRC Aug 09 11:20:00 kanavin: that sounds like it wants its libs to be private Aug 09 11:20:47 kanavin: "gcc-cross-sdk" is also a very very old term Aug 09 11:21:37 kanavin: it may not even be an issue now as I suspect cross-canadian doesn't build the libs it used to duplicate? Aug 09 11:45:08 RP: I am not sure about that, I went the mingw_remove route in the latest iteration of the patch. But we can drop the EXCLUDE_FROM_SHLIBS and see what happens too. Aug 09 11:45:39 basically this line was added by you years ago, and 'really bad idea' bit discouraged me :) Aug 09 11:54:39 kanavin: I figured it might have been me. I'm tempted to try removing it Aug 09 11:54:58 kanavin: back then we didn't have rss and so on so it was a different world Aug 09 11:56:02 kanavin: the key bit in the phrase is "depending on" - we want to mask out its provides, not its depends Aug 09 12:05:04 RP: right, but that requires explicit listing of libraries in PRIVATE_LIBS, which is probably prone to breakage on version upgrades Aug 09 12:05:53 I did this in a couple of places though for ptest packages (dbus and recently elfutils) Aug 09 12:08:45 kanavin: I think we should add something to the code which just disables generating shlibs provides Aug 09 12:09:00 kanavin: I actually thought we had such a thing already Aug 09 12:09:30 RP: I looked at that part in package.bbclass, and couldn't find it. It would certainly be beneficial! Aug 09 12:10:34 kanavin: I also looked and couldn't see it. It would be useful Aug 09 13:16:27 kanavin: I'm also seeing an odd perl-native problem. Sometimes there is a recipe-sysroot-native/usr/lib/perl5/5.30.0/Storable.pm and sometimes not Aug 09 13:17:30 kanavin: tmp/work/x86_64-linux/perl-native/5.30.0-r0/temp$ grep 0/Storable.pm log.do_ins* shows only about half the install logs install it Aug 09 13:19:06 kanavin: looks to correlate with do_compile log size:/ Aug 09 13:25:52 ah, and the reason I see weird determinism problems is the same sstate hash and manifest has different files in it at different times Aug 09 13:30:27 RP, kanavin: I think I've seen a similar perl issued when I was looking at reproducibility (it was for the target packages though) Aug 09 13:33:38 JPEW_: I was trying to figure out why sstate was breaking but its an underlying determinism problem and sstate assuming things with the same hash are really the same :/ Aug 09 13:34:31 RP: perl wasn't producing the same sstate output each time for the same taskhash? Aug 09 13:36:50 JPEW_: correct Aug 09 13:37:20 JPEW_: from local rebuilds of it Aug 09 13:39:41 RP: Matches what I saw. That was one of the reasons I was thinking the reproducible build test might have to do 2 clean builds Aug 09 13:44:23 RP: The hashequiv issue where do_populate_sysroot_setscene skips do_configure is ironic(?) because that is the example I was planning on using in devday presentation Aug 09 13:48:44 I have a recipe that depends on ruby-native, and a particular gem. Since there is no meta-ruby anymore, how can I define my dependency? Aug 09 13:51:43 RP: I suspect the Storable issue might be in do_compile where that thing could be 'generated' (or not) Aug 09 13:52:23 jofr, you take over the maintenance of meta-ruby and place your gem in it:) Aug 09 13:52:42 generally there has not been a lot of interest in ruby, the version in oe-core hasn't been updated in years Aug 09 13:52:50 kanavin: Yay! Aug 09 13:53:06 jofr: I see a ruby recipe in the openembedded layer index: https://layers.openembedded.org/layerindex/recipe/40228/ Aug 09 13:53:51 contrast: Yes. It has Ruby. But there used to be a "bundler" that could install gems Aug 09 13:54:42 I just keep falling more and more in love with this home-grown build-system that we have here (written in Ruby). *sigh* Aug 09 14:00:18 JPEW_: It can skip configure *if and only if* all the pieces come some sstate Aug 09 14:05:06 RP: Ya I was wonder if that was the bug.... it was removing do_configure to aggressively when it discovered do_populate_sysroot, but there were still some non-sstate tasks that need it to run? Aug 09 14:08:28 JPEW_: I think so. Sadly I've been pulled into a uncontrolled funnel of other bugs :/ Aug 09 14:10:11 https://bughunter.tamu.edu/collection/collectionequipment/berlese-funnel/ Aug 09 14:26:23 Hi all Aug 09 14:26:35 Is there a way to deploy all locales (glibc-binary-localedata-*, glibc-charmap-*, glibc-gconv-*, glibc-localedata-*, locale-base-*), please ? Aug 09 14:26:44 I already set GLIBC_GENERATE_LOCALES="en_GB.UTF-8 en_US.UTF-8 fr_FR.UTF-8 ru_RU.UTF-8 he_IL.UTF-8 sv_SE-UTF-8"; IMAGE_LINGUAS?="en-gb" but it still have to specify all combination for each packages) Aug 09 14:28:07 Crofton|work: I'd really like to see your display of bugzilla bugs where each one is carefully pinned to a board and labeled with the scientific name Aug 09 14:58:34 glib-2.0 build for target is broken on master (poky and openembedded) for me... do you have the same issue there ? Aug 09 15:02:49 nabokov, nope. Do you have extra layers enabled? Aug 09 15:05:59 New news from stackoverflow: Enable root password verification while login with serial console in Yocto || Replace mosquitto.conf file with bbappend? Aug 09 15:23:58 hello folks Aug 09 15:25:01 If I build from an external source using externalsrc, and start building the package, press C-cc (interrupt twice). Then change sources, and build again. Does it continue the build where it stopped (i.e if the pacakge's 'do_compile' doesn't do anything special like cleaning). or will yocto clear the build folder with every build? Aug 09 15:25:49 it'll continue. do_compile doesn't wipe the build dir. if it did, builds would break, as do_configure touches the build dir too Aug 09 16:16:58 @ kanavin yes I do (meta-raspberrypi) but they do not override anything in build system or glib-2.0 Aug 09 16:17:40 @kanavin "do_configure" fails indeed Aug 09 16:18:43 meson.build:1:0: ERROR: Unknown compiler(s) Aug 09 16:31:30 So I want to make sure I understand the difference between "native", "nativesdk" and "cross" Aug 09 16:32:14 For "native", it just means that if someone DEPENDS on you (i.e. DEPENDS += "foo-native")...it means you're going to be available somewhere when that recipe is being built, but doesn't mean you're going to be installed into the SDK right? Aug 09 16:33:02 warrior 2.7.1: tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/curses/__init__.py", line 13, in Aug 09 16:33:02 from _curses import * Aug 09 16:33:02 ModuleNotFoundError: No module named '_curses' Aug 09 16:33:02 ^^^ does this ring a bell ? anyone ? Aug 09 16:34:19 If a recipe DEPENDS on a native package...does that mean the "foo-native-dev" package will be installed to the SDK or no? Aug 09 16:34:44 do_rootfs can't exec dnf due to _curses not being found Aug 09 16:35:07 at sumo branch: qemu.bbclass at the end returns qemu-" + target_arch which is x86_64 for 64 multilib image. But what it you want to add in that image lib32-glibc qemu-i383 needs to run. Aug 09 16:35:12 How you can do that? Aug 09 16:35:57 qemu-i386* in order to execute the lib32-executable Aug 09 16:47:46 marler8997: native == built *on* this machine, *for* this machine, completely independent of the target machine/board. cross == built *on* this machine, *for* the target, it's bound to both the host and the target, and is how we build our cross-compiler. nativesdk == built *on* this machine, *for* the SDKMACHINE, targeting the SDKMACHINE. that is, it builds binaries for the sdk which run on the machine that installs the sdk, and are independnet of the Aug 09 16:47:46 target. build tools, in other words. nativesdk == a packaged version of native, but meant to run on the sdkmachine, not the current machine (you can build an sdk intended for 64-bit hosts even if you're builidng it on a 32-bit host) Aug 09 16:49:15 ok that helps Aug 09 16:51:01 so for a cross-compiler recipe meant to be used as an EXTERNAL_TOOLCHAIN to build everything in yocto, I definitely want cross Aug 09 16:51:38 and if I needed a compiler in the sdk, I would want crosssdk Aug 09 16:52:41 actually do Aug 09 16:52:52 crosssdk, despite the misleading name, is the toolchain that *targets* sdkmachine Aug 09 16:53:07 if you're building a 64-bit sdk on a 32-bit x86 host, crosssdk is what builds the nativesdk packages for 64-bit x86 Aug 09 16:53:19 i.e. crosssdk == cross but targeting sdkmachine, not machine Aug 09 16:53:33 it's *cross-canadian* that uses crosssdk to build a toolchain that runs on sdkmachine but targeting machine Aug 09 16:53:48 s/do/no/ Aug 09 16:54:07 first it builds crosssdk toolchain, then it uses that to build the nativesdk and cross-canadian packages Aug 09 16:54:41 gotcha Aug 09 16:54:46 cross-canadian should really get renamed, it sounds like it'd be used to build a cross-canadian toolchain to run on the target, but it's actually specific to the sdk, dspite not having sdk in its name Aug 09 16:55:13 one more question...I get confused about install locations for each type of recipe and which install function to override Aug 09 16:55:34 cross canadian is a generic term. from wikipedia: "The Canadian Cross is a technique for building cross compilers for other machines. Given three machines A, B, and C, one uses machine A (e.g. running Windows XP on an IA-32 processor) to build a cross compiler that runs on machine B (e.g. running Mac OS X on an x86-64 processor) to create executables for machine C (e.g. running Android on an ARM processor)." Aug 09 16:55:45 For my cross compiler, do I override do_install_cross then? And install it to ${D}...and does it just not do the packaging steps or what? Aug 09 16:55:56 you don't need to do anything special Aug 09 16:56:08 just install to ${D} in do_install and the bbclasses will do the rest for you Aug 09 16:56:13 perfect Aug 09 17:26:48 I get the "Nothing PROVIDES..." error for my recipe "/mylayer/recipes-core/systemd_service/systemd_service.bb". "mylayer" is added to bbconf. I am missing something obvious,which is...? Aug 09 17:44:11 Hello I have a question about opkg package signatures. I have enabled opkg package signature, and asc files are generated. When i try to run opkg update though, it fails because i do not have a package.sig file. How do i generate a package.sig file? Aug 09 21:21:31 is there a recipe for yocto with systemd? Aug 09 21:22:16 stefandxm:its a distro option Aug 09 21:22:34 oh ok Aug 09 21:22:41 iam really new to yocto Aug 09 21:22:56 ie, i dont know a shit Aug 09 21:23:15 but its possible? Aug 09 21:23:18 stefandxm:https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-systemd-exclusively Aug 09 21:23:33 cool Aug 09 21:23:38 ill read up thank you :) Aug 09 21:24:45 ive been kicked in to yocto Aug 09 21:24:50 i didnt really want to Aug 09 21:25:05 tbh i want some 'standard' arm distro based solution Aug 09 21:25:08 if you are new then start with getting started kind of docs https://www.yoctoproject.org/docs/ Aug 09 21:25:15 i did Aug 09 21:25:17 but i got lost Aug 09 21:25:31 is it ok if i ask you why i should use yocto isntead of debian arm? Aug 09 21:25:50 may be start with Yocto Project Quick Build Aug 09 21:26:36 yeah ill play with both. iam just a bit at lost why i am doing yocto in the first place Aug 09 21:27:16 basically using a device with a yocto "sdk" ? Aug 09 21:27:31 and i dont really want it. i just want to crosscompile to it and run a systemd environment or similar Aug 09 21:28:45 its a cross build environment so that will help I guess with your cross-compile needs Aug 09 21:28:55 yeah i figured that much Aug 09 21:29:13 and i managed to cross compile and put the binaries and run them on the host itself Aug 09 21:29:24 so i have a rough idea whats happening after yocto Aug 09 21:29:39 just not sure why i need yocto instead of a standard linux distro for arm basically Aug 09 21:30:09 yocto eases maintenance of your own distro, makes it easier to customize how things are built, use non-standard libcs, things not supported by debian, integrate your own software projects, build custom filesystem images, etc Aug 09 21:30:18 at the cost of a steeper learning curve Aug 09 21:30:21 really depends on your needs Aug 09 21:30:39 i think you nailed it :) Aug 09 21:31:09 kergoth: not non-standard but alternate :) Aug 09 21:31:15 we are targetting a bit higher level i think yocto should not be needed for our stuff but ill look into it anyhow :) Aug 09 21:31:46 just so you understand: iam not against yocto at all. just was hoping for a higher level of this boards distro Aug 09 21:31:48 stefandxm:if you are doing apps, then Yocto SDKs will help Aug 09 21:31:49 khem: indeed, well put Aug 09 21:32:21 the sdk seem to have the bit and pieces Aug 09 21:32:47 i just need to learn how to pull out the libs and build it all without the eclipse crap that my board supplier want me to use Aug 09 21:32:50 stefandxm: of course. not every project works for every set of requirements. there are a lot of tools available, some are better for some things and worse for others. there are things that just aren't possible with a desktop distro, but simple stuff can be done with either Aug 09 21:33:08 stefandxm: you can get anything you want into SDK as kergoth said its customizable Aug 09 21:33:15 yeah Aug 09 21:33:23 my problem is i come from the "other side" Aug 09 21:33:29 trying to use a boards yocto stuff Aug 09 21:33:34 ie mangoh red stuff Aug 09 21:33:43 stefandxm:I know its easier to do native development Aug 09 21:33:46 theyve built this legato stuff on top Aug 09 21:33:51 yeah Aug 09 21:33:54 i just want pure c++ Aug 09 21:34:43 but iam happy to learn Aug 09 21:34:58 that attitude will take you long way Aug 09 21:35:00 khem: semi-OT, but https://www.ecliptik.com/Cross-Building-and-Running-Multi-Arch-Docker-Images/ is pretty interesting. with an image builder to convert a docker image to a wic image or something, you could construct semi-customized embedded disk images using a dockerfile instead of an image recipe, based on any number of container distros. i didn't realize you could do that with qemu+multiarch Aug 09 21:35:06 but for me yocto seems a bit too proprietary niched for what i want but.. ill try :) Aug 09 21:35:36 i got this mangoh red card and it has a base set of yocto etc. ill have to abuse it to see if it works :) Aug 09 21:35:49 its worth a go Aug 09 21:36:04 so is yocto primarly focusing a bit lower/niched hardware that cannot run say debian? Aug 09 21:36:54 stefandxm: you can build images for anything infact, it does not limit itself to any hardwaree Aug 09 21:37:05 yeah i read about that Aug 09 21:37:15 its really cool Aug 09 21:37:16 not really. it's more about the level of customization, the ability to cross-build, and the ability to rebuild everything from source, which usually isn't an option with a desktop distro unless you're running gentoo :) Aug 09 21:37:22 kergoth:interesting I will read more on it Aug 09 21:37:35 just trying to sort the yocto vs build an arm board suitable for debian Aug 09 21:38:11 stefandxm: you can use something like rpi4 for native arm development Aug 09 21:38:27 unless buildtimes start eating into your days Aug 09 21:38:31 as i said iam targetting a rather big board anyhow so i was thinking more along the raspery design Aug 09 21:38:55 well i can patch specific software/libs anyhow Aug 09 21:39:48 but ill dig it through Aug 09 21:40:01 but iam very glad for the comments. it makes it easier to understand the docs :) Aug 09 21:40:11 this is not really my domain =) Aug 09 21:40:19 iam more of a server-side c++ guy Aug 09 21:40:40 kergoth:qemu usermode is quite interesting Aug 09 21:41:16 stefandxm: yeah I think with yocto you will become a full stack guy Aug 09 21:41:22 and also devops Aug 09 21:41:26 lol i dont need more stacks ;) Aug 09 21:42:21 but i figured i could help port some c++ code of mine to a yocto -using device :) Aug 09 21:42:34 with yocto you can build a lean and mean image for your platform, then you can generate an image SDK which you can use to build apps Aug 09 21:42:53 you will get power of x86 build systems to do the builds Aug 09 21:43:02 i'd rather compile the "apps" myself as usually with a cross compiler Aug 09 21:43:14 yeah, ive done this all the time in the past Aug 09 21:43:17 ehrm "past" Aug 09 21:43:20 yeah sure, thats where the SDK is going to help you Aug 09 21:43:36 yeah it gives me an abi-compatible compiler right? Aug 09 21:43:52 since the SDK will represent the dev and tuntime env of your target in cross env Aug 09 21:43:59 correct Aug 09 21:44:20 and any dependencies your app has on other opensource you can add to SDK Aug 09 21:44:31 so your app is not bundling stuff Aug 09 21:44:45 well it might anyhow but we will see :) Aug 09 21:45:54 i dont like the idea of "apps" Aug 09 21:45:57 iam a unix guy hehe Aug 09 21:46:06 but it should all be the same Aug 09 21:58:34 kergoth: its all using qemu-user-static thats what I thought see https://wiki.debian.org/QemuUserEmulation Aug 09 21:58:51 * kergoth nods Aug 09 21:59:11 my problem is someone has to be able to build those docker images Aug 09 21:59:29 its not a solution when you ship products that you want to support and maintain for years Aug 09 21:59:34 aye, there's always the issue of bootstrapping Aug 09 21:59:58 but for development its not a bad thing at all Aug 09 22:01:00 so maybe we need a combinations of both approaches ie. OE which maybe used used build docker images and a dev env which could then use these docker images Aug 09 22:01:04 i was mulling over the idea of using dockerfiles to customize yocto images (after building the baselines with the current mechanisms) and then burn them with wic after yanking out the needed bootloader bits from it, as a development tool. folks are already familiar with dockerfile in container environments. Aug 09 22:01:17 yeah. not sure how much value it'd add, just a way to leverage existing expertise in some fashion Aug 09 22:01:41 but it's *fast* since it has the image layering and caching of the binary artifacts Aug 09 22:01:59 most of devs do native development Aug 09 22:02:35 so it will help them to write stuff for embedded systems easily Aug 09 22:02:46 very true. scratchbox leveraged binfmt like this iirc. it'd be interesting to improve our native development story before the dev moves onto recipe creation and deployment for the longer term Aug 09 22:04:01 yeah recipe creation then should be like writing a spec file or debian rules file Aug 09 22:06:07 kergoth:creating dockerfiles for such devenv seems interesting, but wont you need apt-get blah :) Aug 09 22:06:19 gto customize the images Aug 09 22:08:13 true. and it'd be binary based, so you'd ideally have a feed like angstrom for that workflow Aug 09 22:16:29 yeah I think we are at a disadvanrage to not have a strong binary feed based distro except angstrom **** ENDING LOGGING AT Sat Aug 10 03:00:09 2019