**** BEGIN LOGGING AT Thu Jul 13 03:00:03 2017 Jul 13 04:13:22 kergoth rburton small update: needed to update to docker edge release and use a docker volume (e.g. no local filesystems) and it's getting a lot farther Jul 13 07:53:24 hi o/ Jul 13 07:53:41 I want to have PN with capitalize Jul 13 07:53:46 but it fails with ipk Jul 13 07:54:04 I think this is a current problem, so what can I do? Jul 13 07:54:12 current => common Jul 13 07:56:29 alkino: there was some discussion lately on this, but the answer at the moment is: not possible Jul 13 07:56:41 ok Jul 13 07:56:58 sad because I need to define "all" myself. Like S Jul 13 08:00:15 alkino: this suggests that there is actually a reason behind it: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/130873.html Jul 13 08:01:20 LetoThe2nd: so is there a way to overload PN that ipk take? Jul 13 08:01:39 as ipk cannot handle that, I need to f*** up the rest Jul 13 08:01:56 It will be nicier the other way Jul 13 08:02:17 hello world !! I have a problem.. I have a recipe that create a system user (eg. myuser) along with its home direcotry (/home/myuser). Now I have another recipe that has to copy some files un (/home/myuser/myfolder). Jul 13 08:02:17 alkino: no idea. i'm a all lowercase guy anyways. i don't like shouting and marketing emphasizes :) Jul 13 08:02:43 LetoThe2nd: I want to add a project with uppercase in int... Jul 13 08:03:17 So in the second recipe I do_ install -d ${D}/home/myuser/myfolder and cp -R ${WORKDIR}/somefiles/* ${D}/home/myuser/myfolder Jul 13 08:03:50 Hence running bitbake core-image-minimal leads to the following conflict Jul 13 08:03:54 alkino: so is your problem only that the upstream source has uppercases? or do you for some obscure reason actually *NEED* the package name inside the build to include uppercase letters? Jul 13 08:03:57 fberg: I think the second recipie must also do do_ install -d ${D}/home/ Jul 13 08:04:00 do_ install -d ${D}/home/myuser/ Jul 13 08:04:14 then `do_ install -d ${D}/home/myuser/myfolder` for it to access that directroy. Jul 13 08:04:14 LetoThe2nd: upstream has uppercase Jul 13 08:04:41 alkino: wll then just override the SRC_URI and the unpacking process. Jul 13 08:04:49 file /home/myuser conflicts between attempted installs of .... Jul 13 08:05:01 fberg: unless there is some short hand to do recursive creates until you reach the full path. Jul 13 08:05:20 thank you TafThorne Jul 13 08:05:32 LetoThe2nd: ok Jul 13 08:05:46 fberg: first and foremost, remember that the recipe that wants to copy stuff there needs to depend on the one that creates the user Jul 13 08:05:50 fberg: You are welcome. I hope it works. Hopefully not take you too long to give it a try, Jul 13 08:06:25 Leto, I think it too. So I've added the DEPENDS statement Jul 13 08:06:51 TafThorne i think the the .d option with install also creates all the directories in between Jul 13 08:06:53 fberg: could also be that it needs to be an rdepends, i'm not completely sure there. Jul 13 08:07:15 the problem is that bitbake sees that two recipes are installing on the same folder Jul 13 08:09:48 alkino: here is some inspiration on how to fix that: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-unpacking-code Jul 13 08:10:14 LetoThe2nd: overload S and SRC_URI is not enough? Jul 13 08:11:56 alkino: it probably is, i'm just not completely sure. hence the pointer to the docs to guide you further if needed. Jul 13 08:12:23 thanks Jul 13 08:12:45 uhm, how to execute python tasks manually in recipe's devshell? Jul 13 09:30:17 I'm a bit confused about "gcc --sysroot" - why does "x86_64-refkit-linux-gcc ... --sysroot=.../recipe-sysroot -L/usr/lib64" trigger a warning: .../x86_64-refkit-linux/7.1.0/ld: warning: library search path "/usr/lib64" is unsafe for cross-compilation Jul 13 09:31:14 I though --sysroot would make paths specified by -L and -I relative to the sysroot directory? Jul 13 09:31:22 thought Jul 13 09:33:09 pohly: https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Directory-Options.html#Directory-Options does not mention that -L uses --sysroot Jul 13 09:34:07 mcfrisk: it does for gcc 7.1: https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Directory-Options.html#Directory-Options Jul 13 09:34:47 pohly: maybe that's the reason for the warning then, not an error Jul 13 09:35:36 But it triggers a fatal OE QA check: "The compile log indicates that host include and/or library paths were used." Jul 13 09:35:44 So the problem seems to be real. Jul 13 09:39:51 what's the path of least resistance to include a kernel module? I can see CONFIG_RTL8192CE=m makes it into tmp/work/i586-nlp-32-intel-common-poky-linux/linux-yocto/4.4.60+gitAUTOINC+d6733af208_2cc78e92f4-r0/defconfig but I see no sign of the module being built Jul 13 09:52:25 nuts, my ccache patch broke seltest Jul 13 09:59:58 pohly: it is better to set -L and search paths globally, and yocto does this so hard coding paths in recipes not a good idea. I would patch this away and trus what yocto provides by default. If defaults are wrong, the there is something else wrong in the config. Jul 13 10:02:05 mcfrisk: I can try that. My current solution is to replace -L/usr/lib with ${RECIPE_SYSROOT}${libdir}/ via a make variable that the Makefile of this project already supports. Jul 13 10:02:10 I.e. no patching needed. Jul 13 10:22:43 Hello guys! I'm trying to use a PCI to SATA adapter in an ARM device running Yocto, but whenever I perform any operation on the disk filesystem libata explodes with failed commands. I would appreciate if anyone could please help me Jul 13 10:29:08 hello dudes ! Jul 13 10:29:30 I've a problem... I'mn using a yocto generated image of abpout 500MB Jul 13 10:30:14 after the boot I want to extend the filesystem to its whole capacity (say 16G). how can I do this ? Does anibody knows ? Jul 13 10:34:47 fberg: You would normally use cfdisk or any other partitioning tool to expand the partition in the disk table (just delete that partition and create it with larger size and same attributes) and then run resize2fs on that partition. Jul 13 10:35:25 change partition table, resize file system, simpes Jul 13 10:35:33 After flashing of course, otherwise you're adding zeroes to the image file pointlessly Jul 13 10:36:54 ok guys. I'll check it Jul 13 10:37:12 depends how you're writing the file system too Jul 13 10:37:18 ie some imaging tools can do that for you Jul 13 10:37:26 wic is about to gain the ability to do it Jul 13 10:37:34 the live installer script can do it iirc Jul 13 10:37:46 i need to run a script at the very fisrt boot Jul 13 10:38:18 among other operations this script must also expend the filesystem to the sd maximum capacity without user interaction Jul 13 10:46:57 fberg: To avoid that issue, I used to use a script to install the filesystem, creating the partitions correctly for the disk, formatting and installing a tar.gz of the filesystem instead of an image. Jul 13 10:47:53 This was on PPC, so no need to worry about a bootloader on the disk. Jul 13 10:49:03 Alternatively to my former question, what's the correct method to use a more recent kernel version under a Krogoth build? Jul 13 10:51:20 ty MWelchUK Jul 13 10:51:39 it seems probably the easy way Jul 13 10:52:51 fberg: It's worth noting I wasn't running off the disk when I performed that operation too- I was PXE booting or booting from a different media. Jul 13 10:53:39 but the user that has to burn the sd card would be more prone to error if the device is mounted differnetly Jul 13 10:54:18 running it directly on the booted sd card probably is better Jul 13 10:54:55 If it's programming an SD card, do it when writing the SDCard, I didn't have that luxury :-) Jul 13 10:55:55 (That then also depends on what hosts you support for writing the flash...) Jul 13 10:58:04 can anyone suggest why this module isn't built? https://pastebin.com/D8XD6D49 Jul 13 10:59:24 Serede_: fwik you can use PREFERRED_PROVIDER_virtual/kernel = "your_kernel" in your local.conf Jul 13 10:59:46 Serede_: to switch from one kernel to another Jul 13 11:06:42 zero_note: that would select the recipe, right? The problem is my kernel provider fixes the kernel version at 4.1.15 for Krogoth Jul 13 11:08:30 jku: i think that regex isn't enough to silence the checkpkg selftest. Jul 13 11:08:49 huh Jul 13 11:08:52 jku: i think checkpkg needs to be extended to have a way of recipes saying "i don't work" Jul 13 11:09:10 at the moment the selftest demands it works and maintains a list of exceptions in meta-selftest/files Jul 13 11:09:40 need a way of disabling the check from a recipe really, the exception list is ugly Jul 13 11:10:22 oh yeah, never noticed that Jul 13 11:13:12 Serede_: you can use PREFERRED_VERSION_your-kernel = "4.4" , you'll need a recipe in your primary layer Jul 13 11:13:39 Serede_: like your-kernel_4.4.bb Jul 13 11:14:19 Serede_: btw, what do you mean by "my kernel provider fixes the kernel version at 4.1.15 for Krogoth" ? Jul 13 11:15:52 shauno: never used that method to enable kernel modules, why dont you use you own defconfig with that module enabled? Jul 13 11:17:28 I'm trying to make as little change as possible to the vendor's bsp Jul 13 11:20:36 zero_note: I mean I have a meta-compulab layer with only one recipe for kernel, which is indeed 4.1.15 Jul 13 11:25:18 that's probably a freescale arm soc then Jul 13 11:25:27 Serede_: ok, can add you own kernel recipe which will fetch your chosen kernel of the chosen version, updating PREFERRED_PROVIDER and PREFERRED_VERSION in your local.conf Jul 13 11:27:56 zero_note: Will check it out. Thanks a lot! Jul 13 11:28:43 the main issue is thant then you have to port support for your platform from the crappy 4.1.15 kernel from freescale to a more recent one Jul 13 12:43:21 @joshuagl, I had a question about some OpenSSL packaging changes from back last year. Jul 13 12:49:01 mwhoosier: sure, ask away. I'll try to remember :-/ Which branch are you referring to? Jul 13 12:50:01 joshuagl: it was one called "Revert "openssl: prevent ABI break from earlier krogoth releases"" over on the krogoth branch Jul 13 12:51:03 joshuagl: I know that you were just the person who cherry-picked this over from the same reversion that happened on oe-core, but I was wondering if anybody remembers why the ABI backward-compatibility ended up not being retained. Jul 13 12:51:38 joshuagl: the SHA1 is 08f85da10b3a7fc6165f163fd0f23784a2c9c8e4 Jul 13 12:51:47 mwhoosier: I back-ported the ABI backward compat patch, Armin reverted it Jul 13 12:51:54 I'm afraid I can't comment on why it was reverted Jul 13 12:52:20 Okay, I'll see if I can find Armin. Any idea what his nick is here? Jul 13 12:52:32 actually, not sure I even made the initial backport. Though I did write the initial patch it seems Jul 13 12:52:53 Armin usually goes by armpit, doesn't seem to be here Jul 13 12:53:05 mwhoosier: could always try mailing the list with Armin on CC? Jul 13 12:53:30 Yeah, sure. Would yocto-devel be appropriate, or is there a separate list for stuff that happened on oe-core proper? Jul 13 12:53:59 right, OE-Core development happens on openembedded-core@lists.openembedded.org Jul 13 12:54:08 Great, thanks! Jul 13 12:54:27 np Jul 13 12:58:27 hi guys, I am having some problems with the image-live class Jul 13 12:59:08 in morty, that class has added to do_bootimg[depends] a ${PN}:do_image_ext4 Jul 13 12:59:24 but my image does not have do_image_ext4 task Jul 13 12:59:41 is there any way I can delete this task from do_bootimg depends? Jul 13 13:00:02 I tried looking at deltask but that doesn't work Jul 13 13:00:22 what is the difference between the _append and += syntax? Jul 13 13:00:41 _append won't add the space that += adds Jul 13 13:01:14 so when you use _append make sure what you append has a leading space Jul 13 13:01:21 ok, thanks Jul 13 13:01:30 you're welcome Jul 13 13:07:11 guess I'll just stick to removing it in a anon function Jul 13 13:27:21 filt3r: also += and _append happen at different times Jul 13 13:32:12 ye i thing i just found it: "The operators "_append" and "_prepend" differ from the operators ".=" and "=." in that they are deferred until after parsing completes rather than being immediately applied." Jul 13 13:32:45 and i guess += will be applied at parsing as well Jul 13 13:38:35 hi! banging my head on this for hours now... I have a recipe that inherit cmake: the upstream build system looks for the command git by mean of the standard cmake module FindGit which in turn uses the builtin find_program() command. When run through bitbake the GIT_EXECUTABLE variable always return NOT-FOUND. Can't figure out why! Jul 13 13:39:32 manually running cmake against the same CMakeFiles.txt in a devshell successfully finds git (in tmp/hosttools/git) Jul 13 13:42:50 moreover, replacing find_program() with execute_process(which git) does the job but I'd really like to understand why find_program() doesn't. The question looks cmake specific but posting here since I see different behaviour from devshell and hope it can ring a bell from experts Jul 13 13:44:42 gizero: It's related to how CMake finds host-tools, the variable CMAKE_FIND_ROOT_PATH_MODE_PROGRAM and ASSUME_PROVIDED = "git-native" Jul 13 13:45:07 set OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM to BOTH in your recipe Jul 13 13:45:20 someone who totally understands cmake is welcome to rewrite that class btw Jul 13 13:45:51 I think CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is set to ONLY by default, which makes CMake search things only in the native sysroot, but git isn't in there because git-native is in ASSUME_PROVIDED Jul 13 13:53:12 rburton: sounds like you know what you're talking about Jul 13 13:53:32 i'm +1 on Bluff Jul 13 13:54:41 hah Jul 13 14:06:03 Can anyone suggest a good imx based devboard that works well with Yocto? Preferably something with HDMI. Jul 13 14:07:32 jpew: any of the SABRE from NXP Jul 13 14:08:56 zero_note: Thanks! Jul 13 14:09:53 jpew: yw Jul 13 15:02:52 rburton: neverpanic: thanks! OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM did the trick! Jul 13 15:03:21 this little thing was driving me crazy! Jul 13 15:58:47 What is the difference between localedir = "${libdir}/locale" and ${datadir}/locale? Which one should be for autotools --localedir or meson's localedir? Jul 13 15:59:02 binary vs source Jul 13 15:59:11 compiled locales go into the libdir path, iirc Jul 13 16:00:15 kergoth: so is /usr/lib/locale/ca/LC_MESSAGES/appstream-glib.mo correct or should that be under /usr/share? Jul 13 16:00:43 pretty sure that should be going to the /usr/share path Jul 13 16:00:47 but i'm not an expert Jul 13 16:01:25 It's a binary file. Jul 13 16:01:48 ah, maybe not then Jul 13 16:01:50 * kergoth shrugs Jul 13 16:01:59 Yes, me too :-/ Jul 13 16:01:59 maybe someone else knows better than i :) Jul 13 16:02:14 /usr/share would be consistent with Debian. Jul 13 16:02:59 rburton: ^^^ ? Jul 13 16:05:49 meta/conf/bitbake.conf:FILES_${PN}-locale = "${datadir}/locale" Jul 13 16:06:01 So it looks like packages are supposed to use /usr/share. Jul 13 16:06:13 I just wonder how that is done for autotools-based projects. Jul 13 16:06:21 Perhaps most of them do that already correctly. Jul 13 16:12:19 rburton: you are credited with the initial meson.bbclass prototype in the commit which adds meson.bbclass to meta-oe. That commit has --localedir ${@noprefix('localedir', d)} Jul 13 16:12:32 Are you sure that this is correct? Jul 13 16:12:46 no, i'm also credited with the patch that removed it Jul 13 16:12:56 did it still not make meta-oe master? Jul 13 16:13:14 Hmm, good question. Jul 13 16:13:34 Need to check, I'm probably a bit behind. Jul 13 16:14:36 It's in meta-oe master, I need to update refkit... Jul 13 16:17:08 pohly: meson isn't quite there yet for us, GI and gtk-doc are totally bust Jul 13 16:17:13 just so you know Jul 13 16:17:40 rburton: yes, I noticed the GIR failure also with appstream-glib. Jul 13 16:17:56 I'll disable that for now, I don't need it for fwupd. Jul 13 18:17:15 rburton: hello ... Jul 13 18:18:05 rburton: i have some patches awaiting in my queue but I didn't receive complains about them ... are they under MUT or something is locking it up for merge? Jul 13 18:19:25 rburton: i have some patches awaiting in my queue but I didn't receive complains about them ... are they under MUT or something is locking it up for merge? Jul 13 18:19:33 rburton: libarchive and u-boot Jul 13 18:22:21 otavio: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mut << your libarchive looks like its in his queue Jul 13 18:58:25 we keep accepting new packages into meta-openembedded and the original submitters then dont take up maintainership Jul 13 18:58:35 I think we should have a way to control this Jul 13 19:08:13 meta-openembedded-contrib ? Jul 13 22:13:15 nrossi: 'libgcrypt_1.7.6.bbappend: Add patch to fix configure bug for mingw32' <-- is that actually mingw specific or should it be in oe-core? **** ENDING LOGGING AT Fri Jul 14 03:00:02 2017