**** BEGIN LOGGING AT Thu Jun 21 03:00:01 2018 Jun 21 04:39:35 Hello everybody, I think https://alioth.debian.org is discontinued, any idea how we should fix it? Jun 21 05:13:39 jrhenry: salsa.debian.org Jun 21 05:36:50 Hi! Is there a way to reference a variable from a recipe in a different recipe, like you can refer to tasks when specifying dependencies (e.g. virtual/bootloader:do_deploy). My problem is that I want to know the U-Boot binary names without defining a separate variable special for that) Jun 21 06:02:14 Thanks @khem. I've seen this: Jun 21 06:02:14 The alioth.debian.org service is discontinued. Its replacement is a GitLab instance at salsa.debian.org. Jun 21 06:02:14 Migration documentation is available on the wiki, and an archive of VCS repositories can be found on alioth-archive.debian.org. Jun 21 06:02:14 2018-05-31. Jun 21 06:02:14 From: https://anonscm.debian.org/ Jun 21 06:02:14 The thing is I can't find the tarballs with same checksums on GitLab. I guess I'll have to stick with https://alioth-archive.debian.org/ for now. Jun 21 06:36:39 #AIM Jun 21 06:50:40 #AIM, #Bonjour, #Gadu-gadu #GroupWise, #MYSpaceIM #Netsoul #Odnoklassniki #QQ Jun 21 06:50:40 #Sametime #SIMPLE Jun 21 08:44:41 Hi! Can you point me to SDK machine requirements? Is it described somewhere? I can't find it out. Jun 21 08:45:26 I mean the machine which uses SDK populated with populate_sdk Jun 21 08:47:45 It would be very helpful if someone from Yocto team can answer me. I have to make clients to upgrade their old build machines (kernel 2.6 and etc) or to use remote build. Jun 21 08:48:56 Now, I faced with the fact, that Yocto uses glibc 2.26, that can't work with old kernel. Jun 21 10:15:29 New news from stackoverflow: Updating the script present in Poky Source code Jun 21 11:02:57 oh, seems like this channel is dead Jun 21 11:04:14 astrunin[m]: just changing OLDEST_KERNEL will change the requirement but i've no idea of the implications Jun 21 11:04:36 With glibc upgrade to 2.26 release (commit d6a0bc57fa07 Jun 21 11:04:36 "glibc: Upgrade to 2.26 final release") it's not possible Jun 21 11:04:37 to build x86/x86_64 SDK for kernels lower than 3.2.0 Jun 21 11:04:38 (see glibc commit 139ace95756a "Require Linux kernel 3.2 Jun 21 11:04:39 or later on x86 / x86_64.") Jun 21 11:04:46 well, there you go Jun 21 11:05:06 if you need to support ancient hosts then use an older release Jun 21 11:42:19 anyone knows how to remove a line from fstab? a function in ROOTFS_POSTPROCESS_COMMAND seems not late enough Jun 21 11:46:27 ldts: it should work Jun 21 11:50:13 I am able to add to it but not to remove: https://hastebin.com/tosutisoje.http Jun 21 11:50:36 something must be populating fstab after ROOTFS_POSTPROCESS? Jun 21 11:51:26 I tried IMAGE_POSTPROCESS_COMMAND but made no difference Jun 21 12:03:44 ldts you should check what adds that mmc line in fstab Jun 21 12:04:04 ldts what is your machine and distro? Jun 21 12:07:07 you can look at rootfs logs Jun 21 12:11:14 rburton: are you looking at the next round of patches or should I start thinking? Jun 21 12:56:47 RP: let me hit applyotron and push so you can see what i've glanced at Jun 21 13:01:07 rburton: thank you! Jun 21 13:36:11 nayfe_: thanks. I am using a variant of begle bone black. but sure I can chase what is adding that line (which I havent been able to nail down yet so suggestions more than wellcome!); but can I then assume that there is not a safe way of editing a rootfs file? something like a final user hook to run whatever things are required? in this particular case, after ROOTFS_POSTPROCESS_COMMAND something else added to the same file Jun 21 13:36:11 (something outside my meta). Jun 21 13:39:13 ldts: maybe use ROOTFS_POSTPROCESS_COMMAND_append = " myhook;" instead of += Jun 21 13:39:39 nayfe_: yes, did try that already Jun 21 13:42:04 ldts: are you sure your ROOTFS_POSTP ... command is called? Jun 21 13:42:31 yes (it adds the debugfs line at the bottom of the file) Jun 21 13:42:56 https://hastebin.com/tosutisoje.http Jun 21 13:44:00 the second line in the fstab function also deletes the line right below the ...# uncomment this if... Jun 21 13:44:07 so I am 100% sure it has executed Jun 21 13:45:59 ldts: maybe grep your entire yocto layer sources for "/dev/mmcblk0p1 /boot vfat" Jun 21 13:50:33 ldts: or its WIC Jun 21 13:50:41 Hi, I'm building a package which has "inherit native" and this one produces a binary that requires libQtCore.so.4 when executed in sysroot context (that's why it DEPENDS on qt-native). When I 'ldd' the binary in question I see that it does not link against libQtCore.so.4 in sysroot. Is there any "trick or reference" how I can link the binary in question against a library in sysroot? Looking at e.g. python in Jun 21 13:50:42 exactly what I was thinking Jun 21 13:50:47 sysroot I see it links to libraries on the ... Jun 21 13:50:48 @nayfe_ ^ Jun 21 13:50:50 ... sysroot, too Jun 21 13:51:04 it must be wic Jun 21 13:52:05 ldts: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#raw-mode option --no-fstab-update Jun 21 13:52:46 ah! Jun 21 13:52:50 cool. thanks nayfe_ ! Jun 21 13:53:03 --no-fstab-update Do not change fstab file Jun 21 13:53:44 ldts: brst is prolly to provide your custom wks file Jun 21 14:11:44 yeah, just need to remove the mount point from the wks file. all ok. thanks again! Jun 21 14:24:45 ldts: yw :) Jun 21 14:30:01 ldts Jun 21 14:35:23 so if it helps anyone this is the modified canned wks file with the fix (basically it tells wic not to mount the boot partition): https://hastebin.com/erobinuxeq.pas Jun 21 14:45:05 Thx for sharing Jun 21 15:32:17 I built p7zip-native and try to use it then in my own recipe to extract a zip file but i get an error "7za not found" at do_unpack(). It seems 7za binary is not in the sysroot. What could be wrong here? Jun 21 15:40:27 RP, stable/sumo-next clean on ab. missing the lttng backport Jun 21 15:50:35 bfederau_: you'll need to depend on p7zip-native to get it in the sysroot Jun 21 15:51:26 with DEPENDS = "p7zip-native" ? Jun 21 15:53:18 Moto-timo: Is it me or I just saw you on tv at a baseball game? Jun 21 15:54:16 aehs29_1: not me. pehaps an evil twin I don't know about? Jun 21 15:57:53 rburton: DEPENDS = "p7zip-native" did not work Jun 21 15:57:56 Moto-timo: I could swear it was you falling asleep during the game haha Jun 21 16:00:23 aehs29_1: which game? I might look for it on MLB.TV :) Jun 21 16:00:55 Moto-timo: oregon state vs north Carolina I think Jun 21 16:01:29 aehs29_1: ok thanks Jun 21 16:04:20 Hi everyone Jun 21 16:04:34 Does any have experience in cross compiling ruby gems in yocto ? Jun 21 16:04:48 bfederau_: DEPENDS will add to configure onwards, so when are you trying to use p7zip? Jun 21 16:05:19 rburton: at the do_unpack step Jun 21 16:06:29 bfederau_: do_unpack[depends] += "p7zip-native:do_populate_sysroot" Jun 21 16:06:45 bonus points for sending a patch to base.bbclass so you don't need to do that Jun 21 16:09:58 rburton: ah ok I see. :) now it works. thanks. Jun 21 16:10:10 bfederau_: please do send a patch for base.bbclass Jun 21 16:11:30 hello, i'm trying to use yocto to create an image for a i.MX dev board and when i try to run bitbake core-image-base I get an error about the EULA in meta-freescale having a different md5sum Jun 21 16:12:18 rburton: ok. I will have a look how to submit a patch for the project. Jun 21 16:12:42 bfederau_: patch file, git send-email to openembedded-core@lists.openembedded.org Jun 21 16:13:21 rburton: ok. thanks for the info Jun 21 16:20:46 is there somewhere else I should go to ask about the different md5 sum on the EULA? Jun 21 16:21:49 is there an easy way to change what the md5 sum it is looking for to what it is, I didn't change the EULA. Jun 21 16:24:16 looking at the diff of the file it looks like recently someone changed "NXP SEMICONDUCTOR" to "NXP SEMICONDUCTORS" all over the file Jun 21 16:24:23 maybe i'll just try putting it back Jun 21 17:07:52 moto-timo: what makes you think this other person is the evil one??? ;-S Jun 21 17:08:31 lol Jun 21 17:10:17 evil twins.. Jun 21 17:28:25 I think I got it to work by changing the checksum in sources/meta-freescale/classes/fsl-eula-unpack.bbclass Jun 21 18:17:11 New news from stackoverflow: Yocto generated nativesdk-cmake SDK is incomplete Jun 21 18:38:59 I made it futher but now there seems be a makefile issue Jun 21 18:39:12 I get an error saying there is no make target 'zImage' Jun 21 18:41:59 when i google it it seems that zImage doesn't exist for arm Jun 21 18:45:54 has anyone seen this issue? it looks like zImage has something to do with 32-bit targets... Jun 21 18:47:24 in the make command the variable ARCH is set to "arm64 zImage" Jun 21 19:12:44 I'm having issue with a recipe that use a systemd mount file with the '\x2d' escape character in it. This escape character must be there, otherwise systemd complains. In systemd_postinst of systemd.bbclass, ${SYSTEMD_SERVICE} is not escaped or put in single quote, so systemctl is not able to find the corresponding file. Jun 21 19:51:27 dkc: iirc this is fixed in master/sumo, but just put quotes around the variables in the class Jun 21 19:53:37 rburton: yes, that's what I did locally to verify that it works. btw this doesn't look fixed in master/sumo Jun 21 19:53:57 please send a patch then :) Jun 21 19:55:16 will do :) thanks Jun 21 20:50:43 I am using syslog-ng in an embedded build. It has a RDEPENDS for gawk. Since I am not using the configuration scripts using gawk I do not need it. Is there a way in a bbappend file to override this? Jun 21 20:51:20 you could RDEPENDS_${PN}_remove = "gawk" Jun 21 21:26:14 If I want to find out which recipe is responsible for placing a particular file in rootfs, is there an easy way to do that with bitbake? Jun 21 21:50:18 Is there any command to see if a build has a specific patch? Jun 21 22:07:35 Hi guys, does the mailing list server lists.openembedded.org have any delays? I've sent several patches to it but couldn't see the result in the archive. Jun 21 22:53:13 My question was replied here: http://lists.openembedded.org/pipermail/openembedded-devel/2018-June/118994.html Jun 21 23:06:06 Having trouble with a bbappend script. I want to put do_install_append() { some action... } to create a modification to a file put in place by the original recipe. Jun 21 23:06:06 I see the log file for the recipe w/ temp/run.do_install as having my appended action... but the final root image still has the original file unmodified. Jun 21 23:06:30 ideas where else to look for what is going on. Jun 21 23:15:46 dennism: are you modifying the file in ${S} or ${B} instead of ${D}? Jun 21 23:16:17 in do_install_append the files that are about to be packaged are in ${D}, if you modify anything else then you're not touching the right file Jun 21 23:16:53 No I have: echo "XYX" >> ${D}/abc/def Jun 21 23:18:21 It's like my recipe is getting built into an install script, but the install script isn't actually running and the final image has the original contents still. Jun 21 23:19:19 I tried building the recipe with bitbake -f by itself and same thing, the image inside the tmp/work for that recipe is not modified Jun 21 23:48:17 New news from stackoverflow: add gcc to system root image Jun 22 01:58:13 dennism: regarding the question for the file in rootfs, you can use oe-pkgdata-util find-path /path/, the script is in oe-core Jun 22 02:04:48 and from what you describing about your do_install_append, you seem to do everything proprely. I had issues that look like yours when I forgot a $, for instance by writing ${D}{sysconfdir} instead of ${D}${sysconfdir} Jun 22 02:05:19 but without more context, hard to tell you what's going wrong ^^ **** ENDING LOGGING AT Fri Jun 22 03:00:01 2018