**** BEGIN LOGGING AT Fri Apr 08 02:59:58 2016
Apr 08 03:16:29 <[R]> am i going crazy... i can't find where core-image is defined
Apr 08 03:19:07 <[R]> oh wait, there it is
Apr 08 03:59:59 <jrawson> Crazy.
Apr 08 04:00:03 <jrawson> ;)
Apr 08 06:40:43 <ionte_> hi! so i suddenly got this "operation not permitted" error while building a yocto distro. i have run the exact same build on two other computers without any problems. i use debian, and the other computers had debian and ubuntu.
Apr 08 06:41:00 <ionte_> i've tried to delete the build directory and start fresh, but same thing
Apr 08 06:41:10 <ionte_> here's the full error: https://bpaste.net/show/c48482f93572
Apr 08 06:43:38 <ionte_> it's the linux-libc-headers recipe that fails
Apr 08 07:22:12 <fredcadete_> ionte_: that doesn't ring a bell. Maybe you could try editing poky/meta/classes/package.bbclass and activate the existing traces in the function fix_perms (they are commented out)
Apr 08 07:22:26 <ionte_> strange! i did a total clean, cloned poky etc from git again. same error. i then looked in fix_perms function in meta/classes/package.bbclass. there was to disabled bbnotes so i enabled them and ran again. seems that it tries to chmod "/usr" ?|
Apr 08 07:22:45 <fredcadete_> ionte_: haha that was fast
Apr 08 07:22:52 <ionte_> NOTE: Fixup Perms: chmod 0755 /usr
Apr 08 07:22:57 <ionte_> fredcadete_: haha :)
Apr 08 07:23:11 <ionte_> NOTE: Fixup Perms: lchown 0:0 /usr
Apr 08 07:23:51 <fredcadete_> compare with a working build?
Apr 08 07:24:08 <ionte_> fredcadete_: hm, ok.. will try
Apr 08 07:24:18 <fredcadete_> well, it's nearly sure that's the problem
Apr 08 07:29:33 <ionte_> fredcadete_: hm, same thing on a working build. i guess /usr means the root of the image...
Apr 08 07:31:54 <ionte_> hm, how is this supposed to work anyway?
Apr 08 07:31:57 <fredcadete_> ionte_: fun fact: that bbnote is not printing the full path that's being chmodded
Apr 08 07:32:10 <ionte_> fredcadete_: yep
Apr 08 07:32:13 <fredcadete_> it skips out the base
Apr 08 07:32:50 <ionte_> i've never thought of this before, but yocto changes owner of file to root (chown 0:0 ..../usr) and that is not allowed
Apr 08 07:33:12 <ionte_> how is that supposed to work? it obviously does on my other computers, but i can't see how?
Apr 08 07:34:46 <ionte_> this seems related: http://stackoverflow.com/questions/35800095/yocto-bitbake-build-attempts-to-chown-files-to-root-and-fails
Apr 08 07:34:54 <ionte_> pseudo is disabled in my build as well
Apr 08 07:38:33 <fredcadete_> ionte_: ok, you're far ahead of what I know now
Apr 08 07:38:40 <fredcadete_> I drop the ball...
Apr 08 07:39:05 <ionte_> ... but it's disabled in working build as well :(
Apr 08 07:57:59 <mckoan> good morning
Apr 08 08:04:58 <present> Hello
Apr 08 08:05:09 <present> Is there a chan for Toaster?
Apr 08 08:06:02 <present> I love the idea of using a graphical interface but that Toaster drives me far too much crazy in Interactive mode.
Apr 08 08:39:47 <joshuagl> I believe this is the correct channel for Toaster
Apr 08 09:18:32 <present> joshuagl: alright
Apr 08 09:19:52 <joshuagl> you can always use toaster for analysis and the command line for driving builds :-)
Apr 08 09:20:16 <present> joshuagl: Yes this is what I was thinking also.
Apr 08 09:43:33 <ionte_> seems my problem (https://bpaste.net/show/c48482f93572) may be related to pseudo anyway: i get this error when building: ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): igno
Apr 08 09:44:02 <ionte_> it doesn't stop though. it continues building until the error on bpaste...
Apr 08 12:42:46 <ionte_> anyone around who knows about pseudo and how it's used in yocto build? still having problem with LD_PRELOAD...
Apr 08 13:01:37 <rburton> probably best to mail the list
Apr 08 13:01:50 <rburton> pseudo is a fakeroot to intimately tied to LD_PRELOAD
Apr 08 13:18:05 <neverpanic> Or ask your question?
Apr 08 14:27:14 <mbroadst> is it best practice to submit new recipes upstream? or will I have to become a maintainer of those recipes? :)
Apr 08 14:28:24 <mbroadst> ideally I'd like to have more eyes on the recipes I'm writing that don't already exist (apache qpid, rethinkdb, zfs, etc)
Apr 08 14:34:49 <rburton> yes, yes
Apr 08 14:35:08 <rburton> abandon them if you want, but obviously if you wrote the recipe then you'll be using it
Apr 08 14:35:21 <rburton> so everyone is a winner if you then maintain the recipe in meta-whatever
Apr 08 14:36:05 <mbroadst> well I guess I was wondering why things like `meta-browser` or `meta-qt5` aren't just pushed up into poky/oe-core
Apr 08 14:36:20 <rburton> because oe-core is *core*
Apr 08 14:36:28 <rburton> qt5 isn't something everyone needs
Apr 08 14:36:32 <rburton> ditto, chromium
Apr 08 14:36:44 <rburton> back in the old days there was one OE repository with several thousand recipes
Apr 08 14:36:48 <rburton> it never built
Apr 08 14:37:14 <mbroadst> but `meta-gnome` certainly isn't core right?
Apr 08 14:37:21 <mbroadst> yet it exists there
Apr 08 14:37:31 <rburton> have a look and you;ll see that its a tiny bit of gnome
Apr 08 14:37:41 <rburton> and there are pieces of oe-core that exist to exercise other pieces
Apr 08 14:37:58 <rburton> well its recipes-gnome to be accurate
Apr 08 14:38:10 <rburton> and its mostly there to support webkit, which was added to core
Apr 08 14:38:11 <mbroadst> yeah sorry recipes not meta
Apr 08 14:38:30 <rburton> the reference UI in oe-core is gtk+ based which is why that's in there
Apr 08 14:38:33 <mbroadst> so webkit core, chromium not core, gtk+ core, qt5 not core
Apr 08 14:38:35 <mbroadst> :)
Apr 08 14:38:59 <JaMa> but there is also meta-gnome with many additional recipes for gnome
Apr 08 14:39:08 <mbroadst> okay I gotcha, I'll see if I can find a place to pop these in then
Apr 08 14:39:12 <JaMa> so gtk+ is core, but gnome isn't
Apr 08 14:39:30 <rburton> i wonder if anyone has tried gnome3 now gir support has landed
Apr 08 14:41:33 <mbroadst> so perhaps zfs should be committed to git://git.openembedded.org/meta-openembedded 's meta-filesystems?
Apr 08 14:45:01 <rburton> yes
Apr 08 14:45:15 <rburton> exactly the perfect place
Apr 08 14:50:51 <mbroadst> rburton: cheers
Apr 08 15:11:40 <vladb> Hi, I have a question regarding fetching from a huge git repository: I'd like to only fetch a small subdirectory from the master branch of a remote git repo. I found that the command "git archive --remote=<remote_URL> <branch>:<path> | tar xvf -" works great, but I'm wondering what's the best way to use in a recipe.
Apr 08 15:13:17 <boucman_work> vladb: I don't know of any supported way to do that... you might do something with do_fetch_prepend, but do_fetch is a bit special, so I have no idea if it would actually work...
Apr 08 15:13:39 <boucman_work> afaik there is no easy way to add a new fetcher to bitbake...
Apr 08 15:13:54 <rburton> adding a new fetcher is "easy"
Apr 08 15:14:07 <rburton> you just write your fetcher and put it in bitbake/lib/bb/fetch2/
Apr 08 15:14:23 <boucman_work> oh ? I never looked into that... my guess is you can't do it in a layer, though :P
Apr 08 15:14:25 <vladb> Is it possible to add a new fetcher without having to fork poky? say in my layer?
Apr 08 15:14:26 <rburton> for this you could just write do_fetch()
Apr 08 15:14:31 <boucman_work> (that would be an interesting feature)
Apr 08 15:14:41 <rburton> no, you cant put fetchers in layers
Apr 08 15:14:54 <rburton> but you can write your own do_fetch() to fetch however you want
Apr 08 15:14:57 <boucman_work> vladb: you'd need to fork bitbake, not poky
Apr 08 15:15:22 <vladb> Yes, thanks for the information. Do you think such a feature would be accepted upstream?
Apr 08 15:15:22 <rburton> can we put "poky is an example" in the topic?
Apr 08 15:16:16 <rburton> wasn't aware git-archive could fetch subset tarballs like that
Apr 08 15:16:23 <rburton> i wonder if its actually nice on the server, or really hard
Apr 08 15:16:40 <boucman_work> rburton: tbh it took me 6month of intense yocto work to understand all the key concepts, and most users don't have that luxury
Apr 08 15:17:11 <boucman_work> I don't know how to improve that situation, but I've noticed it's a real problem "in the field"
Apr 08 15:17:18 <vladb> I can tell you it's much faster than fetching the whole think. I think it's quick on the server since <branch>:<path> actually describes a tree object which is already a thing in the git database.
Apr 08 15:17:24 <vladb> *thing
Apr 08 15:17:33 <boucman_work> that and BSP providers not understanding how to work with yocto and cloning instead of writing a clean meta
Apr 08 15:17:51 <boucman_work> vladb: I don't doubt it :P
Apr 08 15:18:26 <boucman_work> vladb: your best chance is probably to do what rburton suggested : write a do_fetch yourself...
Apr 08 15:18:36 <rburton> vladb: well a do_fetch() is trivial assuming you decide to ignore source mirrors and proxies
Apr 08 15:18:46 <boucman_work> no idea how the sstate would deal with that, but it might work
Apr 08 15:19:06 <rburton> fetch isn't ssatted
Apr 08 15:19:09 <rburton> sstate'd
Apr 08 15:19:45 <kergoth> worth noting that you can create a custom fetcher in a layer and inject it to make it available without forking bitbake. i've done it before, and that's how the npm fetcher was done before it got merged
Apr 08 15:19:46 * kergoth yawns
Apr 08 15:20:02 <rburton> oh there you go, i'm wrong :)
Apr 08 15:20:33 <kergoth> for reference: https://github.com/imyller/bitbake-npm
Apr 08 15:20:50 <vladb> kergoth: thanks
Apr 08 15:20:52 <boucman_work> kergoth: awesome :)
Apr 08 15:21:10 <kergoth> better that making an entirely custom do_fetch, since you can get the fetcher working nicely, then pursue pushing it upstream to bitbake later
Apr 08 15:21:13 <kergoth> s/that/than/
Apr 08 15:21:33 <mbroadst> can you add a `.target` file when using SYSTEMD_SERVICE_${PN}-whatever ?
Apr 08 15:22:47 <boucman_work> a shallow-clone git fetcher would significantly improve the kernel-fetching time :)
Apr 08 15:24:48 <rburton> only if you only ever fetch it once
Apr 08 15:28:22 <boucman_work> rburton: arguably, that's what you do when building yocto (i.e not kernel dev)
Apr 08 15:29:34 <rburton> arguably you should have an internal source mirror :)
Apr 08 15:29:58 <boucman_work> hehe
Apr 08 15:53:20 <malinus> Is it usually okay to contact layer maintainers directly by mail, or is it frowned upon?
Apr 08 15:56:55 <JaMa> malinus: using corresponding ML is preferred
Apr 08 15:56:59 <kergoth> malinus: much better to go through appropriate channels. the readme should indicate the communications / report mechanism
Apr 08 15:58:34 <malinus> they removed the "ISSUE" from their github repo. And they say to contact yocto@yoctoproject.org on everything, I'm sceptical about following that advice. https://github.com/akuster/meta-odroid/blob/jethro-next/README
Apr 08 15:59:29 <malinus> "Send pull requests, patches, comments or questions to yocto@yoctoproject.org" ....
Apr 08 15:59:51 <malinus> does that sound right?
Apr 08 16:01:04 <kergoth> i'd send an email to the list and cc: akuster
Apr 08 16:01:49 <malinus> Okay, thanks for the advice.
Apr 08 16:03:43 <kergoth> oops, just noticed recipetool-newappend isn't mapping virtuals
Apr 08 16:03:46 <kergoth> ERROR: Unable to determine layer directory containing virtual:nativesdk:/scratch/yocto-new/crosssdk-suffix/poky/meta/recipes-devtools/gcc/libgcc_5.3.bb
Apr 08 16:12:54 <fredcadete_> hello
Apr 08 16:13:39 <fredcadete_> does anyone know if there is some place where I can browse the build dir of a tested yocto build (with meta-qt5 preferrably)
Apr 08 16:14:09 <fredcadete_> I am having some issues here and I'd like to sanity check against a "known good" build
Apr 08 19:05:44 <kergoth> Keyboard Interrupt, closing down...
Apr 08 19:05:45 <kergoth> WARNING: Timeout while attempting to communicate with bitbake server                             WARNING: Timeout while attempting to communicate with bitbake server
Apr 08 19:05:54 <kergoth> then had to pkill bitbake again
Apr 08 19:06:00 <kergoth> anyone else still running into this at times?
Apr 08 19:19:25 * paulg tries to avoid ^C as much as possible
Apr 08 19:22:05 <kergoth> i try, but fail miserably
Apr 08 20:04:09 <mbroadst> hey I've got a cmake project that's outputting its files to /usr/lib64 and the cmake.bbclass isn't picking them up automatically
Apr 08 20:04:15 <mbroadst> that should be a sign that something's off right? :)
Apr 08 20:05:36 <neverpanic> /usr/lib64 is the cmake default in some environments
Apr 08 20:05:43 <neverpanic> chances are somebody hardcoded a path?
Apr 08 20:06:03 <mbroadst> I thought maybe, but I grepped their sources and lib64 doesn't show up at all outside of a single test file
Apr 08 20:08:03 <mbroadst> ah wait maybe this is it..
Apr 08 20:08:23 <mbroadst> https://github.com/apache/qpid-proton/blob/master/CMakeLists.txt#L92
Apr 08 20:17:00 <mbroadst> additionally, shouldn't inheriting from pkgconfig pick up generated pkgconfig files?
Apr 08 20:17:46 <mbroadst> this recipe inherits from cmake and pkgconfig, but neither the generated libraries nor the pkgconfig are automatically picked up and shipped with the recipe
Apr 08 20:18:05 <mbroadst> I got rid of the lib64, they're all sitting in /usr/lib now and I'm getting QA warnings that they aren't packaged
Apr 08 20:20:35 <mbroadst> well thats bizarre.. QA says that, but the generated deb contains the libraries
Apr 08 20:20:38 * mbroadst scratches head
Apr 08 20:24:39 <neverpanic> With or without version numbers?
Apr 08 20:25:00 <mbroadst> without, thats a good point
Apr 08 20:25:13 <mbroadst> so I should just delete those in a do_install_prepend or something?
Apr 08 20:25:35 <neverpanic> those without usually go into the -dev package
Apr 08 20:25:51 <kergoth> mbroadst: all the pkgconfig class does is adds pkgconfig-native to the deps so pkg-config is available to run. it won't ship anything, that's up to do_install
Apr 08 20:26:09 <mbroadst> I see
Apr 08 20:26:42 <mbroadst> is it best practice to delete files in do_install or rather patch the makefile to not install things I'm not interested in?
Apr 08 20:28:32 <mbroadst> kergoth: do_install, or just adding to FILES_${PN}?
Apr 08 20:30:07 <neverpanic> do_install installs, FILES_${PN} only affects packaging
Apr 08 20:33:27 <mbroadst> hm I guess I don't grok the difference there
Apr 08 20:34:38 <mbroadst> aren't I ending up with a pkgconfig file in /usr/lib/pkgconfig (per QA warning) because it installed?
Apr 08 20:39:55 <kergoth> if you're getting an installed but unpackaged warning, then yes, you'd have to add it to FILES, but that should be in teh default files variables
Apr 08 20:41:11 <mbroadst> kergoth: okay just to be crystal here, since I'm getting an installed but unpackaged for these pkgconfig files that means they are in fact being installed (no need for do_install extra steps)
Apr 08 20:41:48 <neverpanic> Yes
Apr 08 20:42:02 <neverpanic> Normally the default for FILES_${PN}-dev would match pkgconfig files
Apr 08 20:42:32 <mbroadst> I wonder why not in this case then. its just files that look like: /usr/lib/pkgconfig/libqpid-proton.pc
Apr 08 20:42:37 <neverpanic> See http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n300
Apr 08 20:42:56 <neverpanic> It has ${libdir}/pkgconfig, so would match that, unless your value of ${libdir} differs?
Apr 08 20:43:18 <neverpanic> Check with bitbake -e yourrecipe | grep -E '^FILES_'
Apr 08 20:43:33 <mbroadst> oh man, bit by the lack of a += again
Apr 08 20:43:40 <mbroadst> I've got: FILES_${PN}-dev = " \
Apr 08 20:44:20 <neverpanic> bitbake -e is immensly helpful to debug these issues; the comments above the line would even have told you that you have overwritten the variable
Apr 08 20:45:49 <mbroadst> yeah for sure, trying to fill my brain with these tools here - it's really just my second day with the system
Apr 08 20:45:56 <mbroadst> I really appreciate your help
Apr 08 21:26:28 <mbroadst> hm seems this recipe isn't picking up CMAKE_MODULE_PATH correctly
**** ENDING LOGGING AT Sat Apr 09 02:59:58 2016