**** BEGIN LOGGING AT Mon Nov 07 03:00:00 2016 Nov 07 08:09:46 Hi eveyrone Nov 07 08:09:58 How do I make Yocto build a hddimg file with my build? Nov 07 08:17:48 cart_man: not completely figured it out how we managed but if you have a look in ./poky/meta/classes/image.bbclass seems like you need to remove all the live image stuff Nov 07 08:18:44 cart_man: basically we do in our image IMAGE_FSTYPES_append = " ext4 " and IMAGE_FSTYPES_remove = " ext3 jffs2 btrfs squasfs ubi ubifs ext2 cramfs live" not sure if this is already the trick Nov 07 08:19:53 cart_man: we also have PACKAGE_INSTALL_remove = "initramfs-live-boot initramfs-live-install initramfs-live-install-efi busybox udev base-passwd" but be aware that we have a really stripped down one Nov 07 08:19:58 will there be a krogoth 2.1.2 release? Nov 07 08:26:38 cart_man: oh not sure if this is what you needed ... like this you get a file *.hdddirect ... anyway if you have some advanced partition topics you anyway maybe should have a look at http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#creating-partitioned-images and the wic tool Nov 07 09:44:03 mdnneo :thanks allot for the help. If I am not mistaken there is some sort of flag you put up in the local.conf file that creates a SDCARD image that you write onto a SD Card using DD Nov 07 09:44:09 I can not seem to get that to work again Nov 07 10:02:15 cart_man: nope, not directly. some bsps bring along the infrastructure for "sdcard" as a IMAGE_FSTYPES selection, but its not generally available Nov 07 10:02:40 namely, meta-fsl-arm has it for a lot of machines. Nov 07 10:04:14 LetoThe2nd : Well that is quite rough Nov 07 10:04:34 Do you know of a simple example on how to build one with the gazillion files I am left with? Nov 07 10:04:56 cart_man: depends(TM) on your target Nov 07 10:04:57 s Nov 07 10:05:18 one beaglebone and other imx6 NXP Sabre Nov 07 10:05:42 for the imx, the sdcard infrastructure from said layer should be fine Nov 07 10:06:54 for the bbb, documentation is here: https://www.yoctoproject.org/downloads/bsps/morty22/beaglebone Nov 07 10:11:25 hi everyone Nov 07 10:12:45 I'm facing some issues when I modify a package which is using "useradd", bitbake always fail to delete user or group, does anyone faces the same issue? Nov 07 10:13:51 aurele: why do you manually invoke useradd and not use the infrastructure already in place? Nov 07 10:18:27 LetoThe2nd, I'm talking about the default behaviour for pulseaudio for example, i'm using the "infrastructure already in place" ;), but everytime I modify something in pulseaudio, "the infrastructure already in place" fail to delete user or group... Nov 07 10:18:54 and build fails because of it... Nov 07 10:19:53 aurele: sorry, i can't follow completely. so you meant the pulseaudio build fails because it already treis to execute some scripts that use useradd? Nov 07 10:23:12 LetoThe2nd, the build fails with this error : http://paste.ubuntu.com/23441105/ because the receipe inherit from useradd and is using useradd facilities : http://paste.ubuntu.com/23441108/ Nov 07 10:24:24 aurele: does the extended log give any hints why the call fails? Nov 07 10:26:35 http://paste.ubuntu.com/23441124/ Nov 07 10:26:43 LetoThe2nd, Nov 07 10:27:52 aurele: is the message correct? e.g., is the ntp user really part of the group? i would guess a numeric overlap. Nov 07 11:01:59 Is there a criteria allowing various fixes to be applied to morty? Nov 07 11:04:31 fixes are good, they should go to master first with a backport request made Nov 07 11:04:41 iirc there's a wiki page which hints at the policy Nov 07 11:04:56 Backport makes sense. Thanks :) Nov 07 12:12:14 ZubairLK: unless a patch only applies to morty - ie is a cve that was fixed in an upgrade to master, then patches should start in master and flow back through the releases in order Nov 07 12:35:16 thanks Nov 07 12:46:37 Good day, Why does FILESEXTRAPATHS_prepend := "${THISDIR}/init-ifupdown-1.0/qemux86:", Result in FILESPATH="~/init-ifupdown/init-ifupdown-1.0/qemux86/poky: ... Instead of FILESPATH="~/init-ifupdown/init-ifupdown-1.0/qemux86: ... Nov 07 12:46:52 Notice the poky tacked onto the end Nov 07 12:48:52 Strike5150: FILESOVERRIDE Nov 07 12:49:13 nrossi: Ok, so I saw mention of this but I didn't understand how to use it Nov 07 12:49:35 The reason i'm asking is because my file is not being selected to overlay the base init-ifupdown interfaces file Nov 07 12:50:21 I've got everything in the right place and I can see in the env dump that everything is ok except for the fact that the base package is being used instead of mine. Nov 07 12:50:45 Strike5150: FILESPATH should expand to ::... Nov 07 12:51:16 which means if their is version of the files in a FILESOVERRIDE directory that will be picked over yours Nov 07 12:51:55 nrossi: Yes that is whats happening, can/should I modify FILESOVERIDES per recipe? Nov 07 12:52:27 Strike5150: What are you trying to do out of query? override the /etc/network/interfaces for qemux86? Nov 07 12:52:42 nrossi: yes Nov 07 12:53:02 Strike5150: From your layer? Nov 07 12:53:06 nrossi: I've got the bbappend in a custom layer Nov 07 12:53:18 with the FILESEXTRAPATHS_prepend in it Nov 07 12:53:39 and the interfaces file under ~/init-ifupdown-1.0/qemux86 Nov 07 12:54:12 when you say ~/ do you mean your home dir or relative to the bbappend dir? Nov 07 12:55:15 relative bbappend Nov 07 12:56:46 Strike5150: And what is the full value of FILESPATH for this recipe? Nov 07 12:57:12 O Nov 07 12:57:31 https://gist.github.com/strike5150/294cac2c06c5ef91e63f06f0f9e40deb Nov 07 12:58:29 Its selecting /home/nautel/poky/meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemux86 before /home/nautel/poky/meta-nautel/recipes-core/init-ifupdown/init-ifupdown-1.0/qemux86/ Nov 07 12:58:39 I believe thats the issue Nov 07 13:00:36 nrossi: I've checked all the other paths before that entry they don't exist or are empty Nov 07 13:01:04 Strike5150: Oh its a simple bug, remove the "qemux86" from your prepend. FILESOVERRIDE already includes MACHINEOVERRIDE which has "qemux86" in it. So qemux86/qemux86 and core/qemux86 are before nautel/qemux86 Nov 07 13:01:40 nrossi: wow, yes good catch. Thank you :D Nov 07 13:23:26 Hey, can somebody help me with building libgfortran? Nov 07 13:27:25 I added all necessary lines in the local.conf, but it is always giving an error during buildprocess of libgfortran. I tried it the whole day but it just doesn't work. It would be really nice if somebody could provide me with some help Nov 07 13:28:22 you'll need to provide some more information about your system & the error benz Nov 07 13:29:13 I'm working on a x64 ubuntu system with a corei7 and I am building fo a x86_64 system Nov 07 13:29:57 I'm using the latest yocto from the master and the lates meta-openembedded Nov 07 13:30:38 The current gcc version is 6.2 and the libgfortran version is also 6.2 Nov 07 13:31:07 I added the following lines to the local.conf: Nov 07 13:31:25 FORTRAN_forcevariable = ",fortran" Nov 07 13:31:29 RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath" Nov 07 13:32:41 gcc-runtime is building fine, but during building of libgfortran I always get an error during the do_compile task, saying that backtrace-supported.h is missing Nov 07 13:32:57 Do you need any additional information? Nov 07 13:38:40 sounds like a race Nov 07 13:39:20 a race? Nov 07 13:39:52 it's trying to compile before a header is available Nov 07 13:41:12 actually gcc-runtime is building a header backtrace.h, but not backtrace-supported.h Nov 07 13:43:32 everything is stock in my yocto project, I just added the two lines in local.conf as the internet told me Nov 07 13:43:47 did you try to build libgfortran? Nov 07 13:49:32 benz: backtrace support is optionnal (see variable DISTRO_FEATURES_LIBC ). As far as i remember, the support is activated in poky distribution. You may also ensure it's present by adding DISTRO_FEATURES += "libc-backtrace" in your local.conf Nov 07 13:49:54 (note taht DISTRO_FEATURES_LIBC is a subset of DISTRO_FEATURES) Nov 07 13:51:33 kk, I'm trying it right now Nov 07 14:42:53 still missing the backtrace-supported.h Nov 07 14:43:53 it is looking for it in poky/build/tmp/work/corei7-64-poky-linux/libgfortran/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/ Nov 07 14:44:13 i think there is an option or package missing in gcc-runtime Nov 07 14:44:17 any clue? Nov 07 15:02:00 when i add KERNEL_DEVICETREE="overlays/ads7846.dtb" (touchscreen support), i can see the Image-ads7846-overlay.dtb in build/tmp/deploy/images/raspberrypi2/ but it isn't installed in /boot partition of my sdcard (i use dd if= Nov 07 15:02:11 if=my.img.sdcard of=sdcard Nov 07 15:02:15 any idea? Nov 07 15:02:37 if i copy by hand ads7846-overlay.dtb into /boot/ads7846-overlay.dtb my touchscreen works Nov 07 15:04:20 Hi all. This might be a stupid question but in depexp when i click through reverse dependencies untill there is no reverse dependency anymore, how can i figure out why this package is even built? (no runtime dependencies either. To be precise i'm talking about libx11-native) Nov 07 15:05:04 we're building a headless system and i've noticed xcb was being built along the way. I'm not sure but from what i see we should not need this package Nov 07 15:05:43 qemu-native, probably Nov 07 15:06:00 if you never run qemu you can change that in your local.conf Nov 07 15:06:22 (or remove sdl from its packageconfig) Nov 07 15:06:32 default is to have PACKAGECONFIG_append_pn-qemu-native = " sdl" in your local.conf Nov 07 15:06:42 just remove that and you get a headless qemu without a x11 dependency Nov 07 15:07:36 thanks, i'll give it a try Nov 07 15:07:56 i assume i can remove the PACKAGECONFIG_append_pn-nativesdk-quemu aswell Nov 07 15:08:35 qemu* idk why i always missspell that lol Nov 07 15:09:10 if you don't want a graphical qemu in your SDK, sure Nov 07 15:09:48 rburton: i wouldn't need that for a headless system or would i? Nov 07 15:10:10 I'm a bit confused. Is it about qemu having a UI or what exactly do you mean with graphical qemu? Nov 07 15:12:03 the 'sdl' packageconfig for qemu controls whether your qemu binary can show you the system that its is emulating on screen, instead of either being proper headless or only over VNC. if you only ever build for a 'real' target and never run system qemus then you can turn that off. Nov 07 15:12:57 my build machine is over gigabit and qemu over x11 over gigabit is painful, so i can turn it off as if i want to see qemu's display i tend to vnc to it instead Nov 07 15:15:40 thank you for elaboration Nov 07 15:16:48 Hi all Nov 07 15:17:06 do you know if it is possible to suppress the output from bitbake build? Nov 07 15:17:20 bitbake foo >/dev/null? Nov 07 15:17:34 -_-' Nov 07 15:17:38 sorry Nov 07 15:17:43 and thanks Nov 07 16:25:25 Hi o/ Nov 07 16:26:54 I would like to build two images with component built with different compilation flag. I have two recipes for the component and one common include. I pass OECMAKE -D argument which compiles library Nov 07 16:27:12 Is this good approach ? Nov 07 16:28:00 when I build second image I got QA information that library is already in sysroot/rootfs (staging area) as library name is the same due to common include Nov 07 16:28:28 should I add do_install_prepend() { install -d } ? Nov 07 16:32:28 sorry not install -d but rm -f Nov 07 16:38:36 wino: its not a good approach as you have the problem you just said. have a configuration in the recipe that you can fiddle from your local.conf or whatever. Nov 07 16:41:40 rburton1: I found just old post and RCONFLICTS_${PN} = "another_conflicting_package_name" Nov 07 16:41:52 started to work Nov 07 17:12:29 hmm, no morty branch for meta-ti yet? Nov 07 17:30:04 kergoth: not yet Nov 07 17:30:22 k Nov 07 17:43:57 Hey. When using CMake's FindGit bitbake refuses it to find it (probably due to http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cmake.bbclass?h=jethro&id=c89a1eb877050557af3ef5cd24b7d772068dbc2e#n66 ) Nov 07 17:44:09 Is there a standard solution? Nov 07 18:21:14 hi guys, im trying to add a package to the native sysroot on SDK Nov 07 18:22:03 I extended my recipe to inherit nativesdk and add to SDK_RDEPENDS this nativesdk-recipe Nov 07 18:22:14 but it is not going to the native sysroot Nov 07 18:22:32 anyone knows how to add? Nov 07 18:24:09 as the yocto project documentation states, you use TOOLCHAIN_HOST_TASK to add packages to the nativesdk sysroot, not SDK_RDEPENDS Nov 07 18:24:17 SDK_RDEPENDS just makes sure it's built, it doesnt' install it Nov 07 19:07:29 thank you very much Mr. kergoth. Nov 07 19:37:17 why does meta-intel set EFI_PROVIDER to rmc-systemd-boot regardless of whether we're using rmc? Nov 07 19:40:26 because otherwise rmc-systemd-boot cries. it *cries* kergoth. what kind of heartless monster are you. Nov 07 19:40:45 it cries when i build it already :) (errors out) Nov 07 19:44:56 yeah turns out rmc is sort of a whiner Nov 07 19:45:31 heh Nov 07 19:45:36 sgw_: ^ Nov 07 19:47:25 what the hell? meta-intel overrides scripts/lib/wic/canned-wks/systemd-bootdisk.wks from oe-core Nov 07 19:47:30 regardless of what MACHINE i have selected Nov 07 19:47:38 and it removes the serial console from the kernel append in so doing Nov 07 19:47:45 this violates our BSP layer policies, IMO Nov 07 19:47:47 lol Nov 07 19:47:50 impact on layer inclusion without setting MACHINE Nov 07 19:48:04 if you want to customize a .wks, provide your own damn wks, don't override another layer's Nov 07 19:48:33 dl9pf, ^^^ Nov 07 19:49:07 I agree that is a bug, open a defect.. we talked about this type of problem a bit (not wic specifically) at OEDEM.. I suspect they don't even realize they're doing it Nov 07 19:49:22 (or they don't understand the ramifications of what they did) Nov 07 19:49:53 yeah it does violate the rules, file a high severity bug Nov 07 19:50:11 i think every bsp has done this as some point… Nov 07 19:50:40 ya -- it's why we need to get those test RP was talking about written and enforced.. I know my guys keep doing things like this, and I keep having to tell them no.. (they're learning) Nov 07 19:50:53 we jsut set very high standards for Intel :) Nov 07 19:51:33 Crofton|work: ok, good test to try out the script Nov 07 19:52:13 check my github, I started the script - not yet to the point where RP can inject his magic on the hashes Nov 07 19:52:36 need some more cycles to finish it Nov 07 19:53:06 i've been running a script to check bsp and distro layers for this by using bitbake-whatchanged for a while. not official, but it works Nov 07 19:54:22 yeah Nov 07 19:54:31 there's a bug for that, and that's essentially it Nov 07 19:56:09 would need to make sure it checks all recipes that might change behavior, not just the ones the layer appends (mine did the later, but would have missed this, since it affected a file search due to BBPATH, not just a recipe the layer appended) Nov 07 19:56:10 * kergoth yawns Nov 07 19:56:55 huh, https://www.schneier.com/blog/archives/2016/11/firefox_removin.html Nov 07 20:02:40 kergoth: should be trivial enough to do a stamp comparison against universe Nov 07 20:03:09 indeed, good point, just need the sigbasedata, i guess Nov 07 22:08:09 kergoth: Oops, sorry about that, I had not tested that directly and did not realize the impact, I will revert the .wks change Nov 07 22:12:16 hi. silly question: is there any documentation like a hello-world on how to add a new userspace-application recipe to poky and then build it into an image? Nov 07 22:12:40 I'm looking at the mega manual and it seems to assume I already know how to use devtool, while my actual attempts to add my application have suffered deep build errors. Nov 07 22:26:10 sgw_: np, it happens, i was just surprised more than anything Nov 07 22:51:54 esennesh: www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html Nov 07 22:53:24 esennesh: There's a lot of info on how to use devtool in there. Nov 07 23:07:55 esennesh: sounds like you want to read section 5.3 and then 5.2 in http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#extendpoky **** ENDING LOGGING AT Tue Nov 08 03:00:00 2016