| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:08 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 00:12 | |
| *** munch <munch!~mark@67.184.166.69> has quit IRC | 00:24 | |
| *** JaMa|Off is now known as JaMa | 00:31 | |
| *** davest <davest!Adium@nat/intel/x-tgfubvppgkyhxnfh> has joined #yocto | 00:33 | |
| *** _julian <_julian!~quassel@x2f00029.dyn.telefonica.de> has joined #yocto | 00:50 | |
| *** ant_home <ant_home!~andrea@host218-250-dynamic.17-79-r.retail.telecomitalia.it> has quit IRC | 00:51 | |
| *** _julian_ <_julian_!~quassel@x2f14bd1.dyn.telefonica.de> has quit IRC | 00:53 | |
| *** _frank_ <_frank_!~frank@1.202.252.122> has quit IRC | 01:01 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 01:08 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:10 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 01:12 | |
| *** davest <davest!Adium@nat/intel/x-tgfubvppgkyhxnfh> has quit IRC | 01:16 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 01:18 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 01:23 | |
| *** sameo <sameo!~samuel@192.55.54.40> has quit IRC | 01:25 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:28 | |
| *** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto | 01:34 | |
| *** arky <arky!~arky@113.22.48.176> has joined #yocto | 01:47 | |
| arky | Anyone seen this error? ERROR: QA Issue: midori: Files/directories were installed but not shipped | 01:48 |
|---|---|---|
| arky | /usr/share/gir-1.0 | 01:48 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 02:03 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 02:05 | |
| *** arky <arky!~arky@113.22.48.176> has quit IRC | 02: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!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 02:08 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC | 02:24 | |
| *** silviof1 <silviof1!~silviof@ppp-188-174-151-76.dynamic.mnet-online.de> has joined #yocto | 02:25 | |
| *** silviof <silviof!~silviof@ppp-188-174-129-34.dynamic.mnet-online.de> has quit IRC | 02:26 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:02 | |
| *** arky <arky!~arky@113.22.50.152> has joined #yocto | 03:09 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 03:35 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 03:42 | |
| lpapp | can I include .inc files into a forked recipe? | 03:59 |
| lpapp | so that I do not need to fork the .inc file, too. | 04:00 |
| *** vicky <vicky!~vicky@122.165.223.135> has joined #yocto | 04:08 | |
| *** tomz2 <tomz2!~trz@c-68-53-177-94.hsd1.in.comcast.net> has left #yocto | 04:16 | |
| nerdboy | sure, but you'll need more path | 04:23 |
| nerdboy | maybe not, actually... | 04:25 |
| nerdboy | is it a .bb or .bbappend recipe? | 04:25 |
| 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" | 04:27 |
| nerdboy | eg, one of the minimal pi images does this "include recipes-core/images/core-image-minimal.bb" | 04:28 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 04:35 | |
| *** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC | 04:49 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 04:51 | |
| *** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto | 04:53 | |
| *** agust <agust!~agust@p4FDE624B.dip0.t-ipconnect.de> has joined #yocto | 04:53 | |
| *** arky <arky!~arky@113.22.50.152> has quit IRC | 05:00 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 05:04 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 05:05 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 05:05 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 05:11 | |
| *** silviof1 is now known as silviof | 05:25 | |
| *** tasslehoff <tasslehoff!~tasslehof@77.40.182.98> has joined #yocto | 05:26 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 05:32 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 05:33 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 05:47 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-icsfzdtykbbnpgvr> has joined #yocto | 05:47 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 05:48 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 05:49 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:51 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 06:05 | |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 06:08 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 06:09 | |
| -YoctoAutoBuilder- build #244 of nightly-intel-gpl is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-intel-gpl/builds/244 | 06:11 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 06:12 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 06:22 | |
| *** arky <arky!~arky@113.22.48.176> has joined #yocto | 06:22 | |
| *** RP <RP!~richard@dan.rpsys.net> has quit IRC | 06:23 | |
| *** B4gder <B4gder!~daniel@sestofw01.enea.se> has joined #yocto | 06:30 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 06:38 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 06:38 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:38 | |
| *** mckoan|away is now known as mckoan | 06:47 | |
| mckoan | good morning | 06:47 |
| lpapp | that sounds weird if -b drop the dependency checking. | 06:47 |
| lpapp | this means I need to submit a feature request then. | 06:48 |
| lpapp | or is it already possible to pass a preferred version to bitbake through the command, and not config file? | 06:49 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:50 | |
| zecke | Crofton|work: ping? | 06:53 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 06:55 | |
| *** arky <arky!~arky@113.22.48.176> has quit IRC | 07:00 | |
| *** blitz00 <blitz00!~stefans@192.198.151.43> has joined #yocto | 07:01 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto | 07:01 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 07:12 | |
| *** arky <arky!~arky@113.22.95.144> has joined #yocto | 07:13 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 07:16 | |
| -YoctoAutoBuilder- build #232 of build-appliance is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/build-appliance/builds/232 | 07:17 | |
| *** volker <volker!~quassel@host-80-81-19-29.customer.m-online.net> has quit IRC | 07:17 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 07:21 | |
| arky | Anyone seen this error? ERROR: QA Issue: midori: Files/directories were installed but not shipped | 07:21 |
| arky | /usr/share/gir-1.0 | 07:21 |
| *** diego <diego!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 07:21 | |
| *** diego is now known as Guest349 | 07:22 | |
| *** Guest349 <Guest349!~diego@static-217-133-170-65.clienti.tiscali.it> has left #yocto | 07:22 | |
| *** fgretief <fgretief!~chatzilla@41.0.38.138> has joined #yocto | 07:23 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 07:25 | |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:28 | |
| *** AlexG <AlexG!c0c69725@gateway/web/freenode/ip.192.198.151.37> has joined #yocto | 07:30 | |
| lpapp | arky: yes | 07:33 |
| arky | lpapp, Any pointers on how to fix this error | 07:33 |
| lpapp | do_install_append() -> rmdir. | 07:34 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 07:34 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 07:34 | |
| arky | lpapp, Sorry I am new to yocto. Can you explain | 07:34 |
| arky | lpapp, Got it, + rmdir ${D}${datadir}/gir-1.0 | 07:36 |
| arky | lpapp, Thx | 07:36 |
| *** slaine_ <slaine_!~slaine@84.203.137.218> has joined #yocto | 07:38 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 07:38 | |
| *** slaine_ is now known as slaine | 07:38 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC | 07:38 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto | 07:41 | |
| arky | Is there openembedded recipe for sugar (from sugarlabs)? | 07:42 |
| lpapp | no | 07:49 |
| arky | lpapp, Found these oe stuff http://cgit.openembedded.org/openembedded/tree/recipes/sugar/sugar_0.82.9.bb? | 07:49 |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 07:51 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:51 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 07:52 | |
| lpapp | sorry, I meant no oe-core recipe. | 07:52 |
| lpapp | I only checked meta/ | 07:52 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 07:53 | |
| 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. | 07:54 |
| arky | lpapp, Thx for the answer | 07:54 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:55 | |
| bluelightning | morning all | 07:57 |
| lpapp | I was even unaware of that collection, so I learnt something new today. :-) | 07:57 |
| bluelightning | not necessarily a distro layer; sugar recipes would be most appropriate in their own software layer | 07:58 |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:58 | |
| lpapp | I think a software layer for one package is a bit excessive. | 07:59 |
| arky | bluelightning, Morning, I can include this (classic-oe) layer in my bblayers and build right | 08:00 |
| bluelightning | arky: unfortunately not, you'll need to migrate it | 08:00 |
| bluelightning | lpapp: I'm assuming it'll be more than just one recipe | 08:01 |
| arky | bluelightning, Ah! I see | 08:01 |
| bluelightning | arky: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core | 08:01 |
| *** florian_kc is now known as florian | 08:01 | |
| lpapp | bluelightning: based on? | 08:02 |
| bluelightning | lpapp: based on other environments that contain multiple applications and components | 08:02 |
| lpapp | ? | 08:02 |
| bluelightning | ? | 08:02 |
| lpapp | not sure what environment means. | 08:03 |
| lpapp | and even multiple applications and components might not be appropriate inside one layer as they might be very different. | 08:03 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 08:04 | |
| 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 | 08:06 |
| bluelightning | could be completely wrong | 08:06 |
| lpapp | bluelightning: it is just a split package. | 08:07 |
| arky | bluelightning, You are right sugar is half-dozen different components with lot supporting desktop,sound, lib packages | 08:07 |
| lpapp | bluelightning: I personally think it makes more sense to have a recipe group for such things, like recipes-qt5 | 08:07 |
| lpapp | not meta-qt5 | 08:07 |
| lpapp | just like recipes-gnome. | 08:08 |
| 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 | 08:08 |
| lpapp | in fact, recipes-gnome has a lot more packages than sugar. | 08:08 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:09 | |
| lpapp | no, sugar is not too common. | 08:09 |
| lpapp | I would not make a separate layer for each recipe group personally. | 08:09 |
| lpapp | I would use the distro layer. | 08:09 |
| lpapp | as the container. | 08:09 |
| bluelightning | then other distros can't as easily re-use those recipes | 08:10 |
| bluelightning | which we ideally would prefer in the OE ecosystem | 08:10 |
| bluelightning | (assuming the author wishes to make any of it public, which is of course optional) | 08:10 |
| lpapp | ? | 08:11 |
| lpapp | they can easily copy and paste. | 08:11 |
| 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. | 08:11 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 08:12 | |
| bluelightning | lpapp: why should people need to? | 08:12 |
| lpapp | bluelightning: because they need the packages? | 08:12 |
| 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 | 08:13 |
| bluelightning | lpapp: it also allows more freedom of maintainership | 08:13 |
| *** silviof <silviof!~silviof@ppp-188-174-151-76.dynamic.mnet-online.de> has quit IRC | 08:14 | |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto | 08:14 | |
| lpapp | haha | 08:14 |
| lpapp | fetching recipes-foo is just as simple as a layer | 08:14 |
| lpapp | it is just a different name after all. | 08:14 |
| lpapp | so I do not see the problem. | 08:14 |
| bluelightning | well, that's the way we are structuring things | 08:14 |
| lpapp | maintainership is also the same. | 08:14 |
| bluelightning | it has been found to work fairly well | 08:15 |
| lpapp | I think recipe-foo makes more sense | 08:15 |
| lpapp | because it is not a full layer after all, just a recipe-foo. | 08:15 |
| lpapp | so everything else would be dummy in the layer. | 08:15 |
| lpapp | bluelightning: how do you judge? | 08:16 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:16 | |
| lpapp | bluelightning: I can open a bugreport if you wish to show it does not work as "fairly well" as it could. | 08:16 |
| bluelightning | lpapp: by fairly wide community consensus? | 08:16 |
| lpapp | why would you populate a full layer just for a recipe family? | 08:16 |
| lpapp | bluelightning: wide means you and some other Intel guys? | 08:16 |
| lpapp | or does it include me and my familiars who agree with me? | 08:17 |
| bluelightning | lpapp: we have done this already many times... meta-efl, meta-opie, etc. | 08:17 |
| bluelightning | lpapp: actually I'm speaking now more about the wider OpenEmbedded community than anyone from Intel | 08:17 |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 08:17 | |
| lpapp | so everyone minus who disagree. :) | 08:18 |
| lpapp | in fact, the layers decrease the reusability if they are really used in layer senses. | 08:19 |
| *** mranostay <mranostay!~mranostay@ec2-54-215-127-238.us-west-1.compute.amazonaws.com> has quit IRC | 08:19 | |
| lpapp | because if there are no recipe groups as a finer tuned "layer" | 08:20 |
| Crofton|work | zecke, pong | 08:20 |
| lpapp | you will put a lot of stuff into a layer | 08:20 |
| lpapp | see meta-sourcery | 08:20 |
| Crofton|work | I should be asleep | 08:20 |
| lpapp | that is a bloat. | 08:20 |
| lpapp | you need the toolchain, but you get a lot more stuff than you need. | 08:20 |
| lpapp | it ruin the proper reusability by demanding layers. | 08:20 |
| lpapp | ruins* | 08:20 |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 08:20 | |
| lpapp | this makes me wanna open a bugreport about more fine tuned "layers" a.k.a. recipe groups. | 08:21 |
| 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 | 08:22 |
| lpapp | bluelightning: no no, that is not a distro layer at all. | 08:22 |
| lpapp | that is a fundamental misunderstanding. :) | 08:22 |
| bluelightning | well it clearly contains more than just one type of thing... | 08:22 |
| lpapp | that does not make it distro, really. | 08:23 |
| bluelightning | I haven't looked at it in detail | 08:23 |
| lpapp | then please do before claiming that it is a distro layer. | 08:23 |
| 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 | 08:23 |
| lpapp | bluelightning: it is buggy | 08:24 |
| lpapp | why would we bother using it | 08:24 |
| lpapp | it blocks us | 08:24 |
| lpapp | we switched on to meta-sourcery which is also buggy | 08:24 |
| lpapp | but at least, that got fixes after my reports. | 08:24 |
| lpapp | oe-core did not, in time. | 08:25 |
| bluelightning | well, strictly speaking the same people are in charge of maintaining both... | 08:25 |
| lpapp | bluelightning: nope... | 08:25 |
| bluelightning | yep | 08:25 |
| lpapp | bluelightning: CS guys do not maintain or even recommend oe-core... | 08:25 |
| bluelightning | the decision about the future of the recipes in OE-Core is largely in their hands, with some input from the community | 08:26 |
| arky | rburton, Thx | 08:26 |
| arky | bluelightning, lpapp Is there any documentation about using distro layer? | 08:27 |
| bluelightning | arky: there is, one sec | 08:27 |
| lpapp | arky: the reference manual. | 08:27 |
| *** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 08:27 | |
| bluelightning | arky: general layers info: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers | 08:28 |
| *** tbn is now known as Guest96449 | 08:28 | |
| arky | bluelightning, lpapp Thx | 08:28 |
| *** honschu_ <honschu_!~honschu@p549EBA34.dip0.t-ipconnect.de> has joined #yocto | 08:28 | |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto | 08:28 | |
| 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 | 08:29 |
| *** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:31 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 08:31 | |
| *** RP <RP!~richard@dan.rpsys.net> has joined #yocto | 08:31 | |
| 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 | 08:33 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:33 | |
| Crofton|work | I haven't touched that in a long time | 08:35 |
| *** tbn_ <tbn_!~tbn@84.55.160.118> has joined #yocto | 08:39 | |
| *** Guest96449 <Guest96449!~tbn@84.55.160.118> has quit IRC | 08:41 | |
| lpapp | bluelightning: is there any particular reason why there is no config option for removing downloads on the fly? | 08:47 |
| lpapp | rm_downloads similarly to rm_work? | 08:47 |
| bluelightning | lpapp: I guess because most people want to be able to rebuild the recipe without re-downloading | 08:47 |
| bluelightning | it's not something I've heard requested before, FWIW | 08:48 |
| lpapp | well, it would not be default | 08:48 |
| lpapp | ok, I am doing that now on the issue tracker. | 08:48 |
| lpapp | I am getting this all the time: | 08:48 |
| bluelightning | there have certainly been requests to be able to delete _old_ downloads | 08:48 |
| lpapp | (regardless I have rm_work) | 08:48 |
| lpapp | WARNING: The free space of /home/lpapp/Projects/poky/build/tmp (/dev/sda7) is running low (0.942GB left) | 08:48 |
| rburton | lpapp: i suggest writing and trialing it for a while, i suspect it would be incredibly painful in real use | 08:48 |
| lpapp | ERROR: No new tasks can be excuted since the disk space monitor action is "STOPTASKS"! | 08:48 |
| lpapp | and the only workaround is to remove stuff manually. | 08:48 |
| lpapp | rburton: huh? | 08:49 |
| lpapp | it is the extremely _only_ workaround for me. | 08:49 |
| bluelightning | lpapp: is that indication of your free space accurate? | 08:49 |
| lpapp | but I have to do it manually every time. | 08:49 |
| lpapp | I am ... frankly, tired of it. | 08:49 |
| rburton | i guess you could have the situation where there's a local fast mirror | 08:49 |
| lpapp | the other fighting instead of "sure, go ahead". | 08:49 |
| lpapp | :-) | 08:49 |
| lpapp | bluelightning: yes, of course. | 08:50 |
| rburton | lpapp: we ask because some filesystems are known to report bad values | 08:50 |
| lpapp | I need an rm_downloads | 08:50 |
| lpapp | explicit bitbake -c delete_downloads could also work | 08:50 |
| lpapp | but that would still imply _manual_ intervention all the time. | 08:50 |
| lpapp | so I prefer rm_downloads to bitbake -c clean-downloads... | 08:51 |
| 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 | 08:51 |
| lpapp | bluelightning: you will pay me a bigger hard disk? | 08:51 |
| lpapp | and setup while I sleep? | 08:51 |
| lpapp | so I do not need to spend time, effort, money? | 08:51 |
| bluelightning | lpapp: do you pay us for giving you support here? ;) | 08:51 |
| lpapp | no one gives support here about it. | 08:51 |
| lpapp | everyone is reluctant for reporting a feature request ... | 08:52 |
| bluelightning | I believe that's what we're doing... | 08:52 |
| lpapp | which would support from _me_, not _you_ for now. | 08:52 |
| lpapp | be* | 08:52 |
| lpapp | these discussion are very hard-going. | 08:52 |
| rburton | lpapp: i suggested that you write it and see how painful it is in real use. file a feature request if you wish. | 08:52 |
| RP | hard disks are usually relatively cheap compared to the value of people's time | 08:52 |
| lpapp | instead of "go ahead", I always have to fight. | 08:52 |
| lpapp | damn, I will not discuss requests here... | 08:52 |
| bluelightning | we're pretty up-front about our disk space requirements in the quick start guide, FWIW | 08:52 |
| rburton | lpapp: it's called "feedback" | 08:52 |
| lpapp | they will go directly to the issue tracker in here. | 08:53 |
| lpapp | RP: ok, so buy one instead of Intel working on it? | 08:53 |
| *** fusman <fusman!~fahad@110.93.212.98> has quit IRC | 08:53 | |
| lpapp | and someone will set up for me? | 08:53 |
| 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. | 08:53 |
| lpapp | do not be obtuse. | 08:53 |
| lpapp | these are personal costs, time, and effort. | 08:53 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 08:53 | |
| RP | lpapp: and there are costs for adding and maintaining a feature too | 08: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 | |
| lpapp | RP: yeah, it is very reasonable to demand many people's time, effort, and money instead of one person maintaining a little feature. | 08:55 |
| lpapp | yay for a better a world. | 08:55 |
| RP | lpapp: those little features mount up | 08:55 |
| lpapp | so do the many people's time, effort, and money? | 08:55 |
| lpapp | I think this channel is just not recommended for feedback. | 08:56 |
| 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 | 08:56 |
| lpapp | it is too hostile for that. | 08:56 |
| 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. | 08:56 |
| lpapp | the bugzilla service works a lot more friendly. | 08:56 |
| RP | lpapp: the bugzilla and here are run by the same people | 08:56 |
| lpapp | RP: I have never hit any other problems... but you know better for sure... | 08:57 |
| RP | lpapp: only been doing this kind of development for the best part of a decade ;-) | 08:57 |
| lpapp | no no | 08:57 |
| lpapp | the bugzilla accepted all my reports pretty much. | 08:57 |
| lpapp | here, I have to fight with 5 people jumping on me for any trivial stuff. | 08:58 |
| lpapp | this is tiring, and frankly, not making me happy. | 08:58 |
| RP | lpapp: for some definition of accepted | 08:58 |
| lpapp | there is one definition. | 08:58 |
| lpapp | check the bugzilla documentation what that is. | 08:58 |
| lpapp | no wonder why the error reporting, documentation, etc are that broken if the users are turned down. | 08:59 |
| lpapp | when they provide fedback. | 08:59 |
| lpapp | feedback* | 08:59 |
| -YoctoAutoBuilder- build #230 of nightly-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/230 | 09:03 | |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-87-78.ronkva.east.verizon.net> has quit IRC | 09:05 | |
| *** belen <belen!Adium@nat/intel/x-hjgexkwuaqnbfuyy> has joined #yocto | 09:07 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 09:08 | |
| -YoctoAutoBuilder- build #234 of nightly-x86 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/234 | 09:17 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 09:19 | |
| eren | morning all | 09:21 |
| *** slaine_ <slaine_!~slaine@84.203.137.218> has joined #yocto | 09:21 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 09:22 | |
| *** slaine_ is now known as slaine | 09:22 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 09:27 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 09:41 | |
| *** fusman <fusman!~fahad@110.93.212.98> has joined #yocto | 09:43 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 09:56 | |
| lpapp | is there any way I can fix busybox without PACKAGECONFIG? | 10:05 |
| lpapp | any easier, that is. | 10:05 |
| *** arky <arky!~arky@113.22.95.144> has quit IRC | 10:05 | |
| lpapp | JaMa: you seem to be the big PACKAGECONFIG hacker based on git log -S. :) | 10:11 |
| *** diego <diego!~diego@5.84.38.224> has joined #yocto | 10:13 | |
| *** diego is now known as Guest37310 | 10:13 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 10:15 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 10:17 | |
| *** Guest37310 <Guest37310!~diego@5.84.38.224> has quit IRC | 10:21 | |
| 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? | 10:25 |
| rburton | lpapp: packageconfig is the recommended way to setup options that various people may want on or off. | 10:30 |
| rburton | not possible for some recipes, but its always worth trying first | 10:30 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 10:32 | |
| *** GunsNRose <GunsNRose!~GunsNRose@118.114.99.237> has joined #yocto | 10:44 | |
| lpapp | rburton: but it takes me quite a bit of time. | 10:48 |
| lpapp | rburton: and I do not find proper examples. | 10:48 |
| lpapp | I grepped through several, but they are stuff that the software handles off-hand. | 10:48 |
| lpapp | that is not so much the case with busybox | 10:48 |
| lpapp | so the mapping would need to be implemented. | 10:48 |
| rburton | the alternative would be a variable you can check in features_to_busybox_settings() | 10:54 |
| lpapp | .bbappend would work as a quick hack for defconfig | 10:54 |
| lpapp | but it would not work for the other two changes. | 10:54 |
| lpapp | and 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 |
| lpapp | not sure why they cause build issues | 10:55 |
| lpapp | our board does not have wifi, nor bluetooth. | 10:55 |
| lpapp | so they should be disabled anyway. | 10:55 |
| rburton | sorted :) | 10:56 |
| rburton | turn off wifi and bluetooth, and rfkill goes away | 10:56 |
| lpapp | ? | 10:57 |
| lpapp | so how cna I implement a package config option | 10:57 |
| lpapp | ? | 10:57 |
| lpapp | --without-rfkill | 10:57 |
| rburton | if you remove the wifi and bluetooth DISTRO_FEATURES from your distro, then the rfkill applet won't be built | 10:57 |
| lpapp | what do I need to do in the background to disable those two lines in busybox.inc | 10:57 |
| lpapp | what do I need to check against? | 10:57 |
| rburton | well, we've a better fix here | 10:57 |
| lpapp | ? | 10:57 |
| rburton | if you don't have wifi or bluetooth, disable those in your distro | 10:58 |
| rburton | you'll save space in busybox and other places | 10:58 |
| lpapp | poky-tiny should not bring wifi and bluetooth anyway | 10:58 |
| lpapp | ? | 10:58 |
| rburton | why not? | 10:58 |
| *** fgretief <fgretief!~chatzilla@41.0.38.138> has quit IRC | 10:58 | |
| rburton | who are you to say that poky-tiny shouldn't have wifi? | 10:58 |
| lpapp | well, the omap supports those potentially. | 10:58 |
| rburton | exactly | 10:58 |
| lpapp | so I would rather keep them for future flexibility. | 10:58 |
| rburton | but *your* distro doesn't need them, so you can disable them. | 10:58 |
| lpapp | so the mapping from PACKAGECONFIG to busybox.inc has to happen somehow. | 10:59 |
| rburton | if in the future you need wifi you can come back to this | 10:59 |
| lpapp | is there any example for this out there how exactly? | 10:59 |
| lpapp | I do not wanna debug this in the future | 10:59 |
| rburton | from ten seconds of reading busybox.inc, you'll need to implement a mapping layer if you wanted to use PACKAGECONFIG. | 10:59 |
| 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) | 11:00 |
| rburton | ie connman won't builds its wifi or bluetooth support, if you're using that | 11:00 |
| lpapp | it is not a distro tweak | 11:01 |
| lpapp | it is a generic older toolchain support tweak. | 11:01 |
| lpapp | and actually I checked, the network layer depends on wifi, and bluetooth, etc. | 11:01 |
| rburton | "network layer"? | 11:02 |
| lpapp | yes, exactly. | 11:02 |
| rburton | i meant what do you mean by network layer | 11:02 |
| lpapp | no, we do not use connman. | 11:02 |
| lpapp | sounds like a bad yocto stuff if it is a lot of work to do a very simple mapping | 11:03 |
| lpapp | if A is set, disable this and that. | 11:03 |
| rburton | its not a lot of work | 11:03 |
| rburton | its just work | 11:03 |
| lpapp | that should be about .. 3-5 LOC? | 11:03 |
| lpapp | or even 2 in an ideal world. :-) | 11:04 |
| rburton | well, the packageconfig string to configure arguments/dependencies is about 20 loc | 11:04 |
| rburton | iirc | 11:04 |
| *** swex <swex!~swex@185.6.250.60> has joined #yocto | 11:04 | |
| lpapp | not sure what you mean? | 11:04 |
| rburton | the code that turns a packageconfig string into configure arguments and dependencies is about 20 loc | 11:04 |
| rburton | maybe a bit more | 11:04 |
| lpapp | that looks like a bad design | 11:05 |
| rburton | its called "python" | 11:05 |
| lpapp | in qt, we have the feature system. | 11:05 |
| lpapp | this is what you do: | 11:05 |
| lpapp | ./configure -with-feature-nooo | 11:05 |
| lpapp | ./configure -with-feature-nofoo* | 11:05 |
| lpapp | NOFOO is defined | 11:05 |
| lpapp | code in the background: | 11:05 |
| lpapp | #ifdef NOFOO | 11:05 |
| lpapp | ... | 11:05 |
| lpapp | #endif | 11:05 |
| rburton | i was refering to the code that in your example reads the configure arguments, parses them, handles duplicates, and defines the variable | 11:06 |
| 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 | 11:06 |
| rburton | so this isn't a trivial task | 11:06 |
| lpapp | not sure what you mean, but do you have an example for such a mapping already implemented and I could take a look? | 11:07 |
| lpapp | maybe, I would get it better. | 11:07 |
| lpapp | yes, that is why it is a bad design. | 11:07 |
| lpapp | it should be a trivial task solved by a centralized boiler-plate. | 11:07 |
| *** swex__ <swex__!~swex@217.197.245.213> has quit IRC | 11:07 | |
| rburton | sigh. as i've said that centralised boilerplate was designed around configure arguments, not cml. feel free to extend it. | 11:07 |
| lpapp | or not bad, but missing. | 11:07 |
| rburton | i was about to point you at base.bbclass | 11:08 |
| lpapp | sounds like a bugreport. | 11:08 |
| rburton | search for PACKAGECONFIG and you'll find the python function that implements it | 11:08 |
| lpapp | not sure what "cml" means. | 11:08 |
| ant_work | martiert: is the error about .gitignore ? | 11:10 |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4964 | 11:11 |
| yocti | Bug 4964: normal, Undecided, ---, saul.wold, NEW , Simplify the mapping between PACKAGECONFIG and .bb/.inc files | 11:11 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 11:13 | |
| *** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto | 11:16 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 11:16 | |
| lpapp | MultiModule.sh was removed in dylan? o_O :( | 11:17 |
| lpapp | is it possible to pass the preferred version to bitbake on the command line? | 11:21 |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965 | 11:24 |
| yocti | Bug 4965: normal, Undecided, ---, richard.purdie, NEW , Not possible to pass the preferred version to bitbake on the command line | 11:24 |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4966 | 11:29 |
| yocti | Bug 4966: normal, Undecided, ---, saul.wold, NEW , Add a feature ("rm_downloads") for INHERIT | 11:29 |
| *** vicky <vicky!~vicky@122.165.223.135> has quit IRC | 11:30 | |
| lpapp | http://pastebin.com/w1qmkJNR -> 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 http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/203 | 11:32 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 11:32 | |
| *** belen2 <belen2!Adium@nat/intel/x-zkwhlwmjigdertqd> has joined #yocto | 11:34 | |
| *** belen <belen!Adium@nat/intel/x-hjgexkwuaqnbfuyy> has quit IRC | 11:35 | |
| rburton | lpapp: it means a file or directory was installed but not packaged. | 11:37 |
| lpapp | rburton: why am I getting such a regression in dylan? | 11:37 |
| lpapp | or well, even master ahead. | 11:37 |
| B4gder | lpapp: we must've missed your fix for it! | 11:37 |
| rburton | mainly because external-sourcery-toolchain isn't tested very well currently | 11:38 |
| lpapp | rburton: how do you know it is related to that? | 11:38 |
| rburton | lpapp: because thats the package that is producing the warnings | 11:38 |
| lpapp | "nice" | 11:38 |
| lpapp | what can I do to fix it? | 11:39 |
| lpapp | do you know the root cause of the issue? | 11:39 |
| lpapp | wany pointers, etc | 11:39 |
| rburton | either delete those files if they're not meant to be installed, or add to FILES_ if they are | 11:39 |
| lpapp | any* | 11:39 |
| rburton | this is basic FILES_* manipulation | 11:39 |
| lpapp | why did it not need any special attention before? | 11:39 |
| * rburton shrugs | 11:39 | |
| rburton | because stuff changes? | 11:39 |
| lpapp | what stuff exactly ... | 11:39 |
| rburton | everything | 11:39 |
| rburton | distro configuration could have changed that meant an assumption wasn't valid | 11:40 |
| lpapp | so, basically you are claiming who cares why it happens. | 11:40 |
| lpapp | that is not my mentality. | 11:40 |
| rburton | no | 11:40 |
| lpapp | I would like to understand why I am fixing things. | 11:40 |
| rburton | and you're in the perfect place to understand | 11:40 |
| rburton | what with you getting the error and not me | 11:40 |
| lpapp | so, you have no clue? | 11:41 |
| rburton | any clue why you're getting those errors exactly? no, never used the external toolchain. | 11:41 |
| rburton | in general i've told you why those errors happen | 11:41 |
| rburton | and what to do to resolve them | 11:41 |
| lpapp | it is an external toolchain. | 11:42 |
| lpapp | it should be deleted in the the meta-sourcery/*/*.bb? | 11:42 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 11:42 | |
| rburton | whatever the recipe is that your building needs fixing | 11:43 |
| lpapp | perhaps it is a dylan enforcement. | 11:43 |
| rburton | maybe it needs more files packages | 11:43 |
| rburton | our QA certainly improved in dylan | 11:43 |
| lpapp | as the recipe of course did not change a bit. | 11:43 |
| lpapp | NOTE: preferred version 141 of udev not available (for item udev) | 11:44 |
| lpapp | NOTE: versions of udev available: 182 | 11:44 |
| lpapp | what happens in such cases? | 11:44 |
| lpapp | 182 will be built? | 11:44 |
| rburton | yes | 11:44 |
| lpapp | how weird. | 11:44 |
| rburton | what would you prefer? | 11:45 |
| lpapp | I mean, it is building udev 182, that is weird. | 11:45 |
| lpapp | it was broken on my home machine. | 11:45 |
| rburton | don't let it know you've noticed, it might break! | 11:46 |
| lpapp | 4941 | 11:46 |
| lpapp | !4941 | 11:46 |
| lpapp | !BUG 4941 | 11:46 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4941 normal, Undecided, ---, saul.wold, NEW , udev doesn't compile with older toolchains | 11:46 |
| lpapp | foo 4941 | 11:46 |
| rburton | bug 4941 | 11:47 |
| rburton | hm, i always forget the syntax | 11:47 |
| lpapp | :P | 11:47 |
| lpapp | !bug 4941 | 11:47 |
| lpapp | !BUG 4941 | 11:47 |
| lpapp | now, that is weird. | 11:47 |
| rburton | ah | 11:47 |
| rburton | 4941 | 11:48 |
| rburton | heh | 11:48 |
| rburton | rate limited? | 11:48 |
| rburton | whatever | 11:48 |
| 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. | 11:48 |
| rburton | that udev fail is because your userspace is old | 11:48 |
| lpapp | the toolchain is. | 11:48 |
| lpapp | is the yocti syntax documented somewhere? | 11:49 |
| lpapp | I do not know off-hand how to use the help. | 11:49 |
| lpapp | it would be preferrable to have a self-contained greppable stuff. | 11:49 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 11:49 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:53 | |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 11:54 | |
| *** calin <calin!86bfdd4a@gateway/web/freenode/ip.134.191.221.74> has joined #yocto | 11:56 | |
| *** calin is now known as Guest93981 | 11:57 | |
| lpapp | poky-dylan-9.0.1/build$ ls /tmp/ | 12:05 |
| lpapp | pulse-PKdhtXMmr18n VMwareDnD vmware-root | 12:05 |
| lpapp | err... this is what? | 12:05 |
| otavio | Hello | 12:13 |
| otavio | I am trying to find why bitbake is not behaving as expected | 12:13 |
| lpapp | otavio: with regards to? | 12:14 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 12:15 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 12:15 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 12:15 | |
| rburton | lpapp: that's your /tmp directory. pulseaudio socket and vmware sockets by the look of it. | 12:15 |
| lpapp | rburton: yeah, I realized that much | 12:16 |
| lpapp | you did not leave me time to finish the writing of that. :p | 12:16 |
| lpapp | this is surprising... | 12:16 |
| lpapp | udev182 builds on ubuntu 12.10 | 12:16 |
| lpapp | with the same toolchain ... | 12:17 |
| rburton | otavio: bitbake always behaves as intended, you're just wrong about what you think it should do ;) | 12:17 |
| lpapp | and the same old toolchain does not have that defined either. | 12:17 |
| otavio | rburton: yaya! | 12:17 |
| otavio | lol | 12:17 |
| otavio | rburton: the data.finalize() bb method does not finalize it hheheh | 12:17 |
| rburton | otavio: well clearly there a good reason for that ;) | 12:18 |
| otavio | rburton: sure ;-) | 12:20 |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has quit IRC | 12:20 | |
| otavio | rburton: do you know this code? | 12:20 |
| otavio | rburton: I can explain the bug, not why | 12:20 |
| rburton | otavio: sorry. not me. try bluelightning. | 12:21 |
| otavio | bluelightning: :-) | 12:21 |
| otavio | bluelightning: it was rburton who pointed at you. Blame him ;) | 12:21 |
| otavio | lol | 12:21 |
| rburton | i know that data_smart is 90% unicorn magic | 12:21 |
| bluelightning | otavio: I'm not sure either... but I might suggest this is why attempting to do this kind of thing is problematic | 12:21 |
| otavio | bluelightning: well | 12:21 |
| otavio | bluelightning: does not solve the bug | 12:22 |
| otavio | and it does seem it is a bug in bitbake. | 12:22 |
| otavio | bluelightning: want me to explain it? | 12:22 |
| bluelightning | otavio: you're calling finalize() and what doesn't happen? | 12:22 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 12:23 | |
| otavio | bluelightning: let's focus on DISTRO_FEATURES only | 12:23 |
| otavio | bluelightning: it is set in two places, in case of poky | 12:23 |
| otavio | bluelightning: ?= in defaultsetup and _append in poky | 12:23 |
| 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 | 12:25 |
| otavio | bluelightning: finalize seems to delay _append (which makes sense) but than the added in _append are done /after/ .finalize | 12:25 |
| otavio | bluelightning: This can be done in many ways and it'd cover the bug. | 12:26 |
| lpapp | so, what is the replacement for MultiModule in dylan? | 12:26 |
| otavio | bluelightning: the point is when ConfigParsed event is triggered, it is not fully done. | 12:26 |
| bluelightning | lpapp: what is MultiModule? | 12:26 |
| lpapp | bluelightning: initscript stuff for updating. | 12:27 |
| *** B4gder <B4gder!~daniel@sestofw01.enea.se> has quit IRC | 12:27 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has joined #yocto | 12:27 | |
| bluelightning | lpapp: "git grep MultiModule" doesn't find anything in denzil nor dylan | 12:28 |
| lpapp | poky-denzil-7.0.1/meta/recipes-core/initscripts/initscripts-1.0/MultiModule.sh | 12:28 |
| lpapp | git grep != grep | 12:28 |
| *** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.91.230.2.244> has joined #yocto | 12:28 | |
| lpapp | and you need find here anyway, not grep. :-) | 12:28 |
| bluelightning | lpapp: you mean git grep is not find | 12:28 |
| lpapp | I 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 it | 12:29 |
| lpapp | it is not so simple. | 12:30 |
| 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! | 12:30 |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 12:30 | |
| lpapp | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initscripts?h=denzil -> true, it is not in the repository. | 12:31 |
| bluelightning | lpapp: this is probably something added on top of poky because it doesn't exist in denzil | 12:31 |
| lpapp | which is kinda worrying how much stuff we have put in there... :/ | 12:31 |
| lpapp | what is the intended way of defining own init scripts/ | 12:31 |
| lpapp | distro layer? | 12:32 |
| bluelightning | it is, I'd strongly suggest you do a comparison and try to break things out into your distro layer | 12:32 |
| 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) | 12:32 |
| bluelightning | lpapp: if it's a standalone script, use an initscripts bbappend | 12:32 |
| *** jkridner <jkridner!~jkridner@nat/ti/x-wmaijdfmtkuxwydd> has joined #yocto | 12:35 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 12:35 | |
| bluelightning | g0hl1n: its contents comes from the BUILDNAME variable which is defaulted within bitbake code if not set | 12:36 |
| 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) | 12:36 |
| g0hl1n | bluelightning: ok, thanks! So i can set BUILDNAME in my distro configuration? | 12:37 |
| 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 | 12:38 |
| g0hl1n | bluelightning: thanks! | 12:44 |
| *** tasslehoff <tasslehoff!~tasslehof@77.40.182.98> has left #yocto | 12:45 | |
| *** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 12:53 | |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 12:53 | |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 12:57 | |
| RP | otavio: the datastore you get with a ConfigParsed event is not expanded/finalised. That is by design | 13:01 |
| otavio | RP: but when I call d.finalize() shouldn't this work? | 13:01 |
| otavio | RP: bb.data.update_data does not help | 13:02 |
| RP | otavio: well, a) you should copy it, then finalize it and b) you also need expand_keys() iirc for some uses | 13:02 |
| RP | otavio: but if everything you need is parsed by then, you should be able to finalise a copy, yes | 13:03 |
| otavio | RP: I did the copy in v2 | 13:03 |
| otavio | RP: and called finalize | 13:03 |
| otavio | RP: and it didn't work :( | 13:03 |
| otavio | RP: _append is done after | 13:03 |
| RP | otavio: Its expected that _append would append to a ?= | 13:04 |
| otavio | RP: http://privatepaste.com/5706fa74c4# current patch. | 13:04 |
| otavio | RP: yes | 13:04 |
| lpapp | is there any option to remove everything except the downloads? | 13:04 |
| otavio | RP: it is done after, right? | 13:04 |
| lpapp | i.e. before checking stuff into the repository. | 13:04 |
| otavio | RP: but ConfigParsed seems to be called /before/ the last append | 13:05 |
| lpapp | and conf, of course. | 13:05 |
| otavio | RP: this part of bb code is confusing for me so I couldn't yet understand it fully | 13:06 |
| RP | otavio: I don't understand what problem you're seeing :/ | 13:06 |
| RP | otavio: I'm also not meant to be here :/ | 13:07 |
| RP | lpapp: most people use .gitignore for that purpose | 13:07 |
| otavio | RP: if I do EXTRA_DISTRO_FEATURES = "~x11 ~wayland" x11 is dropped, wayland does not. | 13:07 |
| otavio | RP: so wayland is kept | 13:07 |
| otavio | RP: yes I know you're in vacations :) | 13:08 |
| RP | otavio: ah, I can see why this does happen :/ | 13:08 |
| lpapp | so bitbake is not our friend in here? | 13:09 |
| RP | otavio: _append is near impossible to cancel out :/ | 13:09 |
| lpapp | :/ | 13:09 |
| otavio | RP: but finalize should have returned it done no? | 13:09 |
| RP | otavio: that code will cancel out wayland in DISTRO_FEATURES at ConfigParsed time | 13:10 |
| RP | otavio: but nothing removes the _append from the system and stops wayland being added back | 13:10 |
| otavio | RP: in fact it is added back | 13:10 |
| otavio | RP: well but this is bad. We cannot get a 'final' result? | 13:11 |
| RP | otavio: no, you get the final result, its just you can't overwrite it completely | 13:12 |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 13:12 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 13:13 | |
| RP | otavio: I suspect you could hack it with a d.delVarFlag("DISTRO_FEATURES", "_append") | 13:13 |
| RP | otavio: but that is assuming internal bitbake knowledge | 13:13 |
| RP | i.e. I will not take patches using that | 13:13 |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto | 13:13 | |
| lpapp | bluelightning: you are maintaining the CS oe-core stuffy? | 13:13 |
| bluelightning | lpapp: no, I'm not | 13:14 |
| lpapp | bluelightning: so what is with this change then? | 13:14 |
| bluelightning | lpapp: which change? | 13:15 |
| lpapp | bluelightning: your fix? | 13:15 |
| 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 | 13:18 |
| *** darknighte_znc is now known as darknighte | 13:18 | |
| *** arky <arky!~arky@113.22.95.144> has joined #yocto | 13:19 | |
| * RP wanders off the play with lime mortar again | 13:20 | |
| *** davest <davest!Adium@nat/intel/x-wwvmjrbsklhzglvu> has joined #yocto | 13:22 | |
| mulhern | Do there exist any regression tests for create-recipe script? | 13:22 |
| mulhern | The one in poky/scripts. | 13:23 |
| JaMa | lpapp: remove PR assignments in your u-boot patch | 13:24 |
| bluelightning | mulhern: I think maybe we don't have a test for that, but testopia would be the best place to check | 13:24 |
| mulhern | testopia? | 13:24 |
| lpapp | JaMa: why? | 13:24 |
| bluelightning | mulhern: it's integrated into our bugzilla | 13:24 |
| JaMa | lpapp: http://lists.openembedded.org/pipermail/openembedded-core/2012-December/071572.html | 13:25 |
| rburton | JaMa: do you have that url memorised? :) | 13:25 |
| 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? | 13:26 |
| rburton | mulhern: its a bit of a maze unless you're a qa expert tbh | 13:28 |
| otavio | RP: and how to handle this in a cleaner way? | 13:29 |
| bluelightning | mulhern: indeed... in theory you should just be able to search for a keyword in all of the test cases | 13:29 |
| JaMa | rburton: no, but I needed the link to persuade some other people about PR_append stupidity, so it was worth finding it | 13:30 |
| otavio | RP: I am testing the delVarFlag hack | 13:31 |
| lpapp | JaMa: but others do it, too. | 13:32 |
| 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. | 13:34 |
| rburton | mulhern: tbh, i'd be surprised if there's a test for it | 13:34 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nakryffsvxjhdqkf> has joined #yocto | 13:35 | |
| 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. | 13:40 |
| bluelightning | mulhern: right, we're in the process of automating our testing for the upcoming release | 13:41 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 13:41 | |
| JaMa | lpapp: most upgrades are dropping PR, existence of bad example isn't good reason for you to follow it, is it? | 13:41 |
| lpapp | rburton: I am not sure if there is any reason for the old ones. | 13:41 |
| lpapp | rburton: there are many around already | 13:41 |
| lpapp | someone with competence needs to judge on that, sorry. | 13:42 |
| lpapp | I would not like to have a take on this. | 13:42 |
| lpapp | JaMa: maybe, but I do not have time to update it now. | 13:42 |
| lpapp | and I do not think it should be a blocker either. | 13:42 |
| JaMa | it can wait till you have time to update it | 13:43 |
| JaMa | upgrade to newer u-boot isn't bloker too | 13:43 |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 13:44 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 13:45 | |
| mulhern | bluelightning: Is this the ptest stuff? I know I've heard rumours. | 13:46 |
| *** adinu <adinu!adinu@nat/intel/x-brgxbsbftsuyagvx> has joined #yocto | 13:46 | |
| bluelightning | mulhern: that's a separate but related effort | 13:46 |
| *** mprica <mprica!c0c69724@gateway/web/freenode/ip.192.198.151.36> has joined #yocto | 13:46 | |
| bluelightning | mulhern: ptest provides the mechanism to integrate tests supplied with each piece of software we build | 13:46 |
| mulhern | bluelightning: That makes sense based on context. So, what is the other effort? | 13:47 |
| *** JimBaxter_ <JimBaxter_!~jbaxter@jimbax.plus.com> has joined #yocto | 13:47 | |
| *** eciobanu <eciobanu!c0c69724@gateway/web/freenode/ip.192.198.151.36> has joined #yocto | 13:48 | |
| *** davest <davest!Adium@nat/intel/x-wwvmjrbsklhzglvu> has quit IRC | 13:49 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 13:49 | |
| 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 | 13:50 |
| *** Krz <Krz!c0c69724@gateway/web/freenode/ip.192.198.151.36> has joined #yocto | 13:50 | |
| 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 | 13:52 |
| 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. | 13:54 |
| mulhern | bluelightning: So, a runtime test is what is run on an image after it is built? | 13:54 |
| bluelightning | mulhern: correct | 13:54 |
| bluelightning | mulhern: FYI: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740 | 13:55 |
| yocti | Bug 4740: enhancement, Medium+, 1.5, mihaix.lindner, NEW , Consider providing an oe-selftest script to run automated tests against bitbake tools | 13:55 |
| 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? | 13:56 |
| bluelightning | mulhern: that's correct, and it would appear there's no manual test case either | 13:58 |
| *** belen2 <belen2!Adium@nat/intel/x-zkwhlwmjigdertqd> has quit IRC | 13:58 | |
| 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 | 13:58 |
| *** davest <davest!~Adium@134.134.137.71> has joined #yocto | 13:59 | |
| bluelightning | Krz: I think the scc file is important, but I'm not an expert in that area | 13:59 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 14:01 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 14:01 | |
| mulhern | bluelightning: It puts over1000 lines of Perl into attempting to infer all sorts of things from downloaded distributions. | 14:02 |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 14:03 | |
| Krz | bluelightning: 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 #yocto | 14:04 | |
| 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 | 14:04 |
| ant_work | Krz: the scc format hasn't changed. Keep that file. For doubts, ^^^ | 14:05 |
| *** elmi82_ <elmi82_!~timo@mail.bmw-carit.de> has joined #yocto | 14:10 | |
| ant_work | bluelightning: where do we put xinput-calibrator now? in XSERVER? | 14:14 |
| bluelightning | ant_work: I would think so yes | 14:15 |
| ant_work | or maybe as RDEPENDS_${PN} of x11-common | 14:16 |
| ant_work | similarly to what was done by meta-oe's xserver-common | 14:16 |
| ant_work | s/was/is/ | 14:16 |
| bluelightning | ant_work: the thing is it would have to be conditional there since it's only needed for devices that have a touchscreen | 14:17 |
| ant_work | did you say xserver-nodm-init will be unified soon? | 14:17 |
| ant_work | so x11-common and xserver-common & their RDEPS ? | 14:18 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:18 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 14:26 | |
| *** davest <davest!~Adium@134.134.137.71> has quit IRC | 14:26 | |
| *** davest <davest!Adium@nat/intel/x-azpndujhybsycxcm> has joined #yocto | 14:27 | |
| *** belen2 <belen2!Adium@nat/intel/x-ugcqutzkbreqfsti> has quit IRC | 14:30 | |
| bluelightning | ant_work: actually I may have been mistaken on that one... I'm not sure if anyone is actively working on that atm | 14:31 |
| bluelightning | ant_work: I suspect xinput-calibrator not being in OE-Core might have been one blocker to that though | 14:32 |
| bluelightning | JaMa: can you recall any others? | 14:32 |
| ant_work | maybe we need to improve that -common recipe adding more conditionals | 14:33 |
| *** belen <belen!Adium@nat/intel/x-cdzhkmbgplalimuo> has joined #yocto | 14:34 | |
| ant_work | pls add this to the long to-do so we don't forget ;) | 14:35 |
| ant_work | bbl | 14:35 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 14:35 | |
| *** tsjsieb <tsjsieb!~tsjsieb@5469C560.cm-12-2d.dynamic.ziggo.nl> has quit IRC | 14:35 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 14:42 | |
| 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 | 14:45 |
| bluelightning | ok | 14:45 |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 14:46 | |
| eren | oh, I hit the problem of "waiting for removable media" | 14:47 |
| bluelightning | JaMa: I guess this one: http://lists.openembedded.org/pipermail/openembedded-core/2013-February/075336.html | 14:48 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:48 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 14:54 | |
| g0hl1n | Hey everybody, is it possible to completely disable all qemu stuff when building an image? | 14:55 |
| g0hl1n | because in my case qemu is opening a lot of files (i think all) and closing it right after. | 14:56 |
| g0hl1n | Because of that my build needs over 4 hours to finish altough most of the packages are skipped... | 14:57 |
| g0hl1n | in my local.conf #IMAGETEST = "qemu" is commented out... | 14:58 |
| g0hl1n | Does anybody have some ideas? | 14:58 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 15:00 | |
| Net147 | satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-boot: busybox-hwclock, any ideas? | 15:01 |
| Net147 | looks like busybox-hwclock is empty due to http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3b9b8d571da6bb3652427e8ccc7948cbcec0e517 when using systemd | 15:04 |
| JaMa | bluelightning: yes, that's the one I was thinking about | 15:04 |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-icsfzdtykbbnpgvr> has left #yocto | 15:05 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 15:06 | |
| lpapp | JaMa: it is a blocker | 15:07 |
| lpapp | it has nice new features, etc. | 15:07 |
| lpapp | which we and probably others need, too. | 15:07 |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 15:07 | |
| lpapp | you would seriously block a software update because of PR? :O | 15:07 |
| bluelightning | lpapp: patches need to be properly formed before merging, that's the way we operate | 15:08 |
| lpapp | it is properly formatted. | 15:08 |
| lpapp | like many other patches going in. | 15:08 |
| lpapp | please do not be discriminative. | 15:08 |
| lpapp | I will leave that patch, too. | 15:09 |
| bluelightning | lpapp: that process need not block you because git allows maintaining your own branch easily | 15:09 |
| lpapp | my contribution is not welcome anyway | 15:09 |
| lpapp | this is not the first blocker change | 15:09 |
| lpapp | which people need. | 15:09 |
| lpapp | yet, it is being rejected due to pedantic nitpicking unpragmatic nonsense | 15:09 |
| 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.. | 15:09 |
| bluelightning | lpapp: every project has certain requirements for submitted changes, I'm sure other projects you've worked with have similar requirements | 15:09 |
| fray | the quality of the project requires pedantic nitpicking | 15:09 |
| *** GunsNRose <GunsNRose!~GunsNRose@118.114.99.237> has quit IRC | 15:11 | |
| JaMa | lpapp: it's called review for other devs to have opportuninty to say needed changes before it's merged | 15:13 |
| lpapp | bluelightning: not this stupid, no. | 15:14 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 15:14 | |
| lpapp | JaMa: I will start meta-qt5 from scratch. | 15:14 |
| lpapp | with my qt5 upstream expertise. | 15:14 |
| lpapp | I cannot collaborate with people who would block packages for .... formal nitpicking not to get the software into users' hand. | 15:15 |
| lpapp | actually, it will be recipes-qt5. | 15:15 |
| davest | lpapp: that's your choice. We must maintain our standards to maintain quality | 15:16 |
| davest | lpapp: and it's such a little thing, yes? | 15:16 |
| fray | Note, someone else has already started a meta-qt5: https://github.com/meta-qt5/meta-qt5 | 15:16 |
| lpapp | davest: yes, people would block it ffs... | 15:16 |
| lpapp | such a little minor nonsense. | 15:16 |
| JaMa | fray: that's mine | 15:16 |
| lpapp | to block it ... like people cannot get the software for that? | 15:16 |
| lpapp | I think I have an entirely different vision with accepting contributions and towards end users. | 15:17 |
| 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 | 15:17 |
| bluelightning | or otherwise addressed | 15:17 |
| lpapp | bluelightning: yes, nice joke. | 15:17 |
| lpapp | you are not blocked, you can fork the project. | 15:17 |
| lpapp | sure, nobody is blocked to contribute to M$ either. | 15:17 |
| bluelightning | lpapp: I'm being completely serious, this is how people get their work done | 15:18 |
| lpapp | they can rewrite it in their branch. | 15:18 |
| lpapp | bluelightning: you are seriously not making sense IMO then. | 15:18 |
| 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? | 15:18 |
| lpapp | JaMa: stupid rules are stupid | 15:18 |
| lpapp | I build the software for the users | 15:18 |
| JaMa | lpapp: do you understand wht PR service is? | 15:19 |
| lpapp | not a few devs to satisfy the "formal ego". | 15:19 |
| JaMa | PR in recipes is stupid | 15:19 |
| JaMa | rule to remove them when possible is reasonable way to get rid of them | 15:19 |
| lpapp | yes, argue a few more hours about it, just not with me, please, thanks. | 15:19 |
| lpapp | I have better things to do than arguing about nuances which even block end users. | 15:19 |
| * JaMa off to doing something more useful | 15:20 | |
| * lpapp is pushing the qt5 improvements to his "own branch" because he is "not" blocked. | 15:21 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 15:26 | |
| *** AlexG <AlexG!c0c69725@gateway/web/freenode/ip.192.198.151.37> has quit IRC | 15:27 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 15:29 | |
| *** cfo215 <cfo215!4473ad42@gateway/web/freenode/ip.68.115.173.66> has joined #yocto | 15:31 | |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 15:32 | |
| 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? | 15:32 |
| jkridner | cfo215: yocto = poky? | 15:33 |
| * jkridner uses meta-beagleboard on occasion | 15:33 | |
| cfo215 | jkrinder: yes poly | 15:34 |
| cfo215 | used hob to generate images | 15:34 |
| * jkridner hasn't used poky | 15:34 | |
| lpapp | cfo215: do you like hob | 15:34 |
| cfo215 | just started using yocto/poky/hob. it seems to work. It at least generated an image. | 15:35 |
| lpapp | cfo215: what do you prefer about it compared to bitbake? | 15:37 |
| lpapp | thinking of writing a better frontend in Qt. :p | 15:37 |
| lpapp | and I need input. | 15:37 |
| 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. | 15:37 |
| lpapp | "writing frontend" -> rewriting bitbake in C++, too. | 15:37 |
| *** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto | 15:38 | |
| 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. | 15:38 |
| lpapp | ok, thanks. | 15:39 |
| 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? | 15:40 |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 15:41 | |
| lpapp | cfo215: I have a beagleboard. | 15:43 |
| lpapp | but I do not use it anymore. | 15:43 |
| lpapp | I am working on getting qt5 and kde frameworks right, in general, though. | 15:43 |
| lpapp | cfo215: I will try to push my recipes today to the KDE repository if you are interested in. | 15:43 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 15:44 | |
| *** arky <arky!~arky@113.22.95.144> has quit IRC | 15:44 | |
| cfo215 | lpapp: I really need to find a solution for the BBB. But thanks for the offer. | 15:44 |
| lpapp | cfo215: well, it is just arm. | 15:45 |
| lpapp | it does not matter from qt's point of view more than that. | 15:45 |
| lpapp | which means I expect my recipes work on arm off-hand. | 15:45 |
| cfo215 | I'll have a look | 15:45 |
| cfo215 | where your recipe located at? | 15:46 |
| lpapp | cfo215: but it is qt5, not qt4. | 15:46 |
| lpapp | but I think that is even better for you, no? | 15:46 |
| lpapp | cfo215: on my machine at home, currently. | 15:46 |
| cfo215 | yes, that could be better. | 15:47 |
| lpapp | cfo215: will be pushing here tonight hopefully, http://quickgit.kde.org/ | 15:47 |
| lpapp | recipes-qt5 recipes-kf5, or so | 15:47 |
| lpapp | cfo215: do you wanna use fb, x, wayland, etc? | 15:48 |
| cfo215 | what I really need (I'm supposing) is the qmake.conf and command line for ./configure that works with my device. hardfloat | 15:48 |
| cfo215 | frame buffer and ts lcd support | 15:49 |
| cfo215 | via qws | 15:49 |
| lpapp | it is jsut the matter of -xplatform and -platform. | 15:49 |
| lpapp | qws? | 15:49 |
| lpapp | probably not ... | 15:49 |
| lpapp | that got replaced in Qt5 by QPA. ;) | 15:49 |
| cfo215 | ic, still on 4 | 15:49 |
| lpapp | any reason? | 15:50 |
| cfo215 | not really. Guess I just don't want to be on the bleeding edge. | 15:50 |
| lpapp | Qt5 was released last December | 15:51 |
| lpapp | it is not really bleeding edge. :) | 15:51 |
| cfo215 | :) | 15:51 |
| lpapp | just because Yocto does not have it sadly, it does not mean, it is bleeding edge. | 15:51 |
| cfo215 | Any help would with Qt would be greatly appreciated. But I still got to get my BBB booting... | 15:51 |
| rburton | lpapp: could say the same about toolchains ;) perspectives vary. | 15:51 |
| lpapp | cfo215: I will probably also blog about it | 15:52 |
| lpapp | http://lpapp.blogspot.com | 15:52 |
| lpapp | rburton: eh? | 15:52 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 15:53 | |
| lpapp | as far as I am aware Yocto has the latest major gcc, 4.8 | 15:53 |
| lpapp | or 4.7, sorry. | 15:53 |
| lpapp | one of* | 15:54 |
| lpapp | that is good enough for C++11, really. | 15:54 |
| rburton | we've 4.8 | 15:54 |
| lpapp | not in my version. | 15:54 |
| bluelightning | lpapp: the ecosystem *does* have qt5 recipes, in meta-qt5 | 15:54 |
| lpapp | but still, I do not understand your comment. | 15:54 |
| lpapp | bluelightning: which are broken. | 15:54 |
| lpapp | outdated | 15:54 |
| lpapp | missing | 15:54 |
| lpapp | lacking basic stuff | 15:55 |
| bluelightning | lpapp: they're being used by a commercial firm, so they can't be that broken | 15:55 |
| bluelightning | lpapp: basic? | 15:55 |
| rburton | contributions welcome! | 15:55 |
| lpapp | I already said I will push my recipes tonight? | 15:55 |
| lpapp | I think they are in a much better shape. :) | 15:55 |
| lpapp | and more complete. | 15:56 |
| lpapp | hence I do not see the future of "meta-qt5". | 15:56 |
| 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. | 15:56 |
| lpapp | as it seems now, at least. | 15:56 |
| lpapp | cfo215: what is the issue at hand? | 15:57 |
| bluelightning | lpapp: have you tried to contribute your improvements to meta-qt5? | 15:57 |
| lpapp | bluelightning: no, it is completely different stuff | 15:57 |
| 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. | 15:57 |
| cfo215 | but the boot process hangs | 15:58 |
| lpapp | bluelightning: and no, I do not wish to work with people whose biggest problem is "PR". | 15:58 |
| lpapp | for blocking and unwelcome a contribution. | 15:58 |
| cfo215 | lpapp: Waiting for root device /dev/mmcblk0p2... | 15:58 |
| lpapp | this rule cannot work for my qt5 recipes. | 15:58 |
| *** mckoan is now known as mckoan|away | 15: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? | 15:58 |
| lpapp | rburton: you guys started the moaning? | 15:59 |
| lpapp | about a nonsense stuff? | 15:59 |
| lpapp | (and still continue) | 15:59 |
| lpapp | you do realize I fully agree with unwelcoming end users and contributions | 16:00 |
| cfo215 | does anyone out there have a recipe for creating the SD Card for BBB post bitbaking the image? | 16:00 |
| lpapp | this might be an Intel way, but not open source and governed. | 16:00 |
| lpapp | and end user oriented. | 16:00 |
| bluelightning | lpapp: we have certain requirements for patch submissions, just like all open source projects do | 16:00 |
| lpapp | yes, stupid IMO | 16:00 |
| bluelightning | lpapp: just try to get a patch into the kernel, you'll see we're actually pretty relaxed by comparison | 16:00 |
| 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. | 16:00 |
| lpapp | so I avoid collaborating as I already wrote several times. Why do you keep asking the same then? | 16:00 |
| lpapp | Why do you get me repeating dozens of times? | 16:00 |
| rburton | lpapp: i wish i knew | 16:01 |
| 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? | 16:01 |
| lpapp | rburton: that is a moan. | 16:01 |
| lpapp | when you say it would block end users and contributions | 16:01 |
| lpapp | surely, it is nice to have maybe, but blocking? Hell not. | 16:01 |
| rburton | Krz: oe-core has iptables in recipes-extended | 16:02 |
| lpapp | I did not tip on someone's shoes because he did not paste a code review link to bugzilla | 16:02 |
| lpapp | I mentioned that, maybe do next time. | 16:02 |
| bluelightning | Krz: both iputils and iptables are in the core set of recipes; did you mean some other ones? | 16:02 |
| lpapp | that is difference between "quality" and "get things done" approaches. | 16:02 |
| lpapp | the* | 16:02 |
| *** elmi82_ <elmi82_!~timo@mail.bmw-carit.de> has quit IRC | 16:03 | |
| *** cfo215 <cfo215!4473ad42@gateway/web/freenode/ip.68.115.173.66> has quit IRC | 16:03 | |
| jkridner | gm all | 16:03 |
| davest | lpapp: ironic - I have heard you are really picky about patches into the code you maintain | 16:03 |
| davest | :-) | 16:03 |
| * jkridner is multitasking, so ping if you for sure need my attention. | 16:03 | |
| lpapp | davest: when it does not hurt the user, sure. | 16:04 |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 16:04 | |
| lpapp | that is the time for being nitpicky. | 16:04 |
| lpapp | but when it hurts, it is not. | 16:04 |
| 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 | 16:04 |
| lpapp | bluelightning: you think that there is black and white. | 16:04 |
| lpapp | the world is a bit more colorful. | 16:04 |
| lpapp | luckily. | 16:05 |
| 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 | 16:07 |
| lpapp | davest: and if I am asked to do next time, I will do. | 16:07 |
| lpapp | or if I am asked nicely. | 16:07 |
| lpapp | but 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 |
| 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 | 16:08 |
| lpapp | davest: also, I do not currently maintain any FOSS software. | 16:09 |
| bluelightning | Krz: ("we" meaning the OpenEmbedded community, since YP doesn't maintain recipes in meta-oe) | 16:09 |
| davest | lpapp: serial module ? | 16:09 |
| lpapp | I get rid of the last project maintenance 1-2 weeks ago, luckily. | 16:09 |
| lpapp | got* | 16:09 |
| *** tbn_ <tbn_!~tbn@84.55.160.118> has quit IRC | 16:10 | |
| Krz | bluelightning: I added recently few things and mixed up what comes from where. I need from meta-openembedded: hostap-daemon and iw | 16:14 |
| Krz | I know about this clashing recipes, so that's why I'm asking if adding openembedded is Yocto way or not so much | 16:14 |
| *** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC | 16:15 | |
| rburton | Krz: ah, they're in meta-connectivity. you may be able to add that without meta-oe itself | 16:15 |
| rburton | Krz: its only the meta-oe layer that is "badly behaved" | 16:15 |
| Crofton|work | rburton, what is badly behaved about it? | 16:16 |
| bluelightning | Krz: they're both in meta-oe | 16:16 |
| bluelightning | rburton: ^ | 16:16 |
| rburton | oh crap | 16:16 |
| rburton | i can't read | 16:16 |
| rburton | sorry | 16:16 |
| rburton | Crofton|work: the remaining bbappends and overlaid recipes - just adding meta-oe isn't a no-op | 16:17 |
| Crofton|work | hwo many of those are left? | 16:17 |
| rburton | only a few | 16:17 |
| rburton | and the big one is something i've been staring at for a while now | 16:17 |
| rburton | (xorg init) | 16:17 |
| Crofton|work | which one is that? | 16:17 |
| Crofton|work | ah | 16:17 |
| Krz | isn't meta-openembedded totally Yocto-independent? | 16:18 |
| rburton | Krz: it depends on oe-core, which is YP | 16:18 |
| bluelightning | Crofton|work: basically: xserver-nodm-init, gst-ffmpeg, tslib, busybox | 16:19 |
| Krz | alright | 16:19 |
| rburton | is anyone *actually* using tslib still? | 16:19 |
| Crofton|work | we need to make a FAQ on the wiki about this | 16:20 |
| bluelightning | rburton: opie ;) | 16:20 |
| bluelightning | rburton: but seriously I'm not sure other than that | 16:20 |
| rburton | bluelightning: i suspect anyone else using qt on fb | 16:20 |
| rburton | need to find a friendly qt developer, i'll ping thiago maybe | 16:20 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 16:29 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 16:33 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 16:38 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 16:39 | |
| *** jchonig1 <jchonig1!~jch@128.224.252.2> has joined #yocto | 16:41 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 16:42 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 16:43 | |
| *** Krz <Krz!c0c69724@gateway/web/freenode/ip.192.198.151.36> has quit IRC | 16:44 | |
| 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? | 16:44 |
| fray | Usually those messages come from a system where there are missing dependencies for some reason. | 16:45 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:45 | |
| fray | the package has a package dependency on 'update-rc.d', but the build system never built it for some reason. | 16:45 |
| zibri | afaict, those packages are being installed (according to the log) (hold on, i'll paste it somewhere) | 16:46 |
| fray | check your tmp/deploy/<package>/* and see if an update-rc.d package exists | 16:46 |
| fray | the error is saying it didn't exist or was not installed, but was required | 16:46 |
| zibri | fray: it isn't available in tmp/deploy/rmp/, no... | 16:47 |
| fray | ya, thats the issue then.. the package is missing.. | 16:48 |
| fray | you may have to do bitbake -c clean update-rc.d ; bitbake update-rc.d | 16:48 |
| *** mr_science <mr_science!~sarnold@net-cf9a4e91.cst.impulse.net> has joined #yocto | 16:49 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:49 | |
| * fray has no idea what could have caused the missing package. | 16:49 | |
| zibri | oh, my bad.. it *is* available in tmp/deplo/rpm/all | 16:49 |
| fray | in that case, I'm not sure. | 16:49 |
| fray | how recent is your master checkout? | 16:50 |
| zibri | today | 16:50 |
| zibri | http://x20.se/rootfs_package_missing.log here's the do_rootfs log | 16:50 |
| fray | there were some recent changes in the resolving code (last few days).. | 16:50 |
| fray | perhaps something went wrong in that? | 16:50 |
| zibri | hum, ok. will have a look | 16:51 |
| fray | ya, first suggestion I can give you.. try to back up a day or so and retry it.. | 16:51 |
| fray | if it works, then it's likely something in the recent smart change.. | 16:51 |
| zibri | right, thanks! | 16:51 |
| zibri | btw, i also got a lot of bb{warn,note} "command not found" from something in do_rootfs | 16:52 |
| fray | it's really odd though.. | 16:52 |
| zibri | but not sure where, was hoping to get the task to complete before trying to investigate that issue.. | 16:52 |
| fray | because from the logs it -did- install update-rc.d, base-passwd and run-postinsts.. | 16:52 |
| zibri | yes, that's what i thought :) | 16:52 |
| 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 | 16:53 |
| fray | and see what is scheduled to happen -after- it prints "Logfile is clean" | 16:53 |
| *** belen2 <belen2!Adium@nat/intel/x-jzbhuadryvqiuuml> has joined #yocto | 16:54 | |
| 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.. | 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 |
| fray | but I havn't seen anything like that | 16:54 |
| zibri | log_check() is called as the last command in rootfs_rpm_do_rootfs(). that is followed by rootfs_remove_unneeded | 16:56 |
| zibri | hah.. "# update-rc.d, base-passwd, run-postinsts are no further use, remove them now" | 16:56 |
| zibri | in rootfs_remove_unneeded | 16:56 |
| *** belen <belen!Adium@nat/intel/x-cdzhkmbgplalimuo> has quit IRC | 16:56 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 17:02 | |
| fray | how strange | 17:02 |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 17:04 | |
| *** seebs <seebs!~seebs@74.122.98.108> has joined #yocto | 17:04 | |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 17:05 | |
| *** seebs <seebs!~seebs@74.122.98.108> has quit IRC | 17:08 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC | 17:09 | |
| 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 =) | 17:12 |
| *** seebs <seebs!~seebs@74.122.98.108> has joined #yocto | 17:12 | |
| fray | I would agree.. | 17:12 |
| fray | I'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 | |
| zibri | mr_science: :) | 17:15 |
| mr_science | but that's just me | 17:15 |
| fray | it's _a_ solution.. | 17:15 |
| fray | the right one depends on so many factors it's hard to say.. | 17:15 |
| mr_science | yeah, i just got tired of rpm a long time ago | 17:16 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 17:16 | |
| mr_science | switched to gentoo and then learned to appreciate debian/apt... | 17:16 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 17:17 | |
| mr_science | so i haven't really touched rhel/centos/whatever for several years | 17:17 |
| 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.. | 17:17 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 17:17 | |
| fray | deb can fit into that continuum.. but it's somewhere between opkg and rpm | 17:18 |
| mr_science | for me, i would choose deb over rpm but that's one of the big things open source is all about | 17:18 |
| mr_science | choice | 17:19 |
| mr_science | seems like opkg has all the basics, which is certainly enough for my rpi needs | 17:21 |
| mr_science | fray: i'd be interested in seeing some kind of requirements analysis for that | 17:23 |
| zibri | it seems that the rootfs_remove_unneeded was introduced in 1ce182e79 (poky) | 17:24 |
| mr_science | i'm not quite sure excatly what would drive the need for more than opkg in an embedded runtime... | 17:25 |
| zibri | merged 2013-06-11 | 17:25 |
| fray | without going indepth, it's everything from familiarity, third party package integration, package signing/validation, and rollback support | 17:27 |
| 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.. | 17:27 |
| fray | most of the users I know of are in the telco space (think call routing, call billing, cell tower control, etc) | 17:28 |
| fray | they want package validation, signatures, rollback, etc.. | 17:28 |
| bluelightning | luckily we provide all three options :) | 17:29 |
| bluelightning | though it's fair to say that ipk/rpm are the two most proven choices | 17:29 |
| bluelightning | within our system, that is | 17:30 |
| fray | yup.. | 17:31 |
| fray | I 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 #yocto | 17:32 | |
| mr_science | fray: that's pretty much what i was thinking... | 17:32 |
| mr_science | just not requirements i've had to meet before | 17:32 |
| fray | familiarity with RPM is likely the largest single requirement that has driven me to support RPM for my customers | 17:33 |
| *** jchonig1 <jchonig1!~jch@128.224.252.2> has quit IRC | 17:33 | |
| mr_science | hmm, gpg signing of ipks would be fairly straight-forward... | 17:33 |
| fray | RPM 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 IRC | 17:34 | |
| fray | it's one of the NIST levels | 17:34 |
| zibri | speaking of familiarity with rpm, how do i list installed packages? :) | 17:34 |
| mr_science | we added gpg signing to our install package a while back | 17:35 |
| rburton | mr_science: if you're volunteering to maintain the dpkg support in YP that would be great! | 17:35 |
| fray | zibri, in the cross environment or on the target? | 17:35 |
| mr_science | rpm -qa i believe... | 17:35 |
| zibri | cross environment | 17:35 |
| fray | :) ya, that is one of the biggest holes in dpkg support right now.. lack of a consistent maintainer | 17:35 |
| zibri | but that's just a matter of adding --root, right? i'll try :) | 17:35 |
| fray | zibri, in the tmp/work/.../image... directory there is a list of what was installed generated.. installed_packages.txt or something like that | 17:35 |
| mr_science | rburton: let me think about that for a bit... | 17:36 |
| 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.. | 17:36 |
| zibri | fray: i wanted to do a package list just before the rpm invocation that fails | 17:36 |
| zibri | i'm running the do_rootfs from the devshell | 17:36 |
| fray | script wise.. it's easy as things are already specificed you just have to run them.. | 17:36 |
| * fray goes to look | 17:36 | |
| mr_science | zibri: looks like rpm -qa --root=/path/to/rootfs shoudl work | 17:37 |
| fray | within the install scripts: | 17:37 |
| fray | rpm --root $target_rootfs --dbpath /var/lib/rpm -qa | 17:37 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 17:37 | |
| zibri | thanks | 17:38 |
| 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 | 17:38 |
| mr_science | fray must be in a later timezone... | 17:38 |
| fray | alternatively you can query smart: | 17:38 |
| fray | smart --data-dir=${target_rootfs}/var/lib/smart query | 17:38 |
| fray | if I remember ight | 17:38 |
| fray | (smart is the package management front end to RPM in oe) | 17:39 |
| *** dvhart <dvhart!~dvhart@static-50-53-108-147.bvtn.or.frontiernet.net> has joined #yocto | 17:39 | |
| mr_science | rburton: i assume there are open bugs on that? | 17:40 |
| fray | Hmmm | 17:40 |
| fray | if ${@base_contains("IMAGE_FEATURES", "package-management", "false", "true", d)}; then | 17:41 |
| lpapp | fray: dpkg is pretty good for embedded. | 17:41 |
| lpapp | we did that for meego | 17:41 |
| fray | rootfs_remove_packages update-rc.d base-passwd ${ROOTFS_BOOTSTRAP_INSTALL} | 17:41 |
| 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.. | 17:41 |
| fray | it should be able to do so though | 17:41 |
| rburton | mr_science: its just not very well tested or used | 17:42 |
| *** nine_pt <nine_pt!d53ac1ce@gateway/web/freenode/ip.213.58.193.206> has joined #yocto | 17:43 | |
| nine_pt | bitbake -e busybox | grep ^PACKAGES= shows busybox-staticdev, but executing bitbake busybox-staticdev says: NoProvider: busybox-staticdev Any idea ? | 17:43 |
| fray | bitbake 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_science | alright, lemme take a look tonight when i get home... | 17:43 |
| fray | you will need to invoke bitbake busybox | 17:44 |
| *** zecke_ <zecke_!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 17:44 | |
| 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 | 17:46 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 17:47 | |
| mr_science | nine_pt: try "ls /path/to/tmp/deploy/*/ipk/busybox-*" and see what packages were built | 17:48 |
| *** silviof2 <silviof2!~silviof@ppp-188-174-127-96.dynamic.mnet-online.de> has joined #yocto | 17:49 | |
| nine_pt | ls tmp/deploy/ipk/armv5te/busybox-*: busybox-dbg busybox-dev busybox-syslog busybox-udhcpc busybox-udhcpd | 17:49 |
| mr_science | there probably are version of the busybox recipe that don't produce a staticdev package | 17:49 |
| fray | Ya, the staticdev is only generated if the package generates static libraries. | 17:50 |
| fray | As far as I know busybox does not do this normally | 17:50 |
| mr_science | you might need to enable static if you really need it | 17:50 |
| *** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC | 17:50 | |
| fray | even enabling static busybox likely won't.. as it's only a 'dev' package.. | 17:51 |
| fray | but enablign static would change the binary in the 'busybox' package.. | 17:51 |
| rburton | zenlinux: good work on the HN post about minnow :) | 17:51 |
| zenlinux | rburton, heh, thanks | 17:51 |
| *** jzhang <jzhang!jzhang@nat/intel/x-vdmtvqjbtuseddra> has joined #yocto | 17:51 | |
| nine_pt | I really need to enable it :) on the recipe busybox.inc don't have any reference to statuc | 17:51 |
| nine_pt | *staticdev | 17:51 |
| nine_pt | any idea how I can add that ? | 17:51 |
| 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 :/ | 17:52 |
| zibri | removing it solved the issue | 17:52 |
| fray | excellent! | 17:52 |
| fray | nine_pt why do you want a statically linked busybox? | 17:53 |
| fray | looking at the busybox recipe, it clears the static setting when it first configures the recipe | 17:53 |
| fray | (you should be able to enable it though if needed) | 17:54 |
| nine_pt | fray: long story made short, have a board if I try to run any command in it, it gives segmentation fault | 17:54 |
| fray | but 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 IRC | 17:54 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 17:55 | |
| fray | ahh so something is going wrong w/ COW and or dynamic loading | 17:55 |
| nine_pt | but if I upload a static binary it works, I am thinking on a corrupt library on memory | 17:55 |
| *** silviof2 <silviof2!~silviof@ppp-188-174-127-96.dynamic.mnet-online.de> has quit IRC | 17:55 | |
| nine_pt | I think so, but need more tools to see if can get more info | 17:55 |
| nine_pt | I only need to generate busybox static once, I don't need it on my images | 17:56 |
| 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 | 17:56 |
| fray | alternatively you may be able to do: | 17:56 |
| fray | bitbake -c menuconfig busybox ; enable it and then recompile | 17:56 |
| *** Circuitsoft_ <Circuitsoft_!ccb603ed@gateway/web/freenode/ip.204.182.3.237> has joined #yocto | 17:57 | |
| nine_pt | is there a option on busybox to be compiled static ? | 17:57 |
| bluelightning | zibri: I'll try to make sure we note that in the 1.5 migration docs | 17:57 |
| nine_pt | I was thinking that I will need to change compilation settings | 17:57 |
| mr_science | you could append -static to CFLAGS | 17:57 |
| zibri | bluelightning: excellent, thanks :) | 17:57 |
| fray | nine_pt, there should be a configuration option that enables static | 17:58 |
| fray | it's called 'CONFIG_STATIC', but I don't know what it looks like in the menuconfig | 17:58 |
| mr_science | looks like the older (classic) recipe does it that way | 17:58 |
| mr_science | export CFLAGS:="${CFLAGS} -static" | 17:58 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:58 | |
| mr_science | other than that, there's just a do_prepare_config_append_pn-busybox-static() function and that's it | 17:59 |
| fray | ya, I don't think that will work, but it might. I've never tried it | 17:59 |
| mr_science | nine_pt: give that a try | 18:00 |
| nine_pt | I find the option | 18: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_science | only takes a few minutes... | 18:00 |
| fray | PREFERRED_VERSION needs to refer to the recipe name, not the package name. RDEPENDS refers to the package name | 18:00 |
| 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 ... | 18:00 |
| fray | bitbake -C build busybox | 18:01 |
| Circuitsoft_ | fray: In this case the package name and recipe name are the same. | 18:01 |
| fray | ok.. then it should adjust which version is used to the one specified.. unless the one specified doesn't exist for some reason | 18:01 |
| mr_science | Circuitsoft_: i usually put that in the image recipe | 18:01 |
| Circuitsoft_ | I'm trying to force use of my-package_0.3.5 instead of my-package_git | 18:01 |
| fray | ya, that should just work.. it needs to be in the global local.conf, or a distro.conf or something | 18:02 |
| Circuitsoft_ | I want my-app_0.17 to require my-package_git and my-app_git to require my-package_git | 18:02 |
| fray | putting it into the recipe isn't enough to trigger the change | 18:02 |
| fray | RDEPENDS 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_science | Circuitsoft_: see if there's distro file already in conf/machine/include or similar | 18:04 |
| mr_science | rpi-default-versions.inc is one example | 18:05 |
| Circuitsoft_ | No includes, only my-machine.conf | 18:05 |
| *** Circuitsoft_ is now known as Circuitsoft | 18:05 | |
| mr_science | make one | 18:05 |
| Circuitsoft | There are a number of PREFERRED_VERSION_package lines in my-machine.conf - should they all go into said include file? | 18:06 |
| mr_science | as fray mentioned, could also be under conf/distro/foo | 18:06 |
| mr_science | they're okay where they are, i think | 18:06 |
| mr_science | just add what you need to that and try it out | 18:07 |
| mr_science | bitbake -c clean recipe and build it again | 18:07 |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 18:08 | |
| mr_science | the rpi layer has several rpi-default-foo.inc files in conf/machine/include | 18:08 |
| mr_science | not sure why it was done that way... might make more sense under conf/distro since it's really not machine-specific | 18:09 |
| 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. | 18:10 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 18:12 | |
| Circuitsoft | Looks 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!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 18:15 | |
| fray | what does bitbake -e show you? (grep for preferred_version) | 18:18 |
| *** darknighte is now known as darknighte_znc | 18:24 | |
| *** nine_pt <nine_pt!d53ac1ce@gateway/web/freenode/ip.213.58.193.206> has quit IRC | 18:25 | |
| Circuitsoft | fray: The package I'm trying to pin didn't show up. | 18:26 |
| Circuitsoft | I'm dumb. I accidentally did PREFERRED_PROVIDER | 18:27 |
| mr_science | Circuitsoft: sounds like you want two custom image recipes, one to include devel_ and one to include release_ | 18:27 |
| Circuitsoft | my_science - yes, but that's a separate issue. | 18:27 |
| mr_science | which can live on the same branch just fine... | 18:27 |
| Circuitsoft | The only difference between what I want in the devel_ and release_ image recipes is PREFERRED_VERSION_myapp. | 18:27 |
| Circuitsoft | But it's appearing that I can't do that in the image recipe. | 18:28 |
| mr_science | are you sure? | 18:28 |
| mr_science | i know i have that in my classic images, have to check my poky images when i get home | 18:28 |
| mr_science | the image value *should* override whatever you set as the distro default | 18:29 |
| 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. | 18:29 |
| mr_science | try it in the image recipe instead of the package recipe | 18:30 |
| mr_science | then clean the package and bitbake the image recipe again and see what version gets pulled in | 18:32 |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 18:34 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 18:40 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 18:41 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 18:47 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 18:50 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 18:55 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 18:57 | |
| *** blloyd <blloyd!~blloyd@mobile-166-137-146-082.mycingular.net> has joined #yocto | 18:59 | |
| *** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC | 19:00 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:02 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:04 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:06 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:09 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:11 | |
| mr_science | Circuitsoft: got it working the way you want? | 19:12 |
| 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. | 19:13 |
| Circuitsoft | rpm is /really/ slow. | 19:14 |
| mr_science | sounds like you want RCONFLICTS/RREPLACES | 19:15 |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:16 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:19 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:23 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:25 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 19:28 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:30 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:31 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 19:31 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:35 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:36 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 19:40 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has joined #yocto | 19:41 | |
| 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... | 19:52 |
| mr_science | so far "integration" looks like a huge multi-car pileup | 19:53 |
| mr_science | and, like the freeway pileup, it's pretty much too gruesome to look at, yet you can't look away... | 19:54 |
| 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) | 19:55 |
| fray | change to ipk for faster behavior, unless you need RPM specific behavior | 19:55 |
| Circuitsoft | fray: Does using 600MB of RAM on a 1GB system count as memory-constrained? | 19:59 |
| Circuitsoft | Also, our rootfs is on an SD card, so it's possibly disk-bound. | 19:59 |
| mr_science | yes, even a good sdcard is pretty slow... | 20:00 |
| 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... | 20:01 |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 20:01 | |
| fray | depends on what you are doing | 20:02 |
| * mr_science has been more than pleasantly surprised at the runtime performance and footprint on rpi | 20:02 | |
| fray | for filesystem, for incremental installs (removals) and other berkleydb cache issues that isn't unusual | 20:02 |
| fray | ya, I'd never use RPM on an SD card if you can avoid it.. | 20:02 |
| fray | the berkelyDB access pattern can cause issues in my experience | 20:02 |
| *** blloyd <blloyd!~blloyd@mobile-166-137-146-082.mycingular.net> has quit IRC | 20:04 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 20:05 | |
| *** blloyd <blloyd!~blloyd@mobile-166-137-146-082.mycingular.net> has joined #yocto | 20:19 | |
| *** sameo <sameo!~samuel@192.55.55.37> has joined #yocto | 20:21 | |
| *** zecke_ <zecke_!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 20:22 | |
| *** jkridner <jkridner!~jkridner@nat/ti/x-ypjagizbljejfxco> has joined #yocto | 20:25 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 20:25 | |
| *** ant_home <ant_home!~andrea@host36-64-dynamic.8-87-r.retail.telecomitalia.it> has joined #yocto | 20:25 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 20:31 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 20:31 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 20:32 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 20:32 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 20:32 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 20:33 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 20:34 | |
| *** quatre <quatre!c0926547@gateway/web/freenode/ip.192.146.101.71> has joined #yocto | 20:45 | |
| 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? | 20:47 |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 20:51 | |
| abelloni | is there any gui for network configuration in core-image-sato ? | 20:54 |
| mr_science | don't think so | 20:57 |
| mr_science | the settings gui seemed a little thin when i looked at it | 20:57 |
| mr_science | the only network config guis i know of are the big three: connman-ui, wicd, and network-manager | 21:07 |
| mr_science | afaik, there's no current recipe for wicd so your choices are somewhat limited | 21:07 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 21:10 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 21:13 | |
| abelloni | yeah | 21:13 |
| abelloni | there is qconnman in meta-oe | 21:13 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 21:14 | |
| mr_science | i tried to build one of those qt guis and it got so hot the bios shut the machine down | 21:14 |
| mr_science | too many jobs/threads for qt i guess... | 21:15 |
| Circuitsoft | mr_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 http://autobuilder.yoctoproject.org:8011/builders/build-appliance/builds/233 | 21:15 | |
| mr_science | just my test buildbox at home | 21:15 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 21:15 | |
| 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. | 21:16 |
| mr_science | no cool room, it was during a heatwave, and qt is a pita | 21:16 |
| mr_science | Circuitsoft: posted that anywhere public?> | 21:16 |
| 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. | 21:17 |
| Circuitsoft | But, start your build, do a "ps -AHO ppid" and find the pid of the build process. | 21:17 |
| 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 | 21:19 |
| Circuitsoft | I think. I just recreated that now. It may need some tweaking. | 21:20 |
| Circuitsoft | Should be /sys/class/hwmon/hwmon(a_number_here)/device/temp(pick_a_number)_input | 21:22 |
| Circuitsoft | grep . /sys/class/hwmon/hwmon*/device/temp*_input | 21:22 |
| Circuitsoft | That will show you all your temperatures. See which one seems to make the most sense. | 21:22 |
| Circuitsoft | As for building Qt, having a 12-core machine with hyper-threading and 48GB of RAM is quite helpful... | 21:24 |
| *** acidfoo <acidfoo!~nib@24.37.17.210> has joined #yocto | 21:29 | |
| mr_science | this is a 95W amd triple-core with 8 GB ram and an unlocked 4th core | 21:32 |
| mr_science | pretty cheap-ass hardware... | 21:32 |
| mr_science | just something i threw together out of spare/random parts | 21:33 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 21:33 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 21:36 | |
| 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. | 21:37 |
| mr_science | yeah, mine here is a little older/lighter but similar | 21:38 |
| mr_science | dell 2950 with 2 quad HT xeons and only 16 GB ram with a couple TB of raid storage | 21:38 |
| mr_science | what's weird is i would swear my cheap box is faster at some things... | 21:39 |
| *** darknighte_znc is now known as darknighte | 21:39 | |
| Circuitsoft | I opted for tons of RAM instead of SSDs, since I figure most Yocto compile jobs will fit entirely in vfs cache. | 21:39 |
| mr_science | but the builds are also fairly different (classic here, yocto master at home) | 21:39 |
| Circuitsoft | My build machine at home is a 65W AMD dual-core with 4GB RAM. | 21:41 |
| *** acidfoo <acidfoo!~nib@24.37.17.210> has quit IRC | 21:44 | |
| *** zedd_ <zedd_!~ddez@128.224.252.2> has joined #yocto | 21:45 | |
| *** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC | 21:47 | |
| mr_science | sounds like my desktop at home... | 21:48 |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 21:53 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 21:53 | |
| *** acidfoo <acidfoo!~nib@24.37.17.210> has joined #yocto | 21:56 | |
| *** darknighte is now known as darknighte_znc | 21:56 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 22:02 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 22:04 | |
| *** _julian <_julian!~quassel@x2f00029.dyn.telefonica.de> has quit IRC | 22:07 | |
| *** _julian <_julian!~quassel@x2f00029.dyn.telefonica.de> has joined #yocto | 22:07 | |
| *** agust <agust!~agust@p4FDE624B.dip0.t-ipconnect.de> has quit IRC | 22:08 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 22:09 | |
| *** ant_home <ant_home!~andrea@host36-64-dynamic.8-87-r.retail.telecomitalia.it> has quit IRC | 22:18 | |
| *** blloyd <blloyd!~blloyd@mobile-166-137-146-082.mycingular.net> has quit IRC | 22:19 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-nqiwhwcjhtvyaazt> has quit IRC | 22:20 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 22:31 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nakryffsvxjhdqkf> has quit IRC | 22:34 | |
| *** jchonig <jchonig!~jch@128.224.252.2> has quit IRC | 22:34 | |
| *** sameo <sameo!~samuel@192.55.55.37> has quit IRC | 22:37 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 22:41 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 22:43 | |
| *** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 22:47 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC | 22:52 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has joined #yocto | 22:52 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 23:05 | |
| *** amarsman <amarsman!~marsman@151.218.104.24> has joined #yocto | 23:07 | |
| *** JimBaxter_ <JimBaxter_!~jbaxter@jimbax.plus.com> has quit IRC | 23:11 | |
| *** Crofton <Crofton!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 23:14 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 23:23 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 23:38 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 23:48 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 23:49 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!