Wednesday, 2013-07-31

*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:08
*** mulhern <mulhern!> has joined #yocto00:12
*** munch <munch!~mark@> has quit IRC00:24
*** JaMa|Off is now known as JaMa00:31
*** davest <davest!Adium@nat/intel/x-tgfubvppgkyhxnfh> has joined #yocto00:33
*** _julian <_julian!> has joined #yocto00:50
*** ant_home <ant_home!> has quit IRC00:51
*** _julian_ <_julian_!> has quit IRC00:53
*** _frank_ <_frank_!~frank@> has quit IRC01:01
*** Jefro <Jefro!> has joined #yocto01:08
*** mulhern <mulhern!> has quit IRC01:10
*** Jefro <Jefro!> has quit IRC01:12
*** davest <davest!Adium@nat/intel/x-tgfubvppgkyhxnfh> has quit IRC01:16
*** mulhern <mulhern!> has joined #yocto01:18
*** hollisb <hollisb!> has joined #yocto01:23
*** sameo <sameo!~samuel@> has quit IRC01:25
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:28
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto01:34
*** arky <arky!~arky@> has joined #yocto01:47
arkyAnyone seen this error? ERROR: QA Issue: midori: Files/directories were installed but not shipped01:48
arky  /usr/share/gir-1.001:48
*** mulhern <mulhern!> has quit IRC02:03
*** mitz <mitz!> has quit IRC02:05
*** arky <arky!~arky@> has quit IRC02:06
sgw_arky: yes, I saw that recently in our meta-web-kiosk, it's easy to fix by doing an rmdir of that directory in the do_install_append()02:07
*** mitz <mitz!> has joined #yocto02:08
*** hollisb <hollisb!> has quit IRC02:24
*** silviof1 <silviof1!> has joined #yocto02:25
*** silviof <silviof!> has quit IRC02:26
*** andyross <andyross!> has joined #yocto03:02
*** arky <arky!~arky@> has joined #yocto03:09
*** seebs <seebs!> has quit IRC03:35
*** seebs <seebs!> has joined #yocto03:42
lpappcan I include .inc files into a forked recipe?03:59
lpappso that I do not need to fork the .inc file, too.04:00
*** vicky <vicky!~vicky@> has joined #yocto04:08
*** tomz2 <tomz2!> has left #yocto04:16
nerdboysure, but you'll need more path04:23
nerdboymaybe not, actually...04:25
nerdboyis it a .bb or .bbappend recipe?04:25
nerdboya bbappend should find the original include, but if it's a separate recipe then you probably need something like "include path/to/"04:27
nerdboyeg, one of the minimal pi images does this "include recipes-core/images/"04:28
*** Jefro <Jefro!> has joined #yocto04:35
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC04:49
*** Jefro <Jefro!> has quit IRC04:51
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto04:53
*** agust <agust!> has joined #yocto04:53
*** arky <arky!~arky@> has quit IRC05:00
*** ericben <ericben!> has quit IRC05:04
*** Jefro <Jefro!> has joined #yocto05:05
*** ericben <ericben!> has joined #yocto05:05
*** Jefro <Jefro!> has quit IRC05:11
*** silviof1 is now known as silviof05:25
*** tasslehoff <tasslehoff!~tasslehof@> has joined #yocto05:26
*** Jefro <Jefro!> has joined #yocto05:32
*** zecke <zecke!> has joined #yocto05:33
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC05:47
*** zeeblex <zeeblex!apalalax@nat/intel/x-icsfzdtykbbnpgvr> has joined #yocto05:47
*** andyross <andyross!> has quit IRC05:48
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto05:49
*** tor <tor!> has joined #yocto05:51
*** mihai <mihai!~mihai@> has joined #yocto06:05
*** mihai <mihai!~mihai@> has quit IRC06:08
*** mihai <mihai!~mihai@> has joined #yocto06:09
-YoctoAutoBuilder- build #244 of nightly-intel-gpl is complete: Failure [failed Building Images Building Images_1] Build details are at
*** Jefro <Jefro!> has quit IRC06:12
*** Jefro <Jefro!> has joined #yocto06:22
*** arky <arky!~arky@> has joined #yocto06:22
*** RP <RP!> has quit IRC06:23
*** B4gder <B4gder!> has joined #yocto06:30
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC06:38
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto06:38
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:38
*** mckoan|away is now known as mckoan06:47
mckoangood morning06:47
lpappthat sounds weird if -b drop the dependency checking.06:47
lpappthis means I need to submit a feature request then.06:48
lpappor is it already possible to pass a preferred version to bitbake through the command, and not config file?06:49
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:50
zeckeCrofton|work: ping?06:53
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto06:55
*** arky <arky!~arky@> has quit IRC07:00
*** blitz00 <blitz00!~stefans@> has joined #yocto07:01
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto07:01
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:12
*** arky <arky!~arky@> has joined #yocto07:13
*** eballetbo <eballetbo!> has joined #yocto07:16
-YoctoAutoBuilder- build #232 of build-appliance is complete: Failure [failed Building Images] Build details are at
*** volker <volker!> has quit IRC07:17
*** panda84kde <panda84kde!> has joined #yocto07:21
arkyAnyone seen this error? ERROR: QA Issue: midori: Files/directories were installed but not shipped07:21
arky  /usr/share/gir-1.007:21
*** diego <diego!> has joined #yocto07:21
*** diego is now known as Guest34907:22
*** Guest349 <Guest349!> has left #yocto07:22
*** fgretief <fgretief!~chatzilla@> has joined #yocto07:23
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto07:25
*** slaine <slaine!~slaine@> has joined #yocto07:28
*** AlexG <AlexG!c0c69725@gateway/web/freenode/ip.> has joined #yocto07:30
lpapparky: yes07:33
arkylpapp, Any pointers on how to fix this error07:33
lpappdo_install_append() -> rmdir.07:34
*** TuTizz <TuTizz!~TuTizz@> has quit IRC07:34
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:34
arkylpapp, Sorry I am new to yocto. Can you explain07:34
arkylpapp, Got it, +    rmdir ${D}${datadir}/gir-1.007:36
arkylpapp, Thx07:36
*** slaine_ <slaine_!~slaine@> has joined #yocto07:38
*** slaine <slaine!~slaine@> has quit IRC07:38
*** slaine_ is now known as slaine07:38
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC07:38
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto07:41
arkyIs there openembedded recipe for sugar (from sugarlabs)?07:42
arkylpapp, Found these oe stuff
*** bluelightning <bluelightning!~paul@> has joined #yocto07:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:51
*** zecke <zecke!> has quit IRC07:52
lpappsorry, I meant no oe-core recipe.07:52
lpappI only checked meta/07:52
*** zecke <zecke!> has joined #yocto07:53
lpappas 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.07:54
arkylpapp, Thx for the answer07:54
*** ant_work <ant_work!> has joined #yocto07:55
bluelightningmorning all07:57
lpappI was even unaware of that collection, so I learnt something new today. :-)07:57
bluelightningnot necessarily a distro layer; sugar recipes would be most appropriate in their own software layer07:58
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:58
lpappI think a software layer for one package is a bit excessive.07:59
arkybluelightning, Morning, I can include this (classic-oe) layer in my bblayers and build right08:00
bluelightningarky: unfortunately not, you'll need to migrate it08:00
bluelightninglpapp: I'm assuming it'll be more than just one recipe08:01
arkybluelightning, Ah! I see08:01
*** florian_kc is now known as florian08:01
lpappbluelightning: based on?08:02
bluelightninglpapp: based on other environments that contain multiple applications and components08:02
lpappnot sure what environment means.08:03
lpappand even multiple applications and components might not be appropriate inside one layer as they might be very different.08:03
*** Jefro <Jefro!> has quit IRC08:04
bluelightninglpapp: 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 collection08:06
bluelightningcould be completely wrong08:06
lpappbluelightning: it is just a split package.08:07
arkybluelightning, You are right sugar is half-dozen different components with lot supporting desktop,sound, lib packages08:07
lpappbluelightning: I personally think it makes more sense to have a recipe group for such things, like recipes-qt508:07
lpappnot meta-qt508:07
lpappjust like recipes-gnome.08:08
bluelightninglpapp: 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 sense08:08
lpappin fact, recipes-gnome has a lot more packages than sugar.08:08
*** JimBaxter <JimBaxter!> has joined #yocto08:09
lpappno, sugar is not too common.08:09
lpappI would not make a separate layer for each recipe group personally.08:09
lpappI would use the distro layer.08:09
lpappas the container.08:09
bluelightningthen other distros can't as easily re-use those recipes08:10
bluelightningwhich we ideally would prefer in the OE ecosystem08:10
bluelightning(assuming the author wishes to make any of it public, which is of course optional)08:10
lpappthey can easily copy and paste.08:11
rburtonarky: 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.08:11
*** smartin <smartin!> has quit IRC08:12
bluelightninglpapp: why should people need to?08:12
lpappbluelightning: because they need the packages?08:12
bluelightninglpapp: 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 pasting08:13
bluelightninglpapp: it also allows more freedom of maintainership08:13
*** silviof <silviof!> has quit IRC08:14
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto08:14
lpappfetching recipes-foo is just as simple as a layer08:14
lpappit is just a different name after all.08:14
lpappso I do not see the problem.08:14
bluelightningwell, that's the way we are structuring things08:14
lpappmaintainership is also the same.08:14
bluelightningit has been found to work fairly well08:15
lpappI think recipe-foo makes more sense08:15
lpappbecause it is not a full layer after all, just a recipe-foo.08:15
lpappso everything else would be dummy in the layer.08:15
lpappbluelightning: how do you judge?08:16
*** smartin <smartin!> has joined #yocto08:16
lpappbluelightning: I can open a bugreport if you wish to show it does not work as "fairly well" as it could.08:16
bluelightninglpapp: by fairly wide community consensus?08:16
lpappwhy would you populate a full layer just for a recipe family?08:16
lpappbluelightning: wide means you and some other Intel guys?08:16
lpappor does it include me and my familiars who agree with me?08:17
bluelightninglpapp: we have done this already many times... meta-efl, meta-opie, etc.08:17
bluelightninglpapp: actually I'm speaking now more about the wider OpenEmbedded community than anyone from Intel08:17
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC08:17
lpappso everyone minus who disagree. :)08:18
lpappin fact, the layers decrease the reusability if they are really used in layer senses.08:19
*** mranostay <mranostay!> has quit IRC08:19
lpappbecause if there are no recipe groups as a finer tuned "layer"08:20
Crofton|workzecke, pong08:20
lpappyou will put a lot of stuff into a layer08:20
lpappsee meta-sourcery08:20
Crofton|workI should be asleep08:20
lpappthat is a bloat.08:20
lpappyou need the toolchain, but you get a lot more stuff than you need.08:20
lpappit ruin the proper reusability by demanding layers.08:20
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto08:20
lpappthis makes me wanna open a bugreport about more fine tuned "layers" a.k.a. recipe groups.08:21
bluelightninglpapp: 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 layers08:22
lpappbluelightning: no no, that is not a distro layer at all.08:22
lpappthat is a fundamental misunderstanding. :)08:22
bluelightningwell it clearly contains more than just one type of thing...08:22
lpappthat does not make it distro, really.08:23
bluelightningI haven't looked at it in detail08:23
lpappthen please do before claiming that it is a distro layer.08:23
bluelightninghonestly I'd rather we had up-to-date recipes for the sourcery toolchain in OE-Core, but it hasn't been up to me08:23
lpappbluelightning: it is buggy08:24
lpappwhy would we bother using it08:24
lpappit blocks us08:24
lpappwe switched on to meta-sourcery which is also buggy08:24
lpappbut at least, that got fixes after my reports.08:24
lpappoe-core did not, in time.08:25
bluelightningwell, strictly speaking the same people are in charge of maintaining both...08:25
lpappbluelightning: nope...08:25
lpappbluelightning: CS guys do not maintain or even recommend oe-core...08:25
bluelightningthe decision about the future of the recipes in OE-Core is largely in their hands, with some input from the community08:26
arkyrburton, Thx08:26
arkybluelightning, lpapp Is there any documentation about using distro layer?08:27
bluelightningarky: there is, one sec08:27
lpapparky: the reference manual.08:27
*** tbn <tbn!~tbn@> has joined #yocto08:27
bluelightningarky: general layers info:
*** tbn is now known as Guest9644908:28
arkybluelightning, lpapp Thx08:28
*** honschu_ <honschu_!> has joined #yocto08:28
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:28
bluelightningarky: specifically about a distro layer (but this is more about top-level configuration/customisation for your specific use case):
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:31
*** smartin <smartin!> has quit IRC08:31
*** RP <RP!> has joined #yocto08:31
zeckeCrofton|work: yeah, you should be. Do you still have access to a Lyrtech SDR platform? E.g. I think the macgine is not bootable08:33
*** smartin <smartin!> has joined #yocto08:33
Crofton|workI haven't touched that in a long time08:35
*** tbn_ <tbn_!~tbn@> has joined #yocto08:39
*** Guest96449 <Guest96449!~tbn@> has quit IRC08:41
lpappbluelightning: is there any particular reason why there is no config option for removing downloads on the fly?08:47
lpapprm_downloads similarly to rm_work?08:47
bluelightninglpapp: I guess because most people want to be able to rebuild the recipe without re-downloading08:47
bluelightningit's not something I've heard requested before, FWIW08:48
lpappwell, it would not be default08:48
lpappok, I am doing that now on the issue tracker.08:48
lpappI am getting this all the time:08:48
bluelightningthere have certainly been requests to be able to delete _old_ downloads08:48
lpapp(regardless I have rm_work)08:48
lpappWARNING: The free space of /home/lpapp/Projects/poky/build/tmp (/dev/sda7) is running low (0.942GB left)08:48
rburtonlpapp: i suggest writing and trialing it for a while, i suspect it would be incredibly painful in real use08:48
lpappERROR: No new tasks can be excuted since the disk space monitor action is "STOPTASKS"!08:48
lpappand the only workaround is to remove stuff manually.08:48
lpapprburton: huh?08:49
lpappit is the extremely _only_ workaround for me.08:49
bluelightninglpapp: is that indication of your free space accurate?08:49
lpappbut I have to do it manually every time.08:49
lpappI am ... frankly, tired of it.08:49
rburtoni guess you could have the situation where there's a local fast mirror08:49
lpappthe other fighting instead of "sure, go ahead".08:49
lpappbluelightning: yes, of course.08:50
rburtonlpapp: we ask because some filesystems are known to report bad values08:50
lpappI need an rm_downloads08:50
lpappexplicit bitbake -c delete_downloads could also work08:50
lpappbut that would still imply _manual_ intervention all the time.08:50
lpappso I prefer rm_downloads to bitbake -c clean-downloads...08:51
bluelightninglpapp: 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 space08:51
lpappbluelightning: you will pay me a bigger hard disk?08:51
lpappand setup while I sleep?08:51
lpappso I do not need to spend time, effort, money?08:51
bluelightninglpapp: do you pay us for giving you support here? ;)08:51
lpappno one gives support here about it.08:51
lpappeveryone is reluctant for reporting a feature request ...08:52
bluelightningI believe that's what we're doing...08:52
lpappwhich would support from _me_, not _you_ for now.08:52
lpappthese discussion are very hard-going.08:52
rburtonlpapp: i suggested that you write it and see how painful it is in real use. file a feature request if you wish.08:52
RPhard disks are usually relatively cheap compared to the value of people's time08:52
lpappinstead of "go ahead", I always have to fight.08:52
lpappdamn, I will not discuss requests here...08:52
bluelightningwe're pretty up-front about our disk space requirements in the quick start guide, FWIW08:52
rburtonlpapp: it's called "feedback"08:52
lpappthey will go directly to the issue tracker in here.08:53
lpappRP: ok, so buy one instead of Intel working on it?08:53
*** fusman <fusman!~fahad@> has quit IRC08:53
lpappand someone will set up for me?08:53
rburtonpersonally, 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.08:53
lpappdo not be obtuse.08:53
lpappthese are personal costs, time, and effort.08:53
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:53
RPlpapp: and there are costs for adding and maintaining a feature too08:54
* 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 08:54
lpappRP: yeah, it is very reasonable to demand many people's time, effort, and money instead of one person maintaining a little feature.08:55
lpappyay for a better a world.08:55
RPlpapp: those little features mount up08:55
lpappso do the many people's time, effort, and money?08:55
lpappI think this channel is just not recommended for feedback.08:56
RPlpapp: general development with the system needs disk space. I suspect you'll hit other problems if you really struggle for that much space08:56
lpappit is too hostile for that.08:56
rburtonoh 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.08:56
lpappthe bugzilla service works a lot more friendly.08:56
RPlpapp: the bugzilla and here are run by the same people08:56
lpappRP: I have never hit any other problems... but you know better for sure...08:57
RPlpapp: only been doing this kind of development for the best part of a decade ;-)08:57
lpappno no08:57
lpappthe bugzilla accepted all my reports pretty much.08:57
lpapphere, I have to fight with 5 people jumping on me for any trivial stuff.08:58
lpappthis is tiring, and frankly, not making me happy.08:58
RPlpapp: for some definition of accepted08:58
lpappthere is one definition.08:58
lpappcheck the bugzilla documentation what that is.08:58
lpappno wonder why the error reporting, documentation, etc are that broken if the users are turned down.08:59
lpappwhen they provide fedback.08:59
-YoctoAutoBuilder- build #230 of nightly-arm is complete: Success [build successful] Build details are at
*** Crofton|work <Crofton|work!> has quit IRC09:05
*** belen <belen!Adium@nat/intel/x-hjgexkwuaqnbfuyy> has joined #yocto09:07
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC09:08
-YoctoAutoBuilder- build #234 of nightly-x86 is complete: Failure [failed Running Sanity Tests] Build details are at
*** Crofton|work <Crofton|work!> has joined #yocto09:19
erenmorning all09:21
*** slaine_ <slaine_!~slaine@> has joined #yocto09:21
*** slaine <slaine!~slaine@> has quit IRC09:22
*** slaine_ is now known as slaine09:22
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:27
*** Crofton|work <Crofton|work!> has quit IRC09:41
*** fusman <fusman!~fahad@> has joined #yocto09:43
*** Crofton|work <Crofton|work!> has joined #yocto09:56
lpappis there any way I can fix busybox without PACKAGECONFIG?10:05
lpappany easier, that is.10:05
*** arky <arky!~arky@> has quit IRC10:05
lpappJaMa: you seem to be the big PACKAGECONFIG hacker based on git log -S. :)10:11
*** diego <diego!~diego@> has joined #yocto10:13
*** diego is now known as Guest3731010:13
*** panda84kde <panda84kde!> has quit IRC10:15
*** panda84kde <panda84kde!> has joined #yocto10:17
*** Guest37310 <Guest37310!~diego@> has quit IRC10:21
zibriI'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?10:25
rburtonlpapp: packageconfig is the recommended way to setup options that various people may want on or off.10:30
rburtonnot possible for some recipes, but its always worth trying first10:30
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto10:32
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto10:44
lpapprburton: but it takes me quite a bit of time.10:48
lpapprburton: and I do not find proper examples.10:48
lpappI grepped through several, but they are stuff that the software handles off-hand.10:48
lpappthat is not so much the case with busybox10:48
lpappso the mapping would need to be implemented.10:48
rburtonthe alternative would be a variable you can check in features_to_busybox_settings()10:54
lpapp.bbappend would work as a quick hack for defconfig10:54
lpappbut it would not work for the other two changes.10:54
lpappand they seem to be mandatory to get it right.10:54
lpapp-       busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)10:55
lpapp-       busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)10:55
lpappnot sure why they cause build issues10:55
lpappour board does not have wifi, nor bluetooth.10:55
lpappso they should be disabled anyway.10:55
rburtonsorted :)10:56
rburtonturn off wifi and bluetooth, and rfkill goes away10:56
lpappso how cna I implement a package config option10:57
rburtonif you remove the wifi and bluetooth DISTRO_FEATURES from your distro, then the rfkill applet won't be built10:57
lpappwhat do I need to do in the background to disable those two lines in busybox.inc10:57
lpappwhat do I need to check against?10:57
rburtonwell, we've a better fix here10:57
rburtonif you don't have wifi or bluetooth, disable those in your distro10:58
rburtonyou'll save space in busybox and other places10:58
lpapppoky-tiny should not bring wifi and bluetooth anyway10:58
rburtonwhy not?10:58
*** fgretief <fgretief!~chatzilla@> has quit IRC10:58
rburtonwho are you to say that poky-tiny shouldn't have wifi?10:58
lpappwell, the omap supports those potentially.10:58
lpappso I would rather keep them for future flexibility.10:58
rburtonbut *your* distro doesn't need them, so you can disable them.10:58
lpappso the mapping from PACKAGECONFIG to has to happen somehow.10:59
rburtonif in the future you need wifi you can come back to this10:59
lpappis there any example for this out there how exactly?10:59
lpappI do not wanna debug this in the future10:59
rburtonfrom ten seconds of reading, you'll need to implement a mapping layer if you wanted to use PACKAGECONFIG.10:59
rburtonso there's your options: lots of work on 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)11:00
rburtonie connman won't builds its wifi or bluetooth support, if you're using that11:00
lpappit is not a distro tweak11:01
lpappit is a generic older toolchain support tweak.11:01
lpappand actually I checked, the network layer depends on wifi, and bluetooth, etc.11:01
rburton"network layer"?11:02
lpappyes, exactly.11:02
rburtoni meant what do you mean by network layer11:02
lpappno, we do not use connman.11:02
lpappsounds like a bad yocto stuff if it is a lot of work to do a very simple mapping11:03
lpappif A is set, disable this and that.11:03
rburtonits not a lot of work11:03
rburtonits just work11:03
lpappthat should be about .. 3-5 LOC?11:03
lpappor even 2 in an ideal world. :-)11:04
rburtonwell, the packageconfig string to configure arguments/dependencies is about 20 loc11:04
*** swex <swex!~swex@> has joined #yocto11:04
lpappnot sure what you mean?11:04
rburtonthe code that turns a packageconfig string into configure arguments and dependencies is about 20 loc11:04
rburtonmaybe a bit more11:04
lpappthat looks like a bad design11:05
rburtonits called "python"11:05
lpappin qt, we have the feature system.11:05
lpappthis is what you do:11:05
lpapp./configure -with-feature-nooo11:05
lpapp./configure -with-feature-nofoo*11:05
lpappNOFOO is defined11:05
lpappcode in the background:11:05
lpapp#ifdef NOFOO11:05
rburtoni was refering to the code that in your example reads the configure arguments, parses them, handles duplicates, and defines the variable11:06
rburtonanyway my point i was trying to make five minutes ago was its not obvious how packageconfig and busybox's CML config system would interact11:06
rburtonso this isn't a trivial task11:06
lpappnot sure what you mean, but do you have an example for such a mapping already implemented and I could take a look?11:07
lpappmaybe, I would get it better.11:07
lpappyes, that is why it is a bad design.11:07
lpappit should be a trivial task solved by a centralized boiler-plate.11:07
*** swex__ <swex__!~swex@> has quit IRC11:07
rburtonsigh.  as i've said that centralised boilerplate was designed around configure arguments, not cml.  feel free to extend it.11:07
lpappor not bad, but missing.11:07
rburtoni was about to point you at base.bbclass11:08
lpappsounds like a bugreport.11:08
rburtonsearch for PACKAGECONFIG and you'll find the python function that implements it11:08
lpappnot sure what "cml" means.11:08
ant_workmartiert: is the error about .gitignore ?11:10
yoctiBug 4964: normal, Undecided, ---, saul.wold, NEW , Simplify the mapping between PACKAGECONFIG and .bb/.inc files11:11
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:13
*** acidfu <acidfu!~nib@> has joined #yocto11:16
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto11:16 was removed in dylan? o_O :(11:17
lpappis it possible to pass the preferred version to bitbake on the command line?11:21
yoctiBug 4965: normal, Undecided, ---, richard.purdie, NEW , Not possible to pass the preferred version to bitbake on the command line11:24
yoctiBug 4966: normal, Undecided, ---, saul.wold, NEW , Add a feature ("rm_downloads") for INHERIT11:29
*** vicky <vicky!~vicky@> has quit IRC11:30
lpapp -> what is this QA error in poky master?11:31
-YoctoAutoBuilder- build #203 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** TuTizz <TuTizz!~TuTizz@> has quit IRC11:32
*** belen2 <belen2!Adium@nat/intel/x-zkwhlwmjigdertqd> has joined #yocto11:34
*** belen <belen!Adium@nat/intel/x-hjgexkwuaqnbfuyy> has quit IRC11:35
rburtonlpapp: it means a file or directory was installed but not packaged.11:37
lpapprburton: why am I getting such a regression in dylan?11:37
lpappor well, even master ahead.11:37
B4gderlpapp: we must've missed your fix for it!11:37
rburtonmainly because external-sourcery-toolchain isn't tested very well currently11:38
lpapprburton: how do you know it is related to that?11:38
rburtonlpapp: because thats the package that is producing the warnings11:38
lpappwhat can I do to fix it?11:39
lpappdo you know the root cause of the issue?11:39
lpappwany pointers, etc11:39
rburtoneither delete those files if they're not meant to be installed, or add to FILES_ if they are11:39
rburtonthis is basic FILES_* manipulation11:39
lpappwhy did it not need any special attention before?11:39
* rburton shrugs11:39
rburtonbecause stuff changes?11:39
lpappwhat stuff exactly ...11:39
rburtondistro configuration could have changed that meant an assumption wasn't valid11:40
lpappso, basically you are claiming who cares why it happens.11:40
lpappthat is not my mentality.11:40
lpappI would like to understand why I am fixing things.11:40
rburtonand you're in the perfect place to understand11:40
rburtonwhat with you getting the error and not me11:40
lpappso, you have no clue?11:41
rburtonany clue why you're getting those errors exactly? no, never used the external toolchain.11:41
rburtonin general i've told you why those errors happen11:41
rburtonand what to do to resolve them11:41
lpappit is an external toolchain.11:42
lpappit should be deleted in the the meta-sourcery/*/*.bb?11:42
*** eren <eren!~eren@unaffiliated/eren> has quit IRC11:42
rburtonwhatever the recipe is that your building needs fixing11:43
lpappperhaps it is a dylan enforcement.11:43
rburtonmaybe it needs more files packages11:43
rburtonour QA certainly improved in dylan11:43
lpappas the recipe of course did not change a bit.11:43
lpappNOTE: preferred version 141 of udev not available (for item udev)11:44
lpappNOTE: versions of udev available: 18211:44
lpappwhat happens in such cases?11:44
lpapp182 will be built?11:44
lpapphow weird.11:44
rburtonwhat would you prefer?11:45
lpappI mean, it is building udev 182, that is weird.11:45
lpappit was broken on my home machine.11:45
rburtondon't let it know you've noticed, it might break!11:46
lpapp!BUG 494111:46
yoctiBug normal, Undecided, ---, saul.wold, NEW , udev doesn't compile with older toolchains11:46
lpappfoo 494111:46
rburtonbug 494111:47
rburtonhm, i always forget the syntax11:47
lpapp!bug 494111:47
lpapp!BUG 494111:47
lpappnow, that is weird.11:47
rburtonrate limited?11:48
lpapp12: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.11:48
rburtonthat udev fail is because your userspace is old11:48
lpappthe toolchain is.11:48
lpappis the yocti syntax documented somewhere?11:49
lpappI do not know off-hand how to use the help.11:49
lpappit would be preferrable to have a self-contained greppable stuff.11:49
*** mulhern <mulhern!> has joined #yocto11:49
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:53
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto11:54
*** calin <calin!86bfdd4a@gateway/web/freenode/ip.> has joined #yocto11:56
*** calin is now known as Guest9398111:57
lpapppoky-dylan-9.0.1/build$ ls /tmp/12:05
lpapppulse-PKdhtXMmr18n  VMwareDnD  vmware-root12:05
lpapperr... this is what?12:05
otavioI am trying to find why bitbake is not behaving as expected12:13
lpappotavio: with regards to?12:14
*** mulhern <mulhern!> has quit IRC12:15
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto12:15
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto12:15
rburtonlpapp: that's your /tmp directory.  pulseaudio socket and vmware sockets by the look of it.12:15
lpapprburton: yeah, I realized that much12:16
lpappyou did not leave me time to finish the writing of that. :p12:16
lpappthis is surprising...12:16
lpappudev182 builds on ubuntu 12.1012:16
lpappwith the same toolchain ...12:17
rburtonotavio: bitbake always behaves as intended, you're just wrong about what you think it should do ;)12:17
lpappand the same old toolchain does not have that defined either.12:17
otaviorburton: yaya!12:17
otaviorburton: the data.finalize() bb method does not finalize it hheheh12:17
rburtonotavio: well clearly there a good reason for that ;)12:18
otaviorburton: sure ;-)12:20
*** gmacario <gmacario!> has quit IRC12:20
otaviorburton: do you know this code?12:20
otaviorburton: I can explain the bug, not why12:20
rburtonotavio: sorry. not me.  try bluelightning.12:21
otaviobluelightning: :-)12:21
otaviobluelightning: it was rburton who pointed at you. Blame him ;)12:21
rburtoni know that data_smart is 90% unicorn magic12:21
bluelightningotavio: I'm not sure either... but I might suggest this is why attempting to do this kind of thing is problematic12:21
otaviobluelightning: well12:21
otaviobluelightning: does not solve the bug12:22
otavioand it does seem it is a bug in bitbake.12:22
otaviobluelightning: want me to explain it?12:22
bluelightningotavio: you're calling finalize() and what doesn't happen?12:22
*** mulhern <mulhern!> has joined #yocto12:23
otaviobluelightning: let's focus on DISTRO_FEATURES only12:23
otaviobluelightning: it is set in two places, in case of poky12:23
otaviobluelightning: ?= in defaultsetup and _append in poky12:23
bluelightningotavio: right, yes... as I kind of indicated in the thread I think we probably ought to just set it outright in poky.conf12:25
otaviobluelightning: finalize seems to delay _append (which makes sense) but than the added in _append are done /after/ .finalize12:25
otaviobluelightning: This can be done in many ways and it'd cover the bug.12:26
lpappso, what is the replacement for MultiModule in dylan?12:26
otaviobluelightning: the point is when ConfigParsed event is triggered, it is not fully done.12:26
bluelightninglpapp: what is MultiModule?12:26
lpappbluelightning: initscript stuff for updating.12:27
*** B4gder <B4gder!> has quit IRC12:27
*** gmacario <gmacario!> has joined #yocto12:27
bluelightninglpapp: "git grep MultiModule" doesn't find anything in denzil nor dylan12:28
lpappgit grep != grep12:28
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.> has joined #yocto12:28
lpappand you need find here anyway, not grep. :-)12:28
bluelightninglpapp: you mean git grep is not find12:28
lpappI mean what I wrote.12:29
bluelightning"git grep" searches in all git managed files, if there were a reference to it it would have found it12:29
lpappit is not so simple.12:30
g0hl1nhi, 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!12:30
*** jchonig <jchonig!~jch@> has joined #yocto12:30
lpapp -> true, it is not in the repository.12:31
bluelightninglpapp: this is probably something added on top of poky because it doesn't exist in denzil12:31
lpappwhich is kinda worrying how much stuff we have put in there... :/12:31
lpappwhat is the intended way of defining own init scripts/12:31
lpappdistro layer?12:32
bluelightningit is, I'd strongly suggest you do a comparison and try to break things out into your distro layer12:32
bluelightninglpapp: 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)12:32
bluelightninglpapp: if it's a standalone script, use an initscripts bbappend12:32
*** jkridner <jkridner!~jkridner@nat/ti/x-wmaijdfmtkuxwydd> has joined #yocto12:35
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:35
bluelightningg0hl1n: its contents comes from the BUILDNAME variable which is defaulted within bitbake code if not set12:36
bluelightningg0hl1n: 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)12:36
g0hl1nbluelightning: ok, thanks! So i can set BUILDNAME in my distro configuration?12:37
bluelightningg0hl1n: 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_COMMAND12:38
g0hl1nbluelightning: thanks!12:44
*** tasslehoff <tasslehoff!~tasslehof@> has left #yocto12:45
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto12:53
*** melonipoika <melonipoika!> has quit IRC12:53
*** Net147 <Net147!> has joined #yocto12:57
RPotavio: the datastore you get with a ConfigParsed event is not expanded/finalised. That is by design13:01
otavioRP: but when I call d.finalize() shouldn't this work?13:01
otavioRP: does not help13:02
RPotavio: well, a) you should copy it, then finalize it and b) you also need expand_keys() iirc for some uses13:02
RPotavio: but if everything you need is parsed by then, you should be able to finalise a copy, yes13:03
otavioRP: I did the copy in v213:03
otavioRP: and called finalize13:03
otavioRP: and it didn't work :(13:03
otavioRP: _append is done after13:03
RPotavio: Its expected that _append would append to a ?=13:04
otavioRP: current patch.13:04
otavioRP: yes13:04
lpappis there any option to remove everything except the downloads?13:04
otavioRP: it is done after, right?13:04
lpappi.e. before checking stuff into the repository.13:04
otavioRP: but ConfigParsed seems to be called /before/ the last append13:05
lpappand conf, of course.13:05
otavioRP: this part of bb code is confusing for me so I couldn't yet understand it fully13:06
RPotavio: I don't understand what problem you're seeing :/13:06
RPotavio: I'm also not meant to be here :/13:07
RPlpapp: most people use .gitignore for that purpose13:07
otavioRP: if I do EXTRA_DISTRO_FEATURES = "~x11 ~wayland" x11 is dropped, wayland does not.13:07
otavioRP: so wayland is kept13:07
otavioRP: yes I know you're in vacations :)13:08
RPotavio: ah, I can see why this does happen :/13:08
lpappso bitbake is not our friend in here?13:09
RPotavio: _append is near impossible to cancel out :/13:09
otavioRP: but finalize should have returned it done no?13:09
RPotavio: that code will cancel out wayland in DISTRO_FEATURES at ConfigParsed time13:10
RPotavio: but nothing removes the _append from the system and stops wayland being added back13:10
otavioRP: in fact it is added back13:10
otavioRP: well but this is bad. We cannot get a 'final' result?13:11
RPotavio: no, you get the final result, its just you can't overwrite it completely13:12
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC13:12
*** elmi82 <elmi82!> has joined #yocto13:13
RPotavio: I suspect you could hack it with a d.delVarFlag("DISTRO_FEATURES", "_append")13:13
RPotavio: but that is assuming internal bitbake knowledge13:13
RPi.e. I will not take patches using that13:13
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto13:13
lpappbluelightning: you are maintaining the CS oe-core stuffy?13:13
bluelightninglpapp: no, I'm not13:14
lpappbluelightning: so what is with this change then?13:14
bluelightninglpapp: which change?13:15
lpappbluelightning: your fix?13:15
bluelightninglpapp: I haven't worked on the external toolchain recipes, I've reviewed some patches from Laurentiu and Saul that have been merged recently though13:18
*** darknighte_znc is now known as darknighte13:18
*** arky <arky!~arky@> has joined #yocto13:19
* RP wanders off the play with lime mortar again13:20
*** davest <davest!Adium@nat/intel/x-wwvmjrbsklhzglvu> has joined #yocto13:22
mulhernDo there exist any regression tests for create-recipe script?13:22
mulhernThe one in poky/scripts.13:23
JaMalpapp: remove PR assignments in your u-boot patch13:24
bluelightningmulhern: I think maybe we don't have a test for that, but testopia would be the best place to check13:24
lpappJaMa: why?13:24
bluelightningmulhern: it's integrated into our bugzilla13:24
rburtonJaMa: do you have that url memorised? :)13:25
mulhernbluelightning: I'm looking at and I see Testopia in drop-down menu, but I don't know how to interact. Can you give me a hint?13:26
rburtonmulhern: its a bit of a maze unless you're a qa expert tbh13:28
otavioRP: and how to handle this in a cleaner way?13:29
bluelightningmulhern: indeed... in theory you should just be able to search for a keyword in all of the test cases13:29
JaMarburton: no, but I needed the link to persuade some other people about PR_append stupidity, so it was worth finding it13:30
otavioRP: I am testing the delVarFlag hack13:31
lpappJaMa: but others do it, too.13:32
mulhernblue 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.13:34
rburtonmulhern: tbh, i'd be surprised if there's a test for it13:34
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nakryffsvxjhdqkf> has joined #yocto13:35
mulhernIt 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.13:40
bluelightningmulhern: right, we're in the process of automating our testing for the upcoming release13:41
*** Net147 <Net147!> has quit IRC13:41
JaMalpapp: most upgrades are dropping PR, existence of bad example isn't good reason for you to follow it, is it?13:41
lpapprburton: I am not sure if there is any reason for the old ones.13:41
lpapprburton: there are many around already13:41
lpappsomeone with competence needs to judge on that, sorry.13:42
lpappI would not like to have a take on this.13:42
lpappJaMa: maybe, but I do not have time to update it now.13:42
lpappand I do not think it should be a blocker either.13:42
JaMait can wait till you have time to update it13:43
JaMaupgrade to newer u-boot isn't bloker too13:43
*** jchonig <jchonig!~jch@> has quit IRC13:44
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC13:45
mulhernbluelightning: Is this the ptest stuff? I know I've heard rumours.13:46
*** adinu <adinu!adinu@nat/intel/x-brgxbsbftsuyagvx> has joined #yocto13:46
bluelightningmulhern: that's a separate but related effort13:46
*** mprica <mprica!c0c69724@gateway/web/freenode/ip.> has joined #yocto13:46
bluelightningmulhern: ptest provides the mechanism to integrate tests supplied with each piece of software we build13:46
mulhernbluelightning: That makes sense based on context. So, what is the other effort?13:47
*** JimBaxter_ <JimBaxter_!> has joined #yocto13:47
*** eciobanu <eciobanu!c0c69724@gateway/web/freenode/ip.> has joined #yocto13:48
*** davest <davest!Adium@nat/intel/x-wwvmjrbsklhzglvu> has quit IRC13:49
*** JimBaxter <JimBaxter!> has quit IRC13:49
bluelightningmulhern: 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 autobuilder13:50
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.> has joined #yocto13:50
bluelightningmulhern: 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 script13:52
KrzHi 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.13:54
mulhernbluelightning: So, a runtime test is what is run on an image after it is built?13:54
bluelightningmulhern: correct13:54
bluelightningmulhern: FYI:
yoctiBug 4740: enhancement, Medium+, 1.5, mihaix.lindner, NEW , Consider providing an oe-selftest script to run automated tests against bitbake tools13:55
mulhernbluelightning: 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?13:56
bluelightningmulhern: that's correct, and it would appear there's no manual test case either13:58
*** belen2 <belen2!Adium@nat/intel/x-zkwhlwmjigdertqd> has quit IRC13:58
bluelightningmulhern: to be honest I don't know how much regular use create-recipe gets, it would certainly be great to improve its capabilities13:58
*** davest <davest!~Adium@> has joined #yocto13:59
bluelightningKrz: I think the scc file is important, but I'm not an expert in that area13:59
*** behanw <behanw!> has joined #yocto14:01
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto14:01
mulhernbluelightning: It puts over1000 lines of Perl into attempting to infer all sorts of things from downloaded distributions.14:02
*** jchonig <jchonig!~jch@> has joined #yocto14:03
Krzbluelightning: I built an image without it, so it's certainly not a build-time requirement. Who should I talk to about scc?14:03
*** belen2 <belen2!Adium@nat/intel/x-ugcqutzkbreqfsti> has joined #yocto14:04
bluelightningKrz: 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 question14:04
ant_workKrz: the scc format hasn't changed. Keep that file. For doubts, ^^^14:05
*** elmi82_ <elmi82_!> has joined #yocto14:10
ant_workbluelightning: where do we put xinput-calibrator now? in XSERVER?14:14
bluelightningant_work: I would think so yes14:15
ant_workor maybe as RDEPENDS_${PN} of x11-common14:16
ant_worksimilarly to what was done by meta-oe's xserver-common14:16
bluelightningant_work: the thing is it would have to be conditional there since it's only needed for devices that have a touchscreen14:17
ant_workdid you say xserver-nodm-init will be unified soon?14:17
ant_workso x11-common and xserver-common & their RDEPS ?14:18
*** munch <munch!> has joined #yocto14:18
*** elmi82 <elmi82!> has quit IRC14:26
*** davest <davest!~Adium@> has quit IRC14:26
*** davest <davest!Adium@nat/intel/x-azpndujhybsycxcm> has joined #yocto14:27
*** belen2 <belen2!Adium@nat/intel/x-ugcqutzkbreqfsti> has quit IRC14:30
bluelightningant_work: actually I may have been mistaken on that one... I'm not sure if anyone is actively working on that atm14:31
bluelightningant_work: I suspect xinput-calibrator not being in OE-Core might have been one blocker to that though14:32
bluelightningJaMa: can you recall any others?14:32
ant_workmaybe we need to improve that -common recipe adding more conditionals14:33
*** belen <belen!Adium@nat/intel/x-cdzhkmbgplalimuo> has joined #yocto14:34
ant_workpls add this to the long to-do so we don't forget ;)14:35
*** ant_work <ant_work!> has quit IRC14:35
*** tsjsieb <tsjsieb!> has quit IRC14:35
*** mulhern <mulhern!> has quit IRC14:42
JaMabluelightning: I can find an e-mail I've sent about it if it mentions other blockers, but xinput-calibrator was definetely one of them14:45
*** hollisb <hollisb!> has joined #yocto14:46
erenoh, I hit the problem of "waiting for removable media"14:47
bluelightningJaMa: I guess this one:
*** mulhern <mulhern!> has joined #yocto14:48
*** andyross <andyross!> has joined #yocto14:54
g0hl1nHey everybody, is it possible to completely disable all qemu stuff when building an image?14:55
g0hl1nbecause in my case qemu is opening a lot of files (i think all) and closing it right after.14:56
g0hl1nBecause of that my build needs over 4 hours to finish altough most of the packages are skipped...14:57
g0hl1nin my local.conf #IMAGETEST = "qemu" is commented out...14:58
g0hl1nDoes anybody have some ideas?14:58
*** Net147 <Net147!> has joined #yocto15:00
Net147satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-boot: busybox-hwclock, any ideas?15:01
Net147looks like busybox-hwclock is empty due to when using systemd15:04
JaMabluelightning: yes, that's the one I was thinking about15:04
*** zeeblex <zeeblex!apalalax@nat/intel/x-icsfzdtykbbnpgvr> has left #yocto15:05
*** Jefro <Jefro!> has joined #yocto15:06
lpappJaMa: it is a blocker15:07
lpappit has nice new features, etc.15:07
lpappwhich we and probably others need, too.15:07
*** pidge <pidge!> has quit IRC15:07
lpappyou would seriously block a software update because of PR? :O15:07
bluelightninglpapp: patches need to be properly formed before merging, that's the way we operate15:08
lpappit is properly formatted.15:08
lpapplike many other patches going in.15:08
lpappplease do not be discriminative.15:08
lpappI will leave that patch, too.15:09
bluelightninglpapp: that process need not block you because git allows maintaining your own branch easily15:09
lpappmy contribution is not welcome anyway15:09
lpappthis is not the first blocker change15:09
lpappwhich people need.15:09
lpappyet, it is being rejected due to pedantic nitpicking unpragmatic nonsense15:09
frayall 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..15:09
bluelightninglpapp: every project has certain requirements for submitted changes, I'm sure other projects you've worked with have similar requirements15:09
fraythe quality of the project requires pedantic nitpicking15:09
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC15:11
JaMalpapp: it's called review for other devs to have opportuninty to say needed changes before it's merged15:13
lpappbluelightning: not this stupid, no.15:14
*** mulhern <mulhern!> has quit IRC15:14
lpappJaMa: I will start meta-qt5 from scratch.15:14
lpappwith my qt5 upstream expertise.15:14
lpappI cannot collaborate with people who would block packages for .... formal nitpicking not to get the software into users' hand.15:15
lpappactually, it will be recipes-qt5.15:15
davestlpapp: that's your choice. We must maintain our standards to maintain quality15:16
davestlpapp: and it's such a little thing, yes?15:16
frayNote, someone else has already started a meta-qt5:
lpappdavest: yes, people would block it ffs...15:16
lpappsuch a little minor nonsense.15:16
JaMafray: that's mine15:16
lpappto block it ... like people cannot get the software for that?15:16
lpappI think I have an entirely different vision with accepting contributions and towards end users.15:17
bluelightninglpapp: nobody is blocking you from being able to build with the fixes applied - you can use a branch containing your changes until they are merged15:17
bluelightningor otherwise addressed15:17
lpappbluelightning: yes, nice joke.15:17
lpappyou are not blocked, you can fork the project.15:17
lpappsure, nobody is blocked to contribute to M$ either.15:17
bluelightninglpapp: I'm being completely serious, this is how people get their work done15:18
lpappthey can rewrite it in their branch.15:18
lpappbluelightning: you are seriously not making sense IMO then.15:18
JaMalpapp: if you're not going to follow rules set by layer maintainer, then why you're surprised that your contributions aren't immediately applied?15:18
lpappJaMa: stupid rules are stupid15:18
lpappI build the software for the users15:18
JaMalpapp: do you understand wht PR service is?15:19
lpappnot a few devs to satisfy the "formal ego".15:19
JaMaPR in recipes is stupid15:19
JaMarule to remove them when possible is reasonable way to get rid of them15:19
lpappyes, argue a few more hours about it, just not with me, please, thanks.15:19
lpappI have better things to do than arguing about nuances which even block end users.15:19
* JaMa off to doing something more useful15:20
* lpapp is pushing the qt5 improvements to his "own branch" because he is "not" blocked.15:21
*** Jefro <Jefro!> has quit IRC15:26
*** AlexG <AlexG!c0c69725@gateway/web/freenode/ip.> has quit IRC15:27
*** mulhern <mulhern!> has joined #yocto15:29
*** cfo215 <cfo215!4473ad42@gateway/web/freenode/ip.> has joined #yocto15:31
*** Net147 <Net147!> has quit IRC15:32
cfo215anyone 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?15:32
jkridnercfo215: yocto = poky?15:33
* jkridner uses meta-beagleboard on occasion15:33
cfo215jkrinder: yes poly15:34
cfo215used hob to generate images15:34
* jkridner hasn't used poky15:34
lpappcfo215: do you like hob15:34
cfo215just started using yocto/poky/hob.  it seems to work.  It at least generated an image.15:35
lpappcfo215: what do you prefer about it compared to bitbake?15:37
lpappthinking of writing a better frontend in Qt. :p15:37
lpappand I need input.15:37
cfo215lpapp: 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.15:37
lpapp"writing frontend" -> rewriting bitbake in C++, too.15:37
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto15:38
cfo215lpapp: 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.15:38
lpappok, thanks.15:39
cfo215lpapp: 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?15:40
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC15:41
lpappcfo215: I have a beagleboard.15:43
lpappbut I do not use it anymore.15:43
lpappI am working on getting qt5 and kde frameworks right, in general, though.15:43
lpappcfo215: I will try to push my recipes today to the KDE repository if you are interested in.15:43
*** Jefro <Jefro!> has joined #yocto15:44
*** arky <arky!~arky@> has quit IRC15:44
cfo215lpapp: I really need to find a solution for the BBB.  But thanks for the offer.15:44
lpappcfo215: well, it is just arm.15:45
lpappit does not matter from qt's point of view more than that.15:45
lpappwhich means I expect my recipes work on arm off-hand.15:45
cfo215I'll have a look15:45
cfo215where your recipe located at?15:46
lpappcfo215: but it is qt5, not qt4.15:46
lpappbut I think that is even better for you, no?15:46
lpappcfo215: on my machine at home, currently.15:46
cfo215yes, that could be better.15:47
lpappcfo215: will be pushing here tonight hopefully,
lpapprecipes-qt5 recipes-kf5, or so15:47
lpappcfo215: do you wanna use fb, x, wayland, etc?15:48
cfo215what I really need (I'm supposing) is the qmake.conf and command line for ./configure that works with my device.  hardfloat15:48
cfo215frame buffer and ts lcd support15:49
cfo215via qws15:49
lpappit is jsut the matter of -xplatform and -platform.15:49
lpappprobably not ...15:49
lpappthat got replaced in Qt5 by QPA. ;)15:49
cfo215ic, still on 415:49
lpappany reason?15:50
cfo215not really.  Guess I just don't want to be on the bleeding edge.15:50
lpappQt5 was released last December15:51
lpappit is not really bleeding edge. :)15:51
lpappjust because Yocto does not have it sadly, it does not mean, it is bleeding edge.15:51
cfo215Any help would with Qt would be greatly appreciated.  But I still got to get my BBB booting...15:51
rburtonlpapp: could say the same about toolchains ;) perspectives vary.15:51
lpappcfo215: I will probably also blog about it15:52
lpapprburton: eh?15:52
*** mulhern <mulhern!> has quit IRC15:53
lpappas far as I am aware Yocto has the latest major gcc, 4.815:53
lpappor 4.7, sorry.15:53
lpappone of*15:54
lpappthat is good enough for C++11, really.15:54
rburtonwe've 4.815:54
lpappnot in my version.15:54
bluelightninglpapp: the ecosystem *does* have qt5 recipes, in meta-qt515:54
lpappbut still, I do not understand your comment.15:54
lpappbluelightning: which are broken.15:54
lpapplacking basic stuff15:55
bluelightninglpapp: they're being used by a commercial firm, so they can't be that broken15:55
bluelightninglpapp: basic?15:55
rburtoncontributions welcome!15:55
lpappI already said I will push my recipes tonight?15:55
lpappI think they are in a much better shape. :)15:55
lpappand more complete.15:56
lpapphence I do not see the future of "meta-qt5".15:56
cfo215lpapp: 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.15:56
lpappas it seems now, at least.15:56
lpappcfo215: what is the issue at hand?15:57
bluelightninglpapp: have you tried to contribute your improvements to meta-qt5?15:57
lpappbluelightning: no, it is completely different stuff15:57
cfo215I 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.15:57
cfo215but the boot process hangs15:58
lpappbluelightning: and no, I do not wish to work with people whose biggest problem is "PR".15:58
lpappfor blocking and unwelcome a contribution.15:58
cfo215lpapp: Waiting for root device /dev/mmcblk0p2...15:58
lpappthis rule cannot work for my qt5 recipes.15:58
*** mckoan is now known as mckoan|away15:58
rburtonlpapp: 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?15:58
lpapprburton: you guys started the moaning?15:59
lpappabout a nonsense stuff?15:59
lpapp(and still continue)15:59
lpappyou do realize I fully agree with unwelcoming end users and contributions16:00
cfo215does anyone out there have a recipe for creating the SD Card for BBB post bitbaking the image?16:00
lpappthis might be an Intel way, but not open source and governed.16:00
lpappand end user oriented.16:00
bluelightninglpapp: we have certain requirements for patch submissions, just like all open source projects do16:00
lpappyes, stupid IMO16:00
bluelightninglpapp: just try to get a patch into the kernel, you'll see we're actually pretty relaxed by comparison16:00
rburtonlpapp: 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.16:00
lpappso I avoid collaborating as I already wrote several times. Why do you keep asking the same then?16:00
lpappWhy do you get me repeating dozens of times?16:00
rburtonlpapp: i wish i knew16:01
KrzGuys, 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?16:01
lpapprburton: that is a moan.16:01
lpappwhen you say it would block end users and contributions16:01
lpappsurely, it is nice to have maybe, but blocking? Hell not.16:01
rburtonKrz: oe-core has iptables in recipes-extended16:02
lpappI did not tip on someone's shoes because he did not paste a code review link to bugzilla16:02
lpappI mentioned that, maybe do next time.16:02
bluelightningKrz: both iputils and iptables are in the core set of recipes; did you mean some other ones?16:02
lpappthat is difference between "quality" and "get things done" approaches.16:02
*** elmi82_ <elmi82_!> has quit IRC16:03
*** cfo215 <cfo215!4473ad42@gateway/web/freenode/ip.> has quit IRC16:03
jkridnergm all16:03
davestlpapp: ironic - I have heard you are really picky about patches into the code you maintain16:03
* jkridner is multitasking, so ping if you for sure need my attention.16:03
lpappdavest: when it does not hurt the user, sure.16:04
*** slaine <slaine!~slaine@> has quit IRC16:04
lpappthat is the time for being nitpicky.16:04
lpappbut when it hurts, it is not.16:04
bluelightninglpapp: 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 review16:04
lpappbluelightning: you think that there is black and white.16:04
lpappthe world is a bit more colorful.16:04
lpappdavest: 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 PR16:07
lpappdavest: and if I am asked to do next time, I will do.16:07
lpappor if I am asked nicely.16:07
lpappbut when it is claimed to be a blocker for a useful feature, well, that frankly annoys me.16:07
lpapp"with quality against UX"16:08
bluelightningKrz: 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 removing16:08
lpappdavest: also, I do not currently maintain any FOSS software.16:09
bluelightningKrz: ("we" meaning the OpenEmbedded community, since YP doesn't maintain recipes in meta-oe)16:09
davestlpapp: serial module ?16:09
lpappI get rid of the last project maintenance 1-2 weeks ago, luckily.16:09
*** tbn_ <tbn_!~tbn@> has quit IRC16:10
Krzbluelightning: I added recently few things and mixed up what comes from where. I need from meta-openembedded: hostap-daemon and iw16:14
KrzI know about this clashing recipes, so that's why I'm asking if adding openembedded is Yocto way or not so much16:14
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC16:15
rburtonKrz: ah, they're in meta-connectivity. you may be able to add that without meta-oe itself16:15
rburtonKrz: its only the meta-oe layer that is "badly behaved"16:15
Crofton|workrburton, what is badly behaved about it?16:16
bluelightningKrz: they're both in meta-oe16:16
bluelightningrburton: ^16:16
rburtonoh crap16:16
rburtoni can't read16:16
rburtonCrofton|work: the remaining bbappends and overlaid recipes - just adding meta-oe isn't a no-op16:17
Crofton|workhwo many of those are left?16:17
rburtononly a few16:17
rburtonand the big one is something i've been staring at for a while now16:17
rburton(xorg init)16:17
Crofton|workwhich one is that?16:17
Krzisn't meta-openembedded totally Yocto-independent?16:18
rburtonKrz: it depends on oe-core, which is YP16:18
bluelightningCrofton|work: basically: xserver-nodm-init, gst-ffmpeg, tslib, busybox16:19
rburtonis anyone *actually* using tslib still?16:19
Crofton|workwe need to make a FAQ on the wiki about this16:20
bluelightningrburton: opie ;)16:20
bluelightningrburton: but seriously I'm not sure other than that16:20
rburtonbluelightning: i suspect anyone else using qt on fb16:20
rburtonneed to find a friendly qt developer, i'll ping thiago maybe16:20
*** mulhern <mulhern!> has joined #yocto16:29
*** eballetbo <eballetbo!> has quit IRC16:33
*** panda84kde <panda84kde!> has quit IRC16:38
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:39
*** jchonig1 <jchonig1!~jch@> has joined #yocto16:41
*** jchonig <jchonig!~jch@> has quit IRC16:42
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC16:43
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.> has quit IRC16:44
zibriasked 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?16:44
frayUsually those messages come from a system where there are missing dependencies for some reason.16:45
*** mulhern <mulhern!> has quit IRC16:45
fraythe package has a package dependency on 'update-rc.d', but the build system never built it for some reason.16:45
zibriafaict, those packages are being installed (according to the log) (hold on, i'll paste it somewhere)16:46
fraycheck your tmp/deploy/<package>/* and see if an update-rc.d package exists16:46
fraythe error is saying it didn't exist or was not installed, but was required16:46
zibrifray: it isn't available in tmp/deploy/rmp/, no...16:47
frayya, thats the issue then.. the package is missing..16:48
frayyou may have to do bitbake -c clean update-rc.d ; bitbake update-rc.d16:48
*** mr_science <mr_science!> has joined #yocto16:49
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:49
* fray has no idea what could have caused the missing package.16:49
zibrioh, my bad.. it *is* available in tmp/deplo/rpm/all16:49
frayin that case, I'm not sure.16:49
frayhow recent is your master checkout?16:50
zibri here's the do_rootfs log16:50
fraythere were some recent changes in the resolving code (last few days)..16:50
frayperhaps something went wrong in that?16:50
zibrihum, ok. will have a look16:51
frayya, first suggestion I can give you.. try to back up a day or so and retry it..16:51
frayif it works, then it's likely something in the recent smart change..16:51
zibriright, thanks!16:51
zibribtw, i also got a lot of bb{warn,note} "command not found" from something in do_rootfs16:52
frayit's really odd though..16:52
zibribut not sure where, was hoping to get the task to complete before trying to investigate that issue..16:52
fraybecause from the logs it -did- install update-rc.d, base-passwd and run-postinsts..16:52
zibriyes, that's what i thought :)16:52
fraycan 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.319416:53
frayand see what is scheduled to happen -after- it prints "Logfile is clean"16:53
*** belen2 <belen2!Adium@nat/intel/x-jzbhuadryvqiuuml> has joined #yocto16:54
frayit 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..16:54
fray(I'm still getting abck from vacation, so the oe-core I'm using is a week or so old still)16:54
fraybut I havn't seen anything like that16:54
zibrilog_check() is called as the last command in rootfs_rpm_do_rootfs(). that is followed by rootfs_remove_unneeded16:56
zibrihah.. "# update-rc.d, base-passwd, run-postinsts are no further use, remove them now"16:56
zibriin rootfs_remove_unneeded16:56
*** belen <belen!Adium@nat/intel/x-cdzhkmbgplalimuo> has quit IRC16:56
*** Umeaboy <Umeaboy!> has joined #yocto17:02
frayhow strange17:02
*** seebs <seebs!> has quit IRC17:04
*** seebs <seebs!~seebs@> has joined #yocto17:04
*** mihai <mihai!~mihai@> has quit IRC17:05
*** seebs <seebs!~seebs@> has quit IRC17:08
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC17:09
zibriit'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 =)17:12
*** seebs <seebs!~seebs@> has joined #yocto17:12
frayI would agree..17:12
frayI'll go pull down the latest and see if I can spot an obvious flaw..17:15
* mr_science is not sure rpm is the "right" solution...17:15
zibrimr_science: :)17:15
mr_sciencebut that's just me17:15
frayit's _a_ solution..17:15
fraythe right one depends on so many factors it's hard to say..17:15
mr_scienceyeah, i just got tired of rpm a long time ago17:16
*** Jefro <Jefro!> has quit IRC17:16
mr_scienceswitched to gentoo and then learned to appreciate debian/apt...17:16
*** Jefro <Jefro!> has joined #yocto17:17
mr_scienceso i haven't really touched rhel/centos/whatever for several years17:17
fraywell, 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..17:17
*** mulhern <mulhern!> has joined #yocto17:17
fraydeb can fit into that continuum.. but it's somewhere between opkg and rpm17:18
mr_sciencefor me, i would choose deb over rpm but that's one of the big things open source is all about17:18
mr_scienceseems like opkg has all the basics, which is certainly enough for my rpi needs17:21
mr_sciencefray: i'd be interested in seeing some kind of requirements analysis for that17:23
zibriit seems that the rootfs_remove_unneeded was introduced in 1ce182e79 (poky)17:24
mr_sciencei'm not quite sure excatly what would drive the need for more than opkg in an embedded runtime...17:25
zibrimerged 2013-06-1117:25
fraywithout going indepth, it's everything from familiarity, third party package integration, package signing/validation, and rollback support17:27
fraythere are a lot of systems that bridge between 'dedicated server' and 'embedded space'.. this is the 'reasonable' area for RPM usage in my experience..17:27
fraymost of the users I know of are in the telco space (think call routing, call billing, cell tower control, etc)17:28
fraythey want package validation, signatures, rollback, etc..17:28
bluelightningluckily we provide all three options :)17:29
bluelightningthough it's fair to say that ipk/rpm are the two most proven choices17:29
bluelightningwithin our system, that is17:30
frayI certainly advocate ipk for the majority what people consider embedded system.. rpm is simply too heavy weight..17:31
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto17:32
mr_sciencefray: that's pretty much what i was thinking...17:32
mr_sciencejust not requirements i've had to meet before17:32
frayfamiliarity with RPM is likely the largest single requirement that has driven me to support RPM for my customers17:33
*** jchonig1 <jchonig1!~jch@> has quit IRC17:33
mr_sciencehmm, gpg signing of ipks would be fairly straight-forward...17:33
frayRPM also has modes that are security compliant.. (for the life of me I can't remember the certification number anymore)17:34
*** eren <eren!~eren@unaffiliated/eren> has quit IRC17:34
frayit's one of the NIST levels17:34
zibrispeaking of familiarity with rpm, how do i list installed packages? :)17:34
mr_sciencewe added gpg signing to our install package a while back17:35
rburtonmr_science: if you're volunteering to maintain the dpkg support in YP that would be great!17:35
frayzibri, in the cross environment or on the target?17:35
mr_sciencerpm -qa i believe...17:35
zibricross environment17:35
fray:)  ya, that is one of the biggest holes in dpkg support right now.. lack of a consistent maintainer17:35
zibribut that's just a matter of adding --root, right? i'll try :)17:35
frayzibri, in the tmp/work/.../image... directory there is a list of what was installed generated.. installed_packages.txt or something like that17:35
mr_sciencerburton: let me think about that for a bit...17:36
frayyou 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..17:36
zibrifray: i wanted to do a package list just before the rpm invocation that fails17:36
zibrii'm running the do_rootfs from the devshell17:36
frayscript wise.. it's easy as things are already specificed you just have to run them..17:36
* fray goes to look17:36
mr_sciencezibri: looks like rpm -qa --root=/path/to/rootfs shoudl work17:37
fraywithin the install scripts:17:37
frayrpm --root $target_rootfs --dbpath /var/lib/rpm -qa17:37
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:37
frayyou 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 look17:38
mr_sciencefray must be in a later timezone...17:38
frayalternatively you can query smart:17:38
fraysmart --data-dir=${target_rootfs}/var/lib/smart query17:38
frayif I remember ight17:38
fray(smart is the package management front end to RPM in oe)17:39
*** dvhart <dvhart!> has joined #yocto17:39
mr_sciencerburton: i assume there are open bugs on that?17:40
fray        if ${@base_contains("IMAGE_FEATURES", "package-management", "false", "true", d)}; then17:41
lpappfray: dpkg is pretty good for embedded.17:41
lpappwe did that for meego17:41
fray                        rootfs_remove_packages update-rc.d base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}17:41
frayso it looks like if you don't have the package-management enabled as an IMAGE_FEAUTRE< it will try to remove those things..17:41
frayit should be able to do so though17:41
rburtonmr_science: its just not very well tested or used17:42
*** nine_pt <nine_pt!d53ac1ce@gateway/web/freenode/ip.> has joined #yocto17:43
nine_ptbitbake -e busybox | grep ^PACKAGES= shows busybox-staticdev, but executing bitbake busybox-staticdev says: NoProvider: busybox-staticdev Any idea ?17:43
fraybitbake uses recipe names, while PACKAGES are package names.. (those are the names you should use in the IMAGE_INSTALL (in image recipes)17:43
mr_sciencealright, lemme take a look tonight when i get home...17:43
frayyou will need to invoke bitbake busybox17:44
*** zecke_ <zecke_!> has joined #yocto17:44
nine_pthumm ... 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 again17:46
*** zecke <zecke!> has quit IRC17:47
mr_sciencenine_pt: try "ls /path/to/tmp/deploy/*/ipk/busybox-*" and see what packages were built17:48
*** silviof2 <silviof2!> has joined #yocto17:49
nine_ptls tmp/deploy/ipk/armv5te/busybox-*: busybox-dbg busybox-dev busybox-syslog busybox-udhcpc busybox-udhcpd17:49
mr_sciencethere probably are version of the busybox recipe that don't produce a staticdev package17:49
frayYa, the staticdev is only generated if the package generates static libraries.17:50
frayAs far as I know busybox does not do this normally17:50
mr_scienceyou might need to enable static if you really need it17:50
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC17:50
frayeven enabling static busybox likely won't.. as it's only a 'dev' package..17:51
fraybut enablign static would change the binary in the 'busybox' package..17:51
rburtonzenlinux: good work on the HN post about minnow :)17:51
zenlinuxrburton, heh, thanks17:51
*** jzhang <jzhang!jzhang@nat/intel/x-vdmtvqjbtuseddra> has joined #yocto17:51
nine_ptI really need to enable it :) on the recipe don't have any reference to statuc17:51
nine_ptany idea how I can add that ?17:51
zibrifray: 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 :/17:52
zibriremoving it solved the issue17:52
fraynine_pt why do you want a statically linked busybox?17:53
fraylooking at the busybox recipe, it clears the static setting when it first configures the recipe17:53
fray(you should be able to enable it though if needed)17:54
nine_ptfray: long story made short, have a board if I try to run any command in it, it gives segmentation fault17:54
fraybut in most cases, static busybox will actually increase the size and memory usage of theresulting filesystem..17:54
*** belen2 <belen2!Adium@nat/intel/x-jzbhuadryvqiuuml> has quit IRC17:54
*** mulhern <mulhern!> has quit IRC17:55
frayahh so something is going wrong w/ COW and or dynamic loading17:55
nine_ptbut if I upload a static binary it works, I am thinking on a corrupt library on memory17:55
*** silviof2 <silviof2!> has quit IRC17:55
nine_ptI think so, but need more tools to see if can get more info17:55
nine_ptI only need to generate busybox static once, I don't need it on my images17:56
frayyou 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 configure17:56
frayalternatively you may be able to do:17:56
fraybitbake -c menuconfig busybox ; enable it and then recompile17:56
*** Circuitsoft_ <Circuitsoft_!ccb603ed@gateway/web/freenode/ip.> has joined #yocto17:57
nine_ptis there a option on busybox to be compiled static ?17:57
bluelightningzibri: I'll try to make sure we note that in the 1.5 migration docs17:57
nine_ptI was thinking that I will need to change compilation settings17:57
mr_scienceyou could append -static to CFLAGS17:57
zibribluelightning: excellent, thanks :)17:57
fraynine_pt, there should be a configuration option that enables static17:58
frayit's called 'CONFIG_STATIC', but I don't know what it looks like in the menuconfig17:58
mr_sciencelooks like the older (classic) recipe does it that way17:58
mr_scienceexport CFLAGS:="${CFLAGS} -static"17:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:58
mr_scienceother than that, there's just a do_prepare_config_append_pn-busybox-static() function and that's it17:59
frayya, I don't think that will work, but it might.  I've never tried it17:59
mr_sciencenine_pt: give that a try18:00
nine_ptI find the option18:00
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?18:00
mr_scienceonly takes a few minutes...18:00
frayPREFERRED_VERSION needs to refer to the recipe name, not the package name.  RDEPENDS refers to the package name18:00
nine_ptsave he  configuration, but how I force the bitbate busybox to compile it ? it don't detect any change or is refusing to work ...18:00
fraybitbake -C build busybox18:01
Circuitsoft_fray: In this case the package name and recipe name are the same.18:01
frayok.. then it should adjust which version is used to the one specified.. unless the one specified doesn't exist for some reason18:01
mr_scienceCircuitsoft_: i usually put that in the image recipe18:01
Circuitsoft_I'm trying to force use of my-package_0.3.5 instead of my-package_git18:01
frayya, that should just work.. it needs to be in the global local.conf, or a distro.conf or something18:02
Circuitsoft_I want my-app_0.17 to require my-package_git and my-app_git to require my-package_git18:02
frayputting it into the recipe isn't enough to trigger the change18:02
frayRDEPENDS can included versioned dependencies, but for resolution purposes I believe bitbake ignores that..18:02
* mr_science forgets which OE world he lives in...18:03
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?18:03
mr_scienceCircuitsoft_: see if there's distro file already in conf/machine/include or similar18:04 is one example18:05
Circuitsoft_No includes, only my-machine.conf18:05
*** Circuitsoft_ is now known as Circuitsoft18:05
mr_sciencemake one18:05
CircuitsoftThere are a number of PREFERRED_VERSION_package lines in my-machine.conf - should they all go into said include file?18:06
mr_scienceas fray mentioned, could also be under conf/distro/foo18:06
mr_sciencethey're okay where they are, i think18:06
mr_sciencejust add what you need to that and try it out18:07
mr_sciencebitbake -c clean recipe and build it again18:07
*** eballetbo <eballetbo!> has joined #yocto18:08
mr_sciencethe rpi layer has several files in conf/machine/include18:08
mr_sciencenot sure why it was done that way...  might make more sense under conf/distro since it's really not machine-specific18:09
CircuitsoftI was also hoping to switch from in two branches to and in the same branch. That way I would also get different names for devel vs release images.18:10
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto18:12
CircuitsoftLooks like I'm still getting only the git version of the package, even after setting a preferred version to a number.18:12
*** mulhern <mulhern!> has joined #yocto18:15
fraywhat does bitbake -e show you?  (grep for preferred_version)18:18
*** darknighte is now known as darknighte_znc18:24
*** nine_pt <nine_pt!d53ac1ce@gateway/web/freenode/ip.> has quit IRC18:25
Circuitsoftfray: The package I'm trying to pin didn't show up.18:26
CircuitsoftI'm dumb. I accidentally did PREFERRED_PROVIDER18:27
mr_scienceCircuitsoft: sounds like you want two custom image recipes, one to include devel_ and one to include release_18:27
Circuitsoftmy_science - yes, but that's a separate issue.18:27
mr_sciencewhich can live on the same branch just fine...18:27
CircuitsoftThe only difference between what I want in the devel_ and release_ image recipes is PREFERRED_VERSION_myapp.18:27
CircuitsoftBut it's appearing that I can't do that in the image recipe.18:28
mr_scienceare you sure?18:28
mr_sciencei know i have that in my classic images, have to check my poky images when i get home18:28
mr_sciencethe image value *should* override whatever you set as the distro default18:29
CircuitsoftI tried setting 'PREFERRED_VERSION_my-pack = "0.3.5"' in to and it didn't work where 'PREFERRED_VERSION_my-pack ?= "0.3.5"' in conf/machine/mymach.conf did.18:29
mr_sciencetry it in the image recipe instead of the package recipe18:30
mr_sciencethen clean the package and bitbake the image recipe again and see what version gets pulled in18:32
*** eballetbo <eballetbo!> has quit IRC18:34
*** mulhern <mulhern!> has quit IRC18:40
*** jchonig <jchonig!~jch@> has joined #yocto18:41
*** jchonig <jchonig!~jch@> has quit IRC18:47
*** jchonig <jchonig!~jch@> has joined #yocto18:50
*** jchonig <jchonig!~jch@> has quit IRC18:55
*** jchonig <jchonig!~jch@> has joined #yocto18:57
*** blloyd <blloyd!> has joined #yocto18:59
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC19:00
*** jchonig <jchonig!~jch@> has quit IRC19:02
*** jchonig <jchonig!~jch@> has joined #yocto19:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:06
*** jchonig <jchonig!~jch@> has quit IRC19:09
*** jchonig <jchonig!~jch@> has joined #yocto19:11
mr_scienceCircuitsoft: got it working the way you want?19:12
CircuitsoftI think so - now I'm trying to install mypack-0.3.5 on a target in place of mypack-git on the target.19:13
Circuitsoftrpm is /really/ slow.19:14
mr_sciencesounds like you want RCONFLICTS/RREPLACES19:15
*** jchonig <jchonig!~jch@> has quit IRC19:16
*** jchonig <jchonig!~jch@> has joined #yocto19:19
*** jchonig <jchonig!~jch@> has quit IRC19:23
*** jchonig <jchonig!~jch@> has joined #yocto19:25
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:28
*** jchonig <jchonig!~jch@> has quit IRC19:30
*** jchonig <jchonig!~jch@> has joined #yocto19:31
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto19:31
*** jchonig <jchonig!~jch@> has quit IRC19:35
*** jchonig <jchonig!~jch@> has joined #yocto19:36
*** jchonig <jchonig!~jch@> has quit IRC19:40
*** jchonig <jchonig!~jch@> has joined #yocto19:41
mr_scienceso our first major change since the last release of the camera is now back-end server integration *and* a newly revamped redis message protocol...19:52
mr_scienceso far "integration" looks like a huge multi-car pileup19:53
mr_scienceand, like the freeway pileup, it's pretty much too gruesome to look at, yet you can't look away...19:54
frayFYI, the only place we know that RPM is very slow is memory contrained systems or MIPS.. (and we have no idea WHY on mips)19:55
fraychange to ipk for faster behavior, unless you need RPM specific behavior19:55
Circuitsoftfray: Does using 600MB of RAM on a 1GB system count as memory-constrained?19:59
CircuitsoftAlso, our rootfs is on an SD card, so it's possibly disk-bound.19:59
mr_scienceyes, even a good sdcard is pretty slow...20:00
mr_sciencethat 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...20:01
*** joeythesaint <joeythesaint!~jjm@> has quit IRC20:01
fraydepends on what you are doing20:02
* mr_science has been more than pleasantly surprised at the runtime performance and footprint on rpi20:02
frayfor filesystem, for incremental installs (removals) and other berkleydb cache issues that isn't unusual20:02
frayya, I'd never use RPM on an SD card if you can avoid it..20:02
fraythe berkelyDB access pattern can cause issues in my experience20:02
*** blloyd <blloyd!> has quit IRC20:04
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto20:05
*** blloyd <blloyd!> has joined #yocto20:19
*** sameo <sameo!~samuel@> has joined #yocto20:21
*** zecke_ <zecke_!> has quit IRC20:22
*** jkridner <jkridner!~jkridner@nat/ti/x-ypjagizbljejfxco> has joined #yocto20:25
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto20:25
*** ant_home <ant_home!> has joined #yocto20:25
*** joeythesaint <joeythesaint!~jjm@> has quit IRC20:31
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC20:31
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto20:32
*** tor <tor!> has quit IRC20:32
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC20:32
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto20:33
*** Crofton|work <Crofton|work!> has quit IRC20:34
*** quatre <quatre!c0926547@gateway/web/freenode/ip.> has joined #yocto20:45
quatreI 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?20:47
*** Crofton|work <Crofton|work!> has joined #yocto20:51
abelloniis there any gui for network configuration in core-image-sato ?20:54
mr_sciencedon't think so20:57
mr_sciencethe settings gui seemed a little thin when i looked at it20:57
mr_sciencethe only network config guis i know of are the big three: connman-ui, wicd, and network-manager21:07
mr_scienceafaik, there's no current recipe for wicd so your choices are somewhat limited21:07
*** mulhern <mulhern!> has joined #yocto21:10
*** Crofton|work <Crofton|work!> has quit IRC21:13
abellonithere is qconnman in meta-oe21:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:14
mr_sciencei tried to build one of those qt guis and it got so hot the bios shut the machine down21:14
mr_sciencetoo many jobs/threads for qt i guess...21:15
Circuitsoftmr_science: What are you on that has insufficient cooling?21:15
-YoctoAutoBuilder- build #233 of build-appliance is complete: Success [build successful] Build details are at
mr_sciencejust my test buildbox at home21:15
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC21:15
CircuitsoftOn 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.21:16
mr_scienceno cool room, it was during a heatwave, and qt is a pita21:16
mr_scienceCircuitsoft: posted that anywhere public?>21:16
CircuitsoftNo, it was a bash one-liner. I might be able to find it in my .bash_history file, but don't count on it.21:17
CircuitsoftBut, start your build, do a "ps -AHO ppid" and find the pid of the build process.21:17
Circuitsoftwhile 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; done21:19
CircuitsoftI think. I just recreated that now. It may need some tweaking.21:20
CircuitsoftShould be /sys/class/hwmon/hwmon(a_number_here)/device/temp(pick_a_number)_input21:22
Circuitsoftgrep . /sys/class/hwmon/hwmon*/device/temp*_input21:22
CircuitsoftThat will show you all your temperatures. See which one seems to make the most sense.21:22
CircuitsoftAs for building Qt, having a 12-core machine with hyper-threading and 48GB of RAM is quite helpful...21:24
*** acidfoo <acidfoo!~nib@> has joined #yocto21:29
mr_sciencethis is a 95W amd triple-core with 8 GB ram and an unlocked 4th core21:32
mr_sciencepretty cheap-ass hardware...21:32
mr_sciencejust something i threw together out of spare/random parts21:33
*** eren <eren!~eren@unaffiliated/eren> has quit IRC21:33
*** Umeaboy <Umeaboy!> has quit IRC21:36
CircuitsoftI 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.21:37
mr_scienceyeah, mine here is a little older/lighter but similar21:38
mr_sciencedell 2950 with 2 quad HT xeons and only 16 GB ram with a couple TB of raid storage21:38
mr_sciencewhat's weird is i would swear my cheap box is faster at some things...21:39
*** darknighte_znc is now known as darknighte21:39
CircuitsoftI opted for tons of RAM instead of SSDs, since I figure most Yocto compile jobs will fit entirely in vfs cache.21:39
mr_sciencebut the builds are also fairly different (classic here, yocto master at home)21:39
CircuitsoftMy build machine at home is a 65W AMD dual-core with 4GB RAM.21:41
*** acidfoo <acidfoo!~nib@> has quit IRC21:44
*** zedd_ <zedd_!~ddez@> has joined #yocto21:45
*** zeddii <zeddii!~ddez@> has quit IRC21:47
mr_sciencesounds like my desktop at home...21:48
*** Umeaboy <Umeaboy!> has joined #yocto21:53
*** Jefro <Jefro!> has quit IRC21:53
*** acidfoo <acidfoo!~nib@> has joined #yocto21:56
*** darknighte is now known as darknighte_znc21:56
*** Crofton|work <Crofton|work!> has joined #yocto22:02
*** mulhern <mulhern!> has quit IRC22:04
*** _julian <_julian!> has quit IRC22:07
*** _julian <_julian!> has joined #yocto22:07
*** agust <agust!> has quit IRC22:08
*** mulhern <mulhern!> has joined #yocto22:09
*** ant_home <ant_home!> has quit IRC22:18
*** blloyd <blloyd!> has quit IRC22:19
*** fitzsim <fitzsim!~user@nat/cisco/x-nqiwhwcjhtvyaazt> has quit IRC22:20
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC22:31
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nakryffsvxjhdqkf> has quit IRC22:34
*** jchonig <jchonig!~jch@> has quit IRC22:34
*** sameo <sameo!~samuel@> has quit IRC22:37
*** zenlinux <zenlinux!> has quit IRC22:41
*** zenlinux <zenlinux!> has joined #yocto22:43
*** Crofton|work <Crofton|work!> has quit IRC22:47
*** Squix <Squix!> has quit IRC22:52
*** Squix <Squix!> has joined #yocto22:52
*** Jefro <Jefro!> has joined #yocto23:05
*** amarsman <amarsman!~marsman@> has joined #yocto23:07
*** JimBaxter_ <JimBaxter_!> has quit IRC23:11
*** Crofton <Crofton!> has joined #yocto23:14
*** Umeaboy <Umeaboy!> has quit IRC23:23
*** Jefro <Jefro!> has quit IRC23:38
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC23:48
*** andyross <andyross!> has quit IRC23:49

Generated by 2.11.0 by Marius Gedminas - find it at!