**** BEGIN LOGGING AT Thu May 05 02:59:58 2016
May 05 03:57:56 <khem> challinan: yes core-image-minimal
May 05 04:50:47 * mranostay waves to khem and challinan
May 05 06:49:04 <present> Hi guys
May 05 06:50:09 <present> I can't find the module "quick" that should come from the qtdeclarative recipe. I'm using krogoth. Someone tried arround?
May 05 06:51:11 <present> This recipe brings me the "qml" module but It seems "quick" does not come with it. I'm checking in the sysroot right now.
May 05 08:38:45 <open-nandra> hi, it is possible to BBMASK only non native package (I'm trying to get rid of cairo but BBMASK = "cairo" take into account also native versio)
May 05 08:39:27 <rburton> why do you want to mask cairo?
May 05 09:09:23 <open-nandra> rburton: just want to check if I need it at all (my system don't have any display...)
May 05 09:09:49 <rburton> remove the x11 distro feature and you'll find that it likely won't get built
May 05 09:10:41 <rburton> BBMASK is a *very* aggressive way to see if cairo doesn't get built
May 05 09:10:49 <rburton> especially as being built != in your images
May 05 09:11:21 <open-nandra> rburton: x11 isn't in my distro feature
May 05 09:11:26 <nine_pt> I have a image that require other, I want to remove a package that is marked to be installed (IMAGE_INSTALL += ) from the required recipe. Is this possible?
May 05 09:15:01 <open-nandra> rburton: that's why I'm trying to mask it
May 05 09:19:29 <rburton> open-nandra: bitbake -g will show you dependency graphs
May 05 09:21:51 <open-nandra> rburton: yes I did check that and harfbuzz, pango, cairo something like that
May 05 09:22:08 <open-nandra> rburton: I don't need anything
May 05 09:22:20 <rburton> yeah, other graphics libraries.  so if you really want cairo gone then follow those up to find out what pulls those in.
May 05 09:23:48 <open-nandra> ok so any advice how to mask it in BBMASK without masking -native ?
May 05 09:25:15 <rburton> doubt you can
May 05 09:26:12 <rburton> a trivial bbappend could make the cairo recipe fail to build if you really want to examine it that way, but looking at the dependency chart and seeing what is pulling it in would be a better way
May 05 09:26:51 <open-nandra> ok seems I found it it seems that gvfs pulls it in 'gvfs', 'gtk-icon-utils-native', 'librsvg-native', 'pango-native', 'harfbuzz-native'
May 05 09:27:05 <open-nandra> rburton: ok thanks for help
May 05 09:28:44 <rburton> yeah if you want gvfs then you have the icon support that comes with it
May 05 09:30:30 <open-nandra> I'll try to drop icon support as gvfs is used on device only
May 05 09:30:30 <rburton> well, actually, that's likely coming via the gnome class, which is overkill
May 05 09:30:36 <open-nandra> not sure if ti's possible
May 05 09:30:42 <open-nandra> oh ok
May 05 09:30:46 <rburton> you could change the inherit gnome to inherit gnomebase
May 05 09:30:58 <rburton> and see what happens to the build from a clean sysroot
May 05 09:31:09 <rburton> (this is why i don't like gnome.bbclass)
May 05 09:31:35 <rburton> you do actually use gvfs itself, right?
May 05 09:31:52 <rburton> (the core bits are in gio, part of glib)
May 05 09:32:22 <open-nandra> yes gvfs is used itself
May 05 09:34:27 <rburton> i'd replace gnome with gnomebase, clean your sysroot, rebuild gvfs, run buildhistory-diff to see what changed, and double-check that nothing important was lost, adding stuff back as required.
May 05 09:35:37 <open-nandra> when switch to gnome base I cannot configure gvfs
May 05 09:36:00 <open-nandra> gvfs-1.12.3/configure: line 14366: syntax error near unexpected token `0.35.0'
May 05 09:36:08 <open-nandra> gvfs-1.12.3/configure: line 14366: `IT_PROG_INTLTOOL(0.35.0)'
May 05 09:36:39 <rburton> that would be a missing dependency on intltool-native
May 05 09:37:05 <rburton> (it would have failed without this change at some point)
May 05 09:38:37 <open-nandra> added dependency and it pass
May 05 09:38:41 <open-nandra> also compilation
May 05 09:39:40 <rburton> buildhistory-diff will likely show a lot of dependencies and maintainer scripts have been changed, you'll need to vet them to make sure that they were all redundant
May 05 09:39:51 <rburton> ie gconf scripts are fine to be removed if the package doesn't install any gconf schemas
May 05 09:44:26 <open-nandra> rburton: ok I'll check that
May 05 09:44:32 <open-nandra> tahnks for hints and help
May 05 09:45:45 <open-nandra> thanks for hints and help
May 05 09:57:01 <jackmitch_work> what's the correct way to create a symlink in autotools when using DESTDIR
May 05 09:57:02 <jackmitch_work> if I symlink to $(DESTDIR)$(sysdir)/libsoc.conf then the symlink ends up being wrong as it points to the temporary directory
May 05 09:57:02 <jackmitch_work> if I symlink to $(sysdir)/libsoc.conf then I end up trying to symlink directly into the filesystem
May 05 10:09:26 <jackmitch_work> ok, using relative symlinks seems to be the way
May 05 10:11:41 <jaskij> hello everyone, a question here: why would the /etc/init.d/syslog link be missing? I do have busybox-syslog installed in the image
May 05 10:16:18 <jaskij> it looks to me like an error in my configuration leading to postinst scripts not doing what they should
May 05 10:22:25 <rburton> jaskij: for me i have a syslog.busybox in that package and update-alternatives should be making the symlink to syslog
May 05 10:25:05 <jaskij> rburton *should* being the keyword, I install update-alternatives and what not and it still does not work
May 05 10:25:56 <jaskij> rburton I install the update-alternatives-opkg (I use opkg)
May 05 10:28:26 <jaskij> anyways it seems like I'm missing something fundamental about the yocto/OE workflow if I have to ask such questions here
May 05 10:28:34 <jaskij> like I'm missing some manual or whatnot
May 05 10:29:01 <rburton> jaskij: well 1) does the package contain syslog.busybox
May 05 10:30:58 <jaskij> rburton in buildhistory it show the busybox-syslog in the installed packages, syslog.busybox also exists in /etc/init.d
May 05 10:32:28 <rburton> my pkgdata says that busybox-syslog depends on update-alternatives-opkg and calls update-alternatives --install /etc/init.d/syslog syslog-init /etc/init.d/syslog.busybox 50 on install
May 05 10:32:47 <rburton> which looks right
May 05 10:37:46 <jaskij> mine doesn't
May 05 10:37:57 <jaskij> rburton thanks, gotta look into that
May 05 10:38:26 <rburton> do you have sysvinit in your distro features?
May 05 10:38:46 <jaskij> rburton busybox-init
May 05 10:39:09 <rburton> if not then you don't get the init scripts
May 05 10:39:12 <jaskij> or think so
May 05 10:39:37 <rburton> i explicitly mean 'sysvinit' in DISTRO_FEATURES
May 05 10:40:07 <rburton> if that isn't set then busybox doesn't call update-alternatives for the init script.
May 05 10:40:22 <jaskij> rburton, nope, only those VIRTUAL-RUNTIME stuff
May 05 10:40:37 <rburton> sysvinit is the default, so check using bitbake -e
May 05 10:41:16 <jaskij> rburton, earlier I experimented with systemd and left sysvinit in backfill_considered
May 05 10:41:18 <jaskij> T_T
May 05 10:42:21 <jaskij> rburton that would explain everything then... busybox-init still needs the sysvinit distro feature, yes?
May 05 10:43:02 <jaskij> rburton should be an hour or two untill the image builds
May 05 11:36:43 <rburton> jaskij: i've never used busybox-init, does that expect sysv style symlinks?
May 05 12:36:46 <jaskij> rburton, busybox-init is a dropin for sysvinit
May 05 12:36:57 <jaskij> rburton works properly now
May 05 13:19:06 <jaskij> is there any recipe which allows detecting the ethernet cable plug?
May 05 13:24:51 <jaskij> or rather reacting to it?
May 05 13:45:14 <riz__> I was watching a yocto optimization lexture where the lecturer used dirsize.py to see the size of the various component in the image. I am confused which directory I run the python script in. Does anyone know?
May 05 13:50:50 <Crofton|work> riz__, have you looked at the buildhistory class?
May 05 13:51:22 <Crofton|work> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-build-output-quality
May 05 13:53:18 <riz__> Crofton|work: No, but now I will :)
May 05 13:53:54 <riz__> I have built up a heavy image just to get it to work and now I want a lite version
May 05 13:53:57 <Crofton|work> where is the lecture you are watching?
May 05 13:54:03 <Crofton|work> heh
May 05 13:54:13 <Crofton|work> I am writing a blog post sort of about that
May 05 13:54:22 <riz__> https://www.youtube.com/watch?v=WHLvI8j31vk
May 05 13:54:33 <riz__> From intel
May 05 13:54:53 <riz__> Crofton|work: Great. Where can I look for it?
May 05 13:55:12 <Crofton|work> not finished
May 05 13:55:35 <riz__> I meant when it is. Do you have a blog you will put it on or some other site?
May 05 13:57:07 <Crofton|work> I'll try and remember to post it here
May 05 13:57:46 <riz__> OK, great
May 05 14:01:01 <Crofton|work> it is pretty focused on a specific case
May 05 14:02:18 <riz__> Yours or the youtube lecture?
May 05 14:02:44 <Crofton|work> mine
May 05 14:02:55 <riz__> oh ok
May 05 14:02:57 <riz__> Crofton|work: Also, I don't ee where build history gives the sizes of each installed package or library..
May 05 14:03:10 <riz__> see*
May 05 14:04:05 <Crofton|work> buildhistory/images/foo/glibc/base-dev-image/installed-packages.txt
May 05 14:04:31 <Crofton|work> er -sizes.txt
May 05 14:04:37 <Crofton|work> 10179   KiB systemd
May 05 14:04:37 <Crofton|work> 6349    KiB kernel-image-4.5.0-yocto-standard-tritium
May 05 14:04:37 <Crofton|work> 5348    KiB udev-hwdb
May 05 14:04:37 <Crofton|work> 2872    KiB systemd-extra-utils
May 05 14:06:11 <rburton> jaskij: connman is in oe-core and does that
May 05 14:07:39 <riz__> oh ok
May 05 14:12:28 <riz__> Has anyone noticed any odd bitbake build behavior such as bitbaking one time with an error, then just bitbaking the same image with 0 changes and it working?
May 05 14:12:38 <riz__> It has happened to me a couple times
May 05 14:13:01 <riz__> The errors we failed oe-runmake due to package dpeendencies
May 05 14:13:14 <riz__> But then they just fix themselves I guess when I run it a second time
May 05 14:14:28 <rburton> riz__: so what happens if that you say bitbake A
May 05 14:14:38 <rburton> A depends on B and C
May 05 14:14:58 <rburton> B and C depend on D but only C actually has a DEPENDS=C
May 05 14:15:03 <rburton> erm, DEPENDS=D
May 05 14:15:23 <rburton> so its quite possible for B to configure before D has built via its dependency though C
May 05 14:15:26 <rburton> B fails
May 05 14:15:30 <riz__> Ahhh
May 05 14:15:33 <riz__> makes sense
May 05 14:15:37 <rburton> the rest of the build finishes, including building D
May 05 14:15:40 <rburton> rerun and it works
May 05 14:15:54 <riz__> Good to know. I was happy it fixed itself but was worried there was an underlying issue that could pop up in release
May 05 14:15:59 <rburton> when you find this happening, the easy way to verify deps is to wipe-sysroot ; bitbake the-recipe-that-failed
May 05 14:16:15 <rburton> erm, clean the recipe first of course
May 05 14:16:16 <riz__> OK. great
May 05 14:16:26 <riz__> Thanks!
May 05 14:16:36 <rburton> wipe-sysroot will empty the sysroot so you only have the deps it actually states, and missing ones will cause a build failure
May 05 14:17:16 <rburton> there's a script in oe-core/scripts to do builds in various ways to exercise the depends, make sure that there's no magically detected depends
May 05 14:20:15 <riz__> ok cool
May 05 14:21:37 <rburton> kergoth: your v2 gcc patch works :)
May 05 14:58:25 <jaskij> rburton conman works, although if I unplug the cable it still lists it in ifconfig as UP
May 05 14:58:29 <jaskij> *connman
May 05 14:59:31 <rburton> likely the kernel didn't report the unplug
May 05 14:59:34 <rburton> (ie works for me)
May 05 14:59:57 <jaskij> it is deconfigured and I get a message about the unplug on debug console
May 05 15:00:06 <jaskij> oh well, will care later
May 05 15:07:21 <jaskij> rburton I don't know what's going on, ifconfig reports up but /var/log/messages shows that connman properly detected the down T_T
May 05 15:09:32 <jaskij> blame me, probably a collision with ifplugd in busybox
May 05 16:51:56 <mortderire> folks
May 05 16:52:08 <mortderire> needs an example reciepe that pulls down more than one tarball
May 05 16:52:59 <mortderire> actually never mind
May 05 17:12:01 <jaskij> is there really no alternative to connman?
May 05 17:12:55 <kergoth> not sure what you mean by that. there are a number of options depending on your requirements and what ui you're using
May 05 17:17:02 <jaskij> kergoth: less permanent storage used
May 05 17:17:51 <jaskij> kergoth: and support for plugging/unplugging ethernet cable... like in the old ubuntu joke I just failed to configure busybox' ifplugd
May 05 17:43:00 <riz__> I am noticing that packages which I have not included in IMAGE_INSTALL_append are still being built. One example is in meta-qt. qtwebkit always gets built even when I do not include it. Anyone know why?
May 05 17:48:25 <jaskij> riz__: https://github.com/scottellis/oe-deptools and check reverse dependencies
May 05 17:49:49 <riz__> jaskij: Thanks
May 05 17:50:46 <riz__> jaskij: I would need buildhistory on for that, correct?
May 05 18:35:36 <kergoth> khem: just noticed that your mkelfimage patch changes the compile of the target tools to use CC rather than HOST_CC, but they still use HOST_CFLAGS, which end up including BUILD_CPPFLAGS. If HOST_ is BUILD_ for this recipe, then we probably should be using CFLAGS, not HOST_CFLAGS, for CC, right?
May 05 18:35:52 <kergoth> .. and then the next patch adds CFLAGS to HOST_CFLAGS
May 05 18:35:58 <kergoth> so HOST_CFLAGS now has both BUILD and TARGET stuff
May 05 18:36:05 <kergoth> what the hell, people
May 05 18:36:08 <kergoth> the two are not the same
May 05 18:37:00 <kergoth> oh, the libz one is for native only, what a mess
May 05 18:49:40 <kergoth> k, think i got that sorted
May 05 18:54:43 <kergoth> bluelightning: found a bug in devtool update-recipe. if S is a subdir of the upstream git repository, the commit will have paths relative to the root, not relative to S, so teh patch it generates won't apply
May 05 18:55:36 <bluelightning> kergoth: hmm yes we should fix that... would you mind filing a bug?
May 05 18:55:41 <kergoth> will do
May 05 18:55:52 <kergoth> we'll probably want to warn/error if the commit touches paths outside of S
May 05 18:56:01 <kergoth> or, we could alter the SRC_URI to apply it at the root
May 05 18:57:29 <bluelightning> yeah, I guess that could happen too
May 05 18:58:38 <kergoth> of course, should probably warn for ochanges outside of S anyway. even if we apply it at toplevel, any changes outside of S won't actually *do* anything to our build anyway..
May 05 18:58:41 <kergoth> heh
May 05 18:58:46 <kergoth> bluelightning: how's the little one?
May 05 19:00:01 <bluelightning> kergoth: she's doing well thanks... crawling everywhere and getting into things now :D
May 05 19:00:08 <kergoth> nice :)
May 05 19:00:12 <bluelightning> how about yours?
May 05 19:00:17 <kergoth> much more fun when they get more active and aware
May 05 19:01:09 <kergoth> he's walking all over, starting to pick up more words, more concepts, making small two word sentences. 'dada, this? *hands me the thing*'
May 05 19:01:10 <kergoth> :)
May 05 19:01:27 <bluelightning> :D
May 05 19:01:48 <kergoth> so cool watching them learn
May 05 19:02:14 <bluelightning> Maria's not quite at that level yet, she's just making sounds... "dadadada mamamamam" etc. cute though :)
May 05 19:02:24 * kergoth nods
May 05 19:02:52 <kergoth> i find it interesting how much kids vary in their development, they really have to go at their own pace. matthew didn't really get walking until like 15 months or so, but some are going wild at 9
May 05 19:03:02 <kergoth> can't push it, have to do things when they're ready, not before
May 05 19:03:28 <kergoth> he was pretty stalled on words for quite a while, just mama and dada, and then in the past week or two he's added like 10 more
May 05 19:16:17 <khem> kergoth: remind me of the patch
May 05 19:18:33 <khem> kergoth: kids bootstrap is unique for each kid :) the key is not to worry but just enjoy it :)
May 05 19:18:39 <kergoth> indeed
May 05 19:18:46 <kergoth> meta/recipes-devtools/mkelfimage/mkelfimage/cross-compile.patch
May 05 19:19:01 <kergoth> i have a patch to sort it out, so don't worry about it
May 05 19:19:04 <khem> its not all u-boot or UEFI you know
May 05 19:20:44 <kergoth>  anyone else getting systemtap failures with the internal default toolchain? specifically oe-core-only, nodistro
May 05 19:20:55 <kergoth> i.e. stap-tapset-utrace.o:(.rodata._ZTI28utrace_var_expanding_visitor[_ZTI28utrace_var_expanding_visitor]+0x8): undefined reference to `typeinfo for var_expanding_visitor'
May 05 19:21:53 <khem> yeah using CFLAGS is the right thing there
May 05 19:23:18 <khem> kergoth: gcc 5 ?
May 05 19:23:19 <kergoth> k, thought so, just figured i'd run it by you real quick
May 05 19:23:20 <kergoth> thanks
May 05 19:23:31 <kergoth> yeah, i think it's defaulting to 5.3 right now
May 05 19:23:39 <khem> which arch ?
May 05 19:23:40 * kergoth double checks
May 05 19:24:45 <kergoth> yeah, 5.3
May 05 19:24:54 <kergoth> default, qemux86
May 05 19:27:03 <khem> kergoth: I only have gcc-6 builds lying around
May 05 19:27:10 <khem> it seems to be building there
May 05 19:27:14 <kergoth> k, np, thanks
May 05 19:27:26 * kergoth 'll check errors.yp and the autobuilder
May 05 19:32:46 <khem> kergoth: just rebuilt is and it built ok again
May 05 19:36:08 <kergoth> k, thanks
May 05 22:01:53 <gtristan> Hi, I'm wondering how I can apply this patch http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120614.html in a layer...
May 05 22:02:56 <gtristan> can I, say, declare a .bbappend and redefine do_configure() in it, overriding completely the do_configure here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/glibc/cross-localedef-native_2.22.bb?h=jethro#n52 ?
May 05 22:03:38 <kergoth> yes, that works fine. a bbappend is like concatenating to the recipe, it can almost always override what hte recipe does
May 05 22:04:21 <gtristan> kergoth, so I could have a recipe with multiple do_configure() declared... and the last one wins basically ?
May 05 22:04:27 <gtristan> Thanks :D
May 05 22:04:39 <kergoth> bitabke variables are a key/value store
May 05 22:04:46 <kergoth> as soon as you define a second instance of the same name, it overrides any existing
May 05 22:16:02 <kergoth> ah, there's the webkitgtk failure i keep hitting -- http://errors.yoctoproject.org/Errors/Details/60469/
May 05 22:17:12 <gtristan> kergoth, so in this case... I can call autotools_do_configure() directly, this would be the same as removing the cross-localedef-native do_configure() completely yes ?
May 05 22:17:48 <kergoth> should work, yeah
May 05 22:47:23 <gtristan> When creating a .bbappend file, a '%' in the filename is a wildcard ?
May 05 22:47:28 <kergoth> yes
May 05 22:47:34 <gtristan> great
**** ENDING LOGGING AT Fri May 06 02:59:58 2016