**** BEGIN LOGGING AT Tue Apr 26 02:59:58 2016 Apr 26 06:45:34 hi everyone Apr 26 06:45:45 I have a problem with glibc Apr 26 06:45:55 it seems that a patch doesn't apply Apr 26 06:46:56 here is the log : http://paste.ubuntu.com/16060246/ Apr 26 06:47:53 if anyone has an idea ... Apr 26 07:59:29 good morning Apr 26 08:15:01 Hello, is it possible to have a recipe with a different toolchain ? I have a u-boot booting in 32 bits than the rest in 64 Apr 26 08:56:37 hi everyone :) is there anything like .bbclassappend? Apr 26 08:57:29 bananadev, I think what you want is the inherit keyword Apr 26 08:58:56 gatisp: tks, but my problem is i want override variable in python-dir.bbclass Apr 26 08:58:57 and recipes has only inherit pythonnative which inherit python-dir Apr 26 09:38:08 bananadev: you could set the variable at the configuration level... which var is it? Apr 26 09:40:42 bluelightning: the variable is PYTHON_SITEPACKAGES_DIR. For some reasons, I want to change it to dist-packages instead of site-packages Apr 26 09:41:41 you could use an override to set it Apr 26 09:42:13 e.g. PYTHON_SITEPACKAGES_DIR_yourdistroname = "${libdir}/${PYTHON_DIR}/dist-packages" Apr 26 09:42:22 it's a little ugly, but should work Apr 26 09:44:12 :) thanks Apr 26 09:45:41 I think this is only way I can do Apr 26 09:46:18 for now :) Apr 26 10:10:16 seems like i cant use POKY_DEFAULT_DISTRO_FEATURES_remove = "opengl" Apr 26 10:10:49 so i am back to my original problem , how to ship my own gles + libgbm vs mesa Apr 26 10:42:50 if you have your own gles and gbm then you should be able to stop mesa being built at all Apr 26 10:42:59 so the first question is what is pulling in mesa Apr 26 12:24:36 Hi, I am using DART MX6 with Yocto meta-variscite-mx6. Following a suggestion at http://variscite.com/support-forum/viewtopic.php?f=5&t=211 I merged remotes/origin/imx_3.14.38_6qp-var02 Apr 26 12:24:48 The problem is that I no longer get the kernel-modules or firmware-imx included in the rootfs image. Apr 26 12:24:56 I have deleted tmp and sstate-cache and rebuilt everything using the image recipe that used to work. Apr 26 12:25:00 I was able to get kernel modules in again by adding: Apr 26 12:25:03 IMAGE_INSTALL_append = " kernel-modules" Apr 26 12:25:11 But I have not been able to include the firmware again, these didn't work: Apr 26 12:25:16 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "firmware-imx" Apr 26 12:25:21 IMAGE_INSTALL += " firmware-imx " Apr 26 12:25:28 Does anyone have any idea why it doesn't work, or why it used to work? Apr 26 12:25:37 Thanks in advance. Apr 26 12:46:19 RP: can you respond to the "combo-layer: update with history" that I sent on Friday? We need to figure out this week how to proceed with that, because Mikko is going to be away for a while starting next week. Apr 26 12:53:39 pohly: sorry, I meant to reply. Basically I don't mind taking the code into OE-Core, its probably more desirable than you having to modify it Apr 26 12:55:05 hello Apr 26 12:56:22 hello, back after harddrive failure :-( Apr 26 13:27:22 RP: okay, then it's a matter of timing - can something like that patch still be merged into master now? OTOH, it doesn't have to be - we can keep using the current combo-layer when it works and manually use the newer one in cases where we have issues again. Apr 26 13:28:03 pohly: master and the release branch have not diverged yet and I'm reluctant to do so for a few more days Apr 26 13:29:01 bluelightning: welcome back! I was looking for you past few days... :) Apr 26 13:29:18 hi denix Apr 26 13:30:07 anything I can help with Apr 26 13:30:39 bluelightning: wanted your feedback on [YOCTO #9505] and corresponding patch... Apr 26 13:31:10 it's about pkg DB in SDK Apr 26 13:32:29 denix: ah right - I did take a quick look over the patch, it looked reasonable - I just wanted to check if we were reading other vars like that in that part of the code or whether we expected options like that to be passed in, I didn't manage to check that Apr 26 13:32:42 but it's probably not worth worrying about Apr 26 13:33:50 bluelightning: thanks Apr 26 13:34:05 now that I look, I see we're reading all sorts of vars Apr 26 13:34:10 so no issue there Apr 26 13:34:17 I'd say go ahead and send the patch to the list Apr 26 13:35:30 bluelightning: http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/79310 Apr 26 13:36:10 hmm, I'm really not paying enough attention, sorry Apr 26 13:38:11 Have I got a question for you. Does anybody know what determines the names of packages in "deploy-debs" directory. I thought they would be named according to the package definition in .bb file but apparently that is not the case. Apr 26 13:38:33 denix: I guess RP is only waiting until master reopens Apr 26 13:40:10 bluelightning, denix: Its in master-next fwiw Apr 26 13:40:15 bluelightning: sounds good. can this be a candidate for backporting to krogoth branch after the release? RP? Apr 26 13:40:25 RP: does it mean it can make it to the release? Apr 26 13:40:36 or release is closed already? Apr 26 13:40:41 denix: its unlikely at this point unless we have to respin Apr 26 13:41:29 RP: yeah, thought so. what about my question of backporting it from master to krogoth after the release is out? Apr 26 13:42:07 denix: it is more featureish that bugfix ish, not sure :/ Apr 26 13:42:26 depends on how you look at it Apr 26 13:42:26 RP: it is really a regression for me - we always used that pkg DB for parsing and extracting info for legal purposes Apr 26 13:43:10 unfortunately I missed when the removal patch was submitted, my bad Apr 26 13:43:17 denix: why do we only find out about these things after we've built the final rc :( Apr 26 13:43:52 RP: I know, my bad - I got buried in the old release and didn't pay attention to what was happening in master... Apr 26 13:44:17 muppe: the debian class will rename library packages to match the soname if you have that enabled (which it is by default) Apr 26 13:45:03 denix: we can probably backport it I guess Apr 26 13:47:58 RP: thanks! also, FWIW, lately I've been changing my arrangements around here to be more involved in current master development and don't get dragged to old releases that much. I'll try to keep this up and be more (pro-)active :) Apr 26 13:50:10 rburton: ok, that makes sense. That happened in a package which had just one .so file. Others seem to follow the naming I am setting in a .bb file. I am also struggling with another issue: in creating a rootfs, do_package_write fails due to a parsing error. It refers to a DEBIAN/control file which does not exist and prints out "EOF before value of field `Homepage' (missing final newline)". I don't seem to be able to pull the right strings to fix that. Any Apr 26 13:50:33 denix: keep in mind what I've said about test cases too. If there are usecases you rely on, try and ensure there are test cases for them Apr 26 13:51:16 muppe: do you really need to use package_deb? it's not the best tested. Apr 26 13:51:53 rburton, stop discouraging people from testing stuff Apr 26 13:52:09 Crofton|work: if there's patches to fix stuff, fine :) Apr 26 13:53:17 muppe: i can suggest either a) using package_ipk instead or b) finding where that file is / stopping it getting deleted and figure out why its not writing valid files. Apr 26 13:54:35 rburton: We originally had ipk but changed it because the yocto version we are using did not allow us to go from gcc 4.7 to gcc 4.8. So now we need to cross-compile debs separately, use them as sources for the bitbake and repackage them during bitbake build. This also allows us to harmonize packages between various platforms (e.g cross-compile and desktop). Apr 26 13:55:19 RP: understood and makes perfect sense - in this particular case it wouldn't have been caught until after our next release is done and SDK went to legal dept for review... Apr 26 13:55:45 rburton: The whole chain is actually working fine except for this little issue. Apr 26 13:57:38 rburton: This is the error I am getting: dpkg-deb: error: parsing file '/home/moberg/rel_v1_7/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-oe-linux-gnueabi/blaablaa/1.7-r01/packages-split/mypackage/DEBIAN/control' near line 10 package 'mypackage' Apr 26 13:58:21 rburton: but there is not DEBIAN/control in that directory. Not sure if that is a temporary thing which gets deleted. Apr 26 13:58:54 yeah it probably gets deleted, should be simple to find that line and comment it out Apr 26 13:59:14 rburton: easy for you :) Apr 26 13:59:34 well there's a function called cleanupcontrol in package_deb.bbclass which deletes a directory called DEBIAN Apr 26 13:59:45 comment out anything that calls that? Apr 26 14:01:17 rburton: would that be in oe-core/meta/classes? Apr 26 14:01:54 yes Apr 26 14:02:32 I don't have "cleanupcontrol" in that file. I am probably using something very ancient. Apr 26 14:06:30 rburton: ok, this is a bit off the wall... but can I use .deb packages in SRC_URI but use ipk for PACKAGE_CLASS? Apr 26 14:06:52 muppe: 4.7 was probably daisy and 4.9 is fido? Apr 26 14:59:18 After reading the yocto manual I am having a little trouble understandig the difference between DISTRO_FEATURES and CORE_IMAGE_EXTRA_INSTALL. Furthermore I am having trouble understanding how they relate to PACKAGECONFIG. Does anyone have a simple explanation of what exactly they do that is different from the other and how they relate? Apr 26 15:03:04 they are entirely unrelated Apr 26 15:03:25 DISTRO_FEATURES are large-scale features that hint to the rest of the system things that should be enabled Apr 26 15:03:35 like alsa, or wifi, or ipv6 Apr 26 15:04:08 CORE_IMAGE_EXTRA_INSTALL is a variable respected by core-image.bbclass (inherited by the core-image-* recipes) to install more packages easily Apr 26 15:04:47 PACKAGECONFIG is a way to easily give recipe configurations, like whether mesa should build gles support or not Apr 26 15:05:01 a lot of PACKAGECONFIG options respect the relevant DISTRO_FEATURES Apr 26 15:06:40 OK, because I have seen CORE_IMAGE_EXTRA_INSTALL += "libgles2-mesa mesa-megadriver" and DISTRO_FEATURES_append = " directfb linuxfb libgl1-mesa-dri" kin the same local.conf once and it confused me Apr 26 15:06:56 It seemed as if they did the same thing Apr 26 15:07:19 Then again, the person could have been doing it wrong Apr 26 15:08:14 *in Apr 26 15:08:35 yeah those DISTRO_FEATURES are wrong Apr 26 15:08:40 directfb is a valid distro feature Apr 26 15:08:55 And linuxfb, no? Apr 26 15:08:57 unless you've started inventing distro features - which is fine - linuxfb isn't one and libgl1-mesa-dri is a recipe name Apr 26 15:09:04 erm, binary package name, generated by mesa Apr 26 15:09:11 oh ok Apr 26 15:09:55 Doesn't the mesa-megadrive include everything? Why would you need to specify the other mesa drivers? Apr 26 15:11:43 the megadriver features all *machine drivers* but libgles2-mesa isn't a driver Apr 26 15:13:13 ahh Apr 26 15:22:40 btw, distros can have their own DISTRO_FEATURES flags, as long as they are not conflicting with other layers and aren't confusing, right? Apr 26 15:29:22 yeah you can invent your own Apr 26 15:29:26 there's no registry of flags Apr 26 15:30:04 and if you're worried about confusing flags, just remember "opengl" Apr 26 15:31:07 heh, that one is rather abused... :) Apr 26 15:32:43 JaMa: want your opinion on this - http://article.gmane.org/gmane.comp.handhelds.openembedded.core/79410 Apr 26 15:42:27 rburton: have we opened master for 2.2 ? Apr 26 15:43:59 i'm collecting a mut Apr 26 15:44:04 master isn't yet diverged though Apr 26 15:44:22 denix: its not abused, it just means "gl or something, whatever dude" Apr 26 15:45:18 rburton: I have lined up gcc 6 and glibc 2.24 upgrades Apr 26 15:45:19 rburton: it is a matter of interpretation, yes :) Apr 26 15:45:36 rburton: would be great if they could get some scorching Apr 26 15:46:09 mwhahaha Apr 26 15:46:11 we can do that Apr 26 15:46:16 can you ping oe-core to remind me? Apr 26 15:46:26 rburton: https://github.com/kraj/openembedded-core/commits/kraj/master Apr 26 15:46:53 its kraj/master branch on my github fork Apr 26 15:48:47 rburton: btw. I did not switch the defaults to 2.24 and gcc 6.x Apr 26 15:48:54 may be I should do that too Apr 26 15:49:04 yeah, please Apr 26 15:49:04 I do it manually Apr 26 15:49:15 OK let me push a change for that in a moment Apr 26 15:51:11 rburton: ok pushed Apr 26 16:08:16 denix: have you tried the tune checking script to make sure all these options are valid and compatible? Apr 26 16:09:50 JaMa: I tried several combinations of different machines and archs w/ different optimization levels, but haven't tried the script you mention - any pointers? Apr 26 16:11:32 denix: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test Apr 26 16:12:24 JaMa: thanks, I'll give it a try Apr 26 16:29:03 rburton: QA checks are not using file utility from native sysroot, where as it should Apr 26 16:29:19 for yocto 2.1 we have systemd 229 Apr 26 16:29:28 and it is so much better Apr 26 16:29:39 you can do very complex stuff with ease Apr 26 16:29:56 someday I wish RDK would be fully compliant Apr 26 16:30:48 khem: why should it use sysroot file? we only build that because target file needs a matching native file binary to build Apr 26 16:40:49 password Apr 26 16:41:04 Please excuse that Apr 26 16:42:25 khem: (i almost had a patch that removed file-native entirely) Apr 26 17:03:00 rburton: there is a file in strace sources Apr 26 17:03:13 rburton: which file utility on archlinux can not read Apr 26 17:03:21 but ubuntu 14.04 can Apr 26 17:04:29 % file ./strace-4.11/tests/pipe.expected Apr 26 17:04:31 ./strace-4.11/tests/pipe.expected: ERROR: EOF computing DER offset Apr 26 17:12:18 khem: it works on my FC23 system, but apparently a recent upstream issue and fix. If you haven't already found it: https://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg387853.html Apr 26 17:14:13 billr: has it been submitted upstream as well ? Apr 26 17:29:25 khem: my understanding is that it came from upstream. There's a similar set of patches here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c540f9ea27b6c6e14481b3364d6193862a3377b1 Apr 26 20:57:14 rburton: that libunwind aarch64 patch in master-next will conflict with one of my gcc6 patches where I upgrade libunwind to just move to latest master and not have many backports Apr 26 20:57:31 we were lately doing so many backports on top of 1.1 that it just made sense Apr 26 21:29:47 khem: watch the yocto ab, just fired a gcc6 series Apr 27 01:04:09 http://lists.denx.de/pipermail/u-boot/2016-February/244655.html should be applied to fsl-ppc u-boot recipes **** ENDING LOGGING AT Wed Apr 27 02:59:58 2016