**** BEGIN LOGGING AT Fri Apr 22 02:59:58 2016 Apr 22 06:21:42 Hi, i'm build a release for a beaglebone black, meta-ti doesn't have a jethro branch, should I use an older yocto release or use the master branch of meta-ti ? What's the difference between meta-ti and meta-bbb ? Apr 22 07:02:17 Gwik: you can build for BBB with yocto only no additional layers Apr 22 07:15:59 good morning Apr 22 08:27:20 is it safe to clean the work directory after finishing a build, If I plan to recompile a recipe later? Apr 22 08:30:15 yes Apr 22 08:30:28 thats what rm_work does Apr 22 08:32:19 rburton, Hi, I was wondering if that gpgme missing *.pc file issue that we talked about few days back has been resolved? Apr 22 08:32:49 rburton: that was my understanding, I just didn't want to recompile one package and it have to do the work again for all the dependencies if I got rid of it Apr 22 09:10:35 gatisp: not yet, did other stuff yesterday Apr 22 09:12:41 rburton, ah ok, later this afternoon I am returning back to that task, so I will workaround it somehow for now :) Apr 22 09:13:06 or send a patch :) Apr 22 09:13:11 easier for you to test it Apr 22 09:14:42 If I will get a clean solution then sure Apr 22 09:14:53 just needs a gpgme-pthread.pc file added Apr 22 09:15:06 created manually? Apr 22 09:15:19 yes, the recipe already adds a gpgme.pc file Apr 22 09:15:36 probably worth seeing what fedora is doing Apr 22 09:15:53 upstream refuses to ship .pc files so i suspect fedora are patching in .pc files too Apr 22 09:16:46 sounds simple enough, I will check this out soonish Apr 22 09:37:12 I have some custom recipes that builds my app and does a few misc things and builds a custom image. Now, however, I'd like to make an image that includes all the dependencies of my app but not the app itself Apr 22 09:38:01 a -dev image to which I can copy the app after the fact. Any suggestions for an elegant approach to do this? Apr 22 09:38:30 I imagine it might be possible with a python snippet, but I don't know where I can find documentation for that stuff. Apr 22 10:10:56 Hi, I have a question, someone coluld help me. Apr 22 10:10:57 I have a layer which provides configuration packages for core components, I would like to prepare a packagegroup such that, add configuration packages to images only the core component exists. Apr 22 10:12:11 i try to use 'oe.packagedata.pkgmap' to check if the core component exists so that i can add the correcsponding package to RDEPENDS_${PN} Apr 22 10:12:47 this works fine if the package map exits, but it fails when there is no package map :( Apr 22 10:13:01 Is there a better way to achieve this Apr 22 10:40:33 hello, ant Freescale/NXP exper here? Apr 22 10:40:51 Does anybody ever used RTS/CTS on iMX6 ? Apr 22 10:41:03 I have this weird problem Apr 22 10:41:06 https://community.freescale.com/message/636387 Apr 22 11:15:20 mckoan: You're aware that RTS/CTS are a bit back-to-front on mx6? Apr 22 11:15:22 https://community.freescale.com/docs/DOC-97509 Apr 22 11:17:33 Ah, now I see comments to your post to that effect. Apr 22 11:30:38 hi Apr 22 11:32:19 for some mysterious reason, my bitbaking is failing because of a PRINC expansion that allegedly happens in a cherokee recipe. Though that does not contain such a line Apr 22 11:33:07 are the recipes based on perl or alike? I'm using Arch Linux, so I might face some issue because of using a modern version of an interpreter? Apr 22 11:56:44 LeifSo: maybe the PRINC happens in a .bbappend file somewhere else? Apr 22 11:58:38 hello Apr 22 12:06:37 Primordus: ah, the digi layer is the culprid. thanks for the hint :) Apr 22 12:24:37 arkver: thx :-) Apr 22 12:26:50 Hi, this may be a really noob question but I didn't find the answer after some research so : Apr 22 12:27:00 what "?=" means in .conf files ? Apr 22 12:28:27 I undestand this is like ifndef => var = " .. ", but i'm not sure, if there is multiple value like (#MACHINE ?= ... #MACHINE ?= ... ) the only first one will be set ? is it correct ? Apr 22 12:37:10 yes Apr 22 12:39:05 thanks ;) Apr 22 12:40:19 And the difference between '?=' and '??=' ? Apr 22 12:40:24 if I want a file to be added to /etc/, and I am appending the busybox recipe, should my layer include etc or should I specify etc in a recipe? Apr 22 12:41:00 ie meta-JFD-BUSYBOX/recipes-core/busybox/busybox/foo.conf or should it be busybox/etc/foo.conf? Apr 22 12:44:44 i guess I can add a section do_install() { and mod it there Apr 22 13:16:01 I've created my own layer for poky, with bitbake I get a sdcard image which contains my software. When people are building an image using my layer how can they easily add wireless keys into wpa_supplicant.conf? One option is to just boot from the sd card and use vi from the resultant running operating system. However I wondered if there was a way to include something in build/conf/local.conf that could include extra wireless keys at bitbake run time? Apr 22 13:23:44 you can write a recipe to do that, yes Apr 22 13:35:31 rburton, I didn't know you can write recipe's in build/*? Apr 22 13:38:19 Pelalil: they can write a recipe in their own layer while also using your layer Apr 22 13:38:27 Pelalil: I'm in the process of learning yocto, so my comments might be fscked up Apr 22 13:39:02 but you can append a layer and I'm in the process of appending install routine for adding a new file Apr 22 13:39:32 i imagine you could do something similar to append your keys Apr 22 13:49:23 Pelalil: here is the gist with my work. notes5 shows how I am appending to busybox to add a new file to the target file system Apr 22 13:49:27 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33 Apr 22 13:50:06 sadly it looks like the right approach, but I get an error during the bitbake. Apr 22 13:50:18 | install: cannot stat 'udhcpd.eth1.conf': No such file or directory Apr 22 13:50:54 I'm guessing I need to add a prefix for where to find the file similar to how I am doiing the destination. Apr 22 13:52:54 hello everybody Apr 22 13:53:00 helloo Apr 22 13:53:17 I have a soft that #include some kernel headers, but it seems not to find it at build time Apr 22 13:53:33 do I need to specify something special in the recipe to get it to work ? Apr 22 13:57:07 I've got a package which provides a .py file, which is added to sysroot-destdir and the genericx86-64 sysroot. If I add this package to IMAGE_INSTALL of a core-image with MACHINE=genericx86-64, the .py file fails to be added to the rootfs. Is this weird or am I missing something Apr 22 13:58:51 karobar: share the recipe? Apr 22 13:59:05 karobar: for a file to be in the image it needs to be in a package, not in the sysroot Apr 22 13:59:25 hmm. I have a suffix problem with my append. Apr 22 14:00:42 I get an error where I can't find a file using ${B}/foo.conf which expands to .../version-r0/.. but my file is located in build dir in ..../version/... no r0 suffix Apr 22 14:03:32 the python_2.7.9.bb recipe (from jethro) adds numbers.py to the sysroot-destdir but not to the rootfs. Apr 22 14:06:57 hmm this r0 suffix is weird Apr 22 14:12:24 i have a top layer dir named oe-yocto-2.0 which I think is provided by our vendor Apr 22 14:12:40 in there I find a streamsdk_overrides.cfg Apr 22 14:12:48 which pertains to busybox Apr 22 14:13:19 i wonder if that is where they are adding this -r suffix Apr 22 14:24:30 hmm. i have tried to add ${S}/myfile and ${B}/myfile as the source of a file during install step Apr 22 14:24:39 neither works. Apr 22 14:25:41 do I need to do bitbake -e busybox | less and simply grep for a variable which expands to the proper dir in order to find my prefix variable? Apr 22 14:26:06 $S sounded like source and my file is being put in the top level src dir. Apr 22 14:27:52 davis: you want ${WORKDIR} Apr 22 14:28:12 WORKDIR="/home/davis/progs/tiotop/stream/unpack/packages/src/build/.build-yocto/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0" Apr 22 14:28:17 SRC_URI stuff isn't put into $S, one of the entries of SRC_URI *is* $S Apr 22 14:28:17 yes indeed Apr 22 14:28:54 neverpanic: many thanks. +1 for your good karma for the day. Apr 22 14:46:36 neverpanic: hmm. that somewhat worked Apr 22 14:47:10 the build did not fail, but I get a error message saying QA issue. files were installed but not shipped in any package Apr 22 14:47:18 it list my new config file Apr 22 14:48:19 in my busybox append, i said file://foo.conf Apr 22 14:48:32 is this because I did Apr 22 14:48:41 install -m 0644 ${WORKDIR}/udhcpd.eth1.conf ${D}/${etcdir}/udhcpd.eth1.conf Apr 22 14:49:00 and the .conf file is in a dir other than etc? Apr 22 14:50:45 What's $etcdir? Apr 22 14:51:13 i thought etcdir would be the equiv of bindir Apr 22 14:51:22 ive seen bindir in some examples Apr 22 14:51:31 well, then maybe you should verify your assumptions rather than guessing? Apr 22 14:51:32 i see where you are going Apr 22 14:51:48 etcdir is probably not in -e output Apr 22 14:56:24 davis: you probably want ${sysconfdir} Apr 22 14:56:53 many thanks billr i'll try that. Apr 22 14:58:25 its worth reading the top half of bitbake.conf if you haven't Apr 22 15:00:02 davis: that message means that your do_install added files on the (pseudo)target filesystem Apr 22 15:00:28 but the yocto code that decides to what package belongs each installed file didn't know who to give that file to Apr 22 15:01:11 please check the FILES variable, Apr 22 15:01:49 you probably need to set FILES_pn-${PV}_append = "/etc/udhcp.eth1.conf" Apr 22 15:01:54 or something like that Apr 22 15:02:10 or is it ${PN}, I never remember... Apr 22 15:03:08 the pn- prefix in overides is pn-[PN] Apr 22 15:03:12 thus the name, pn :) Apr 22 15:03:30 but you'd only use that syntax in a local.conf or similar Apr 22 15:03:49 i tried /etc/ and it worked, i'm trying ${D}/${sysconfdir}/ this time Apr 22 15:04:08 just ${sysconfdir} Apr 22 15:04:31 ${D} is added magically to FILES as otherwise you'd need it on every single line Apr 22 15:05:30 rburton: how do you specify "this file should go in -dev" then (/me is slightly confused here) Apr 22 15:06:07 FILES_${PN}-dev = "/path/to/file" Apr 22 15:06:30 ie ${includedir}/*.h Apr 22 15:10:49 fwiw, https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33 Apr 22 15:10:58 notes5 shows the result Apr 22 15:11:15 that works, if there is a more yocto way to do it, i'm all ears Apr 22 16:12:44 Is there any negative effect if you duplicate something in DISTRO_FEATURES? For example, if opengl is already included in my distro and I add it again by accident, will that cause any problems? I know I can obviously not add it again, but it is just a general question that I have been wondering about. Apr 22 16:30:23 riz__: no Apr 22 16:42:43 rburton: thanks Apr 22 18:09:26 rburton: re ldflags, the internal toolchain doesn't hit QA failures when the buildsystems don't obey our LDFLAGS since we build the internal toolchain with that hash style as its default, but external toolchains don't necessarily do so (and the sourcery one definitely doesn't), so QA failures occur there Apr 22 18:09:27 Noor: ^ Apr 22 18:09:53 rburton: but given supporting external toolchains is an important use case, and obeying ldflags is a clear correctness fix, i think it's appropriate to get those fixes merged Apr 22 18:10:19 as long as they're done well, of course Apr 22 18:10:27 kergoth: thanks Apr 22 18:11:31 rburton: sorry for the initial patch for cups .... It was sent accidently ..... check the V2 and let me know if the fix looks reasonable to you Apr 22 18:39:01 Regarding meta-intel, I would like to know if what I found is a bug or if I am misunderstanding it. I see that in libva there is this dependency: RDEPENDS_${PN}-egl =+ "${PN}-x11" Apr 22 18:39:32 Does this mean that even if x11 is not used there is still an x11 dependecy on libva-egl? Apr 22 18:39:52 guess that depends on what ${PN}-x11 depends on, but it sounds like it Apr 22 18:40:18 The reason I ask is because I cannot build my non x11 package because it says libva depends on libva-x11 Apr 22 18:40:33 I would think this is a bug if I am right Apr 22 18:40:38 Unless I am missing something Apr 22 18:41:20 How can I see was libva-x11 depends on? Apr 22 18:42:08 Nvm. It depends on libx11, so it does Apr 22 18:42:29 Now, who is familiar enough with meta-intel to know whether that is a bug or not? Apr 22 18:42:42 sounds like either that dep needs to be conditional, if it oesn't really require x11, or the recipe needs REQUIRED_DISTRO_FEATURES = "x11", so it can't be built without it Apr 22 18:42:54 i'd say email the list, see the meta-intel README Apr 22 18:43:07 well I believe you should be able to use libva without x11 Apr 22 18:43:11 ok Apr 22 18:49:55 hi Apr 22 18:54:34 ugh Apr 22 18:54:37 | DEBUG: Executing shell function do_configure Apr 22 18:54:37 | /usr/bin/perl: symbol lookup error: /data/ostro-os/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.1/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_xs_handshake Apr 22 18:55:03 Seems like rburton ran into this before here: https://www.yoctoproject.org/irc/%23yocto.2015-07-08.log.html Apr 22 19:27:04 Hmm, wonder why paul implemented subparser groups as a group= argument rather than returning an object to add subparsers to. the latter would be more in line with all the existing grouping mechanisms in argparse Apr 22 19:35:29 I wonder if you could add add_subparsers() to _ArgumentGroup Apr 22 19:36:52 What does a line like this mean: PACKAGECONFIG[x11] = "--enable-x11,--disable-x11" ? Apr 22 19:43:47 riz__: http://www.yoctoproject.org/docs/2.0.1/mega-manual/mega-manual.html#var-PACKAGECONFIG Apr 22 19:48:42 rburton: thanks, so how do you configure it? Is that at runtime? Apr 22 19:49:23 lets say I want to disable x11, where do I put --disable-x11? Apr 22 19:51:31 you ensure the PACKAGECONFIG assignment doesn't mention x11 Apr 22 19:51:52 so if it does by default you can use a bbappend or local.conf to remove it Apr 22 19:52:39 OK. So I guess I was right when I put "PACKAGECONFIG[x11] = "--disable-x11"" in local.conf to override it Apr 22 19:52:40 see the bit about "if you want to change an existing PACKAGECONFIG block" Apr 22 19:52:45 no Apr 22 19:52:49 you need to read the documentation again Apr 22 19:53:25 ahhh ok Apr 22 20:27:46 Ok, tried googling this one to no avail, 'installed-packages.txt' of build history has mis-named packages. For example 'libnl-3-genl_3.2.25-r1_amd64.deb' becomes 'libnl-3-genl_1:3.2.25-r1_amd64.deb' ??? Apr 22 20:28:56 how did the '1:' get in there? Of 1100+ packages listed, about 8 were mis-named. Apr 22 20:35:37 T0mW: looks like epoch? Apr 22 20:35:51 Check the value of PE for those recipes Apr 22 20:45:59 T0mW: as neverpanic says, that's the package epoch, not a misname. it's usually used to correct a versioning mistake. for example, if someone was to set a recipe version to 1.1beta instead of 1.0+1.1beta, then '1.1beta' will sort ahead of '1.1', which would break package upgrades. The only way to fix it is to bump a more important version component, which is the epoch. Apr 22 20:46:09 T0mW: see the debian docs for details, that's where it originated Apr 22 20:46:19 iirc, anyway Apr 22 20:48:52 you know, we've been wrestling with this version number crap since, the 1990s, probably earlier in un*x. Apr 22 20:50:40 Problem is that the contents of 'installed-packages.txt' is useless for identifying the 'installed packages' by filename. Although, it touts itself as doing so by giving a fully qualified names of files and not 'name = value' pairs. Apr 22 20:51:14 IMHO, epochs don't belong in that file. Apr 22 20:52:41 epoch is part of the package/recipe version. Apr 22 20:52:43 Otherwise, if "epochs" are important, add a default epoch (e.g. 'e0') to all recipe default names such as done with 'r0'? Apr 22 20:53:00 again, it's part of the version, not the package/recipe name Apr 22 20:53:24 but it is only visible inside the recipe,not as the "installed package" (package name). Apr 22 20:54:18 I used the following line in local.conf: PACKAGECONFIG_pn-libva-intel-driver = "--disable-x11" Apr 22 20:54:25 and got the following warning: WARNING: QA Issue: libva-intel-driver: invalid PACKAGECONFIG: --disable-x11 [invalid-packageconfig] Apr 22 20:54:27 so, I just 's/[0-9]://;' and hope the perl script doesn't break. Apr 22 20:54:52 Does anyone know what I did wrong? Apr 22 20:54:59 kergoth, just sayin' Apr 22 20:55:01 no idea what you mean by that. again, it's part of the package version, not the name. just as with the rest of the version, it's parto f the version in the package's metadata, not the name Apr 22 20:55:40 so it's accessible from the package's metadata just like all of the rest of its metadata Apr 22 20:56:08 colons are even in the file manifest Apr 22 20:56:10 so no, it's not "only visible inside the recipe" Apr 22 20:56:14 it's in the package Apr 22 20:56:46 oh, so it should just libva? Apr 22 20:56:59 PACKAGECONFIG_pn-libva = "--disable-x11" Apr 22 20:57:56 riz__: that's not how packageconfig is used Apr 22 20:58:14 if PACKAGECONFIG[x11] is available, then you'd add or remove 'x11' from PACKAGECONFIG, not '--disable-x11' Apr 22 20:58:24 PACKAGECONFIG_remove_pn-libva = "x11" Apr 22 20:58:27 trying to write a means of collecting the "changed / added" packages using a perl script. but, it appears that I cannot reliably identify what deb packages have changed via the build history / manifest. We won't distro changes via a deb repository, we spoon-feed the changed packages to the unit in the field. Apr 22 20:58:45 OK, I completely screwed this up. Apr 22 20:58:54 Thanks. Apr 22 20:58:58 T0mW: you do realize all the package info is in buildhistory too, not just image? Apr 22 20:59:25 kergoth, in what,the packages tree? Apr 22 20:59:29 yes Apr 22 21:00:23 I was working from the images branch as in "looky, one file has all the info I need". :( Apr 22 21:01:32 i think that depends on what info you need Apr 22 21:01:40 i can't imagine its possible to satisfy every possible use case Apr 22 21:01:59 what info are you trying to get and what are you using it for? Apr 22 21:03:25 well, the packages branch has all possible, including -dev, -dbg, -staticdev, everything possible. Pretty much useless at identifying what package is in the root image. Apr 22 21:06:05 manifest + install-packages.txt are almost dead-on with the package names, except for the epoch thingy. AFAIK, the epoch is meaningless, exept for a few coders that cannot correct their versioning. Anyway, I'll just ignore the epoch number (remove it) from the package name within the manifest / installed-packages.txt file as it is irrelevant. Apr 22 21:07:53 kergoth, see, 'installed-packages.txt == recipes-installed'. therefore, 'installed-packages.txt != names_of_deb_files' Apr 22 21:08:22 kergoth, fwiw Apr 22 21:08:30 kergoth, TGIF! Apr 22 21:09:44 you keep implying that epoch is recipe only, but that's not the case, the epoch is in the binary package version Apr 22 21:09:53 it's talking about the binary packages, not the upstream *projects* Apr 22 21:09:57 the two are not the same Apr 22 21:10:28 kergoth, right, but it is not in the name of debian package that was installed that contained that binary. Apr 22 21:11:15 it is in the name of the recipe that created the package. But it is not what 'dpkg -i ' uses Apr 22 21:11:59 you don't install via 'dpkg -i libnl_3:3.3.4_r0_amd.deb' Apr 22 21:12:06 right? Apr 22 21:12:29 you do it with 'dpkg -i libnl_3.3.4_r0_amd.deb' Apr 22 21:12:42 you're right that the installed-packages file needs to match up with the filenames, but IMO the epoch belongs in the filename, otherwise it's not reflecting the entire package version Apr 22 21:12:43 that's what I mean by the package name. Apr 22 21:12:59 okay, part of our communications issue is your overuse of the word name Apr 22 21:13:06 the package name is libnl. the version is 3:3.3.4 Apr 22 21:13:10 the *filename* is the .deb Apr 22 21:13:15 but maybe that's just me Apr 22 21:13:30 * kergoth shrugs Apr 22 21:13:35 no, you're correct, sorry. Apr 22 21:13:41 i'd suggest opening a bug in the yocto bug tracking system, there's a clear mismatch Apr 22 21:13:51 kergoth, hey, have a good weekend, eh? Apr 22 21:14:03 likewise **** ENDING LOGGING AT Sat Apr 23 02:59:58 2016