**** BEGIN LOGGING AT Tue May 10 02:59:59 2016 May 10 03:56:07 I'm trying to build the kernel and FS for the Intel Galileo 2. I DLed the BSP from the Intel website and the and ran setup.sh . The build complains of many layer.conf files not found. I've noticed that some layers (meta-*whatever*) don't have a 'conf' or layer.conf file. Shouldn't all layers have a layer.conf ? May 10 05:45:17 I have an old target running dylan. Can't move on because I'm stuck at kernel 2.6.39. Now I want GCC 5.2. Think that can be done? May 10 07:37:57 good morning May 10 08:15:48 RP: Here is fix for non-glibc c++ header issue in SDK that I was talking about other day http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-6&id=e52025a59bc3bc19a5bcb16c9ab43ba7eb29f872 May 10 08:17:10 khem: ah, neat :) May 10 08:28:10 RP: my tree is growing, I have accumulated many updates in there May 10 08:28:16 when are we opening master May 10 08:29:30 khem: its open now basically May 10 08:40:31 RP: OK May 10 08:41:09 RP: In my tree, I have currently pointed the gcc/glibc/gdb to branches inside my github forks for ease of fixing May 10 08:42:05 RP: I will ask rburton to give it another run on ab May 10 09:12:51 Hi. Can RREPLACES/RCONFLICTS/RPROVIDES be applied for moving files from one package (also recipe) to another (also recipe)? May 10 09:13:05 or what would be the right way for making opkg happy at a potential upgrade on the field? May 10 09:13:14 yes, that's what they're generally for May 10 09:14:42 I used these when I renamed a package from old to new: RREPLACES_${PN} = "old-name" May 10 09:14:50 but I have not yet used them for files. May 10 09:15:35 i.e. in the file restructuring sense, both packages will coexist in the future, they will just differently distribute the files at a potential upgrade. May 10 09:18:56 or is it something like opkg that I should use with some force option at package upgrade not to complain about clashing files from different packages? May 10 09:19:28 or I should first remove the old packages and then install the new ones? What is the best practice here to solve this? May 10 09:21:51 easiest way is to go read the debian developer guide, the chapter on moving files between packages May 10 09:22:05 explains how to do it, but basically use replaces/conflicts/provides May 10 09:23:01 thank you, do you have a recipe in mind doing this in meta already? May 10 09:23:15 grep RCONFLICTS, you'll find some May 10 09:35:52 rburton: I can only see package conflicts, not file. May 10 09:41:08 e.g. in ./meta/recipes-support/libnl/libnl_3.2.22.bb May 10 09:43:33 or ./meta/recipes-kernel/lttng/lttng-ust_2.4.0.bb May 10 09:43:52 these are all replacing packages, which is fine, but I cannot find an example for file restructing between two existing packages. May 10 09:44:03 or is it enough to set these up between two packages? May 10 09:44:07 without caring about the files? May 10 10:12:55 rburton: from the debian manual: "It is usually an error for a package to contain files which are on the system in another package. However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. The file will no longer be listed as "owned" by the old package and will be taken over by the May 10 10:13:01 new package. Normally, Breaks should be used in conjunction with Replaces.[53] " May 10 10:13:47 Replaces: foo (<< 1.2-3) May 10 10:13:47 Breaks: foo (<< 1.2-3) May 10 10:14:01 so it seems to be that the specification is not file based, but the same as for whole packages. May 10 10:14:40 except that it does not say conflict May 10 10:14:52 not sure why it does not say rprovides though May 10 10:52:53 is it RREPLACES_${PN} = "foo (<= 1.1.1)" -> is it possible to specify the PR version in that line for foo? May 10 10:53:10 so for instance, something like 1.1.1-r3 instead of 1.1.1? May 10 11:35:58 if I want to define do_compile() differently for native builds and for cross compilation builds: is there any do_compile_native() or how do I have to express this ? May 10 11:36:51 do_compile_class-native May 10 11:48:45 @rburton: thanks, works! May 10 11:52:02 if a recipe is built indirectly natively because of a bitbake rootfs-image -c populate_sdk, how do I access the devshell for the native build of that recipe ? May 10 11:53:24 bitbake recipe-native -c devshell May 10 12:04:15 this seems to work RREPLACES_${PN}-foo = "bar", but this does not RREPLACES_${PN}-foo = "bar (<=1.1.1)", i.e. I am getting conflicts at opkg install pkg-foo: RREPLACES_${PN}-foo = "bar". What am I doing wrong? May 10 12:33:38 has this ever been tested ? ./meta/recipes-support/libcheck/libcheck_0.9.12.bb:20:RREPLACES_${PN} = "check (<= 0.9.5)" I see no version specified at other replace places. May 10 12:34:03 also, this is weirdly constructed, too: ./meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb:37:RCONFLICTS_${PN} = "netbase (< 1:5.0)" -> what does 1:5.0 mean? May 10 12:35:40 lpapp: I suppose 1 is epoch (PE) May 10 12:38:00 jku: hmm, ok, thanks. May 10 12:39:50 I cannot see an example for the versioning restriction even in meta-oe... May 10 12:40:31 perhaps opkg is buggy for the version operators? Because it works fine without... May 10 12:40:56 but once the replace happens, it is not required in newer versions for our project. May 10 13:06:26 does jethro run nicely with read-only rootfs, or are fixes/backports/hacks needed? May 10 13:33:28 anyone have an idea what would cause a improperly implemented machine configure file to cause satisfy_dependencies_for errors? I've got a better explained question here http://stackoverflow.com/questions/37124104/bitbake-fails-during-satisfy-dependency-for May 10 14:15:38 Hi all. Does putting relative paths in bblayers.conf work? May 10 14:17:01 My task is to assemble a git repo (probably using submodules) to have a single repo that can be checked out and is ready to build our image. Afaik this is not how it's meant to be used but have to do that, unless you've got a better suggestion of course :) May 10 14:17:52 Anticom: you could use variables such as $â{TOPDIR} May 10 14:18:13 Anticom: for example BBLAYERS = "${TOPDIR}/../meta" May 10 14:18:29 shagu: oh... totally forgot that it was an actual bb file... lol thanks :) May 10 14:46:18 in my nativesdk libpthread is missing, how to add it to there ? May 10 15:06:05 Btw. why is there meta-*/ in poky's .gitignore? May 10 15:07:49 Anticom: gitignore doesn't ignore stuff that is already tracked by git May 10 15:07:50 people may like cloning meta layers into the poke root May 10 15:07:57 poky* May 10 15:08:09 I certainly used to do that May 10 15:08:11 so my guess is that it allows to hide whatever layers the dev has added while still tracking the ones that are in git May 10 15:08:20 that is right. May 10 15:08:22 lpapp: that's exactly what i wanted to do. However now i'd have to force them in May 10 15:08:36 Anticom: why not submodule? May 10 15:09:09 lpapp: from poky? May 10 15:09:22 hm May 10 15:09:47 because they have their own history... May 10 15:09:49 i'm having a parent repo where poky is one of its submodules. That's how i wanted to do it May 10 15:10:09 guess i can set our repo as upstream for poky and leave the downstream for updates? May 10 15:17:24 Anticom: if you've a parent repo then you could put the other layers alongside poky instead of under it May 10 15:17:46 rburton: that's the solution i'm going with now :) May 10 15:18:38 makes it clear that the layers are not part of poky May 10 15:18:57 Anticom: that's also what we're doing. May 10 15:19:24 So if that's "not how it's meant to be used", rest assured that there are others violating that rule. May 10 15:19:54 rburton: Also i still don't get how to use yocto w/o poky repo. Iirc it's "just" a reference distro however there are plenty of scripts and tools already set up for you so starting from ground up would be a rather huge efford, wouldn't it? May 10 15:20:18 no May 10 15:20:27 clone bitbake and oe-core May 10 15:20:28 sorted! May 10 15:20:53 neverpanic: I thought you just version your own layers and set up your environment by getting the provided stuff yourself instaed of managing them in submodules May 10 15:21:05 rburton: oh okay May 10 15:21:37 oh man, haven't worked with yocto for 4 weeks bc of vacation and now i'm starting from scratch again :/ May 10 15:22:45 Anticom: We want to be able to have one central version where we can go back and forth to bisect problems May 10 15:29:47 rburton: btw is there any reason, why the layers have to be cloned manually and then added? Wouldn't it be more convenient to just specify the layers's location similar to SRC_URI and let some script handle the rest? May 10 15:29:56 besides effort to change it of course May 10 15:30:52 you've just described bitbake-layers ;) May 10 15:31:14 rburton: well but i can't check that bblayers.conf in May 10 15:31:21 since the paths are absolute and unique to my machine May 10 15:31:27 yeah May 10 15:32:07 rburton: i was thinking about like a bbproject.conf where you just say BBLAYERS = "git://git.yoctoproject.org/poky.git git://git.openembedded.org/meta-openembedded ..." May 10 15:32:13 and have a tool to set up your environment May 10 15:32:22 this way it could be versioned and easily managed May 10 15:34:50 RP; finally got to the point where I saw your reply to the oeqa2 email thread. What you said here earlier reiterates your comments in the email. Thanks. May 10 15:42:06 Anticom: as rburton says, bitbake-layers can fetch from the layer index. one ofthe montavista guys had a patch series to add remote layers support to BBLAYERS, but i don't think it ended up getting too far May 10 15:42:14 most folks just address it with other tooling May 10 15:42:18 rather than making bitbake do everything May 10 15:42:34 Sorry for repeating my question: my nativesdk recipe needs /usr/lib/libpthread_nonshared.a which according to the host manifest is not installed in the sdk, but according to the target manifest it is. I added a nativesdk-packagegroup-sdk-host.bbappend and inside RDEPENDS for libpthread-stubs, but it does not add the lib to the native sdk :( Any ideas ? May 10 15:43:33 you need nativesdk-libpthread-stubs May 10 15:43:38 nativesdk packages are nativesdk- prefixed May 10 15:44:05 you could also ust add it to TOOLCHAIN_HOST_TASK in the sdk / image / local.conf rather than adjusting the packagegroup May 10 15:46:11 are variables like TOPDIR and THISDIR expanded in bblayers.conf? May 10 15:49:45 @kergoth, so is it ok to add it as RDEPENDS_${PN} += "nativesdk-libpthread-stubs" of the nativesdk-packagegroup-sdk-host.bbappend ? May 10 15:51:11 anyone have an idea what would cause satisfy_dependencies_for errors, even when the .ipks are in a package arch dir which is set to my MACHINE variable? I've got a better explained question here http://stackoverflow.com/questions/37124104/bitbake-fails-during-satisfy-dependency-for May 10 15:51:57 and to make the dependency clear that this has to be available before my recipe is compiled, to add RDEPENDS_${PN}_class-nativesdk += "nativesdk-libpthread-stubs" to the recipe ? May 10 15:56:45 lumpidu: do you really need pthread-stubs? May 10 15:59:18 rburton: unfortunately yes: I am about to put grpc under a recipe: for that I need protobuf for generating the translated files and then the grpc libs depend on pthread May 10 16:00:00 rburton: is this a problem ? May 10 16:00:39 glibc should be shipping pthreads May 10 16:01:19 my glibc has /lib/libpthread-2.23.so and /lib/libpthread.so.0 in May 10 16:02:09 what I am doing is bitbake rootfs -c populate-sdk and the pthread libs are in the target sysroot but not in the host sysroot May 10 16:06:22 sadly i don't have a sdk built to compare May 10 16:06:58 lumpidu: so you want a nativesdk-grpc so you can run grpc inside the sdk itself May 10 16:07:31 rburton: ah what I am seeing is that the host sysroot has the libpthread.so inside but not the libpthread_nonshared.a which is required by grpc and which is present in the target sysroot May 10 16:07:58 why would you need a host libpthread-nonshared.a in a sdk? May 10 16:08:09 unless you're building other host binaries May 10 16:08:59 what I want is to have the protoc plugins of grpc compiled for the native sdk so they can be run on the host when generating the grpc code for the target May 10 16:21:14 rburton: is libpthread_nonshared.a a problem for host sdk ? May 10 16:22:15 lumpidu: afaik, the host bits are just to run, so you won't get headers and static libraries May 10 16:24:12 is this something I could tweak with some .bbappend ? any hint on which recipe to look for ? glibc ? May 10 16:25:05 you want to add nativesdk-glibc-dev to the sdk i guess May 10 17:40:32 JaMa: if we want to stay on 5.6, is the best bet to just lock down meta-qt5 to c1b0c9f546289b1592d7a895640de103723a0305? Is there a tag/branch for folks who aren't prepared for the jump yet? May 10 17:42:58 kergoth: krogoth branch May 10 17:43:16 we're not sticking to krogoth elsewhere, though :) May 10 17:44:01 but it will get bugfixes which apply fot 5.6 May 10 17:44:16 ah May 10 17:44:17 many projects are using older Yocto releases and meta-qt5 from krogoth branch May 10 17:44:20 because they want 5.6 May 10 17:44:27 so you have oposite case :) May 10 17:44:56 I don't know if we'll have to stay with 5.6 or not, but it needs to be carefully considered due to the licensing changes, which means dealing with legal :) May 10 17:45:07 i'll try sticking with krogoth for now May 10 17:45:12 thanks May 10 17:45:27 it's possible that I'll eventually create separate branch for 5.6 maintanance which will be compatible with latest Yocto relases (once there are some incompatible changes) because of licensing May 10 17:46:06 * kergoth nods May 10 17:56:56 * kergoth preps more ldflags fixes May 10 17:57:13 * kergoth wonders how he didn't hit some of these with the external toolchain, must not have built some of those recipes May 10 18:00:42 RP: sorry i didn't get to the ldflags issues yesterday, feel free to hold off on the ldflags poisoning merge. i've got a sick kid at home, and he's in a dada phase, i barely got a half day of work in yesterday May 10 18:00:42 heh May 10 18:11:09 kergoth: ldflags poising is going to expose a lot of recipes which dont respect ldflags so imo that should be fixed May 10 18:11:39 kergoth: secondly, its going to mean that when I do $CC hello.c with installed SDK from OE that wont work May 10 18:12:03 its a different behavior than rest of gcc world May 10 18:12:17 binaries don't work without setting the hash style to gnu? May 10 18:12:29 no May 10 18:12:33 default it sysv May 10 18:13:34 even though gnu_hash is better and faster, it would be less of a pain to drop it and take the hit if we really want the ldflags May 10 18:13:40 poisoning May 10 18:14:13 i didn't realize gnu hash is required to run binaries, i thought it was just a performance improvement. regardless, we could easily apply the poisoning only to gcc-cross and not gcc-cross-canadian and sidestep the sdk issues entirely May 10 18:14:25 the main goal here to identify problematic recipes, which is via gcc-cross May 10 18:16:56 RP: thoughts on that? i think we should set it aside entirely until more of the qa failures are fixed, regardless, but perhaps cross-canadian should be excluded May 10 18:18:43 are there some gut of gcc-cross that is exposed to libgcc and gcc-runtime as well ? May 10 18:18:56 subsequently May 10 18:42:59 anyone have an idea what would cause opkg to spit out satisfy_dependencies_for errors, even when the .ipks are in a package arch dir which is set to my MACHINE variable? I've got a better explained question here http://stackoverflow.com/questions/37124104/bitbake-fails-during-satisfy-dependency-for May 10 18:54:17 karobar: are those ipks empty ? May 10 18:56:57 rburton: can you take a look at Neena's e-mail about FreeGLUT? May 10 18:58:46 kergoth: I don't think 5.6 is worse than 5.5. 5.4 is the last one which were not gplv3 IIRC May 10 19:02:30 Qt is headed wrong way May 10 19:06:34 khem: no, the .ipks for all the dependencies seem to have control and data tars May 10 19:53:03 otavio: but meta-qt5/master has 5.7 which is a lot worse than 5.6 in meta-qt5/krogoth for many people May 10 19:55:48 otavio: 5.7 removes lgpl 2.1 as an option May 10 19:55:51 * kergoth yawns May 10 20:48:56 kergoth: indeed May 10 22:20:28 kergoth: In theory people should be using our SDK flags. If they're not, they're asking for trouble :/ May 10 22:20:49 kergoth: I know people are unhappy about the --sysroot poisoning though May 10 22:26:22 RP: I think as far as the options are bundled into CFLAGS or CC it should be fine May 10 22:27:00 RP: however, saying that you can not do $CC -o test test.c is not acceptable IMO May 10 22:32:57 khem: its a tricky one... :/ May 10 22:35:59 RP: most of folks have preexisting Makefiles, May 10 22:36:39 khem: doesn't this mean we have problems changing gcc-cross too? May 10 22:37:02 asking for CC ${CLFAGS} -o test.o test.c ; LD $LDFLAGS test.o -o test May 10 22:37:19 is fine but then whats the point of gcc driver ? May 10 22:37:40 gcc-cross doesnt interact with users as much as SDK does May 10 22:37:53 it can be dealt with at recipe level May 10 22:38:36 it would help with cleanup but then we also have to keep in mind what developers expect May 10 22:38:54 most of them expect native kind of experience May 10 22:39:06 especially with SDKs May 10 22:39:09 khem: don't you just do CC $CFLAGS $LDFLAGS -o test test.c ? May 10 22:39:28 khem: our LDFLAGS are designed to go to the driver rather than the linker directly anyway May 10 22:39:50 RP: yes that would do it too May 10 22:39:58 however, they will begrudge May 10 22:40:31 hmm do we export CFLAGS and LDFLAGS into sdk env ? May 10 22:40:50 in that case it may not be needed May 10 22:44:57 khem: we do export both afaik, yes May 10 23:56:20 ok that may help bit makefiles **** ENDING LOGGING AT Wed May 11 02:59:58 2016