**** BEGIN LOGGING AT Wed Jul 31 02:59:58 2013
Jul 31 03:59:53 <lpapp> can I include .inc files into a forked recipe?
Jul 31 04:00:08 <lpapp> so that I do not need to fork the .inc file, too.
Jul 31 04:23:23 <nerdboy> sure, but you'll need more path
Jul 31 04:25:04 <nerdboy> maybe not, actually...
Jul 31 04:25:53 <nerdboy> is it a .bb or .bbappend recipe?
Jul 31 04:27:24 <nerdboy> a bbappend should find the original include, but if it's a separate recipe then you probably need something like "include path/to/include.inc"
Jul 31 04:28:57 <nerdboy> eg, one of the minimal pi images does this "include recipes-core/images/core-image-minimal.bb"
Jul 31 06:47:36 <mckoan> good morning
Jul 31 06:47:52 <lpapp> that sounds weird if -b drop the dependency checking.
Jul 31 06:48:11 <lpapp> this means I need to submit a feature request then.
Jul 31 06:49:26 <lpapp> or is it already possible to pass a preferred version to bitbake through the command, and not config file?
Jul 31 06:53:40 <zecke> Crofton|work: ping?
Jul 31 07:21:46 <arky> Anyone seen this error? ERROR: QA Issue: midori: Files/directories were installed but not shipped
Jul 31 07:21:48 <arky>   /usr/share/gir-1.0
Jul 31 07:33:20 <lpapp> arky: yes
Jul 31 07:33:41 <arky> lpapp, Any pointers on how to fix this error
Jul 31 07:34:07 <lpapp> do_install_append() -> rmdir.
Jul 31 07:34:40 <arky> lpapp, Sorry I am new to yocto. Can you explain
Jul 31 07:36:15 <arky> lpapp, Got it, +    rmdir ${D}${datadir}/gir-1.0
Jul 31 07:36:19 <arky> lpapp, Thx
Jul 31 07:42:03 <arky> Is there openembedded recipe for sugar (from sugarlabs)?
Jul 31 07:49:00 <lpapp> no
Jul 31 07:49:54 <arky> lpapp, Found these oe stuff http://cgit.openembedded.org/openembedded/tree/recipes/sugar/sugar_0.82.9.bb?
Jul 31 07:52:19 <lpapp> sorry, I meant no oe-core recipe.
Jul 31 07:52:26 <lpapp> I only checked meta/
Jul 31 07:54:20 <lpapp> as far as I am aware, there is no such a recipe in yocto/poky, so you need to get it into your own distribution layer.
Jul 31 07:54:56 <arky> lpapp, Thx for the answer
Jul 31 07:57:34 <bluelightning> morning all
Jul 31 07:57:34 <lpapp> I was even unaware of that collection, so I learnt something new today. :-)
Jul 31 07:58:36 <bluelightning> not necessarily a distro layer; sugar recipes would be most appropriate in their own software layer
Jul 31 07:59:33 <lpapp> I think a software layer for one package is a bit excessive.
Jul 31 08:00:11 <arky> bluelightning, Morning, I can include this (classic-oe) layer in my bblayers and build right
Jul 31 08:00:58 <bluelightning> arky: unfortunately not, you'll need to migrate it
Jul 31 08:01:06 <bluelightning> lpapp: I'm assuming it'll be more than just one recipe
Jul 31 08:01:11 <arky> bluelightning, Ah! I see
Jul 31 08:01:20 <bluelightning> arky: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core
Jul 31 08:02:10 <lpapp> bluelightning: based on?
Jul 31 08:02:41 <bluelightning> lpapp: based on other environments that contain multiple applications and components
Jul 31 08:02:55 <lpapp> ?
Jul 31 08:02:59 <bluelightning> ?
Jul 31 08:03:22 <lpapp> not sure what environment means.
Jul 31 08:03:37 <lpapp> and even multiple applications and components might not be appropriate inside one layer as they might be very different.
Jul 31 08:06:19 <bluelightning> lpapp: I'm assuming that sugar is not just one monolithic piece of software but consists of multiple separately buildable components, that would still naturally go into the same collection
Jul 31 08:06:30 <bluelightning> could be completely wrong
Jul 31 08:07:00 <lpapp> bluelightning: it is just a split package.
Jul 31 08:07:13 <arky> bluelightning, You are right sugar is half-dozen different components with lot supporting desktop,sound, lib packages
Jul 31 08:07:50 <lpapp> bluelightning: I personally think it makes more sense to have a recipe group for such things, like recipes-qt5
Jul 31 08:07:53 <lpapp> not meta-qt5
Jul 31 08:08:25 <lpapp> just like recipes-gnome.
Jul 31 08:08:54 <bluelightning> lpapp: staying with the subject of sugar, it's not something that everyone needs, but if there's still a group of recipes a separate layer makes sense
Jul 31 08:08:58 <lpapp> in fact, recipes-gnome has a lot more packages than sugar.
Jul 31 08:09:27 <lpapp> no, sugar is not too common.
Jul 31 08:09:46 <lpapp> I would not make a separate layer for each recipe group personally.
Jul 31 08:09:49 <lpapp> I would use the distro layer.
Jul 31 08:09:54 <lpapp> as the container.
Jul 31 08:10:03 <bluelightning> then other distros can't as easily re-use those recipes
Jul 31 08:10:19 <bluelightning> which we ideally would prefer in the OE ecosystem
Jul 31 08:10:31 <bluelightning> (assuming the author wishes to make any of it public, which is of course optional)
Jul 31 08:11:28 <lpapp> ?
Jul 31 08:11:35 <lpapp> they can easily copy and paste.
Jul 31 08:11:40 <rburton> arky: so that gir-1.0 directory is the gobject-introspection data.  there's often a configure argument to turn it off.  this is something we do need to integrate a stub for into oe-core though.
Jul 31 08:12:17 <bluelightning> lpapp: why should people need to?
Jul 31 08:12:38 <lpapp> bluelightning: because they need the packages?
Jul 31 08:13:14 <bluelightning> lpapp: we mostly take care to structure our layers so people can just fetch and add the pieces they want, and then build, avoiding error-prone copying and pasting
Jul 31 08:13:52 <bluelightning> lpapp: it also allows more freedom of maintainership
Jul 31 08:14:02 <lpapp> haha
Jul 31 08:14:30 <lpapp> fetching recipes-foo is just as simple as a layer
Jul 31 08:14:35 <lpapp> it is just a different name after all.
Jul 31 08:14:44 <lpapp> so I do not see the problem.
Jul 31 08:14:52 <bluelightning> well, that's the way we are structuring things
Jul 31 08:14:56 <lpapp> maintainership is also the same.
Jul 31 08:15:25 <bluelightning> it has been found to work fairly well
Jul 31 08:15:27 <lpapp> I think recipe-foo makes more sense
Jul 31 08:15:38 <lpapp> because it is not a full layer after all, just a recipe-foo.
Jul 31 08:15:45 <lpapp> so everything else would be dummy in the layer.
Jul 31 08:16:02 <lpapp> bluelightning: how do you judge?
Jul 31 08:16:18 <lpapp> bluelightning: I can open a bugreport if you wish to show it does not work as "fairly well" as it could.
Jul 31 08:16:27 <bluelightning> lpapp: by fairly wide community consensus?
Jul 31 08:16:30 <lpapp> why would you populate a full layer just for a recipe family?
Jul 31 08:16:48 <lpapp> bluelightning: wide means you and some other Intel guys?
Jul 31 08:17:03 <lpapp> or does it include me and my familiars who agree with me?
Jul 31 08:17:05 <bluelightning> lpapp: we have done this already many times... meta-efl, meta-opie, etc.
Jul 31 08:17:31 <bluelightning> lpapp: actually I'm speaking now more about the wider OpenEmbedded community than anyone from Intel
Jul 31 08:18:25 <lpapp> so everyone minus who disagree. :)
Jul 31 08:19:25 <lpapp> in fact, the layers decrease the reusability if they are really used in layer senses.
Jul 31 08:20:06 <lpapp> because if there are no recipe groups as a finer tuned "layer"
Jul 31 08:20:06 <Crofton|work> zecke, pong
Jul 31 08:20:13 <lpapp> you will put a lot of stuff into a layer
Jul 31 08:20:16 <lpapp> see meta-sourcery
Jul 31 08:20:16 <Crofton|work> I should be asleep
Jul 31 08:20:17 <lpapp> that is a bloat.
Jul 31 08:20:25 <lpapp> you need the toolchain, but you get a lot more stuff than you need.
Jul 31 08:20:34 <lpapp> it ruin the proper reusability by demanding layers.
Jul 31 08:20:38 <lpapp> ruins*
Jul 31 08:21:18 <lpapp> this makes me wanna open a bugreport about more fine tuned "layers" a.k.a. recipe groups.
Jul 31 08:22:15 <bluelightning> lpapp: I can't speak to the design of meta-sourcery, I think that's mostly a distro layer - hence my earlier statement against adding new blocks of recipes to distro layers
Jul 31 08:22:35 <lpapp> bluelightning: no no, that is not a distro layer at all.
Jul 31 08:22:42 <lpapp> that is a fundamental misunderstanding. :)
Jul 31 08:22:51 <bluelightning> well it clearly contains more than just one type of thing...
Jul 31 08:23:03 <lpapp> that does not make it distro, really.
Jul 31 08:23:23 <bluelightning> I haven't looked at it in detail
Jul 31 08:23:35 <lpapp> then please do before claiming that it is a distro layer.
Jul 31 08:23:51 <bluelightning> honestly I'd rather we had up-to-date recipes for the sourcery toolchain in OE-Core, but it hasn't been up to me
Jul 31 08:24:29 <lpapp> bluelightning: it is buggy
Jul 31 08:24:37 <lpapp> why would we bother using it
Jul 31 08:24:40 <lpapp> it blocks us
Jul 31 08:24:49 <lpapp> we switched on to meta-sourcery which is also buggy
Jul 31 08:24:55 <lpapp> but at least, that got fixes after my reports.
Jul 31 08:25:04 <lpapp> oe-core did not, in time.
Jul 31 08:25:17 <bluelightning> well, strictly speaking the same people are in charge of maintaining both...
Jul 31 08:25:38 <lpapp> bluelightning: nope...
Jul 31 08:25:41 <bluelightning> yep
Jul 31 08:25:48 <lpapp> bluelightning: CS guys do not maintain or even recommend oe-core...
Jul 31 08:26:26 <bluelightning> the decision about the future of the recipes in OE-Core is largely in their hands, with some input from the community
Jul 31 08:26:47 <arky> rburton, Thx
Jul 31 08:27:10 <arky> bluelightning, lpapp Is there any documentation about using distro layer?
Jul 31 08:27:18 <bluelightning> arky: there is, one sec
Jul 31 08:27:21 <lpapp> arky: the reference manual.
Jul 31 08:28:11 <bluelightning> arky: general layers info: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers
Jul 31 08:28:33 <arky> bluelightning, lpapp Thx
Jul 31 08:29:55 <bluelightning> arky: specifically about a distro layer (but this is more about top-level configuration/customisation for your specific use case): http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution
Jul 31 08:33:28 <zecke> Crofton|work: yeah, you should be. Do you still have access to a Lyrtech SDR platform? E.g. I think the macgine is not bootable
Jul 31 08:35:31 <Crofton|work> I haven't touched that in a long time
Jul 31 08:47:27 <lpapp> bluelightning: is there any particular reason why there is no config option for removing downloads on the fly?
Jul 31 08:47:35 <lpapp> rm_downloads similarly to rm_work?
Jul 31 08:47:50 <bluelightning> lpapp: I guess because most people want to be able to rebuild the recipe without re-downloading
Jul 31 08:48:04 <bluelightning> it's not something I've heard requested before, FWIW
Jul 31 08:48:05 <lpapp> well, it would not be default
Jul 31 08:48:13 <lpapp> ok, I am doing that now on the issue tracker.
Jul 31 08:48:19 <lpapp> I am getting this all the time:
Jul 31 08:48:21 <bluelightning> there have certainly been requests to be able to delete _old_ downloads
Jul 31 08:48:25 <lpapp> (regardless I have rm_work)
Jul 31 08:48:34 <lpapp> WARNING: The free space of /home/lpapp/Projects/poky/build/tmp (/dev/sda7) is running low (0.942GB left)
Jul 31 08:48:36 <rburton> lpapp: i suggest writing and trialing it for a while, i suspect it would be incredibly painful in real use
Jul 31 08:48:37 <lpapp> ERROR: No new tasks can be excuted since the disk space monitor action is "STOPTASKS"!
Jul 31 08:48:40 <lpapp> and the only workaround is to remove stuff manually.
Jul 31 08:49:02 <lpapp> rburton: huh?
Jul 31 08:49:10 <lpapp> it is the extremely _only_ workaround for me.
Jul 31 08:49:11 <bluelightning> lpapp: is that indication of your free space accurate?
Jul 31 08:49:15 <lpapp> but I have to do it manually every time.
Jul 31 08:49:20 <lpapp> I am ... frankly, tired of it.
Jul 31 08:49:21 <rburton> i guess you could have the situation where there's a local fast mirror
Jul 31 08:49:44 <lpapp> the other fighting instead of "sure, go ahead".
Jul 31 08:49:45 <lpapp> :-)
Jul 31 08:50:10 <lpapp> bluelightning: yes, of course.
Jul 31 08:50:27 <rburton> lpapp: we ask because some filesystems are known to report bad values
Jul 31 08:50:28 <lpapp> I need an rm_downloads
Jul 31 08:50:38 <lpapp> explicit bitbake -c delete_downloads could also work
Jul 31 08:50:48 <lpapp> but that would still imply _manual_ intervention all the time.
Jul 31 08:51:01 <lpapp> so I prefer rm_downloads to bitbake -c clean-downloads...
Jul 31 08:51:02 <bluelightning> lpapp: ok, so you probably need a larger disk/partition; if you prefer you can tune the BB_DISKMON_* to warn when you are closer to running out of space
Jul 31 08:51:21 <lpapp> bluelightning: you will pay me a bigger hard disk?
Jul 31 08:51:27 <lpapp> and setup while I sleep?
Jul 31 08:51:33 <lpapp> so I do not need to spend time, effort, money?
Jul 31 08:51:38 <bluelightning> lpapp: do you pay us for giving you support here? ;)
Jul 31 08:51:53 <lpapp> no one gives support here about it.
Jul 31 08:52:03 <lpapp> everyone is reluctant for reporting a feature request ...
Jul 31 08:52:03 <bluelightning> I believe that's what we're doing...
Jul 31 08:52:12 <lpapp> which would support from _me_, not _you_ for now.
Jul 31 08:52:26 <lpapp> be*
Jul 31 08:52:38 <lpapp> these discussion are very hard-going.
Jul 31 08:52:40 <rburton> lpapp: i suggested that you write it and see how painful it is in real use. file a feature request if you wish.
Jul 31 08:52:43 <RP> hard disks are usually relatively cheap compared to the value of people's time
Jul 31 08:52:46 <lpapp> instead of "go ahead", I always have to fight.
Jul 31 08:52:52 <lpapp> damn, I will not discuss requests here...
Jul 31 08:52:54 <bluelightning> we're pretty up-front about our disk space requirements in the quick start guide, FWIW
Jul 31 08:52:55 <rburton> lpapp: it's called "feedback"
Jul 31 08:53:00 <lpapp> they will go directly to the issue tracker in here.
Jul 31 08:53:28 <lpapp> RP: ok, so buy one instead of Intel working on it?
Jul 31 08:53:32 <lpapp> and someone will set up for me?
Jul 31 08:53:34 <rburton> personally, the 40 quid it cost me to get a 1TB disk for yocto builds has paid for itself rapidly because i've not had to worry for a year about clearing space.
Jul 31 08:53:34 <lpapp> do not be obtuse.
Jul 31 08:53:39 <lpapp> these are personal costs, time, and effort.
Jul 31 08:54:08 <RP> lpapp: and there are costs for adding and maintaining a feature too
Jul 31 08:54:20 * lpapp is just reporting it as this discussion goes nowhere as usual with full of reluctance unlike the bugreports where the requests are actually accepted 
Jul 31 08:55:16 <lpapp> RP: yeah, it is very reasonable to demand many people's time, effort, and money instead of one person maintaining a little feature.
Jul 31 08:55:30 <lpapp> yay for a better a world.
Jul 31 08:55:40 <RP> lpapp: those little features mount up
Jul 31 08:55:55 <lpapp> so do the many people's time, effort, and money?
Jul 31 08:56:30 <lpapp> I think this channel is just not recommended for feedback.
Jul 31 08:56:33 <RP> lpapp: general development with the system needs disk space. I suspect you'll hit other problems if you really struggle for that much space
Jul 31 08:56:34 <lpapp> it is too hostile for that.
Jul 31 08:56:37 <rburton> oh this is getting silly. lpapp, nobody is stopping you write rm_downloads, or file a bug.  we're recommending you get more disk space, as the documentation says.
Jul 31 08:56:41 <lpapp> the bugzilla service works a lot more friendly.
Jul 31 08:56:53 <RP> lpapp: the bugzilla and here are run by the same people
Jul 31 08:57:18 <lpapp> RP: I have never hit any other problems... but you know better for sure...
Jul 31 08:57:39 <RP> lpapp: only been doing this kind of development for the best part of a decade ;-)
Jul 31 08:57:48 <lpapp> no no
Jul 31 08:57:58 <lpapp> the bugzilla accepted all my reports pretty much.
Jul 31 08:58:07 <lpapp> here, I have to fight with 5 people jumping on me for any trivial stuff.
Jul 31 08:58:17 <lpapp> this is tiring, and frankly, not making me happy.
Jul 31 08:58:24 <RP> lpapp: for some definition of accepted
Jul 31 08:58:38 <lpapp> there is one definition.
Jul 31 08:58:43 <lpapp> check the bugzilla documentation what that is.
Jul 31 08:59:20 <lpapp> no wonder why the error reporting, documentation, etc are that broken if the users are turned down.
Jul 31 08:59:23 <lpapp> when they provide fedback.
Jul 31 08:59:25 <lpapp> feedback*
Jul 31 09:21:00 <eren> morning all
Jul 31 10:05:04 <lpapp> is there any way I can fix busybox without PACKAGECONFIG?
Jul 31 10:05:08 <lpapp> any easier, that is.
Jul 31 10:11:00 <lpapp> JaMa: you seem to be the big PACKAGECONFIG hacker based on git log -S. :)
Jul 31 10:25:42 <zibri> I'm having issues with do_rootfs for our image after moving from dylan to master, i get "error: package update-rc.d is not installed" (same error message for update-rc.d, base-passwd and run-postinsts). is this something anybody recognizes?
Jul 31 10:30:17 <rburton> lpapp: packageconfig is the recommended way to setup options that various people may want on or off.
Jul 31 10:30:30 <rburton> not possible for some recipes, but its always worth trying first
Jul 31 10:48:29 <lpapp> rburton: but it takes me quite a bit of time.
Jul 31 10:48:36 <lpapp> rburton: and I do not find proper examples.
Jul 31 10:48:45 <lpapp> I grepped through several, but they are stuff that the software handles off-hand.
Jul 31 10:48:53 <lpapp> that is not so much the case with busybox
Jul 31 10:48:59 <lpapp> so the mapping would need to be implemented.
Jul 31 10:54:10 <rburton> the alternative would be a variable you can check in features_to_busybox_settings()
Jul 31 10:54:33 <lpapp> .bbappend would work as a quick hack for defconfig
Jul 31 10:54:39 <lpapp> but it would not work for the other two changes.
Jul 31 10:54:46 <lpapp> and they seem to be mandatory to get it right.
Jul 31 10:55:13 <lpapp> -       busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
Jul 31 10:55:14 <lpapp> -       busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)
Jul 31 10:55:33 <lpapp> not sure why they cause build issues
Jul 31 10:55:41 <lpapp> our board does not have wifi, nor bluetooth.
Jul 31 10:55:52 <lpapp> so they should be disabled anyway.
Jul 31 10:56:30 <rburton> sorted :)
Jul 31 10:56:37 <rburton> turn off wifi and bluetooth, and rfkill goes away
Jul 31 10:57:01 <lpapp> ?
Jul 31 10:57:22 <lpapp> so how cna I implement a package config option
Jul 31 10:57:22 <lpapp> ?
Jul 31 10:57:26 <lpapp> --without-rfkill
Jul 31 10:57:31 <rburton> if you remove the wifi and bluetooth DISTRO_FEATURES from your distro, then the rfkill applet won't be built
Jul 31 10:57:37 <lpapp> what do I need to do in the background to disable those two lines in busybox.inc
Jul 31 10:57:42 <lpapp> what do I need to check against?
Jul 31 10:57:48 <rburton> well, we've a better fix here
Jul 31 10:57:55 <lpapp> ?
Jul 31 10:58:01 <rburton> if you don't have wifi or bluetooth, disable those in your distro
Jul 31 10:58:09 <rburton> you'll save space in busybox and other places
Jul 31 10:58:14 <lpapp> poky-tiny should not bring wifi and bluetooth anyway
Jul 31 10:58:15 <lpapp> ?
Jul 31 10:58:17 <rburton> why not?
Jul 31 10:58:26 <rburton> who are you to say that poky-tiny shouldn't have wifi?
Jul 31 10:58:34 <lpapp> well, the omap supports those potentially.
Jul 31 10:58:40 <rburton> exactly
Jul 31 10:58:40 <lpapp> so I would rather keep them for future flexibility.
Jul 31 10:58:50 <rburton> but *your* distro doesn't need them, so you can disable them.
Jul 31 10:59:02 <lpapp> so the mapping from PACKAGECONFIG to busybox.inc has to happen somehow.
Jul 31 10:59:03 <rburton> if in the future you need wifi you can come back to this
Jul 31 10:59:08 <lpapp> is there any example for this out there how exactly?
Jul 31 10:59:18 <lpapp> I do not wanna debug this in the future
Jul 31 10:59:41 <rburton> from ten seconds of reading busybox.inc, you'll need to implement a mapping layer if you wanted to use PACKAGECONFIG.
Jul 31 11:00:39 <rburton> so there's your options: lots of work on busybox.inc to implement a generic packageconfig layer for per-distro tweaks, or change your distro features to remove wifi and bluetooth which will have the side-effect of disabling rfkill (and likely a few other things in various places)
Jul 31 11:00:53 <rburton> ie connman won't builds its wifi or bluetooth support, if you're using that
Jul 31 11:01:41 <lpapp> it is not a distro tweak
Jul 31 11:01:49 <lpapp> it is a generic older toolchain support tweak.
Jul 31 11:01:58 <lpapp> and actually I checked, the network layer depends on wifi, and bluetooth, etc.
Jul 31 11:02:22 <rburton> "network layer"?
Jul 31 11:02:33 <lpapp> yes, exactly.
Jul 31 11:02:48 <rburton> i meant what do you mean by network layer
Jul 31 11:02:49 <lpapp> no, we do not use connman.
Jul 31 11:03:31 <lpapp> sounds like a bad yocto stuff if it is a lot of work to do a very simple mapping
Jul 31 11:03:39 <lpapp> if A is set, disable this and that.
Jul 31 11:03:47 <rburton> its not a lot of work
Jul 31 11:03:50 <rburton> its just work
Jul 31 11:03:50 <lpapp> that should be about .. 3-5 LOC?
Jul 31 11:04:12 <lpapp> or even 2 in an ideal world. :-)
Jul 31 11:04:13 <rburton> well, the packageconfig string to configure arguments/dependencies is about 20 loc
Jul 31 11:04:16 <rburton> iirc
Jul 31 11:04:27 <lpapp> not sure what you mean?
Jul 31 11:04:44 <rburton> the code that turns a packageconfig string into configure arguments and dependencies is about 20 loc
Jul 31 11:04:47 <rburton> maybe a bit more
Jul 31 11:05:12 <lpapp> that looks like a bad design
Jul 31 11:05:17 <rburton> its called "python"
Jul 31 11:05:19 <lpapp> in qt, we have the feature system.
Jul 31 11:05:23 <lpapp> this is what you do:
Jul 31 11:05:35 <lpapp> ./configure -with-feature-nooo
Jul 31 11:05:38 <lpapp> ./configure -with-feature-nofoo*
Jul 31 11:05:42 <lpapp> NOFOO is defined
Jul 31 11:05:45 <lpapp> code in the background:
Jul 31 11:05:53 <lpapp> #ifdef NOFOO
Jul 31 11:05:54 <lpapp> ...
Jul 31 11:05:55 <lpapp> #endif
Jul 31 11:06:15 <rburton> i was refering to the code that in your example reads the configure arguments, parses them, handles duplicates, and defines the variable
Jul 31 11:06:53 <rburton> anyway my point i was trying to make five minutes ago was its not obvious how packageconfig and busybox's CML config system would interact
Jul 31 11:06:57 <rburton> so this isn't a trivial task
Jul 31 11:07:00 <lpapp> not sure what you mean, but do you have an example for such a mapping already implemented and I could take a look?
Jul 31 11:07:03 <lpapp> maybe, I would get it better.
Jul 31 11:07:20 <lpapp> yes, that is why it is a bad design.
Jul 31 11:07:30 <lpapp> it should be a trivial task solved by a centralized boiler-plate.
Jul 31 11:07:55 <rburton> sigh.  as i've said that centralised boilerplate was designed around configure arguments, not cml.  feel free to extend it.
Jul 31 11:07:58 <lpapp> or not bad, but missing.
Jul 31 11:08:03 <rburton> i was about to point you at base.bbclass
Jul 31 11:08:12 <lpapp> sounds like a bugreport.
Jul 31 11:08:15 <rburton> search for PACKAGECONFIG and you'll find the python function that implements it
Jul 31 11:08:51 <lpapp> not sure what "cml" means.
Jul 31 11:10:18 <ant_work> martiert: is the error about .gitignore ?
Jul 31 11:11:28 <lpapp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4964
Jul 31 11:11:29 <yocti> Bug 4964: normal, Undecided, ---, saul.wold, NEW , Simplify the mapping between PACKAGECONFIG and .bb/.inc files
Jul 31 11:17:43 <lpapp> MultiModule.sh was removed in dylan? o_O :(
Jul 31 11:21:55 <lpapp> is it possible to pass the preferred version to bitbake on the command line?
Jul 31 11:24:48 <lpapp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965
Jul 31 11:24:49 <yocti> Bug 4965: normal, Undecided, ---, richard.purdie, NEW , Not possible to pass the preferred version to bitbake on the command line
Jul 31 11:29:32 <lpapp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4966
Jul 31 11:29:33 <yocti> Bug 4966: normal, Undecided, ---, saul.wold, NEW , Add a feature ("rm_downloads") for INHERIT
Jul 31 11:31:15 <lpapp> http://pastebin.com/w1qmkJNR -> what is this QA error in poky master?
Jul 31 11:37:11 <rburton> lpapp: it means a file or directory was installed but not packaged.
Jul 31 11:37:31 <lpapp> rburton: why am I getting such a regression in dylan?
Jul 31 11:37:38 <lpapp> or well, even master ahead.
Jul 31 11:37:49 <B4gder> lpapp: we must've missed your fix for it!
Jul 31 11:38:07 <rburton> mainly because external-sourcery-toolchain isn't tested very well currently
Jul 31 11:38:17 <lpapp> rburton: how do you know it is related to that?
Jul 31 11:38:34 <rburton> lpapp: because thats the package that is producing the warnings
Jul 31 11:38:53 <lpapp> "nice"
Jul 31 11:39:04 <lpapp> what can I do to fix it?
Jul 31 11:39:11 <lpapp> do you know the root cause of the issue?
Jul 31 11:39:15 <lpapp> wany pointers, etc
Jul 31 11:39:17 <rburton> either delete those files if they're not meant to be installed, or add to FILES_ if they are
Jul 31 11:39:19 <lpapp> any*
Jul 31 11:39:29 <rburton> this is basic FILES_* manipulation
Jul 31 11:39:38 <lpapp> why did it not need any special attention before?
Jul 31 11:39:43 * rburton shrugs
Jul 31 11:39:49 <rburton> because stuff changes?
Jul 31 11:39:54 <lpapp> what stuff exactly ...
Jul 31 11:39:58 <rburton> everything
Jul 31 11:40:10 <rburton> distro configuration could have changed that meant an assumption wasn't valid
Jul 31 11:40:11 <lpapp> so, basically you are claiming who cares why it happens.
Jul 31 11:40:15 <lpapp> that is not my mentality.
Jul 31 11:40:16 <rburton> no
Jul 31 11:40:22 <lpapp> I would like to understand why I am fixing things.
Jul 31 11:40:33 <rburton> and you're in the perfect place to understand
Jul 31 11:40:39 <rburton> what with you getting the error and not me
Jul 31 11:41:03 <lpapp> so, you have no clue?
Jul 31 11:41:25 <rburton> any clue why you're getting those errors exactly? no, never used the external toolchain.
Jul 31 11:41:30 <rburton> in general i've told you why those errors happen
Jul 31 11:41:34 <rburton> and what to do to resolve them
Jul 31 11:42:20 <lpapp> it is an external toolchain.
Jul 31 11:42:40 <lpapp> it should be deleted in the the meta-sourcery/*/*.bb?
Jul 31 11:43:28 <rburton> whatever the recipe is that your building needs fixing
Jul 31 11:43:30 <lpapp> perhaps it is a dylan enforcement.
Jul 31 11:43:31 <rburton> maybe it needs more files packages
Jul 31 11:43:40 <rburton> our QA certainly improved in dylan
Jul 31 11:43:41 <lpapp> as the recipe of course did not change a bit.
Jul 31 11:44:28 <lpapp> NOTE: preferred version 141 of udev not available (for item udev)
Jul 31 11:44:28 <lpapp> NOTE: versions of udev available: 182
Jul 31 11:44:31 <lpapp> what happens in such cases?
Jul 31 11:44:36 <lpapp> 182 will be built?
Jul 31 11:44:38 <rburton> yes
Jul 31 11:44:57 <lpapp> how weird.
Jul 31 11:45:02 <rburton> what would you prefer?
Jul 31 11:45:19 <lpapp> I mean, it is building udev 182, that is weird.
Jul 31 11:45:28 <lpapp> it was broken on my home machine.
Jul 31 11:46:10 <rburton> don't let it know you've noticed, it might break!
Jul 31 11:46:20 <lpapp> 4941
Jul 31 11:46:28 <lpapp> !4941
Jul 31 11:46:31 <lpapp> !BUG 4941
Jul 31 11:46:33 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4941 normal, Undecided, ---, saul.wold, NEW , udev doesn't compile with older toolchains
Jul 31 11:46:44 <lpapp> foo 4941
Jul 31 11:47:01 <rburton> bug 4941
Jul 31 11:47:12 <rburton> hm, i always forget the syntax
Jul 31 11:47:18 <lpapp> :P
Jul 31 11:47:29 <lpapp> !bug 4941
Jul 31 11:47:38 <lpapp> !BUG 4941
Jul 31 11:47:49 <lpapp> now, that is weird.
Jul 31 11:47:58 <rburton> ah
Jul 31 11:48:01 <rburton> 4941
Jul 31 11:48:10 <rburton> heh
Jul 31 11:48:13 <rburton> rate limited?
Jul 31 11:48:15 <rburton> whatever
Jul 31 11:48:29 <lpapp> 12:46 <yocti> (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
Jul 31 11:48:32 <rburton> that udev fail is because your userspace is old
Jul 31 11:48:39 <lpapp> the toolchain is.
Jul 31 11:49:11 <lpapp> is the yocti syntax documented somewhere?
Jul 31 11:49:18 <lpapp> I do not know off-hand how to use the help.
Jul 31 11:49:27 <lpapp> it would be preferrable to have a self-contained greppable stuff.
Jul 31 12:05:04 <lpapp> poky-dylan-9.0.1/build$ ls /tmp/
Jul 31 12:05:04 <lpapp> pulse-PKdhtXMmr18n  VMwareDnD  vmware-root
Jul 31 12:05:13 <lpapp> err... this is what?
Jul 31 12:13:25 <otavio> Hello
Jul 31 12:13:45 <otavio> I am trying to find why bitbake is not behaving as expected
Jul 31 12:14:43 <lpapp> otavio: with regards to?
Jul 31 12:15:54 <rburton> lpapp: that's your /tmp directory.  pulseaudio socket and vmware sockets by the look of it.
Jul 31 12:16:01 <lpapp> rburton: yeah, I realized that much
Jul 31 12:16:14 <lpapp> you did not leave me time to finish the writing of that. :p
Jul 31 12:16:52 <lpapp> this is surprising...
Jul 31 12:16:57 <lpapp> udev182 builds on ubuntu 12.10
Jul 31 12:17:00 <lpapp> with the same toolchain ...
Jul 31 12:17:04 <rburton> otavio: bitbake always behaves as intended, you're just wrong about what you think it should do ;)
Jul 31 12:17:11 <lpapp> and the same old toolchain does not have that defined either.
Jul 31 12:17:21 <otavio> rburton: yaya!
Jul 31 12:17:22 <otavio> lol
Jul 31 12:17:52 <otavio> rburton: the data.finalize() bb method does not finalize it hheheh
Jul 31 12:18:17 <rburton> otavio: well clearly there a good reason for that ;)
Jul 31 12:20:12 <otavio> rburton: sure ;-)
Jul 31 12:20:20 <otavio> rburton: do you know this code?
Jul 31 12:20:30 <otavio> rburton: I can explain the bug, not why
Jul 31 12:21:08 <rburton> otavio: sorry. not me.  try bluelightning.
Jul 31 12:21:20 <otavio> bluelightning: :-)
Jul 31 12:21:35 <otavio> bluelightning: it was rburton who pointed at you. Blame him ;)
Jul 31 12:21:36 <otavio> lol
Jul 31 12:21:37 <rburton> i know that data_smart is 90% unicorn magic
Jul 31 12:21:46 <bluelightning> otavio: I'm not sure either... but I might suggest this is why attempting to do this kind of thing is problematic
Jul 31 12:21:56 <otavio> bluelightning: well
Jul 31 12:22:10 <otavio> bluelightning: does not solve the bug
Jul 31 12:22:20 <otavio> and it does seem it is a bug in bitbake.
Jul 31 12:22:30 <otavio> bluelightning: want me to explain it?
Jul 31 12:22:48 <bluelightning> otavio: you're calling finalize() and what doesn't happen?
Jul 31 12:23:24 <otavio> bluelightning: let's focus on DISTRO_FEATURES only
Jul 31 12:23:38 <otavio> bluelightning: it is set in two places, in case of poky
Jul 31 12:23:54 <otavio> bluelightning: ?= in defaultsetup and _append in poky
Jul 31 12:25:19 <bluelightning> otavio: right, yes... as I kind of indicated in the thread I think we probably ought to just set it outright in poky.conf
Jul 31 12:25:25 <otavio> bluelightning: finalize seems to delay _append (which makes sense) but than the added in _append are done /after/ .finalize
Jul 31 12:26:12 <otavio> bluelightning: This can be done in many ways and it'd cover the bug.
Jul 31 12:26:27 <lpapp> so, what is the replacement for MultiModule in dylan?
Jul 31 12:26:32 <otavio> bluelightning: the point is when ConfigParsed event is triggered, it is not fully done.
Jul 31 12:26:56 <bluelightning> lpapp: what is MultiModule?
Jul 31 12:27:20 <lpapp> bluelightning: initscript stuff for updating.
Jul 31 12:28:07 <bluelightning> lpapp: "git grep MultiModule" doesn't find anything in denzil nor dylan
Jul 31 12:28:13 <lpapp> poky-denzil-7.0.1/meta/recipes-core/initscripts/initscripts-1.0/MultiModule.sh
Jul 31 12:28:23 <lpapp> git grep != grep
Jul 31 12:28:37 <lpapp> and you need find here anyway, not grep. :-)
Jul 31 12:28:41 <bluelightning> lpapp: you mean git grep is not find
Jul 31 12:29:22 <lpapp> I mean what I wrote.
Jul 31 12:29:53 <bluelightning> "git grep" searches in all git managed files, if there were a reference to it it would have found it
Jul 31 12:30:25 <lpapp> it is not so simple.
Jul 31 12:30:39 <g0hl1n> hi, I've a question regarding the /etc/version file. What recipe is writing this file and where does it get it's value from? Thanks!
Jul 31 12:31:19 <lpapp> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initscripts?h=denzil -> true, it is not in the repository.
Jul 31 12:31:26 <bluelightning> lpapp: this is probably something added on top of poky because it doesn't exist in denzil
Jul 31 12:31:45 <lpapp> which is kinda worrying how much stuff we have put in there... :/
Jul 31 12:31:58 <lpapp> what is the intended way of defining own init scripts/
Jul 31 12:32:04 <lpapp> distro layer?
Jul 31 12:32:10 <bluelightning> it is, I'd strongly suggest you do a comparison and try to break things out into your distro layer
Jul 31 12:32:48 <bluelightning> lpapp: depends, if it's for starting a service that comes as part of another recipe, you should use the update-rc.d functionality (see other recipes for examples)
Jul 31 12:32:59 <bluelightning> lpapp: if it's a standalone script, use an initscripts bbappend
Jul 31 12:36:09 <bluelightning> g0hl1n: its contents comes from the BUILDNAME variable which is defaulted within bitbake code if not set
Jul 31 12:36:29 <bluelightning> g0hl1n: creating the /etc/version file is not done within a recipe, it happens when post-processing the image during image construction (see references to ${sysconfdir}/version in meta/classes/rootfs_*.bbclass)
Jul 31 12:37:46 <g0hl1n> bluelightning: ok, thanks! So i can set BUILDNAME in my distro configuration?
Jul 31 12:38:53 <bluelightning> g0hl1n: you can if appropriate, or alternatively you can just write your own value to ${IMAGE_ROOTFS}${sysconfdir}/version in a shell function that you call from ROOTFS_POSTPROCESS_COMMAND
Jul 31 12:44:44 <g0hl1n> bluelightning: thanks!
Jul 31 13:01:26 <RP> otavio: the datastore you get with a ConfigParsed event is not expanded/finalised. That is by design
Jul 31 13:01:51 <otavio> RP: but when I call d.finalize() shouldn't this work?
Jul 31 13:02:30 <otavio> RP: bb.data.update_data does not help
Jul 31 13:02:38 <RP> otavio: well, a) you should copy it, then finalize it and b) you also need expand_keys() iirc for some uses
Jul 31 13:03:02 <RP> otavio: but if everything you need is parsed by then, you should be able to finalise a copy, yes
Jul 31 13:03:04 <otavio> RP: I did the copy in v2
Jul 31 13:03:20 <otavio> RP: and called finalize
Jul 31 13:03:26 <otavio> RP: and it didn't work :(
Jul 31 13:03:32 <otavio> RP: _append is done after
Jul 31 13:04:11 <RP> otavio: Its expected that _append would append to a ?=
Jul 31 13:04:41 <otavio> RP: http://privatepaste.com/5706fa74c4# current patch.
Jul 31 13:04:44 <otavio> RP: yes
Jul 31 13:04:46 <lpapp> is there any option to remove everything except the downloads?
Jul 31 13:04:52 <otavio> RP: it is done after, right?
Jul 31 13:04:54 <lpapp> i.e. before checking stuff into the repository.
Jul 31 13:05:12 <otavio> RP: but ConfigParsed seems to be called /before/ the last append
Jul 31 13:05:25 <lpapp> and conf, of course.
Jul 31 13:06:25 <otavio> RP: this part of bb code is confusing for me so I couldn't yet understand it fully
Jul 31 13:06:48 <RP> otavio: I don't understand what problem you're seeing :/
Jul 31 13:07:04 <RP> otavio: I'm also not meant to be here :/
Jul 31 13:07:35 <RP> lpapp: most people use .gitignore for that purpose
Jul 31 13:07:35 <otavio> RP: if I do EXTRA_DISTRO_FEATURES = "~x11 ~wayland" x11 is dropped, wayland does not.
Jul 31 13:07:53 <otavio> RP: so wayland is kept
Jul 31 13:08:14 <otavio> RP: yes I know you're in vacations :)
Jul 31 13:08:57 <RP> otavio: ah, I can see why this does happen :/
Jul 31 13:09:08 <lpapp> so bitbake is not our friend in here?
Jul 31 13:09:08 <RP> otavio: _append is near impossible to cancel out :/
Jul 31 13:09:09 <lpapp> :/
Jul 31 13:09:37 <otavio> RP: but finalize should have returned it done no?
Jul 31 13:10:10 <RP> otavio: that code will cancel out wayland in DISTRO_FEATURES at ConfigParsed time
Jul 31 13:10:28 <RP> otavio: but nothing removes the _append from the system and stops wayland being added back
Jul 31 13:10:57 <otavio> RP: in fact it is added back
Jul 31 13:11:27 <otavio> RP: well but this is bad. We cannot get a 'final' result?
Jul 31 13:12:40 <RP> otavio: no, you get the final result, its just you can't overwrite it completely
Jul 31 13:13:23 <RP> otavio: I suspect you could hack it with a d.delVarFlag("DISTRO_FEATURES", "_append")
Jul 31 13:13:31 <RP> otavio: but that is assuming internal bitbake knowledge
Jul 31 13:13:41 <RP> i.e. I will not take patches using that
Jul 31 13:13:51 <lpapp> bluelightning: you are maintaining the CS oe-core stuffy?
Jul 31 13:14:03 <bluelightning> lpapp: no, I'm not
Jul 31 13:14:40 <lpapp> bluelightning: so what is with this change then?
Jul 31 13:15:02 <bluelightning> lpapp: which change?
Jul 31 13:15:13 <lpapp> bluelightning: your fix?
Jul 31 13:18:39 <bluelightning> lpapp: I haven't worked on the external toolchain recipes, I've reviewed some patches from Laurentiu and Saul that have been merged recently though
Jul 31 13:20:25 * RP wanders off the play with lime mortar again
Jul 31 13:22:59 <mulhern> Do there exist any regression tests for create-recipe script?
Jul 31 13:23:53 <mulhern> The one in poky/scripts.
Jul 31 13:24:13 <JaMa> lpapp: remove PR assignments in your u-boot patch
Jul 31 13:24:14 <bluelightning> mulhern: I think maybe we don't have a test for that, but testopia would be the best place to check
Jul 31 13:24:29 <mulhern> testopia?
Jul 31 13:24:31 <lpapp> JaMa: why?
Jul 31 13:24:43 <bluelightning> mulhern: it's integrated into our bugzilla
Jul 31 13:25:28 <JaMa> lpapp: http://lists.openembedded.org/pipermail/openembedded-core/2012-December/071572.html
Jul 31 13:25:54 <rburton> JaMa: do you have that url memorised? :)
Jul 31 13:26:51 <mulhern> bluelightning: I'm looking at bugzilla.yoctoproject.org and I see Testopia in drop-down menu, but I don't know how to interact. Can you give me a hint?
Jul 31 13:28:25 <rburton> mulhern: its a bit of a maze unless you're a qa expert tbh
Jul 31 13:29:00 <otavio> RP: and how to handle this in a cleaner way?
Jul 31 13:29:02 <bluelightning> mulhern: indeed... in theory you should just be able to search for a keyword in all of the test cases
Jul 31 13:30:51 <JaMa> rburton: no, but I needed the link to persuade some other people about PR_append stupidity, so it was worth finding it
Jul 31 13:31:51 <otavio> RP: I am testing the delVarFlag hack
Jul 31 13:32:56 <lpapp> JaMa: but others do it, too.
Jul 31 13:34:16 <mulhern> blue lightning + rburton: Yes, my problem is that I found that one Perl script I'm trying to install has about 60 or so distinct, non-core dependencies. So, the plan is to extend create-recipe to handle Perl modules. But I don't want to break it during that process.
Jul 31 13:34:34 <rburton> mulhern: tbh, i'd be surprised if there's a test for it
Jul 31 13:40:25 <mulhern> It seems like a lot of the tests are narrative? I did a search on "hob" and what I see are instructions for what a person might do.
Jul 31 13:41:15 <bluelightning> mulhern: right, we're in the process of automating our testing for the upcoming release
Jul 31 13:41:41 <JaMa> lpapp: most upgrades are dropping PR, existence of bad example isn't good reason for you to follow it, is it?
Jul 31 13:41:43 <lpapp> rburton: I am not sure if there is any reason for the old ones.
Jul 31 13:41:53 <lpapp> rburton: there are many around already
Jul 31 13:42:03 <lpapp> someone with competence needs to judge on that, sorry.
Jul 31 13:42:08 <lpapp> I would not like to have a take on this.
Jul 31 13:42:25 <lpapp> JaMa: maybe, but I do not have time to update it now.
Jul 31 13:42:32 <lpapp> and I do not think it should be a blocker either.
Jul 31 13:43:06 <JaMa> it can wait till you have time to update it
Jul 31 13:43:20 <JaMa> upgrade to newer u-boot isn't bloker too
Jul 31 13:46:02 <mulhern> bluelightning: Is this the ptest stuff? I know I've heard rumours.
Jul 31 13:46:29 <bluelightning> mulhern: that's a separate but related effort
Jul 31 13:46:57 <bluelightning> mulhern: ptest provides the mechanism to integrate tests supplied with each piece of software we build
Jul 31 13:47:33 <mulhern> bluelightning: That makes sense based on context. So, what is the other effort?
Jul 31 13:50:18 <bluelightning> mulhern: we've added a meta/classes/testimage.bbclass and meta/lib/oeqa/* to allow us to easily define runtime tests that can be run regularly on the autobuilder
Jul 31 13:52:58 <bluelightning> mulhern: the only other missing piece then is the ability to run non-runtime tests, that's not implemented yet but we plan to run those through an oe-selftest script
Jul 31 13:54:17 <Krz> Hi guys, I inherited kernel config & *.scc file from 1.3 Yocto layer. Now moved this to Yocto 1.4 and still using this scc file. Does Yocto need it? The scc file contains only few lines: define KMACHINE abc, define KTYPE def, define KARCH ghi, kconf hardware xyz.cfg.
Jul 31 13:54:23 <mulhern> bluelightning: So, a runtime test is what is run on an image after it is built?
Jul 31 13:54:55 <bluelightning> mulhern: correct
Jul 31 13:55:43 <bluelightning> mulhern: FYI: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740
Jul 31 13:55:44 <yocti> Bug 4740: enhancement, Medium+, 1.5, mihaix.lindner, NEW , Consider providing an oe-selftest script to run automated tests against bitbake tools
Jul 31 13:56:07 <mulhern> bluelightning: It's good to know. But you'ld agree with me that there's no infrastructure for my create-recipe regression problem at this time?
Jul 31 13:58:17 <bluelightning> mulhern: that's correct, and it would appear there's no manual test case either
Jul 31 13:58:55 <bluelightning> mulhern: to be honest I don't know how much regular use create-recipe gets, it would certainly be great to improve its capabilities
Jul 31 13:59:32 <bluelightning> Krz: I think the scc file is important, but I'm not an expert in that area
Jul 31 14:02:07 <mulhern> bluelightning: It puts over1000 lines of Perl into attempting to infer all sorts of things from downloaded distributions.
Jul 31 14:03:24 <Krz> bluelightning: I built an image without it, so it's certainly not a build-time requirement. Who should I talk to about scc?
Jul 31 14:04:48 <bluelightning> Krz: Bruce Ashfield (zeddii), Darren Hart (dvhart) or Tom Zanussi (tomz1) probably the best people to talk to about that, assuming our BSP guide isn't able to answer the question
Jul 31 14:05:48 <ant_work> Krz: the scc format hasn't changed. Keep that file. For doubts, ^^^
Jul 31 14:14:42 <ant_work> bluelightning: where do we put xinput-calibrator now? in XSERVER?
Jul 31 14:15:53 <bluelightning> ant_work: I would think so yes
Jul 31 14:16:09 <ant_work> or maybe as RDEPENDS_${PN} of x11-common
Jul 31 14:16:46 <ant_work> similarly to what was done by meta-oe's xserver-common
Jul 31 14:16:56 <ant_work> s/was/is/
Jul 31 14:17:02 <bluelightning> ant_work: the thing is it would have to be conditional there since it's only needed for devices that have a touchscreen
Jul 31 14:17:48 <ant_work> did you say xserver-nodm-init will be unified soon?
Jul 31 14:18:17 <ant_work> so x11-common and xserver-common & their RDEPS ?
Jul 31 14:31:44 <bluelightning> ant_work: actually I may have been mistaken on that one... I'm not sure if anyone is actively working on that atm
Jul 31 14:32:25 <bluelightning> ant_work: I suspect xinput-calibrator not being in OE-Core might have been one blocker to that though
Jul 31 14:32:31 <bluelightning> JaMa: can you recall any others?
Jul 31 14:33:17 <ant_work> maybe we need to improve that -common recipe adding more conditionals
Jul 31 14:35:02 <ant_work> pls add this to the long to-do so we don't forget ;)
Jul 31 14:35:03 <ant_work> bbl
Jul 31 14:45:19 <JaMa> bluelightning: I can find an e-mail I've sent about it if it mentions other blockers, but xinput-calibrator was definetely one of them
Jul 31 14:45:38 <bluelightning> ok
Jul 31 14:47:04 <eren> oh, I hit the problem of "waiting for removable media"
Jul 31 14:48:00 <bluelightning> JaMa: I guess this one: http://lists.openembedded.org/pipermail/openembedded-core/2013-February/075336.html
Jul 31 14:55:47 <g0hl1n> Hey everybody, is it possible to completely disable all qemu stuff when building an image?
Jul 31 14:56:58 <g0hl1n> because in my case qemu is opening a lot of files (i think all) and closing it right after.
Jul 31 14:57:49 <g0hl1n> Because of that my build needs over 4 hours to finish altough most of the packages are skipped...
Jul 31 14:58:34 <g0hl1n> in my local.conf #IMAGETEST = "qemu" is commented out...
Jul 31 14:58:44 <g0hl1n> Does anybody have some ideas?
Jul 31 15:01:21 <Net147> satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-boot: busybox-hwclock, any ideas?
Jul 31 15:04:01 <Net147> looks like busybox-hwclock is empty due to http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3b9b8d571da6bb3652427e8ccc7948cbcec0e517 when using systemd
Jul 31 15:04:33 <JaMa> bluelightning: yes, that's the one I was thinking about
Jul 31 15:07:09 <lpapp> JaMa: it is a blocker
Jul 31 15:07:14 <lpapp> it has nice new features, etc.
Jul 31 15:07:26 <lpapp> which we and probably others need, too.
Jul 31 15:07:36 <lpapp> you would seriously block a software update because of PR? :O
Jul 31 15:08:26 <bluelightning> lpapp: patches need to be properly formed before merging, that's the way we operate
Jul 31 15:08:41 <lpapp> it is properly formatted.
Jul 31 15:08:45 <lpapp> like many other patches going in.
Jul 31 15:08:49 <lpapp> please do not be discriminative.
Jul 31 15:09:01 <lpapp> I will leave that patch, too.
Jul 31 15:09:04 <bluelightning> lpapp: that process need not block you because git allows maintaining your own branch easily
Jul 31 15:09:06 <lpapp> my contribution is not welcome anyway
Jul 31 15:09:11 <lpapp> this is not the first blocker change
Jul 31 15:09:13 <lpapp> which people need.
Jul 31 15:09:25 <lpapp> yet, it is being rejected due to pedantic nitpicking unpragmatic nonsense
Jul 31 15:09:48 <fray> all contributors need to follow the requirements of the project they are contributing to.  This include patch headers, commit message records, and general cleanup changes, such as the PR removal..
Jul 31 15:09:57 <bluelightning> lpapp: every project has certain requirements for submitted changes, I'm sure other projects you've worked with have similar requirements
Jul 31 15:09:59 <fray> the quality of the project requires pedantic nitpicking
Jul 31 15:13:08 <JaMa> lpapp: it's called review for other devs to have opportuninty to say needed changes before it's merged
Jul 31 15:14:24 <lpapp> bluelightning: not this stupid, no.
Jul 31 15:14:38 <lpapp> JaMa: I will start meta-qt5 from scratch.
Jul 31 15:14:42 <lpapp> with my qt5 upstream expertise.
Jul 31 15:15:00 <lpapp> I cannot collaborate with people who would block packages for .... formal nitpicking not to get the software into users' hand.
Jul 31 15:15:54 <lpapp> actually, it will be recipes-qt5.
Jul 31 15:16:02 <davest> lpapp: that's your choice. We must maintain our standards to maintain quality
Jul 31 15:16:27 <davest> lpapp: and it's such a little thing, yes?
Jul 31 15:16:28 <fray> Note, someone else has already started a meta-qt5: https://github.com/meta-qt5/meta-qt5
Jul 31 15:16:37 <lpapp> davest: yes, people would block it ffs...
Jul 31 15:16:45 <lpapp> such a little minor nonsense.
Jul 31 15:16:48 <JaMa> fray: that's mine
Jul 31 15:16:53 <lpapp> to block it ... like people cannot get the software for that?
Jul 31 15:17:16 <lpapp> I think I have an entirely different vision with accepting contributions and towards end users.
Jul 31 15:17:30 <bluelightning> lpapp: nobody is blocking you from being able to build with the fixes applied - you can use a branch containing your changes until they are merged
Jul 31 15:17:40 <bluelightning> or otherwise addressed
Jul 31 15:17:41 <lpapp> bluelightning: yes, nice joke.
Jul 31 15:17:46 <lpapp> you are not blocked, you can fork the project.
Jul 31 15:17:59 <lpapp> sure, nobody is blocked to contribute to M$ either.
Jul 31 15:18:00 <bluelightning> lpapp: I'm being completely serious, this is how people get their work done
Jul 31 15:18:03 <lpapp> they can rewrite it in their branch.
Jul 31 15:18:18 <lpapp> bluelightning: you are seriously not making sense IMO then.
Jul 31 15:18:27 <JaMa> lpapp: if you're not going to follow rules set by layer maintainer, then why you're surprised that your contributions aren't immediately applied?
Jul 31 15:18:47 <lpapp> JaMa: stupid rules are stupid
Jul 31 15:18:57 <lpapp> I build the software for the users
Jul 31 15:19:04 <JaMa> lpapp: do you understand wht PR service is?
Jul 31 15:19:05 <lpapp> not a few devs to satisfy the "formal ego".
Jul 31 15:19:09 <JaMa> PR in recipes is stupid
Jul 31 15:19:24 <JaMa> rule to remove them when possible is reasonable way to get rid of them
Jul 31 15:19:41 <lpapp> yes, argue a few more hours about it, just not with me, please, thanks.
Jul 31 15:19:56 <lpapp> I have better things to do than arguing about nuances which even block end users.
Jul 31 15:20:06 * JaMa off to doing something more useful
Jul 31 15:21:05 * lpapp is pushing the qt5 improvements to his "own branch" because he is "not" blocked.
Jul 31 15:32:39 <cfo215> anyone out there using yocto for beaglebone black?  I can't seem to find any information on using the bitbaked am335x-evm images to build an SD card that can boot on the BBB.  Can anyone help me?
Jul 31 15:33:41 <jkridner> cfo215: yocto = poky?
Jul 31 15:33:57 * jkridner uses meta-beagleboard on occasion
Jul 31 15:34:00 <cfo215> jkrinder: yes poly
Jul 31 15:34:06 <cfo215> used hob to generate images
Jul 31 15:34:08 * jkridner hasn't used poky
Jul 31 15:34:55 <lpapp> cfo215: do you like hob
Jul 31 15:35:35 <cfo215> just started using yocto/poky/hob.  it seems to work.  It at least generated an image.
Jul 31 15:37:05 <lpapp> cfo215: what do you prefer about it compared to bitbake?
Jul 31 15:37:11 <lpapp> thinking of writing a better frontend in Qt. :p
Jul 31 15:37:13 <lpapp> and I need input.
Jul 31 15:37:16 <cfo215> lpapp: but I cant seem to get the SD card configure correctly.  I have the uImage, u-boot.bin, dtc files etc and rootfs tarball.  i use Ti's mk2partSD shell script to format SD Card.
Jul 31 15:37:50 <lpapp> "writing frontend" -> rewriting bitbake in C++, too.
Jul 31 15:38:44 <cfo215> lpapp: sorry man, I'm a noob when it comes to bitbake.  which is why I'm using hob.  It allegedly builds the configuration for you.  All I have to do is pick a device and type of image.  and then I can tweek the individual packages to install if I wnat to.
Jul 31 15:39:52 <lpapp> ok, thanks.
Jul 31 15:40:02 <cfo215> lpapp: speaking of Qt... that's what I'm trying to get to work on my BBB.  Do you have a BBB and have you had success porting Qt to it?
Jul 31 15:43:01 <lpapp> cfo215: I have a beagleboard.
Jul 31 15:43:05 <lpapp> but I do not use it anymore.
Jul 31 15:43:26 <lpapp> I am working on getting qt5 and kde frameworks right, in general, though.
Jul 31 15:43:38 <lpapp> cfo215: I will try to push my recipes today to the KDE repository if you are interested in.
Jul 31 15:44:34 <cfo215> lpapp: I really need to find a solution for the BBB.  But thanks for the offer.
Jul 31 15:45:07 <lpapp> cfo215: well, it is just arm.
Jul 31 15:45:15 <lpapp> it does not matter from qt's point of view more than that.
Jul 31 15:45:40 <lpapp> which means I expect my recipes work on arm off-hand.
Jul 31 15:45:58 <cfo215> I'll have a look
Jul 31 15:46:24 <cfo215> where your recipe located at?
Jul 31 15:46:32 <lpapp> cfo215: but it is qt5, not qt4.
Jul 31 15:46:37 <lpapp> but I think that is even better for you, no?
Jul 31 15:46:46 <lpapp> cfo215: on my machine at home, currently.
Jul 31 15:47:06 <cfo215> yes, that could be better.
Jul 31 15:47:16 <lpapp> cfo215: will be pushing here tonight hopefully, http://quickgit.kde.org/
Jul 31 15:47:24 <lpapp> recipes-qt5 recipes-kf5, or so
Jul 31 15:48:07 <lpapp> cfo215: do you wanna use fb, x, wayland, etc?
Jul 31 15:48:15 <cfo215> what I really need (I'm supposing) is the qmake.conf and command line for ./configure that works with my device.  hardfloat
Jul 31 15:49:14 <cfo215> frame buffer and ts lcd support
Jul 31 15:49:21 <cfo215> via qws
Jul 31 15:49:29 <lpapp> it is jsut the matter of -xplatform and -platform.
Jul 31 15:49:33 <lpapp> qws?
Jul 31 15:49:36 <lpapp> probably not ...
Jul 31 15:49:45 <lpapp> that got replaced in Qt5 by QPA. ;)
Jul 31 15:49:57 <cfo215> ic, still on 4
Jul 31 15:50:12 <lpapp> any reason?
Jul 31 15:50:47 <cfo215> not really.  Guess I just don't want to be on the bleeding edge.
Jul 31 15:51:01 <lpapp> Qt5 was released last December
Jul 31 15:51:05 <lpapp> it is not really bleeding edge. :)
Jul 31 15:51:10 <cfo215> :)
Jul 31 15:51:25 <lpapp> just because Yocto does not have it sadly, it does not mean, it is bleeding edge.
Jul 31 15:51:40 <cfo215> Any help would with Qt would be greatly appreciated.  But I still got to get my BBB booting...
Jul 31 15:51:43 <rburton> lpapp: could say the same about toolchains ;) perspectives vary.
Jul 31 15:52:07 <lpapp> cfo215: I will probably also blog about it
Jul 31 15:52:12 <lpapp> http://lpapp.blogspot.com
Jul 31 15:52:21 <lpapp> rburton: eh?
Jul 31 15:53:49 <lpapp> as far as I am aware Yocto has the latest major gcc, 4.8
Jul 31 15:53:59 <lpapp> or 4.7, sorry.
Jul 31 15:54:03 <lpapp> one of*
Jul 31 15:54:16 <lpapp> that is good enough for C++11, really.
Jul 31 15:54:16 <rburton> we've 4.8
Jul 31 15:54:27 <lpapp> not in my version.
Jul 31 15:54:46 <bluelightning> lpapp: the ecosystem *does* have qt5 recipes, in meta-qt5
Jul 31 15:54:49 <lpapp> but still, I do not understand your comment.
Jul 31 15:54:54 <lpapp> bluelightning: which are broken.
Jul 31 15:54:57 <lpapp> outdated
Jul 31 15:54:58 <lpapp> missing
Jul 31 15:55:01 <lpapp> lacking basic stuff
Jul 31 15:55:12 <bluelightning> lpapp: they're being used by a commercial firm, so they can't be that broken
Jul 31 15:55:26 <bluelightning> lpapp: basic?
Jul 31 15:55:31 <rburton> contributions welcome!
Jul 31 15:55:41 <lpapp> I already said I will push my recipes tonight?
Jul 31 15:55:54 <lpapp> I think they are in a much better shape. :)
Jul 31 15:56:30 <lpapp> and more complete.
Jul 31 15:56:43 <lpapp> hence I do not see the future of "meta-qt5".
Jul 31 15:56:46 <cfo215> lpapp: thanks I'll look at your info... now I got to get back to my initial question about using the created images to create an SD card that will actually boot on the BBB.
Jul 31 15:56:47 <lpapp> as it seems now, at least.
Jul 31 15:57:01 <lpapp> cfo215: what is the issue at hand?
Jul 31 15:57:13 <bluelightning> lpapp: have you tried to contribute your improvements to meta-qt5?
Jul 31 15:57:53 <lpapp> bluelightning: no, it is completely different stuff
Jul 31 15:57:54 <cfo215> I copy all the required files (using info from various sources since I can't seem to find a good answer). to boot and rootfs on the sd card.
Jul 31 15:58:06 <cfo215> but the boot process hangs
Jul 31 15:58:15 <lpapp> bluelightning: and no, I do not wish to work with people whose biggest problem is "PR".
Jul 31 15:58:23 <lpapp> for blocking and unwelcome a contribution.
Jul 31 15:58:32 <cfo215> lpapp: Waiting for root device /dev/mmcblk0p2...
Jul 31 15:58:35 <lpapp> this rule cannot work for my qt5 recipes.
Jul 31 15:58:58 <rburton> lpapp: you do realise that you could have deleted the PR line and re-sent the patch in a fraction of the time you've moaned about a policy you were not aware of?
Jul 31 15:59:15 <lpapp> rburton: you guys started the moaning?
Jul 31 15:59:19 <lpapp> about a nonsense stuff?
Jul 31 15:59:37 <lpapp> (and still continue)
Jul 31 16:00:01 <lpapp> you do realize I fully agree with unwelcoming end users and contributions
Jul 31 16:00:03 <cfo215> does anyone out there have a recipe for creating the SD Card for BBB post bitbaking the image?
Jul 31 16:00:09 <lpapp> this might be an Intel way, but not open source and governed.
Jul 31 16:00:25 <lpapp> and end user oriented.
Jul 31 16:00:29 <bluelightning> lpapp: we have certain requirements for patch submissions, just like all open source projects do
Jul 31 16:00:37 <lpapp> yes, stupid IMO
Jul 31 16:00:40 <bluelightning> lpapp: just try to get a patch into the kernel, you'll see we're actually pretty relaxed by comparison
Jul 31 16:00:45 <rburton> lpapp: it's not nonsense, and it's called "review".  jama's message was and i quote "remove PR assignments in your u-boot patch". that is not a moan, that's a simple request.
Jul 31 16:00:50 <lpapp> so I avoid collaborating as I already wrote several times. Why do you keep asking the same then?
Jul 31 16:00:58 <lpapp> Why do you get me repeating dozens of times?
Jul 31 16:01:03 <rburton> lpapp: i wish i knew
Jul 31 16:01:26 <Krz> Guys, I need some stuff from meta-oe like: iputils / iptables. Is there any Yocto source of that? Or adding meta-openembedded/meta-oe to bblayers.conf is the proper way of doing it?
Jul 31 16:01:28 <lpapp> rburton: that is a moan.
Jul 31 16:01:44 <lpapp> when you say it would block end users and contributions
Jul 31 16:01:51 <lpapp> surely, it is nice to have maybe, but blocking? Hell not.
Jul 31 16:02:00 <rburton> Krz: oe-core has iptables in recipes-extended
Jul 31 16:02:29 <lpapp> I did not tip on someone's shoes because he did not paste a code review link to bugzilla
Jul 31 16:02:35 <lpapp> I mentioned that, maybe do next time.
Jul 31 16:02:42 <bluelightning> Krz: both iputils and iptables are in the core set of recipes; did you mean some other ones?
Jul 31 16:02:48 <lpapp> that is difference between "quality" and "get things done" approaches.
Jul 31 16:02:51 <lpapp> the*
Jul 31 16:03:23 <jkridner> gm all
Jul 31 16:03:24 <davest> lpapp: ironic - I have heard you are really picky about patches into the code you maintain
Jul 31 16:03:30 <davest> :-)
Jul 31 16:03:42 * jkridner is multitasking, so ping if you for sure need my attention.
Jul 31 16:04:26 <lpapp> davest: when it does not hurt the user, sure.
Jul 31 16:04:30 <lpapp> that is the time for being nitpicky.
Jul 31 16:04:34 <lpapp> but when it hurts, it is not.
Jul 31 16:04:36 <bluelightning> lpapp: FWIW, in the old days of OpenEmbedded, we had the "getting things done" approach - and the result was different people with different requirements all falling over eachothers' changes because there wasn't much in the way of review
Jul 31 16:04:53 <lpapp> bluelightning: you think that there is black and white.
Jul 31 16:04:58 <lpapp> the world is a bit more colorful.
Jul 31 16:05:00 <lpapp> luckily.
Jul 31 16:07:08 <lpapp> davest: just to make it clear, as I have already done a favor for someone for a not must have thing when asked: I am not against removing PR
Jul 31 16:07:15 <lpapp> davest: and if I am asked to do next time, I will do.
Jul 31 16:07:20 <lpapp> or if I am asked nicely.
Jul 31 16:07:31 <lpapp> but when it is claimed to be a blocker for a useful feature, well, that frankly annoys me.
Jul 31 16:08:14 <lpapp> "with quality against UX"
Jul 31 16:08:38 <bluelightning> Krz: to answer your question about meta-oe, you can just add it as a layer; but be aware it is quite large and contains one or two appends/overlayed recipes that we're in the process of removing
Jul 31 16:09:20 <lpapp> davest: also, I do not currently maintain any FOSS software.
Jul 31 16:09:29 <bluelightning> Krz: ("we" meaning the OpenEmbedded community, since YP doesn't maintain recipes in meta-oe)
Jul 31 16:09:43 <davest> lpapp: serial module ?
Jul 31 16:09:43 <lpapp> I get rid of the last project maintenance 1-2 weeks ago, luckily.
Jul 31 16:09:50 <lpapp> got*
Jul 31 16:14:07 <Krz> bluelightning: I added recently few things and mixed up what comes from where. I need from meta-openembedded: hostap-daemon and iw
Jul 31 16:14:41 <Krz> I know about this clashing recipes, so that's why I'm asking if adding openembedded is Yocto way or not so much
Jul 31 16:15:38 <rburton> Krz: ah, they're in meta-connectivity. you may be able to add that without meta-oe itself
Jul 31 16:15:47 <rburton> Krz: its only the meta-oe layer that is "badly behaved"
Jul 31 16:16:18 <Crofton|work> rburton, what is badly behaved about it?
Jul 31 16:16:21 <bluelightning> Krz: they're both in meta-oe
Jul 31 16:16:27 <bluelightning> rburton: ^
Jul 31 16:16:32 <rburton> oh crap
Jul 31 16:16:35 <rburton> i can't read
Jul 31 16:16:42 <rburton> sorry
Jul 31 16:17:03 <rburton> Crofton|work: the remaining bbappends and overlaid recipes - just adding meta-oe isn't a no-op
Jul 31 16:17:16 <Crofton|work> hwo many of those are left?
Jul 31 16:17:19 <rburton> only a few
Jul 31 16:17:30 <rburton> and the big one is something i've been staring at for a while now
Jul 31 16:17:38 <rburton> (xorg init)
Jul 31 16:17:38 <Crofton|work> which one is that?
Jul 31 16:17:41 <Crofton|work> ah
Jul 31 16:18:40 <Krz> isn't meta-openembedded totally Yocto-independent?
Jul 31 16:18:58 <rburton> Krz: it depends on oe-core, which is YP
Jul 31 16:19:38 <bluelightning> Crofton|work: basically: xserver-nodm-init, gst-ffmpeg, tslib, busybox
Jul 31 16:19:48 <Krz> alright
Jul 31 16:19:58 <rburton> is anyone *actually* using tslib still?
Jul 31 16:20:10 <Crofton|work> we need to make a FAQ on the wiki about this
Jul 31 16:20:11 <bluelightning> rburton: opie ;)
Jul 31 16:20:19 <bluelightning> rburton: but seriously I'm not sure other than that
Jul 31 16:20:34 <rburton> bluelightning: i suspect anyone else using qt on fb
Jul 31 16:20:53 <rburton> need to find a friendly qt developer, i'll ping thiago maybe
Jul 31 16:44:54 <zibri> asked earlier, trying again :). I'm having issues with do_rootfs for our image after moving from dylan to master, i get "error: package update-rc.d is not installed" (same error message for update-rc.d, base-passwd and run-postinsts). is this something anybody recognizes?
Jul 31 16:45:33 <fray> Usually those messages come from a system where there are missing dependencies for some reason.
Jul 31 16:45:59 <fray> the package has a package dependency on 'update-rc.d', but the build system never built it for some reason.
Jul 31 16:46:14 <zibri> afaict, those packages are being installed (according to the log) (hold on, i'll paste it somewhere)
Jul 31 16:46:16 <fray> check your tmp/deploy/<package>/* and see if an update-rc.d package exists
Jul 31 16:46:32 <fray> the error is saying it didn't exist or was not installed, but was required
Jul 31 16:47:55 <zibri> fray: it isn't available in tmp/deploy/rmp/, no...
Jul 31 16:48:09 <fray> ya, thats the issue then.. the package is missing..
Jul 31 16:48:24 <fray> you may have to do bitbake -c clean update-rc.d ; bitbake update-rc.d
Jul 31 16:49:32 * fray has no idea what could have caused the missing package.
Jul 31 16:49:32 <zibri> oh, my bad.. it *is* available in tmp/deplo/rpm/all
Jul 31 16:49:49 <fray> in that case, I'm not sure.
Jul 31 16:50:11 <fray> how recent is your master checkout?
Jul 31 16:50:25 <zibri> today
Jul 31 16:50:42 <zibri> http://x20.se/rootfs_package_missing.log here's the do_rootfs log
Jul 31 16:50:46 <fray> there were some recent changes in the resolving code (last few days)..
Jul 31 16:50:52 <fray> perhaps something went wrong in that?
Jul 31 16:51:05 <zibri> hum, ok. will have a look
Jul 31 16:51:22 <fray> ya, first suggestion I can give you.. try to back up a day or so and retry it..
Jul 31 16:51:31 <fray> if it works, then it's likely something in the recent smart change..
Jul 31 16:51:31 <zibri> right, thanks!
Jul 31 16:52:05 <zibri> btw, i also got a lot of bb{warn,note} "command not found" from something in do_rootfs
Jul 31 16:52:12 <fray> it's really odd though..
Jul 31 16:52:30 <zibri> but not sure where, was hoping to get the task to complete before trying to investigate that issue..
Jul 31 16:52:33 <fray> because from the logs it -did- install update-rc.d, base-passwd and run-postinsts..
Jul 31 16:52:46 <zibri> yes, that's what i thought :)
Jul 31 16:53:17 <fray> can you look at the file: /var/opt/builds/olofjn/oe/master/build/porky/tmp/work/p3367-poky-linux/axis-image-porky/1.0-r0/temp/run.do_rootfs.3194
Jul 31 16:53:29 <fray> and see what is scheduled to happen -after- it prints "Logfile is clean"
Jul 31 16:54:27 <fray> it almost looks to me like something in your configuration is attempting to do some cleanup, validation, etc.. and isn't getting the correct result, so it assumes those things are not installed..
Jul 31 16:54:41 <fray> (I'm still getting abck from vacation, so the oe-core I'm using is a week or so old still)
Jul 31 16:54:56 <fray> but I havn't seen anything like that
Jul 31 16:56:25 <zibri> log_check() is called as the last command in rootfs_rpm_do_rootfs(). that is followed by rootfs_remove_unneeded
Jul 31 16:56:42 <zibri> hah.. "# update-rc.d, base-passwd, run-postinsts are no further use, remove them now"
Jul 31 16:56:53 <zibri> in rootfs_remove_unneeded
Jul 31 17:02:38 <fray> how strange
Jul 31 17:12:30 <zibri> it's the rpm invocation in rootfs_remove_packages that fails, adding || : did make it complete, but... uhm. i don't think that's the right solution =)
Jul 31 17:12:46 <fray> I would agree..
Jul 31 17:15:18 <fray> I'll go pull down the latest and see if I can spot an obvious flaw..
Jul 31 17:15:28 * mr_science is not sure rpm is the "right" solution...
Jul 31 17:15:37 <zibri> mr_science: :)
Jul 31 17:15:40 <mr_science> but that's just me
Jul 31 17:15:44 <fray> it's _a_ solution..
Jul 31 17:15:55 <fray> the right one depends on so many factors it's hard to say..
Jul 31 17:16:04 <mr_science> yeah, i just got tired of rpm a long time ago
Jul 31 17:16:38 <mr_science> switched to gentoo and then learned to appreciate debian/apt...
Jul 31 17:17:17 <mr_science> so i haven't really touched rhel/centos/whatever for several years
Jul 31 17:17:50 <fray> well, I see the needs as being a continuum..  you've got a lot of folks who don't need a package manager, other then to setup the filesystem..  you have a group who want light weight (opkg).. and you have folks who want the full weight of RPM..
Jul 31 17:18:13 <fray> deb can fit into that continuum.. but it's somewhere between opkg and rpm
Jul 31 17:18:51 <mr_science> for me, i would choose deb over rpm but that's one of the big things open source is all about
Jul 31 17:19:03 <mr_science> choice
Jul 31 17:21:42 <mr_science> seems like opkg has all the basics, which is certainly enough for my rpi needs
Jul 31 17:23:20 <mr_science> fray: i'd be interested in seeing some kind of requirements analysis for that
Jul 31 17:24:18 <zibri> it seems that the rootfs_remove_unneeded was introduced in 1ce182e79 (poky)
Jul 31 17:25:18 <mr_science> i'm not quite sure excatly what would drive the need for more than opkg in an embedded runtime...
Jul 31 17:25:19 <zibri> merged 2013-06-11
Jul 31 17:27:15 <fray> without going indepth, it's everything from familiarity, third party package integration, package signing/validation, and rollback support
Jul 31 17:27:48 <fray> there are a lot of systems that bridge between 'dedicated server' and 'embedded space'.. this is the 'reasonable' area for RPM usage in my experience..
Jul 31 17:28:08 <fray> most of the users I know of are in the telco space (think call routing, call billing, cell tower control, etc)
Jul 31 17:28:21 <fray> they want package validation, signatures, rollback, etc..
Jul 31 17:29:41 <bluelightning> luckily we provide all three options :)
Jul 31 17:29:59 <bluelightning> though it's fair to say that ipk/rpm are the two most proven choices
Jul 31 17:30:31 <bluelightning> within our system, that is
Jul 31 17:31:23 <fray> yup..
Jul 31 17:31:43 <fray> I certainly advocate ipk for the majority what people consider embedded system.. rpm is simply too heavy weight..
Jul 31 17:32:37 <mr_science> fray: that's pretty much what i was thinking...
Jul 31 17:32:53 <mr_science> just not requirements i've had to meet before
Jul 31 17:33:32 <fray> familiarity with RPM is likely the largest single requirement that has driven me to support RPM for my customers
Jul 31 17:33:52 <mr_science> hmm, gpg signing of ipks would be fairly straight-forward...
Jul 31 17:34:26 <fray> RPM also has modes that are security compliant.. (for the life of me I can't remember the certification number anymore)
Jul 31 17:34:38 <fray> it's one of the NIST levels
Jul 31 17:34:58 <zibri> speaking of familiarity with rpm, how do i list installed packages? :)
Jul 31 17:35:05 <mr_science> we added gpg signing to our install package a while back
Jul 31 17:35:19 <rburton> mr_science: if you're volunteering to maintain the dpkg support in YP that would be great!
Jul 31 17:35:22 <fray> zibri, in the cross environment or on the target?
Jul 31 17:35:25 <mr_science> rpm -qa i believe...
Jul 31 17:35:31 <zibri> cross environment
Jul 31 17:35:36 <fray> :)  ya, that is one of the biggest holes in dpkg support right now.. lack of a consistent maintainer
Jul 31 17:35:56 <zibri> but that's just a matter of adding --root, right? i'll try :)
Jul 31 17:35:59 <fray> zibri, in the tmp/work/.../image... directory there is a list of what was installed generated.. installed_packages.txt or something like that
Jul 31 17:36:15 <mr_science> rburton: let me think about that for a bit...
Jul 31 17:36:30 <fray> you have to use the version of RPM that is in the build system.  Your host system version likely won't work.. also you need to run under 'pseudo' so that the chroot and similar support is available to you..
Jul 31 17:36:31 <zibri> fray: i wanted to do a package list just before the rpm invocation that fails
Jul 31 17:36:49 <zibri> i'm running the do_rootfs from the devshell
Jul 31 17:36:53 <fray> script wise.. it's easy as things are already specificed you just have to run them..
Jul 31 17:36:56 * fray goes to look
Jul 31 17:37:51 <mr_science> zibri: looks like rpm -qa --root=/path/to/rootfs shoudl work
Jul 31 17:37:54 <fray> within the install scripts:
Jul 31 17:37:55 <fray> rpm --root $target_rootfs --dbpath /var/lib/rpm -qa
Jul 31 17:38:00 <zibri> thanks
Jul 31 17:38:21 <fray> you should pass the dbpath so that if the macros file can't be instantiated for some reason (which can happen in a cross install) it knows where to look
Jul 31 17:38:30 <mr_science> fray must be in a later timezone...
Jul 31 17:38:30 <fray> alternatively you can query smart:
Jul 31 17:38:49 <fray> smart --data-dir=${target_rootfs}/var/lib/smart query
Jul 31 17:38:51 <fray> if I remember ight
Jul 31 17:39:07 <fray> (smart is the package management front end to RPM in oe)
Jul 31 17:40:53 <mr_science> rburton: i assume there are open bugs on that?
Jul 31 17:40:59 <fray> Hmmm
Jul 31 17:41:10 <fray>         if ${@base_contains("IMAGE_FEATURES", "package-management", "false", "true", d)}; then
Jul 31 17:41:12 <lpapp> fray: dpkg is pretty good for embedded.
Jul 31 17:41:14 <lpapp> we did that for meego
Jul 31 17:41:16 <fray>                         rootfs_remove_packages update-rc.d base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}
Jul 31 17:41:45 <fray> so it looks like if you don't have the package-management enabled as an IMAGE_FEAUTRE< it will try to remove those things..
Jul 31 17:41:50 <fray> it should be able to do so though
Jul 31 17:42:56 <rburton> mr_science: its just not very well tested or used
Jul 31 17:43:19 <nine_pt> bitbake -e busybox | grep ^PACKAGES= shows busybox-staticdev, but executing bitbake busybox-staticdev says: NoProvider: busybox-staticdev Any idea ?
Jul 31 17:43:53 <fray> bitbake uses recipe names, while PACKAGES are package names.. (those are the names you should use in the IMAGE_INSTALL (in image recipes)
Jul 31 17:43:59 <mr_science> alright, lemme take a look tonight when i get home...
Jul 31 17:44:01 <fray> you will need to invoke bitbake busybox
Jul 31 17:46:45 <nine_pt> humm ... busybox is on  the image, and already generated some of the packages but staticdev isn't there. If I run the bitbake busybox it don't detect any change and don't say to compile again
Jul 31 17:48:00 <mr_science> nine_pt: try "ls /path/to/tmp/deploy/*/ipk/busybox-*" and see what packages were built
Jul 31 17:49:21 <nine_pt> ls tmp/deploy/ipk/armv5te/busybox-*: busybox-dbg busybox-dev busybox-syslog busybox-udhcpc busybox-udhcpd
Jul 31 17:49:27 <mr_science> there probably are version of the busybox recipe that don't produce a staticdev package
Jul 31 17:50:20 <fray> Ya, the staticdev is only generated if the package generates static libraries.
Jul 31 17:50:27 <fray> As far as I know busybox does not do this normally
Jul 31 17:50:40 <mr_science> you might need to enable static if you really need it
Jul 31 17:51:01 <fray> even enabling static busybox likely won't.. as it's only a 'dev' package..
Jul 31 17:51:12 <fray> but enablign static would change the binary in the 'busybox' package..
Jul 31 17:51:13 <rburton> zenlinux: good work on the HN post about minnow :)
Jul 31 17:51:26 <zenlinux> rburton, heh, thanks
Jul 31 17:51:46 <nine_pt> I really need to enable it :) on the recipe busybox.inc don't have any reference to statuc
Jul 31 17:51:50 <nine_pt> *staticdev
Jul 31 17:51:59 <nine_pt> any idea how I can add that ?
Jul 31 17:52:22 <zibri> fray: thanks for your help! i figured it out. core-image-minimal had remove_packaging_data_files in ROOTFS_POSTPROCESS_COMMAND, but removed it in 98ce0b7 (poky commit). we still had it in our image :/
Jul 31 17:52:32 <zibri> removing it solved the issue
Jul 31 17:52:40 <fray> excellent!
Jul 31 17:53:43 <fray> nine_pt why do you want a statically linked busybox?
Jul 31 17:53:58 <fray> looking at the busybox recipe, it clears the static setting when it first configures the recipe
Jul 31 17:54:24 <fray> (you should be able to enable it though if needed)
Jul 31 17:54:45 <nine_pt> fray: long story made short, have a board if I try to run any command in it, it gives segmentation fault
Jul 31 17:54:48 <fray> but in most cases, static busybox will actually increase the size and memory usage of theresulting filesystem..
Jul 31 17:55:13 <fray> ahh so something is going wrong w/ COW and or dynamic loading
Jul 31 17:55:17 <nine_pt> but if I upload a static binary it works, I am thinking on a corrupt library on memory
Jul 31 17:55:49 <nine_pt> I think so, but need more tools to see if can get more info
Jul 31 17:56:10 <nine_pt> I only need to generate busybox static once, I don't need it on my images
Jul 31 17:56:25 <fray> you need to add a file that ends in .cfg, to the busybox sources.. and in that file have 'CONFIG_STATIC yes'  (or something like that) whatever the setting looks like when you run configure
Jul 31 17:56:33 <fray> alternatively you may be able to do:
Jul 31 17:56:41 <fray> bitbake -c menuconfig busybox ; enable it and then recompile
Jul 31 17:57:21 <nine_pt> is there a option on busybox to be compiled static ?
Jul 31 17:57:34 <bluelightning> zibri: I'll try to make sure we note that in the 1.5 migration docs
Jul 31 17:57:37 <nine_pt> I was thinking that I will need to change compilation settings
Jul 31 17:57:43 <mr_science> you could append -static to CFLAGS
Jul 31 17:57:47 <zibri> bluelightning: excellent, thanks :)
Jul 31 17:58:00 <fray> nine_pt, there should be a configuration option that enables static
Jul 31 17:58:13 <fray> it's called 'CONFIG_STATIC', but I don't know what it looks like in the menuconfig
Jul 31 17:58:30 <mr_science> looks like the older (classic) recipe does it that way
Jul 31 17:58:45 <mr_science> export CFLAGS:="${CFLAGS} -static"
Jul 31 17:59:14 <mr_science> other than that, there's just a do_prepare_config_append_pn-busybox-static() function and that's it
Jul 31 17:59:18 <fray> ya, I don't think that will work, but it might.  I've never tried it
Jul 31 18:00:03 <mr_science> nine_pt: give that a try
Jul 31 18:00:05 <nine_pt> I find the option
Jul 31 18:00:09 <Circuitsoft_> I tried putting a PREFERRED_VERSION_package-name= line in a bitbake recipe that had package-name in RDEPENDS_${PN} but it doesn't seem to work. Should it?
Jul 31 18:00:11 <mr_science> only takes a few minutes...
Jul 31 18:00:39 <fray> PREFERRED_VERSION needs to refer to the recipe name, not the package name.  RDEPENDS refers to the package name
Jul 31 18:00:50 <nine_pt> save he  configuration, but how I force the bitbate busybox to compile it ? it don't detect any change or is refusing to work ...
Jul 31 18:01:03 <fray> bitbake -C build busybox
Jul 31 18:01:23 <Circuitsoft_> fray: In this case the package name and recipe name are the same.
Jul 31 18:01:50 <fray> ok.. then it should adjust which version is used to the one specified.. unless the one specified doesn't exist for some reason
Jul 31 18:01:50 <mr_science> Circuitsoft_: i usually put that in the image recipe
Jul 31 18:01:55 <Circuitsoft_> I'm trying to force use of my-package_0.3.5 instead of my-package_git
Jul 31 18:02:13 <fray> ya, that should just work.. it needs to be in the global local.conf, or a distro.conf or something
Jul 31 18:02:17 <Circuitsoft_> I want my-app_0.17 to require my-package_git and my-app_git to require my-package_git
Jul 31 18:02:24 <fray> putting it into the recipe isn't enough to trigger the change
Jul 31 18:02:50 <fray> RDEPENDS can included versioned dependencies, but for resolution purposes I believe bitbake ignores that..
Jul 31 18:03:12 * mr_science forgets which OE world he lives in...
Jul 31 18:03:44 <Circuitsoft_> Is there a special case for git to make it prefer the highest-numbered non-git version of a package over the git version?
Jul 31 18:04:30 <mr_science> Circuitsoft_: see if there's distro file already in conf/machine/include or similar
Jul 31 18:05:00 <mr_science> rpi-default-versions.inc is one example
Jul 31 18:05:13 <Circuitsoft_> No includes, only my-machine.conf
Jul 31 18:05:34 <mr_science> make one
Jul 31 18:06:27 <Circuitsoft> There are a number of PREFERRED_VERSION_package lines in my-machine.conf - should they all go into said include file?
Jul 31 18:06:29 <mr_science> as fray mentioned, could also be under conf/distro/foo
Jul 31 18:06:47 <mr_science> they're okay where they are, i think
Jul 31 18:07:03 <mr_science> just add what you need to that and try it out
Jul 31 18:07:26 <mr_science> bitbake -c clean recipe and build it again
Jul 31 18:08:37 <mr_science> the rpi layer has several rpi-default-foo.inc files in conf/machine/include
Jul 31 18:09:28 <mr_science> not sure why it was done that way...  might make more sense under conf/distro since it's really not machine-specific
Jul 31 18:10:33 <Circuitsoft> I was also hoping to switch from core-image-mydist.bb in two branches to core-image-devel.bb and core-image-release.bb in the same branch. That way I would also get different names for devel vs release images.
Jul 31 18:12:37 <Circuitsoft> Looks like I'm still getting only the git version of the package, even after setting a preferred version to a number.
Jul 31 18:18:06 <fray> what does bitbake -e show you?  (grep for preferred_version)
Jul 31 18:26:36 <Circuitsoft> fray: The package I'm trying to pin didn't show up.
Jul 31 18:27:03 <Circuitsoft> I'm dumb. I accidentally did PREFERRED_PROVIDER
Jul 31 18:27:07 <mr_science> Circuitsoft: sounds like you want two custom image recipes, one to include devel_ and one to include release_
Jul 31 18:27:23 <Circuitsoft> my_science - yes, but that's a separate issue.
Jul 31 18:27:40 <mr_science> which can live on the same branch just fine...
Jul 31 18:27:49 <Circuitsoft> The only difference between what I want in the devel_ and release_ image recipes is PREFERRED_VERSION_myapp.
Jul 31 18:28:06 <Circuitsoft> But it's appearing that I can't do that in the image recipe.
Jul 31 18:28:17 <mr_science> are you sure?
Jul 31 18:28:47 <mr_science> i know i have that in my classic images, have to check my poky images when i get home
Jul 31 18:29:29 <mr_science> the image value *should* override whatever you set as the distro default
Jul 31 18:29:55 <Circuitsoft> I tried setting 'PREFERRED_VERSION_my-pack = "0.3.5"' in my-app_0.17.bb to and it didn't work where 'PREFERRED_VERSION_my-pack ?= "0.3.5"' in conf/machine/mymach.conf did.
Jul 31 18:30:57 <mr_science> try it in the image recipe instead of the package recipe
Jul 31 18:32:07 <mr_science> then clean the package and bitbake the image recipe again and see what version gets pulled in
Jul 31 19:12:18 <mr_science> Circuitsoft: got it working the way you want?
Jul 31 19:13:20 <Circuitsoft> I think so - now I'm trying to install mypack-0.3.5 on a target in place of mypack-git on the target.
Jul 31 19:14:17 <Circuitsoft> rpm is /really/ slow.
Jul 31 19:15:33 <mr_science> sounds like you want RCONFLICTS/RREPLACES
Jul 31 19:52:26 <mr_science> so our first major change since the last release of the camera is now back-end server integration *and* a newly revamped redis message protocol...
Jul 31 19:53:02 <mr_science> so far "integration" looks like a huge multi-car pileup
Jul 31 19:54:22 <mr_science> and, like the freeway pileup, it's pretty much too gruesome to look at, yet you can't look away...
Jul 31 19:55:18 <fray> FYI, the only place we know that RPM is very slow is memory contrained systems or MIPS.. (and we have no idea WHY on mips)
Jul 31 19:55:30 <fray> change to ipk for faster behavior, unless you need RPM specific behavior
Jul 31 19:59:42 <Circuitsoft> fray: Does using 600MB of RAM on a 1GB system count as memory-constrained?
Jul 31 19:59:57 <Circuitsoft> Also, our rootfs is on an SD card, so it's possibly disk-bound.
Jul 31 20:00:27 <mr_science> yes, even a good sdcard is pretty slow...
Jul 31 20:01:09 <mr_science> that can be mitigated somewhat with zram and mount options, but when you have to write to the card, you have to write to the card...
Jul 31 20:02:00 <fray> depends on what you are doing
Jul 31 20:02:07 * mr_science has been more than pleasantly surprised at the runtime performance and footprint on rpi
Jul 31 20:02:15 <fray> for filesystem, for incremental installs (removals) and other berkleydb cache issues that isn't unusual
Jul 31 20:02:36 <fray> ya, I'd never use RPM on an SD card if you can avoid it..
Jul 31 20:02:45 <fray> the berkelyDB access pattern can cause issues in my experience
Jul 31 20:47:46 <quatre> I noticed that the recipe for QEMU available in Yocto does not come with support for VDE. Is there a reason why it was left out?
Jul 31 20:54:46 <abelloni> is there any gui for network configuration in core-image-sato ?
Jul 31 20:57:04 <mr_science> don't think so
Jul 31 20:57:31 <mr_science> the settings gui seemed a little thin when i looked at it
Jul 31 21:07:19 <mr_science> the only network config guis i know of are the big three: connman-ui, wicd, and network-manager
Jul 31 21:07:54 <mr_science> afaik, there's no current recipe for wicd so your choices are somewhat limited
Jul 31 21:13:14 <abelloni> yeah
Jul 31 21:13:23 <abelloni> there is qconnman in meta-oe
Jul 31 21:14:35 <mr_science> i tried to build one of those qt guis and it got so hot the bios shut the machine down
Jul 31 21:15:01 <mr_science> too many jobs/threads for qt i guess...
Jul 31 21:15:24 <Circuitsoft> mr_science: What are you on that has insufficient cooling?
Jul 31 21:15:45 <mr_science> just my test buildbox at home
Jul 31 21:16:21 <Circuitsoft> On my laptop (needs new thermal grease) I wrote a script that watches the contents of /sys/class/hwmon/whatever and will send SIGTSTP and SIGCONT to a build process.
Jul 31 21:16:24 <mr_science> no cool room, it was during a heatwave, and qt is a pita
Jul 31 21:16:57 <mr_science> Circuitsoft: posted that anywhere public?>
Jul 31 21:17:20 <Circuitsoft> No, it was a bash one-liner. I might be able to find it in my .bash_history file, but don't count on it.
Jul 31 21:17:43 <Circuitsoft> But, start your build, do a "ps -AHO ppid" and find the pid of the build process.
Jul 31 21:19:46 <Circuitsoft> while sleep 1; do [ `cat /sys/class/hwmon/my_sensor/temp1_input` -gt 90 ] && kill -TSTP -pgid_of_build_process || [ `cat /sys/class/hwmon/my_sensor/temp1_input` -lt 85 ] && kill -CONT -pgid_of_build_process; done
Jul 31 21:20:13 <Circuitsoft> I think. I just recreated that now. It may need some tweaking.
Jul 31 21:22:11 <Circuitsoft> Should be /sys/class/hwmon/hwmon(a_number_here)/device/temp(pick_a_number)_input
Jul 31 21:22:25 <Circuitsoft> grep . /sys/class/hwmon/hwmon*/device/temp*_input
Jul 31 21:22:41 <Circuitsoft> That will show you all your temperatures. See which one seems to make the most sense.
Jul 31 21:24:55 <Circuitsoft> As for building Qt, having a 12-core machine with hyper-threading and 48GB of RAM is quite helpful...
Jul 31 21:32:29 <mr_science> this is a 95W amd triple-core with 8 GB ram and an unlocked 4th core
Jul 31 21:32:43 <mr_science> pretty cheap-ass hardware...
Jul 31 21:33:11 <mr_science> just something i threw together out of spare/random parts
Jul 31 21:37:17 <Circuitsoft> I guess I'm lucky that I'm doing this for work. The build machine is a 1u dual-socket HP rackmount server with 96GB RAM (can hold up to 192GB), two Xeon X5650s, and lots of disk running VMWare ESXi.
Jul 31 21:38:11 <mr_science> yeah, mine here is a little older/lighter but similar
Jul 31 21:38:51 <mr_science> dell 2950 with 2 quad HT xeons and only 16 GB ram with a couple TB of raid storage
Jul 31 21:39:26 <mr_science> what's weird is i would swear my cheap box is faster at some things...
Jul 31 21:39:46 <Circuitsoft> I opted for tons of RAM instead of SSDs, since I figure most Yocto compile jobs will fit entirely in vfs cache.
Jul 31 21:39:56 <mr_science> but the builds are also fairly different (classic here, yocto master at home)
Jul 31 21:41:15 <Circuitsoft> My build machine at home is a 65W AMD dual-core with 4GB RAM.
Jul 31 21:48:54 <mr_science> sounds like my desktop at home...
Aug 01 01:10:38 <Circuitsoft> Is there a proper place to add files to /etc/profile.d/
Aug 01 01:10:39 <Circuitsoft> ?
Aug 01 02:11:52 <nerdboy> Circuitsoft: i see a few things in meta/ that install a file there
Aug 01 02:12:06 <nerdboy> that's pretty much it...
Aug 01 02:21:59 <sgw_> Circuitsoft: new files for a recipe you are writing or in general?  You can use a .bbappend file for base-files or create your own recipe that will install the ${sysconfdir}/profile.d and then install your file or files to that dir.  Then in your image install that recipe.
**** ENDING LOGGING AT Thu Aug 01 02:59:58 2013