**** BEGIN LOGGING AT Thu Apr 28 02:59:58 2016 Apr 28 07:32:20 hi guys Apr 28 07:32:30 where do I send patches for pseudo? Apr 28 07:33:02 with github not being used any longer and no separate mailing list (it seems) it's not clear how to contribute Apr 28 07:48:20 andrewsh: found a pseudo bug? Apr 28 07:48:57 send patches against http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/ to yocto@ with [pseudo] in the title? possibly file in BZ too (not sure which seebs pays more attention to) Apr 28 07:55:40 how does the 'virtual' category(?) in a package's name affect things? Apr 28 08:06:07 Hi everyone Apr 28 08:06:35 does anyone knows if it is possible to get pyqt5 ? Apr 28 08:06:43 thanks for any help Apr 28 08:13:14 hello. I don't quite fully understand what the Yocto Project is. Would it be possible to build a system using this tool for a personal x86_64 system and maintain it yourself? Apr 28 08:26:22 Is it possible to retrieve the sysroot of another package .... D-pn-SOMEPACKAGE ? Apr 28 09:09:20 Hello Apr 28 09:55:20 Hello, I have a general embedded linux question, is it okay to ask here? Apr 28 09:56:43 fire away Apr 28 09:58:30 say I want to develop a product and use Linux as the OS, what are my options? build my own (yocto) or are there other alternatives? Apr 28 09:59:40 that is a pretty loaded question actually and you may not realize it. Apr 28 10:01:04 sure Apr 28 10:01:55 yocto / buildroot / take fedora/debian/yourfavouritedistro and adapt it / more Apr 28 10:02:03 all have pros and cons Apr 28 10:02:17 sane people use yocto or buildroot Apr 28 10:02:29 oh android, of course Apr 28 10:03:26 option die hard: do everything by hand, from scratch. :-) Apr 28 10:03:59 yeah, cross-lfs Apr 28 10:04:04 if you're truly insane Apr 28 10:04:37 Or use a CPU module with a pre-installed Linux in your device, there are lot of manufaturers Apr 28 10:05:09 rburton: nah thats the lame option, bcs then you're relying on existing documentation. Apr 28 10:05:23 really die hard means - no docs, no nothing, its all in your brains. Apr 28 10:07:21 now, did we unlaoad that question or actually load it further? ;-) Apr 28 10:12:30 hello, could someone help me with some trouble regarding building? Apr 28 10:12:42 folks, how can I list what is installed in the rootfs as part of package, package-dev, package-dbg ???? Apr 28 10:13:18 mortderire: should all be in the manifests that are created along the images, check you build output directories Apr 28 10:13:26 I have a straigh from git yocto, currently on Krogoth (but same trouble on Jetrho) and sed's ptest fails Apr 28 10:13:32 ok thanks Apr 28 10:14:21 checked encoding, is UTF-8 so that should not be an issue Apr 28 10:14:35 where can I find the manifests? Apr 28 10:17:29 mortderire: should be right next to your image file. build/tmp/deploy/images/$MACHINE/$WHATEVER Apr 28 10:18:15 JaMa, I followed your advice for writing a correct bug report. The patch now is much smoother. I did the least modification as possible to get pkgconfg and mkspecs working. I just sawped the order. pkgconfig comes last. Apr 28 10:18:35 JaMa, tell me if I missed something else. Apr 28 10:20:18 LetoThe2nd: This is listing the pacakges, I want the contents of each packages Apr 28 10:21:28 present: it looks good, I'll try to apply it in meta-qt5 after test-round of 5.7 upgrade Apr 28 10:22:06 mortderire: ah ok.. well you can have the contents of a package output through a package manager tool like dpkg -c, but at the moment i don't know if theres a full manifest that contains a definition of each and every package->file in the image Apr 28 10:22:34 ok thankts that is a good idea Apr 28 10:23:26 anyone? any kind of pointer at least? I'm totally lost at the moment Apr 28 10:23:59 jaskij: nothing besides the standard pointers.... leave out as much as possible, cut down, bisect, etc. Apr 28 10:24:38 LetoThe2nd: damnit :/ point is I did nothing to it! just cloned yocto, so most likely some general misconfiguration :/ Apr 28 10:25:27 jaskij: to be precise, i guess you cloned poky, not yocto ;-) Apr 28 10:26:05 LetoThe2nd: true that, all done according to Yocto quick start Apr 28 10:26:14 jaskij: and as poky itself does not build anything, i suspect that you at least did some minimal configuration. based on what? what system are you building on? Apr 28 10:26:16 mortderire: oe-pkgutil-tools Apr 28 10:26:30 erm, oe-pkgdata-util even Apr 28 10:26:32 rburton: thanks Apr 28 10:26:58 ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh ................ Apr 28 10:26:58 LetoThe2nd: OE, Yocto on Linux Manjaro inside python virtualenv Apr 28 10:27:21 mortderire: oe oe-pkgdata-util list-pkg-files —recipe m4 Apr 28 10:27:21 I mean I run BB inside virtualenv Apr 28 10:27:35 mortderire: that first oe was meant to be "ie" :/ Apr 28 10:27:39 jaskij: örks Apr 28 10:27:58 jaskij: that just screams for trouble in my ears. Apr 28 10:28:04 LetoThe2nd ? why? Apr 28 10:28:11 virtualenv should work fine Apr 28 10:28:23 jaskij: niche, rolling release distribution.... Apr 28 10:28:30 jaskij: if you paste the error we might be able to help more Apr 28 10:28:51 rburton: yes Apr 28 10:28:53 rburton: doesn't work for -dev or -dbg Apr 28 10:29:03 mortderire: note the *recipe* bit Apr 28 10:29:10 sed-4.2.2-r0 do_package: QA Issue: split_and_strip_files: 'file yocto/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sed/4.2.2-r0/package/usr/lib/sed/ptest/testsuite/0range.good' failed [split-strip] Apr 28 10:29:34 oh thats the bug that khem mentioned, some distros have a broken file binary Apr 28 10:29:51 so remember when poky told you "this distro is unsupported"? Apr 28 10:29:58 got it Apr 28 10:30:01 *BINGO Apr 28 10:30:15 i suspect if you run that file command, it crashes Apr 28 10:30:28 is there any sort of bug report for this? Apr 28 10:30:40 you'll have to check the manjaro bug system Apr 28 10:30:56 ok, great thx Apr 28 10:30:59 verify my diagnosis by running that file command on its own Apr 28 10:31:40 file 0range.good 0range.good: ERROR: Offset out of range Apr 28 10:32:39 rburton: apologies, you are right Apr 28 10:33:00 jaskij: there we go. see if your distro has an updated file package Apr 28 10:33:15 already ran full system update :/ Apr 28 10:33:27 roll back to the previous release of file? Apr 28 10:33:44 (and file a bug with manjaro) Apr 28 10:33:53 * rburton must be out of touch, never heard of that one Apr 28 10:33:54 rburton: there really doesn't seem to be a way to debug on target with yocto ... install a package source and run gdb Apr 28 10:34:08 rburton: out-of-the-box Arch based Apr 28 10:34:42 mortderire: install -dbg packages on target and gdb works fine (they contain debug symbols and relevant source) Apr 28 10:34:53 mortderire: or do remote gdb and you don't need to install on the target Apr 28 10:35:38 rburton: http://pastebin.com/xenGgN2d Apr 28 10:36:11 rburton: _nothing_ in the dbg package? Apr 28 10:36:13 mortderire: try the same for something like m4 Apr 28 10:36:26 (as i have that build here and its in oe-core) Apr 28 10:36:48 rburton: ERROR: Unable to find packaged recipe with name m4 Apr 28 10:36:52 rburton: busybox Apr 28 10:36:58 yeah whatever, anything in core Apr 28 10:37:26 mortderire: http://pastebin.com/TmN7iSTx <— mine Apr 28 10:37:29 rburton: http://pastebin.com/PQ99Z9JD Apr 28 10:37:42 you sir, have a distro that is disabling debug packaging Apr 28 10:37:47 rburton: is it because I am using core-image-mimal Apr 28 10:37:48 ? Apr 28 10:38:02 no, image is entirely unrelated Apr 28 10:38:03 ah f**k f**k ... Apr 28 10:38:06 what distro? Apr 28 10:38:09 ok let me check Apr 28 10:38:25 rburton, LetoThe2nd: rolling back file helped, graet thanks! Apr 28 10:40:30 # "${@d.getVar('DISTRO', True) or ''}" Apr 28 10:40:30 DISTROOVERRIDES="nodistro" Apr 28 10:41:19 rburton: http://pastebin.com/2BtyHkxw Apr 28 10:41:38 really no distro? no bsp doing funky things? Apr 28 10:42:29 rburton: ok I think I know why ... Apr 28 10:43:03 rburton: I didn't clone poky to start out ... I clone openembedded and openembedded-core Apr 28 10:43:14 actually, openembedded? that's about a decade old. Apr 28 10:43:22 poky is just bitbake + oe-core. Apr 28 10:43:39 rburton: nope sorry openembedded-core, meta-openembedded and bitbake Apr 28 10:43:49 as long as they all match branches, you're fine with that Apr 28 10:44:00 rburton: yeah I made sure they did Apr 28 10:44:14 rburton: thats what I thought ... but there is no distro setting in my local.conf Apr 28 10:44:19 ls Apr 28 10:45:44 rburton: grep -i distro openembedded-core/*/conf/local.conf.sample .... isn't set in the local.conf.sample that come with meta. Apr 28 10:46:23 rburton: [11:46 ][silv-debian7-yocto-build 65] yocto > grep -i distro poky/*/conf/local.conf.sample Apr 28 10:46:24 DISTRO ?= "poky" Apr 28 10:46:24 # DISTRO ?= "poky-bleeding" Apr 28 10:46:43 but when I do the same thing with "poky" my distro is set. Apr 28 10:46:52 ls Apr 28 10:47:30 mortderire: bitbake m4 and then pastebin the contents of the do_package log Apr 28 10:47:46 (m4 is my favourite test recipe as it's so small) Apr 28 10:48:49 rburton: do_package_log ... don't understand ... do a bitbake -e m4 and copy and the contents of do_package Apr 28 10:50:32 no, bitbake m4, then pastebin tmp/work/(machine)/m4/(version)/temp/log.do_package Apr 28 10:50:49 we really need a built in way to get those logs. i use the bb tool but thats not included by default. Apr 28 10:52:58 rburton: got you know .. .slow today sorry Apr 28 10:55:27 rburton: http://pastebin.com/dUfPQdLH Apr 28 10:55:39 rburton: do_populate_sysroot Apr 28 10:55:59 rburton: there is no do_populate Apr 28 10:56:19 *package* Apr 28 10:56:39 rburton: sorry Apr 28 10:57:53 rburton: http://pastebin.com/RBz8x8gQ Apr 28 11:00:19 mortderire: bitbake -e m4 |grep INHIBIT_PACKAGE_STRIP? Apr 28 11:00:42 I have INHIBIT_PACKAGE_STRIP set Apr 28 11:00:50 or INHIBIT_PACKAGE_DEBUG_SPLIT? Apr 28 11:00:51 I don't want to strip symbols Apr 28 11:01:07 well thats why you don't have any debug stuff, because you turned it off. Apr 28 11:01:16 rburton: Or have I misunderstood what it does Apr 28 11:01:57 rburton: [11:53 ][silv-debian7-yocto-build 99] yocto_build > grep INHIBIT conf/local.conf Apr 28 11:01:57 INHIBIT_PACKAGE_STRIP = "1" Apr 28 11:02:18 rburton: set it zero? Apr 28 11:02:26 out of the box the behaviour is that the normal package contains stripped binaries, and the -dbg package contains the debug data and relevant source files. so if you want to do debugging, you install foo and foo-dbg Apr 28 11:02:34 just delete that line,and rebuild m4 Apr 28 11:03:32 ah .............. Apr 28 11:03:45 rburton: doesn't say that on the tin .... :-) Apr 28 11:04:50 i guess we need to expand the docs a bit Apr 28 11:04:59 does that give you back sources and debug objects? Apr 28 11:05:12 rburton: building now, will let you know. Apr 28 11:06:43 rburton: debug on target is not documented anywhere I can see. ... its all remote debugging Apr 28 11:06:51 rburton: which is overkill most of the time Apr 28 11:07:35 mortderire: debug on target just works if you install dbg packages and gdb, exactly like 99% of linux distros Apr 28 11:08:03 rburton: sure, but it isn't called out - or at least not that I can find Apr 28 11:08:44 agreed and noted Apr 28 11:22:49 rburton: http://pastebin.com/VUBfgu2G Apr 28 11:22:56 rburton: mystery solved Apr 28 11:27:49 what exactly is stored in /var/lib/opkg/status? both 'opkg list' and 'opkg list-installed' seem to only look at this file (from looking at 'strace -e open'). Apr 28 11:29:50 an overview of /var/lib/opkg/info and /var/lib/opkg/lists would be nice too :) Apr 28 11:58:33 I'm trying to build an overlayed kernel, using the .bbappend approach. Apr 28 11:59:14 problem is that the do_shared_workdir-task seems to be triggered before the kernel is built. Thus leading to a failure, because of the missing System.map Apr 28 12:02:49 Hi Apr 28 12:04:01 A little question, if I want to create a yocto image for a RPi3 based on meta-raspberrypi (master branch), which yocto branch should I clone ? Jethro ? or Krogoth ? Apr 28 12:32:44 I would go with jethro, as meta-raspberrypi has it Apr 28 12:35:43 omg, could someone take a look at this: http://paste.debian.net/443787 ? I'm trying to clone kernel from kernel.org with a specific commit, but no matter what i do: when the kernel finally is cloned (takes like 20 minutes at least on my connection!) it says that commit is not available. i've tried to do it manually, and it works as expected. must be something i've missed...? Apr 28 12:35:54 ok, thanks maciejjo Apr 28 12:40:38 and when bitbake is finished, it seems to have removed the git so i cannot investigate it further Apr 28 12:42:42 first SRC_URI + first SRCREV works though.. Apr 28 12:56:36 ionte: my first move would be to clone the same url manually and check that the commit actually exists Apr 28 12:56:54 (commits can disapear if the maintainer rebases his branch Apr 28 13:03:08 boucman_work yes, i've done that already Apr 28 13:03:31 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8c9aef03d3b540b6885e7534a885ea25f62dd9ed Apr 28 13:06:48 could it be because that commit is not in master branch? (linux-4.4.y) if so, how do specify both commit revision *and* branch? Apr 28 13:06:54 hmm, perhaps nobranch=1 ..? Apr 28 13:08:10 i'm also conf used about src_uri vs srcrev: seems the revision could be specified using either... Apr 28 13:17:12 one more: is there any way to make a shallow git clone, using --depth? can't see anything such in git.py ... Apr 28 13:25:34 ionte: only if you patch it in Apr 28 13:58:25 if an yocto image on a RPi3 is not booting up (I just see a black screen with 4 raspberries on top left corner), is there any way to diagnose what is going on ? Apr 28 13:58:37 I struggle to understand FULL_OPTIMIZATION and DEBUG_OPTIMIZATION. Why do both contain the "-g" flag by default? Apr 28 14:03:09 OE builds debug packages, then strips binaries Apr 28 14:10:54 Crofton|work: ah, ok. So how can I change the CFLAGS in my toolchain env script to not contain the -g? Apr 28 14:14:52 I got a device with arm v7 without internet. I'm trying to run scrot (to take a screenshot), but I get that it fails. I haven't installed it properly, I have just downloaded the binaries I need, then added a bin-folder with scrot to PATH, and added a lib-folder to LD_LIBRARY_PATH Apr 28 14:16:30 I think it might not be able to create the PNG format. I tried running mami as well, with similar result, only there it said it was unable to load the format. Could be I'm having problems with imlib2 or something, only there are no errors Apr 28 14:24:12 frsc, why do not need to do that? OE will strip the binaries for you Apr 28 14:26:59 Just tried using fbgrab instead, I don't think that use imlib2, and it works Apr 28 14:27:20 Crofton|work: I deploy a sdk for cross development and that contains the env setup script with -g in CFLAGS. Using these settings I always have -g, even if I set my IDE to release build. Apr 28 14:28:34 so the problem is default sdk flags? Apr 28 14:29:19 Crofton|work: Yes, I want to avoid needing to strip the binaries build with the sdk. Apr 28 14:30:55 I do not know the answer there Apr 28 14:32:43 Crofton|work: I'm currently trying to bbappend the meta-environment recipe and set TARGET_CFLAGS without -g there. I hope that does the trick... Apr 28 15:01:49 frsc: that's what i'd suggest. you can atually use en environment-setup.d script to do it in a separate package, rather than hacking the recipe Apr 28 15:02:28 frsc: if you want an example, i have a recipe in meta-sourcery which does that sort of thing, though it appends rather than removes. https://github.com/MentorEmbedded/meta-sourcery/tree/master/recipes-sdk/sdk-env-external-toolchain Apr 28 15:03:28 kergoth: ok, thanks! Apr 28 15:04:28 https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L51-L52 being the bits to add that package to the sdk, of course Apr 28 15:23:19 andrewsh: Bugzilla works, also you can just ping me directly. Apr 28 16:09:12 RP: I'm wondering if we shouldn't change the internal toolchain to drop the default GNU_HASH bits. It'd make a failure to obey LDFLAGS much more visible, much like the sysroot poisoning does for obeying the --sysroot= / TARGET_CC_ARCH / CC. Of course, we spot the failure to obey it in our builds since we're using external toolchains that aren't built the same way as the internal one, so we spot them, at least. Apr 28 16:10:38 kergoth: I'd be ok with that Apr 28 16:11:28 k, will add to the todo Apr 28 16:20:09 kergoth, I think it's worth an experiment at least Apr 28 16:20:54 my only concern is the generated SDK.. we've got lots of people that for whatever reason are -convinced- they know better then the 'environment' files, and call the compiler and linker themslves.. :P Apr 28 16:21:24 they were wrong, and they'll still be wrong :) Apr 28 16:21:50 yes.. but the point is, pissing off users needs an explanation on "why".. and with the right "ok fine, then add this" Apr 28 16:21:55 thus my concern Apr 28 16:22:05 with the inevitable "but it used to work" Apr 28 16:22:26 (I am soooo intirely sick of the 'but it used to work' line, when whatever they were doing is obviously wrong) Apr 28 16:24:02 it used to work when my son cycles through a muddly puddle with his legs high up in the air, until the day he hits a big stone in the puddle Apr 28 16:27:42 hello. i have a stupid problem here, DISTRO_FEATURES_remove in local.conf does nothing. DISTRO_FEATURES += for a different feature in the same file works. Apr 28 16:27:45 any ideas? Apr 28 16:27:59 Hi, what is the correct way to conditionally add a dependency in a bitbake file ? Apr 28 16:28:17 maelcum: possibly you're on an old yocto release that didn't yet support _remove Apr 28 16:28:33 gtristan: inline python or packageconfig, depending on the condition / situation Apr 28 16:28:39 i'm trying to improve a customer's botched yocto setup from patching stuff in upstream repos to at least doing it through local.conf... Apr 28 16:29:27 kergoth: BB_VERSION = "1.16.0", DISTRO_VERSION = "1.3.1" Apr 28 16:32:34 kergoth, in my case I just want to avoid valgrind going into RDEPENDS_${PN} on non x86 platforms, as in this recipe: https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/tree/meta-freedesktop/recipes-core/tasks/task-freedesktop-contents-sdk.bb Apr 28 16:33:17 * gtristan is trying to navigate the bitbake docs looking for how packageconfig works Apr 28 16:33:51 http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-PACKAGECONFIG Apr 28 16:34:51 ah thanks joshuagl Apr 28 16:35:08 hello, I am working on a 64 bit machine (everything compiles) but the u-boot starts in 32 bit. Is there a simple way to use the different toolchain for this recipe ? Apr 28 16:39:21 so if I understand correctly, the behavior of PACKAGECONFIG blocks are only controlled via overriding in .bbappend layers or a configuration file Apr 28 16:45:58 minipada:Can 32bit bootloader switch kernel to 64bit ? Apr 28 16:47:08 yeah, it is working fine. I found the meta-tc-icc, going to configure and try Apr 28 16:49:46 yep, my bitbake is too old. _remove needs 1.5.1 Apr 28 17:14:38 *1.5 of course Apr 28 17:22:36 Is this the correct expression for an arch conditional dependency: DEPENDS = "${@base_conditional('TARGET_ARCH', 'x86_64', 'nasm-native', '', d)}" ? Apr 28 17:23:02 well, is this "a" correct expression (obviously there is more than one correct way) Apr 28 17:23:24 overrides work nicely for this Apr 28 17:23:31 DEPENDS_append_archoverride Apr 28 17:27:41 rburton, I see some examples of that, for instance: DISTRO_EXTRA_RDEPENDS_append_qemuarm = ... so basically I can put DEPENDS_append_x86_64 = "nasm-native" and it will depend on that for any build targeting a machine with x86_64 ? Apr 28 17:27:54 any arch name basically ? Apr 28 17:31:17 gtristan: i think x86-64 will work, but i always need to double check the machine overrides. Apr 28 17:31:22 gtristan: give it a go ;) Apr 28 17:31:31 (bitbake -e |grep OVERRIDES= is useful) Apr 28 17:31:39 gtristan: also you forgot the leading space Apr 28 17:31:49 " nasm-native" Apr 28 17:35:54 rburton, oh nice... setting MACHINE=aarch64 bitbake -e | grep OVERRIDES= ... tells me interesting things :) Apr 28 18:13:08 So I want to build for a more specific CPU, there are a few basic machine.conf files provided in poky, and a wealth of cpu compiler tuning configuration files Apr 28 18:14:24 And I'm trying to add a machine.conf to my layer, and just "require conf/machine/include/tune-cortexa9.inc" Apr 28 18:15:12 it seems that yocto finds the machine.conf correctly, but fails to include the tune-cortexa9.inc file... so first I wonder: Is this the right thing to do ? Apr 28 18:15:25 i.e. add a machine.conf to your own layer ? Apr 28 18:15:46 and if so... how do you resolve the include path ? Apr 28 18:15:54 what do you mean by 'fails to include'? what exactly is the behavior? Apr 28 18:16:02 relative include paths work fine, they're found by searching BBPATH Apr 28 18:17:14 Specific error is: ParseError at /home/builder/BUILD/freedesktop-sdk-base//meta-freedesktop/conf/machine/qemuarmv7.conf:6: Could not include required file conf/machine/include/tune-cortexta9.inc Apr 28 18:17:27 typo: cortext Apr 28 18:17:50 oops Apr 28 18:18:46 oh nice, only that typo seems to be the mistake Apr 28 18:48:05 hmmm, DEPENDS_append_x86 = " nasm-native" does not cause nasm-native to be built when OVERRIDES="linux:i586:build-linux:pn-defaultpkgname:x86:qemuall:qemux86:poky:class-target:forcevariable:libc-glibc" Apr 28 18:50:12 ooops Apr 28 18:50:21 * gtristan palmface... alright carry on... Apr 28 18:55:31 ok, DEPENDS_append_x86-64 = " nasm-native" seems to work Apr 28 19:45:21 at what point will STAGING_BINDIR be assigned a value? Apr 28 19:46:08 what do you mean? Apr 28 19:46:19 it's defined in bitbake.conf, which is the first config file to be parsed after the layers are set up Apr 28 19:46:35 early early in the parsing, long before recipes are parsed or tasks run or anything else Apr 28 19:46:37 it's always set Apr 28 19:47:24 that's what I was thinking but I've been referencing it in a recipe and it's empty Apr 28 19:50:54 use bitbake -e, it shows full variable modification history Apr 28 19:51:01 you can see exactly what set it to empty andwhere Apr 28 19:52:42 cool thanks Apr 28 19:59:15 specifically bitbake -e in this case, of course. just bitbake -e will show configuration metadata, is which global Apr 28 22:14:05 So when building my stack for armv7 I get these errors when staging the rpms into an image, basically all my packages "is intended for a different operating system" Apr 28 22:14:23 Does this mean anything to anyone here ? Apr 28 22:15:49 it seems to me that the stage which creates the image from rpms... somewhere in python do_rootfs... it cant cope with target != host ? Apr 28 22:47:31 fwiw, this is the log for failing to create the rootfs from rpms which are "intended for a different operating system" : https://paste.fedoraproject.org/360875/61883588/raw/ Apr 28 22:50:34 it looks like rootfs_rpm.bbclass is running stuff from the host aarch64 sysroot to manipulate packages for the qemuarmv7 sysroot... which sounds like the right thing to do, but only that rpm is whining about it Apr 28 22:51:23 maybe rootfs_rpm.bbclass is only supposed to be used with native builds ? Apr 28 22:54:26 ahh, I think I get what's going on Apr 28 22:55:07 I called my target qemuarmv7, and the rpms were probably built with a different target string Apr 28 22:58:24 right... I have a ton of rpms with armv7a_vfp_neon... Apr 28 22:59:05 and some named qemuarmv7 Apr 28 23:00:28 * gtristan suspects he got something wrong while adding the new qemuarmv7.conf machine... missed some crucial detail... maybe the name of the machine is not entirely arbitrary after all Apr 28 23:25:07 I find this odd... http://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-newmachine says that one should set TARGET_ARCH in a machine definition in meta/conf/machine/ Apr 28 23:25:30 but grep -r shows that no machine conf files do that... just very outdated documentation ? Apr 28 23:29:37 you're reading docs from 1.4, current is 2.1. Apr 28 23:29:51 check the current docs if you're using current yocto Apr 28 23:32:55 kergoth, yeah... now I'm reading the README files in the meta/conf subdirs... Apr 28 23:34:50 heh, the new docs say "If you want to add support for a new machine to the Yocto Project, look in this directory." **** ENDING LOGGING AT Fri Apr 29 02:59:58 2016