*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:17 | |
*** nitink <nitink!~nitink@134.134.137.73> has quit IRC | 00:18 | |
sgw_ | khem: I just tested that pcc/floor issue with 1.6-rc1 qemu and got a failure so something changed between 1.4 and 1.5 versions of qemu, I guess I could try a bisect, but maybe you have other ideas? | 00:21 |
---|---|---|
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 00:27 | |
*** phdeswer_ <phdeswer_!~phdeswer@a88-113-104-180.elisa-laajakaista.fi> has quit IRC | 00:30 | |
-YoctoAutoBuilder- build #231 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/231 | 00:34 | |
*** _julian <_julian!~quassel@x2f02b60.dyn.telefonica.de> has joined #yocto | 00:48 | |
*** _julian_ <_julian_!~quassel@x2f127a7.dyn.telefonica.de> has quit IRC | 00:51 | |
*** amarsman <amarsman!~marsman@151.218.104.24> has joined #yocto | 00:57 | |
*** ant_home <ant_home!~andrea@host36-64-dynamic.8-87-r.retail.telecomitalia.it> has quit IRC | 01:02 | |
*** GunsNRose <GunsNRose!~GunsNRose@182.148.68.102> has joined #yocto | 01:04 | |
*** davest <davest!Adium@nat/intel/x-jcfupoeldehmojyw> has quit IRC | 01:12 | |
*** davest <davest!Adium@nat/intel/x-swroronwqelbngek> has joined #yocto | 01:17 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:21 | |
*** davest <davest!Adium@nat/intel/x-swroronwqelbngek> has quit IRC | 01:25 | |
*** swex <swex!~swex@178.17.193.139> has joined #yocto | 01:29 | |
*** ash_charles <ash_charles!~ash_charl@adsl-172-15-162-30.dsl.pltn13.sbcglobal.net> has quit IRC | 01:31 | |
*** Bagder <Bagder!~daniel@rockbox/developer/bagder> has quit IRC | 01:32 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 01:33 | |
*** swex <swex!~swex@178.17.193.139> has quit IRC | 01:35 | |
*** swex <swex!~swex@178.17.193.139> has joined #yocto | 01:40 | |
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has left #yocto | 01:55 | |
-YoctoAutoBuilder- build #243 of nightly-x32 is complete: Failure [failed Building Images Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/243 | 02:01 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 02:03 | |
-YoctoAutoBuilder- build #238 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/poky-tiny/builds/238 | 02:04 | |
otavio | khem: I am building gcc fix | 02:07 |
-YoctoAutoBuilder- build #231 of nightly-multilib is complete: Failure [failed Building Images Running Sanity Tests Building Images_1 Running Sanity Tests_1 Building Images_2 Running Sanity Tests_2 Building Images_3 Running Sanity Tests_3 Building Images_4] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-multilib/builds/231 | 02:09 | |
*** seebs <seebs!~seebs@74.122.98.108> has quit IRC | 02:09 | |
*** seebs <seebs!~seebs@74.122.98.108> has joined #yocto | 02:14 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 02:16 | |
-YoctoAutoBuilder- build #4 of eclipse-plugin-kepler is complete: Failure [failed Building Eclipse Plugin Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/eclipse-plugin-kepler/builds/4 | 02:30 | |
khem | sgw_: are you able to get same failure on 1.6rc1 or a different one ? | 02:42 |
khem | otavio: ok. Cool add your results to patch thread | 02:42 |
otavio | 1.6? | 02:42 |
khem | otavio: thats the qemu version | 02:43 |
khem | not YP | 02:43 |
otavio | oh | 02:43 |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 02:55 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 03:18 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:24 | |
*** vicky <vicky!~vicky@122.165.223.135> has joined #yocto | 03:36 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 03:45 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 03:48 | |
sgw_ | khem, same failure with 1.6rc1, so I bisected with in the 1.4->1.5 range and came up with that commit. | 03:48 |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 04:12 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 04:24 | |
*** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 04:26 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 04:26 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 04:36 | |
*** vicky_ <vicky_!~vicky@122.165.223.135> has joined #yocto | 05:08 | |
-YoctoAutoBuilder- build #239 of poky-tiny is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/poky-tiny/builds/239 | 05:09 | |
vicky_ | hi yocto. i m getting error of "cannot find -lm" while compiling gcc-4.7.2. but in sysroot lib directory, there is no libm file.anyway to fix this? | 05:10 |
vicky_ | i m using poky distro for at91sam9x5 soc. | 05:10 |
vicky_ | my machine.conf at http://pastebin.com/CegDy8Q0 | 05:12 |
vicky_ | my local.conf at http://pastebin.com/5QfxyKVw | 05:13 |
-YoctoAutoBuilder- build #234 of nightly-non-gpl3 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-non-gpl3/builds/234 | 05:16 | |
*** GunsNRose <GunsNRose!~GunsNRose@182.148.68.102> has quit IRC | 05:18 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 05:21 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 05:22 | |
*** amarsman <amarsman!~marsman@151.218.104.24> has quit IRC | 05:25 | |
vicky_ | sorry my local.conf at http://pastebin.com/Si0kqnUA | 05:26 |
-YoctoAutoBuilder- build #244 of nightly-x32 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/244 | 05:28 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 05:39 | |
*** ynezz <ynezz!ynezz@ibawizard.net> has quit IRC | 05:47 | |
*** ynezz <ynezz!ynezz@ibawizard.net> has joined #yocto | 05:47 | |
-YoctoAutoBuilder- build #234 of nightly-mips is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/234 | 05:49 | |
-YoctoAutoBuilder- build #236 of nightly-x86 is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/236 | 05:51 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 05:55 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 05:56 | |
*** agust <agust!~agust@p4FDE6832.dip0.t-ipconnect.de> has joined #yocto | 06:03 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 06:05 | |
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 06:06 | |
*** zeeblex <zeeblex!~apalalax@134.134.137.75> has joined #yocto | 06:11 | |
*** jjardon <jjardon!uid723@gateway/web/irccloud.com/x-tneyydyxhvnnefbm> has quit IRC | 06:14 | |
*** GunsNRose <GunsNRose!~GunsNRose@182.148.68.102> has joined #yocto | 06:30 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:31 | |
*** thesignal <thesignal!~deadbot@134.255.234.222> has joined #yocto | 06:53 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 06:55 | |
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 06:56 | |
thesignal | hi, i'm unable to compile perl und libxml-parser-perl-native for armv7a, @perl, i get some error about miniperl not being found. i thought miniperl got replaced by a full perl implementation? | 06:57 |
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 06:57 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 06:57 | |
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:02 | |
*** swex_ <swex_!~swex@178.17.193.139> has joined #yocto | 07:02 | |
*** swex <swex!~swex@178.17.193.139> has quit IRC | 07:02 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:05 | |
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 07:06 | |
*** thesignal <thesignal!~deadbot@134.255.234.222> has left #yocto | 07:07 | |
*** GunsNRose <GunsNRose!~GunsNRose@182.148.68.102> has quit IRC | 07:12 | |
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:24 | |
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has joined #yocto | 07:29 | |
lpapp_ | is it possible to put the tarball next to the recipe? | 07:30 |
lpapp_ | or insides files? | 07:30 |
*** silviof2 <silviof2!~silviof@ppp-188-174-34-191.dynamic.mnet-online.de> has quit IRC | 07:33 | |
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto | 07:34 | |
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has quit IRC | 07:35 | |
melonipoika | morning | 07:36 |
melonipoika | qt5 question | 07:36 |
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:36 | |
melonipoika | i ahve modified qt5-versions.inc to use version 5.1.0 (default is 5.0.2) | 07:36 |
melonipoika | now i need to include that file, but where? | 07:37 |
*** Bagder <Bagder!~daniel@rockbox/developer/bagder> has joined #yocto | 07:40 | |
*** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 07:44 | |
*** tbn is now known as Guest28477 | 07:44 | |
*** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 07:50 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:50 | |
*** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 07:58 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 07:59 | |
bluelightning | morning all | 08:00 |
lpapp | is there a recipe finder service | 08:01 |
bluelightning | lpapp: there is indeed: http://layers.openembedded.org/layerindex/recipes/ | 08:04 |
lpapp | ok, nginx is not available. :( | 08:04 |
bluelightning | coincidentally someone was asking about that the other day, I don't know if they started working on one | 08:05 |
bluelightning | it was mr_science in #oe | 08:07 |
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:07 | |
lpapp | and uwsgi ? | 08:09 |
*** jjardon <jjardon!uid723@gateway/web/irccloud.com/x-mnupqrxpluqguzmm> has joined #yocto | 08:10 | |
bluelightning | haven't heard any discussion about that one | 08:11 |
rburton | all hail the layer index | 08:11 |
rburton | whoever wrote that was a life-saver | 08:12 |
*** jjardon <jjardon!uid723@gateway/web/irccloud.com/x-mnupqrxpluqguzmm> has quit IRC | 08:24 | |
*** jjardon <jjardon!uid723@gateway/web/irccloud.com/x-ppiobuvqolqmbfkc> has joined #yocto | 08:26 | |
bluelightning | rburton: bah, humbug :) | 08:28 |
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:30 | |
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 08:34 | |
ant_work | rburton: yet the author ignored the users and did not write a proper qt frontend | 08:38 |
rburton | some people eh | 08:39 |
rburton | anyway, should have been gtk+ | 08:39 |
lpapp | what is the benefit of a qt frontend anyway | 08:40 |
lpapp | rburton: gtk is not cross-platform. | 08:41 |
bluelightning | ant_work: I could have written a qt frontend, it might have been qt2 though ;) | 08:41 |
lpapp | what do I need to check into the repostory for the downloads to work? | 08:55 |
lpapp | sstate-cache and tmp as well? | 08:55 |
*** belen <belen!~Adium@134.134.139.72> has joined #yocto | 08:55 | |
rburton | what are you trying to do? | 08:56 |
lpapp | as I wrote above, check downloads into the repository. | 08:56 |
rburton | just the downloads directory then | 08:56 |
rburton | tmp is where the builds happen, and will be giant and frequently changing | 08:57 |
rburton | and yes, sstate-cache is incredibly useful to share between multiple machines if you can. that's not "downloads" though, but intermediate-stage build objects. | 08:57 |
rburton | i.e. compiled libraries it can use to build a sysroot from | 08:58 |
*** blitz00 <blitz00!~stefans@192.198.151.43> has joined #yocto | 08:58 | |
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto | 08:58 | |
lpapp | rburton: we have some tmp committed already, and that is why I was wondering. | 09:02 |
lpapp | probably I can remove it all. | 09:02 |
*** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has quit IRC | 09:03 | |
*** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has joined #yocto | 09:03 | |
*** wgao <wgao!~wgao@1.202.252.122> has joined #yocto | 09:04 | |
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.91.230.2.244> has quit IRC | 09:07 | |
lpapp | rburton: is that correct, then? | 09:11 |
lpapp | and I probably do not need "cache" either? | 09:14 |
lpapp | nor bitbake.lock? | 09:15 |
lpapp | what about pseudodone? | 09:16 |
ant_work | lpapp: remove all the 3 above and tmp- | 09:17 |
ant_work | I keep only downloads | 09:17 |
lpapp | ant_work: why don't you keep sstate? | 09:17 |
ant_work | I do prefer build from scratch | 09:18 |
lpapp | why? | 09:18 |
ant_work | soemtimes I increase by hand the revision of my dev recipes | 09:18 |
ant_work | so those would always be preferred | 09:18 |
ant_work | and build from scratch just takes couple of hours | 09:19 |
lpapp | ok, I will check in for now as is, and I can remove later. | 09:19 |
lpapp | that is a lot | 09:19 |
lpapp | I build it within 40 minutes. | 09:19 |
lpapp | but I use core-image-minimal | 09:19 |
ant_work | lpapp: I build core-image-base and core-image-sato | 09:20 |
lpapp | k | 09:20 |
ant_work | on rather old hw | 09:20 |
lpapp | that makes sense, then. | 09:21 |
*** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 09:21 | |
ant_work | on the last partition of the disk :/ | 09:21 |
ant_work | lpapp: build from sstate-cache takes just 5 mins | 09:22 |
lpapp | ant_work: does that matter it is the last partition? | 09:22 |
lpapp | swap is already slow, no? | 09:23 |
ant_work | it's never swapping, it's just the disk is slower on last part | 09:24 |
rburton | lpapp: pseudodone is the stamp that says its done building pseudo | 09:25 |
rburton | the bitbake cache is a cache of the parse tree | 09:25 |
rburton | both of which clearly shouldnt be persisted anywhere | 09:25 |
lpapp | yeah | 09:27 |
lpapp | ant_work: any benchmark how much? | 09:27 |
lpapp | (if any) | 09:27 |
rburton | depends on the disk etc etc | 09:27 |
ant_work | lpapp: I can provide later | 09:27 |
*** roinn <roinn!~roinn@194.9.242.240> has joined #yocto | 09:34 | |
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 09:38 | |
lpapp | ant_work: k, please do not forget it as you got me curious. :-) | 09:39 |
ant_work | llpapp: http://superuser.com/questions/159890/does-the-order-of-partitions-matter | 09:39 |
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 09:40 | |
ant_work | lpapp: I was obliged to keep Win$ on my hackintosh and it needed to be installed on first part of the second hdd | 09:40 |
ant_work | lpapp: otherwise I'd set first partition of second disk for that | 09:40 |
ant_work | lpapp: before you ask: raid is not an option in my case... | 09:41 |
*** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has quit IRC | 09:49 | |
*** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has joined #yocto | 09:50 | |
*** dRp3pP3r <dRp3pP3r!d5bf22ee@gateway/web/freenode/ip.213.191.34.238> has joined #yocto | 09:51 | |
dRp3pP3r | hi everyone. | 09:51 |
dRp3pP3r | i have some issues with inconsistent library dependencies | 09:51 |
dRp3pP3r | on poky 9.0.1 | 09:52 |
lpapp | ant_work: interesting. | 09:52 |
lpapp | ant_work: it is not something I heard programmers talking about when optimizing stuff. | 09:52 |
ant_work | well, lets' hope HDD are the past ;) | 09:52 |
dRp3pP3r | precisely: libfm depends on libicuuc.so.50 and gtk.sato depends on libicuuc.so.51 | 09:53 |
dRp3pP3r | both won't shut up when i feed them the other version | 09:53 |
dRp3pP3r | and i don't know, how to modify the depends of libfm to be happy with .51 | 09:54 |
dRp3pP3r | which should work in practice, i think. | 09:54 |
dRp3pP3r | can someone tell me, whether this is a good idea, and if, how to modify this dependency? | 09:54 |
rburton | dRp3pP3r: same problem as before, you need to rebuild libfm | 09:56 |
rburton | that should have happened :( | 09:56 |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto | 09:56 | |
dRp3pP3r | well, tried so, but didn't work. btw: the solution didn't work for libtasn1 as well. i had to downgrade to libtasn1_3.2, which provides libtasn1.so.6 as needed by gnutls | 09:57 |
dRp3pP3r | i mean libtasn1.so.3 | 09:57 |
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 09:57 | |
dRp3pP3r | .6 is provided by libtasn1_3.3 | 09:57 |
*** Guest28477 <Guest28477!~tbn@84.55.160.118> has quit IRC | 09:58 | |
dRp3pP3r | the problem with icu is, that both versions are needed | 09:58 |
dRp3pP3r | so downgrading is not an option this time... | 09:58 |
rburton | the problem is that at some point you upgraded icu and libfm didn't rebuild | 09:58 |
rburton | (or you've downgraded icu and gtk+ didn't rebuild) | 09:59 |
dRp3pP3r | ok, makes sense, than a rebuild should solve. | 09:59 |
dRp3pP3r | give me a minute, it's working :) | 10:00 |
*** belen <belen!~Adium@134.134.139.72> has quit IRC | 10:00 | |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has left #yocto | 10:05 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:05 | |
lpapp | rburton: unsubscribed from oe. If you need me, cc. | 10:05 |
*** pev <pev!~pev@2.31.90.141> has joined #yocto | 10:07 | |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto | 10:08 | |
lpapp | btw, I had a question this morning about local tarballs. | 10:11 |
*** dRp3pP3r_ <dRp3pP3r_!d5bf22ee@gateway/web/freenode/ip.213.191.34.238> has joined #yocto | 10:11 | |
*** dRp3pP3r <dRp3pP3r!d5bf22ee@gateway/web/freenode/ip.213.191.34.238> has quit IRC | 10:13 | |
dRp3pP3r_ | rburton: you were right. that worked. | 10:15 |
dRp3pP3r_ | thanks. :) | 10:15 |
rburton | dRp3pP3r_: would love to know why these rebuilds are not happening automatically. what release are you using? | 10:16 |
dRp3pP3r_ | todays snapshot of master for both, poky and oe | 10:16 |
rburton | huh, *really* should work then | 10:16 |
*** belen <belen!~Adium@134.134.139.72> has joined #yocto | 10:16 | |
dRp3pP3r_ | hm. git-pulled them two hours ago. | 10:17 |
dRp3pP3r_ | do i see it correctly, that the root of the problem is a lower-level library is updated, but some libraries that depend on further mentioned lib don't. so they get their depends messed up? | 10:18 |
ant_work | rburton: http://cgit.openembedded.org/meta-openembedded/commit/?id=47f3975a6a009bf61d4c8f61e1b70a5eeaee873b | 10:26 |
lpapp | any ideas? | 10:27 |
rburton | lpapp: sorry, missed the question. | 10:27 |
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.192.109.190.88> has joined #yocto | 10:27 | |
rburton | dRp3pP3r_: that normally happens if the packages don't include the dependencies, so check that. gnutls/tasn i'm pretty sure do though. | 10:27 |
rburton | ant_work: ? | 10:28 |
simon_b | Hello | 10:28 |
lpapp | rburton: https://www.yoctoproject.org/irc/%23yocto.2013-08-02.log.html#t2013-08-02T07:30:00 | 10:28 |
rburton | ant_work: oh god what's that do_compile_append doing. i'm scared to look. | 10:28 |
rburton | lpapp: yes | 10:28 |
rburton | SRC_URI is a list of stuff | 10:28 |
dRp3pP3r_ | ok. include the dependecies? what do you mean? | 10:28 |
rburton | local, git, http, whatever. | 10:29 |
rburton | dRp3pP3r_: the DEPENDS field. should be working for the packages you're seeing problems with though. :( | 10:29 |
ant_work | rburton: I guess the right one is openembedded-core/tree/meta/recipes-support/icu/icu.inc | 10:29 |
simon_b | How can I bring header only recipes into an image? I tried with glm, and when adding glm-dev to a packagegroup it complaints: "Can't install glm-dev-0.9.4.4-r1@cortexa9hf_vfp_neon: no package provides glm = 0.9.4.4-r1" which is true, but there won't be a library or so.. | 10:29 |
dRp3pP3r_ | rburton: hm. ok. for now it works. if i come across such stuff again, i'll further investigate. thanks a lot. | 10:30 |
simon_b | Thinking about a fake package. is there a better way? | 10:30 |
rburton | simon_b: RDEPENDS_${PN}-dev = "" | 10:30 |
rburton | simon_b: a -dev package by default depends on the "main" package, but you don't want that | 10:31 |
simon_b | rburton: thank you. trying that. | 10:31 |
dRp3pP3r_ | rburton: libfm does not depend on libicu, according to libfm_1.1.0.bb | 10:31 |
rburton | dRp3pP3r_: probably something else does, and that should have got rebuilt. | 10:32 |
dRp3pP3r_ | but gnutls does depend on libtasn1, yes | 10:32 |
dRp3pP3r_ | maybe. | 10:32 |
dRp3pP3r_ | anyway, have a nce day :) | 10:32 |
*** dRp3pP3r_ <dRp3pP3r_!d5bf22ee@gateway/web/freenode/ip.213.191.34.238> has quit IRC | 10:32 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 11:08 | |
lpapp | rburton: is there any example out there? | 11:24 |
*** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 11:28 | |
*** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 11:47 | |
rburton | lpapp: of using a tarball in SRC_URI? just use a file: url. | 11:49 |
rburton | file://mytarball.tar.gz | 11:49 |
lpapp | rburton: yes, any existing example would be welcome. | 11:49 |
lpapp | rburton: yeah, and where to put the file actually ... | 11:49 |
rburton | same rules as patches | 11:49 |
rburton | so files/ or PN/ or PN-PV/ | 11:49 |
rburton | there is literally no difference as far as the fetching logic is concerned here | 11:50 |
rburton | tarballs get extracted, patches get applied | 11:50 |
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 11:54 | |
*** GunsNRose <GunsNRose!~GunsNRose@118.114.151.41> has joined #yocto | 11:59 | |
*** vicky_ <vicky_!~vicky@122.165.223.135> has quit IRC | 12:07 | |
*** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 12:23 | |
*** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 12:28 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 12:31 | |
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 12:35 | |
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 12:36 | |
*** zeeblex <zeeblex!~apalalax@134.134.137.75> has left #yocto | 12:46 | |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has quit IRC | 12:49 | |
*** vicky <vicky!~vicky@122.165.223.135> has quit IRC | 13:05 | |
*** smartin_ <smartin_!~smartin@81.253.46.196> has joined #yocto | 13:08 | |
*** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto | 13:10 | |
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 13:10 | |
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 13:11 | |
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 13:12 | |
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 13:14 | |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto | 13:17 | |
ErkiS | how can I conveniently get all build-essentials RPMs installed onto my target host (Gumstix Overo)? tracking down each required dependent RPM seems hopeless.. | 13:18 |
otavio | khem: gcc fix looks good :) | 13:25 |
bluelightning | ErkiS: I mentioned this yesterday - packagegroup-core-buildessential will pull in all the necessary packages | 13:29 |
*** simar <simar!~simar@128.224.252.2> has quit IRC | 13:30 | |
*** simar <simar!~simar@128.224.252.2> has joined #yocto | 13:31 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvsurvaccwlrwfck> has joined #yocto | 13:33 | |
ErkiS | bluelightning, I also answered yesterday :) - getting ERROR: Nothing PROVIDES 'packagegroup-core-buildessential' | 13:34 |
bluelightning | ErkiS: which version of the build system are you using? | 13:34 |
*** smartin_ <smartin_!~smartin@81.253.46.196> has quit IRC | 13:35 | |
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC | 13:35 | |
*** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 13:36 | |
ErkiS | bluelightning - not sure how to check this? last git commit is 2806646a263527ec0487ea160afd4bdc0a3c1703 | 13:37 |
bluelightning | ErkiS: ah, that's in danny (1.3)... packagegroup-core-buildessential wasn't added until the release after i.e. dylan (1.4) | 13:40 |
bluelightning | ErkiS: it's a pretty trivial recipe though, you could just add it on top | 13:40 |
bluelightning | ErkiS: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb | 13:40 |
ErkiS | thank you, will try :) | 13:41 |
bluelightning | ErkiS: apologies for missing your reply yesterday | 13:41 |
ErkiS | no problemo | 13:43 |
ErkiS | do I need to configure the target system in some way as well? the resulting RPM is tiny and doing "rpm -ivh packagegroup-core-buildessential-1.0-r0.all.rpm" complains about a number of missing dependencies | 13:45 |
lpapp | ok, so bitbake can handle .tar.xz | 13:47 |
lpapp | is it a good practice to have one .bb per recipe? | 13:48 |
lpapp | I mean one type of .bb (might be separate version variants) | 13:48 |
bluelightning | ErkiS: erm, rpm doesn't automatically install dependencies | 13:48 |
lpapp | because u-boot is going against that principle for instance. | 13:48 |
bluelightning | lpapp: yes, I noted that when we discussed this previously | 13:49 |
bluelightning | lpapp: I don't know why that is | 13:49 |
lpapp | is it a good practice | 13:49 |
bluelightning | the convention is to just have one unless there is a bleeding edge git or old gplv2 version | 13:49 |
lpapp | err... I think you are misunderstanding the situation. | 13:50 |
lpapp | I do not refer to the versions at all, I think that is fine. | 13:50 |
lpapp | what is not fine is foo.bb | 13:50 |
lpapp | foo-bar.bb | 13:50 |
lpapp | foo-baz.bb, etc. | 13:50 |
bluelightning | right, and if you recall I explained why at least one of these additional ones is needed | 13:50 |
ErkiS | bluelightning, so back to my original question - how can I *conveniently* get all required RPMs installed? :) | 13:51 |
ErkiS | I tried installing all listed dependencies one by one, until I ran into an absurd circular dependency where perl-module-carp depends on perl-module-exporter, which depends on perl-module-exporter-heavy, which depends on perl-module-carp and perl-module-exporter | 13:51 |
lpapp | bluelightning: that is irrelevant | 13:51 |
bluelightning | ErkiS: in danny we provided zypper as a front-end to resolve and install dependencies | 13:51 |
bluelightning | lpapp: no, it isn't | 13:51 |
lpapp | the question is, whether or not it is a good practice. | 13:51 |
lpapp | yep. | 13:51 |
bluelightning | lpapp: it's pretty much required, because you want to build the mkimage tool for the host (native) and the actual bootloader for the target | 13:52 |
lpapp | bluelightning: you could you different recipe folders, really. | 13:52 |
ErkiS | bluelightning: aha, so I should upgrade my yocto. is 1.3 -> 1.4 upgrade painless? | 13:52 |
lpapp | ErkiS: depends, for me, it is not. | 13:53 |
lpapp | it is painful. | 13:53 |
bluelightning | lpapp: we'd rather keep u-boot derived recipes in the same folder; there are plenty of other examples where we do the same thing | 13:53 |
lpapp | but I use external toolchains, etc. | 13:53 |
bluelightning | ErkiS: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration | 13:53 |
bluelightning | ErkiS: as noted, in 1.4 we moved from zypper to smart, but largely the same functionality is provided | 13:54 |
* lpapp does not understand the smart thingie | 13:55 | |
ErkiS | bluelightning: ah, sorry, I misread you. so if I install zypper, that should help me installing the rest? | 13:56 |
lpapp | what about opkg | 13:57 |
JaMa | opkg has new maintainer :) | 13:58 |
bluelightning | ErkiS: it should yes | 13:58 |
bluelightning | JaMa: I did not hear that news...? | 13:59 |
lpapp | I mean that is probably the best for embedded? | 13:59 |
bluelightning | lpapp: typical embedded applications, if you need a package manager at all, yes | 13:59 |
ErkiS | bluelightning: unfortunately, zypper is telling me that 'gumstix' and 'Angstrom' repositories are invalid (File '/repodata/repomd.xml' not found on medium 'http://package-cache.gumstix.org/') | 14:00 |
JaMa | bluelightning: Paul Barker volunteered on opkg-devel ML and is now merging pending patches | 14:00 |
bluelightning | JaMa: great, that is very good news | 14:00 |
bluelightning | at some point I was subscribed to that list, not sure why I'm not anymore... | 14:00 |
lpapp | it did not have a maintainer?! | 14:01 |
bluelightning | the last maintainer wasn't really active over the last few years no | 14:01 |
bluelightning | he did do quite a lot of work on it before then though | 14:01 |
JaMa | I got couple of patches (all from oe-core) merged few months ago, but there was no development and no plans for new release | 14:02 |
bluelightning | mostly it just works; but there are a few rough edges... the libopkg API rework never got properly finished for example | 14:03 |
bluelightning | AFAIK | 14:03 |
lpapp | it is written in c. :( | 14:04 |
lpapp | why is it better than other package managers | 14:08 |
lpapp | what makes it minimal | 14:08 |
* lpapp used to hav a package manager written in qt | 14:08 | |
lpapp | have* | 14:08 |
rburton | JaMa: oh that's excellent news. i wonder if he'll fill in all the TODO bits ;) | 14:12 |
rburton | lpapp: vastly less memory usage is the main reason | 14:12 |
lpapp | I also wonder if it is that good, why it is not the default for Yocto. | 14:12 |
lpapp | rburton: ? | 14:12 |
lpapp | less memory usage means less stuff to deal with I guess? | 14:12 |
lpapp | but is that really good? | 14:12 |
rburton | more like it is designed to use a little ram, instead of apt which assumes it can just fill ram with everything | 14:13 |
rburton | (and thus can't be used on systems with low ram) | 14:13 |
rburton | (ditto rpm) | 14:13 |
lpapp | not sure what that means. | 14:13 |
rburton | of course if you're not putting the package manager on the target itself, then it doesn't matter. | 14:14 |
*** JaMa is now known as JaMa|Off | 14:14 | |
lpapp | du -sh `which pacman` | 14:15 |
lpapp | 108K /usr/bin/pacman | 14:15 |
lpapp | I would call that lightweight. | 14:15 |
lpapp | and pacman is designed to use very small amount of RAM, too. | 14:15 |
lpapp | so again, why did we need opkg? | 14:15 |
*** tstableford <tstableford!5221da4a@gateway/web/freenode/ip.82.33.218.74> has joined #yocto | 14:15 | |
rburton | lpapp: because pacman didn't exist when opkg was written. | 14:16 |
lpapp | | POD document had syntax errors at /usr/bin/core_perl/pod2man line 71. | 14:16 |
lpapp | | make: *** [install_docs] Error 1 | 14:16 |
lpapp | | ERROR: oe_runmake failed | 14:16 |
rburton | at the time opkg was written, both rpm and dpkg would OOM on the typical target | 14:16 |
lpapp | | ERROR: Function failed: do_install ( | 14:16 |
lpapp | rburton: are you actually sure | 14:16 |
tstableford | Hello yocto community. I've read that yocto has systemd support but I can't find any documentation on how to enable it. Could anyone point to some instructions or throw me some hints? | 14:16 |
lpapp | pacman started very early. | 14:16 |
lpapp | at least 7-8 years ago | 14:17 |
lpapp | sorry, 11.5 | 14:17 |
lpapp | when 1.0 was released. | 14:17 |
lpapp | so probably 12-13 years ago when it started. | 14:17 |
rburton | if i'm wrong then i'm sorry, i wasn't around when opkg was created. | 14:18 |
rburton | if you want to write a layer to use pacman, go for it | 14:18 |
rburton | you can do that in a standalone layer no problem | 14:18 |
lpapp | I do not feel the need for opkg, personally. | 14:19 |
lpapp | if there had been a project with such goals in mind, already. | 14:19 |
rburton | don't use it then | 14:20 |
rburton | linux is about choice :) | 14:20 |
lpapp | it has to have some project mission which differs from pacman | 14:20 |
lpapp | pacman has been written in C, as well. | 14:20 |
*** eren <eren!~eren@unaffiliated/eren> has quit IRC | 14:20 | |
bluelightning | tstableford: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#selecting-an-initialization-manager | 14:20 |
lpapp | rburton: it is not about that. | 14:20 |
lpapp | I just dislike when I see projects reinventing the wheel. | 14:20 |
rburton | lpapp: welcome to the other side of "choice" | 14:20 |
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 14:21 | |
rburton | in yocto *right now* there is rpm, deb and opkg. deb doesn't work that great. some people demand rpm, some people refuse rpm, so use opkg. | 14:21 |
lpapp | how can I disable the doc generation globally? | 14:21 |
rburton | if you want to write a pacman layer and prove how great it is, then do so. | 14:21 |
lpapp | rburton: write a layer for an unsupported OS? Nice joke. | 14:22 |
lpapp | people would associate pacman with arch. | 14:22 |
rburton | lpapp: so why are we discussing this then? it sounded like you wanted to use pacman. | 14:22 |
lpapp | and if they see, arch is banned, they would not use pacman. | 14:22 |
lpapp | so then what is the point really if it gets no users. | 14:22 |
lpapp | rburton: no | 14:22 |
lpapp | rburton: I wanted to understand the existence of opkg | 14:23 |
lpapp | I still do not understand though. :) | 14:23 |
bluelightning | lpapp: opkg has many users; it's in use not just by OpenEmbedded but also by OpenWRT and other unrelated projects | 14:23 |
lpapp | so, how can I ban doc for Yocto? | 14:24 |
bluelightning | lpapp: it derives from ipkg which has been around since 2002 and possibly earlier | 14:24 |
lpapp | bluelightning: but _why_ was it born in the first place when there was such a project with such a goal in mind? | 14:24 |
tstableford | thanks bluelightning | 14:24 |
rburton | lpapp: what recipe, and what release? | 14:25 |
bluelightning | lpapp: I don't know, perhaps you can ask florian ;) | 14:25 |
lpapp | rburton: all | 14:25 |
rburton | lpapp: re-phrase your question: why was pacman born when dpkg/rpm/ipkg/more already existed? | 14:25 |
rburton | lpapp: "because" is the usual answer | 14:25 |
rburton | because each one considers itself "better" by some metric | 14:26 |
lpapp | rburton: because it is lightweight | 14:26 |
lpapp | meant for a very thin system | 14:26 |
lpapp | it has a lot better design. | 14:26 |
lpapp | and it does not have a bloated interface. | 14:26 |
lpapp | and it is a lot easier to deal with for packagers | 14:27 |
lpapp | and it was also fully community driven. | 14:28 |
lpapp | another try: how can I disable the docs? | 14:28 |
lpapp | fully and globally for yocto | 14:29 |
bluelightning | lpapp: there is no such global switch, that I know of | 14:29 |
lpapp | sucks | 14:30 |
lpapp | so there is another build failure in dylan, then. | 14:30 |
lpapp | which I cannot even disable. :( | 14:30 |
bluelightning | we have disabled documentation for some troublesome recipes on an individual basis | 14:30 |
lpapp | please do that for openssl as well. | 14:30 |
bluelightning | lpapp: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ea886ed79d7f10d2f8392398e65138f5da04a892 | 14:31 |
lpapp | http://patchwork.openembedded.org/patch/52387/ | 14:31 |
lpapp | yeah, why on earth did it not make it into dylan sigh | 14:31 |
bluelightning | it's in the dylan branch already, queued for 1.4.2 | 14:32 |
lpapp | yeah for ages | 14:33 |
lpapp | so it is useless for dylan users. | 14:33 |
bluelightning | or not, as the case may be | 14:33 |
lpapp | sure, I should wait here sitting for weeks | 14:34 |
lpapp | or months for it to get released. | 14:34 |
rburton | lpapp: have you considered tracking the dylan git branch? | 14:35 |
lpapp | ? | 14:35 |
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 14:36 | |
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto | 14:38 | |
lpapp | anyway, this sounds like a new feature request | 14:40 |
lpapp | I would like to be able to say that I do not wanna any kind of docs. | 14:40 |
lpapp | and that is globally... it is an embedded board... doc would make no sense. | 14:40 |
lpapp | worst case scenario a local.conf entry. | 14:41 |
rburton | lpapp: the docs won't get installed unless you ask for them | 14:41 |
rburton | (doc-pkgs image feature) | 14:41 |
lpapp | I do not wanna _build_ them,even. | 14:41 |
rburton | potentially useful in sdk builds though | 14:41 |
lpapp | why would I build them if I do not wanna install them? | 14:41 |
lpapp | and have no any intention to use them. | 14:41 |
*** tstableford <tstableford!5221da4a@gateway/web/freenode/ip.82.33.218.74> has quit IRC | 14:42 | |
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 14:48 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 14:52 | |
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has left #yocto | 14:53 | |
* rburton cheers at sstate | 14:53 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 14:57 | |
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 15:03 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 15:06 | |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 15:13 | |
lpapp | ERROR: Function failed: bar: LIC_FILES_CHKSUM points to an invalid file: /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/bar/0.1-r0/bar-0.1/COPYRIGHT | 15:33 |
lpapp | why is it like that? | 15:33 |
lpapp | I have the COPYRIGHT in PN | 15:33 |
lpapp | is it mandatory to have do_make/install sections? | 15:36 |
*** roinn <roinn!~roinn@194.9.242.240> has quit IRC | 15:36 | |
rburton | there are defaults in base.bbclass, so effectively no | 15:37 |
lpapp | how can I avoid that error? | 15:37 |
rburton | presumably your LIC_FILS_CHKSUM is wrong | 15:38 |
rburton | pastebin? | 15:38 |
rburton | you may want to use ${WORKDIR} if the path is wrong | 15:39 |
lpapp | but it does not suggest any correct. | 15:39 |
rburton | i.e. if you use a relative path, it uses ${S} as the root | 15:39 |
lpapp | ? | 15:39 |
lpapp | I have been told PN, files, etc are looked up by default. | 15:39 |
rburton | they are | 15:39 |
rburton | and the fetch/unpack worked | 15:39 |
rburton | because LIC_FILES_CHKSUM happens after that | 15:40 |
lpapp | so why would I need WORKDIR then? | 15:40 |
rburton | i'm entirely guessing because you're not giving any context | 15:40 |
lpapp | ? | 15:40 |
lpapp | context is simply file://COPYRIGHT | 15:41 |
lpapp | nothing magical. | 15:41 |
rburton | and the file isn't at the path it says its looking at? | 15:41 |
lpapp | I wonder why I need the WORKDIR | 15:41 |
rburton | right | 15:41 |
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 15:41 | |
lpapp | it works without that for SRC_URI | 15:41 |
rburton | so your LIC_FILES_CHKSUM has just file://COPYRIGHT in a LIC_FILES_CHKSUM,? | 15:41 |
lpapp | why do I need for the other one? | 15:41 |
lpapp | yes | 15:41 |
lpapp | ;md5... | 15:41 |
lpapp | without WORKDIR | 15:41 |
rburton | that's a relative path, so the implicit base is $S | 15:42 |
rburton | which is WORKDIR/PN-PV by default | 15:42 |
rburton | which is why its looking where it's looking | 15:42 |
rburton | but that's not where the file went | 15:42 |
rburton | so your LIC_FILES_CHKSUM needs to be file://${WORKDIR}/COPYRIGHT | 15:42 |
rburton | (because it's not in $S, which is the default) | 15:43 |
rburton | lpapp: did that help? | 15:45 |
Garibaldi|work | Hum... anyone know why when I try to run bitbake, I get stuck at "Parsing recipes: 99% |#...| ETA: 00:00:00" | 15:47 |
Garibaldi|work | (this is w/ danny) | 15:48 |
Garibaldi|work | and I end up with a couple of zombie python processes | 15:49 |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 15:49 | |
lpapp | rburton: I think it would be simpler if we did not always need to put WORKDIR in there. | 15:50 |
rburton | Garibaldi|work: huh. try deleting build/cache | 15:50 |
rburton | lpapp: needing WORKDIR puts you in the 1% of recipes | 15:50 |
rburton | 99% of the time, you're checksumming a file in an extracted tarball | 15:50 |
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC | 15:50 | |
rburton | which is why the root for relative paths is $S | 15:50 |
lpapp | rburton: all our custom files are like this though. | 15:50 |
rburton | lpapp: that's fine, use ${WORKDIR} | 15:50 |
lpapp | I would not like to, in the future | 15:51 |
rburton | the alternative is to use ${WORKDIR} as the default, and fix 728 mentions in oe-core | 15:51 |
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 15:52 | |
Garibaldi|work | rburton: didn't help :-( | 15:52 |
rburton | lpapp: there has to be a default root for relative paths, and the one that works for 700 mentions is preferable to the one that works for about 9 mentions | 15:52 |
lpapp | rburton: I think there should be an in-between solution. | 15:52 |
rburton | Garibaldi|work: huh | 15:52 |
lpapp | rburton: btw, if I do not use do_compile/install | 15:52 |
*** GunsNRose <GunsNRose!~GunsNRose@118.114.151.41> has quit IRC | 15:52 | |
lpapp | apparently nothing gets built. :( | 15:52 |
lpapp | even though the default "make" should be fine! | 15:52 |
rburton | lpapp: the default do_compile will run make if it can find a normal makefile | 15:53 |
rburton | lpapp: but you'll need to install yourself still | 15:53 |
lpapp | rburton: I do not even find a binary in the work dirt. | 15:54 |
lpapp | dir.* | 15:54 |
rburton | lpapp: check the log, it will either show you it running make, or saying "nothing to compile" | 15:54 |
sgw_ | lpapp: Almost all open source projects that provide a LICENSE or COPYING file have that file reside in the "top-level" of their source tree, which is ${S} in oe-core, therefore our default lookup path for the LIC_FILE_CHECKSUM is to be relative to ${S} | 15:54 |
rburton | lpapp: if that happens then it couldn't find the makefile | 15:54 |
lpapp | sgw_: yes, so? | 15:55 |
rburton | lpapp: (base.bbclass has the default functions) | 15:55 |
lpapp | sgw_: I would like to have the option to simplify my job. | 15:55 |
lpapp | rburton: where is the log file? | 15:55 |
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 15:55 | |
rburton | lpapp: workdir/temp/ | 15:55 |
kergoth | heh, I hate our automatic "magic" we put in place to try to keep recipes small. it would have been better to have the base bbclass do_compile error out indicating hte user has to do something, and then add a make class, then it'd at least be explicit, and you woudln't get into a case where oyur software didn't build, but do_compile succeeded, and no package is produced | 15:56 |
kergoth | oh well, a bit late to do much about that | 15:56 |
rburton | kergoth: i've long suspected a "make" class is needed | 15:56 |
lpapp | rburton: yeah, but which file? | 15:56 |
*** zenlinux <zenlinux!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has joined #yocto | 15:56 | |
kergoth | our default EXTRA_OEMAKE is anothe rpet peeve of mine, even though i'm the one that created it | 15:56 |
kergoth | the -e stuff is.. ugh | 15:57 |
rburton | lpapp: the log files are the ones called "log.*". then the name reflects the task that was running. | 15:57 |
lpapp | rburton: no compile task. | 15:58 |
lpapp | log.do_cleanall log.do_cleanall.17386 log.do_cleansstate log.do_cleansstate.17385 log.task_order run.do_cleanall.17386 run.do_cleansstate.17385 | 15:58 |
rburton | might be best to see your recipe then | 15:59 |
lpapp | rburton: nothing after SRC_URI | 16:00 |
lpapp | as the usual make && make install is sufficient. | 16:00 |
lpapp | I should have no code for default stuff. | 16:00 |
rburton | "make install" isn't "usual", so you'll have to code that | 16:00 |
rburton | as i said, see base.bbclass for the defaults. | 16:00 |
lpapp | that sounds bad | 16:00 |
rburton | no, it doesn't | 16:00 |
lpapp | yes, it does. | 16:00 |
lpapp | actually any package manager I have used managed to put everything into the package by default. | 16:01 |
lpapp | without explicitly specifying. | 16:01 |
lpapp | Yocto is the first weird stuff not following that. | 16:01 |
* rburton shrugs | 16:02 | |
lpapp | sounds like a feature request. | 16:02 |
lpapp | an important one. | 16:02 |
rburton | dpkg doesn't by default. if you tell it you're using "automake" it will. | 16:02 |
rburton | just like oe | 16:02 |
lpapp | dpkg actually does. | 16:03 |
rburton | lpapp: there isn't a universal way of doing re-rooted installs, so there really isn't much point | 16:03 |
lpapp | there is much point. | 16:03 |
lpapp | to avoid the boilerplate hell. | 16:03 |
rburton | one line. | 16:03 |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 16:03 | |
*** darknighte_znc is now known as darknighte | 16:03 | |
lpapp | it does not matter how many. | 16:03 |
rburton | anyway, kernels to kick | 16:03 |
lpapp | if it can be automated, it should be. | 16:03 |
lpapp | also, even compile does not work off-hand. :( | 16:04 |
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-afqhaidaspnalmvo> has quit IRC | 16:04 | |
lpapp | what boilerplate do people need to put into do_compile to do the default stuff? | 16:05 |
lpapp | "make"? | 16:05 |
* lpapp is currently blocked due to this | 16:08 | |
rburton | the default do_compile calls make. you can see the logic in base.bbclass. | 16:08 |
lpapp | why is it not working then? | 16:08 |
kergoth | the most common cause of do_compile doing nothing when you have a makefile is having S set incorrectly (or the default doesnt match reality), or you're trying to build something autotools and forgot to inherit autotools, so no makefile was created | 16:09 |
lpapp | how can I get more verbose stuff from bitbake for this? | 16:10 |
*** davest1 <davest1!Adium@nat/intel/x-sewolfxavaofqzbi> has joined #yocto | 16:10 | |
lpapp | temp/ is useless | 16:11 |
lpapp | and temp/../foo/ is empty. | 16:11 |
lpapp | wow, COPYRIGHT files have different checksums, as in really? | 16:12 |
kergoth | that reminds me, we shouldn't be auto-creating S if it doesn't exist. better to fail uot with a 'this path we looked for doesn't exist, aiee' than to create and use an empty directory, and end up doing nothing quietly | 16:12 |
lpapp | "No generic license file exists for: Propriate in any provider" -> what is this warning? | 16:13 |
lpapp | bitbake foo -c cleanall -> does not rebuilt it either. | 16:14 |
lpapp | what is going on? o_O | 16:14 |
lpapp | so what more can I do? | 16:16 |
lpapp | if I run make on the host, it just works | 16:16 |
lpapp | does it uncompress the tar.xz at all? | 16:17 |
lpapp | how can I make sure? | 16:17 |
bluelightning | lpapp: look in the workdir? | 16:17 |
lpapp | ? | 16:17 |
lpapp | what do you think I have been doing? | 16:17 |
bluelightning | lpapp: what do you have in there? | 16:18 |
lpapp | see above, nothing, really. | 16:18 |
lpapp | an emptyfolder and a few useless temp/ entries. | 16:18 |
lpapp | empty folder* | 16:18 |
lpapp | tar.xz is not supported?! | 16:18 |
bluelightning | kind of sounds like it has not been unpacked | 16:19 |
lpapp | why does it not support .tar.xz? | 16:20 |
lpapp | tar xvpf just uncompresses it fine. | 16:20 |
lpapp | and even if it does not support that, shouldn't it complain? | 16:21 |
lpapp | also, why do I get a license warning here and not for other packages with the exactly same COPYRIGHT file?! | 16:23 |
lpapp | this is all chaotic. :-) | 16:23 |
bluelightning | lpapp: it most certainly does support tar.xz; if you look you'll see a number of recipes that point to tar.xz files | 16:24 |
bluelightning | lpapp: the license warning is based upon the value of LICENSE not LIC_FILES_CHKSUM | 16:24 |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 16:24 | |
*** blloyd <blloyd!~blloyd@mobile-166-137-146-249.mycingular.net> has joined #yocto | 16:27 | |
*** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has quit IRC | 16:27 | |
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC | 16:28 | |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:40 | |
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 16:45 | |
blloyd | Is there a way to specify one file that should not be stripped? without either debug symbols for or an unstripped copy of libthead_db.1.so | 16:46 |
blloyd | core files from a system are highly likely to not be able to get all thread information. | 16:46 |
blloyd | Place that file on the end system and all crash dumps are able to be debugged in all threads. | 16:47 |
mr_science | have you tried installing the debug package? | 16:47 |
mr_science | ie, foo-dbg for whatever you're trying to debug... | 16:47 |
*** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 16:48 | |
blloyd | Of course the system debugging the crash has the debug symbols. The system producing the core (think end user crash dump analysis) seems to also need that one file. | 16:48 |
mr_science | and what you need isn't in another -dbg package? | 16:49 |
lpapp | bluelightning: I looked yesterday, however that is the only reason I can come up with. | 16:50 |
mr_science | otherwise i think it would take some jiggering of the recipe | 16:50 |
blloyd | Seems it is a problem with the way threading is done. However, without an unstripped version of that file ulimit -c unlimited and then sftping the resulting core when the dump is seen ends up with a dump with only one thread. | 16:50 |
lpapp | bluelightning: but you are of course more than welcome to suggest alternative bug options. | 16:50 |
bluelightning | lpapp: without seeing the recipe itself I can't tell what might be going on | 16:50 |
blloyd | mr_science, so are you saying install the debug symbols on the system doing the debugging or install them on the end device? | 16:51 |
lpapp | bluelightning: I pretty much pasted the recipe here already. | 16:51 |
*** fgretief <fgretief!~chatzilla@196-215-192-74.dynamic.isadsl.co.za> has joined #yocto | 16:51 | |
*** Crofton|work <Crofton|work!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 16:51 | |
mr_science | blloyd: in some case it seems like you need both | 16:51 |
lpapp | LICENSE = "Propriate" | 16:51 |
lpapp | what should that contain instead? | 16:51 |
mr_science | though i am not the remote debugging expert... | 16:51 |
bluelightning | lpapp: "Proprietary" or "CLOSED" | 16:52 |
bluelightning | lpapp: note that CLOSED will completely disable LIC_FILES_CHKSUM | 16:52 |
mr_science | still need to work through and document some of that stuff for our current classic build... | 16:52 |
lpapp | bluelightning: too bad it is not documented. | 16:53 |
bluelightning | lpapp: it was last I checked | 16:53 |
blloyd | it's a limitation of gcc, and it's dealing exclusively with the libthread.so.debug file. gcc can't use a copy that doesn't have symbols available. | 16:53 |
mr_science | blloyd: see if installing the -dbg packages to your (non-target) sysroot does what you need | 16:53 |
lpapp | bluelightning: not in the reference, nor in the development manual. | 16:53 |
bluelightning | lpapp: yep, in the reference manual in two separate places | 16:53 |
lpapp | not in the current. | 16:53 |
lpapp | nope | 16:54 |
blloyd | it doesn't. I already have the dbg symbols | 16:54 |
bluelightning | lpapp: yep | 16:54 |
mr_science | blloyd: in both places? | 16:54 |
bluelightning | lpapp: 3.4.1.1. Specifying the LIC_FILES_CHKSUM Variable and the variable glossary entry for LIC_FILES_CHKSUM | 16:54 |
lpapp | bluelightning: not in the current, no. | 16:54 |
bluelightning | lpapp: yes in the current | 16:54 |
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 16:54 | |
lpapp | bluelightning: nope | 16:54 |
lpapp | could you please show where Proprietary is mentioned? | 16:55 |
lpapp | I must be blind. | 16:55 |
blloyd | for everything. For target, I can add the single file. Already discussed with gcc group. Basically, they suggest putting the symbols back into that file. | 16:55 |
bluelightning | lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#usingpoky-configuring-LIC_FILES_CHKSUM | 16:55 |
lpapp | bluelightning: I do not see the word there. | 16:55 |
lpapp | can you paste the sentence? | 16:55 |
bluelightning | lpapp: Proprietary isn't but then there's not any special behaviour associated with it | 16:55 |
blloyd | Thus my question: is there a way to say don't strip this file? I missed it if there is. | 16:55 |
mr_science | blloyd: then it sounds like you need a new recipe to build/install an unstripped version | 16:55 |
bluelightning | lpapp: unlike CLOSED | 16:55 |
lpapp | bluelightning: then why do you recommend something without special meaning? | 16:56 |
lpapp | I need a special meaning. | 16:56 |
mr_science | blloyd: yes there is, but i don't think it soes just a single file | 16:56 |
lpapp | clearly, Propriate and Proprietary are not the same, so some special meaning has to be there. | 16:56 |
mr_science | *does | 16:56 |
lpapp | sounds like a bugreport entry. | 16:57 |
blloyd | recipe wide, or PACKAGES wide? | 16:57 |
bluelightning | lpapp: I assumed that "Propriate" was a mistake and what was meant was "Proprietary"; which happens to be a convention that some use | 16:57 |
mr_science | you can specify nostrip in a recipe, not sure if there's a way to nostrip a single lib | 16:57 |
lpapp | also, how can I debug the uncompression issue? | 16:57 |
bluelightning | lpapp: I'd be looking at log.do_unpack | 16:57 |
bluelightning | anyway I have to go in about 5 seconds | 16:57 |
mr_science | blloyd: one sec, looking at the busybox recipe | 16:58 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 16:59 | |
lpapp | blloyd: there is nothing like that. | 16:59 |
lpapp | blloyd: sorry about that. | 17:00 |
lpapp | rburton: what can I check in for the CI to have the proper bblayers.conf thingie? | 17:00 |
lpapp | without our own layer, there was nothing to be checked in before, and that made the CI generate correct stuff. | 17:00 |
lpapp | but we cannot use default anymore. | 17:00 |
lpapp | and my checked in layers conf is well ... /home/lpapp/etc... :) | 17:00 |
mr_science | blloyd: try this | 17:03 |
mr_science | in the recipe use PACKAGE_STRIP = "no" | 17:04 |
lpapp | rburton: some bitbake variable to the conf path? | 17:04 |
lpapp | or at least to the build folder path? | 17:04 |
lpapp | mr_science: hi, how are you | 17:04 |
lpapp | mr_science: what is the situation with nginx | 17:04 |
mr_science | you could try PACKAGE_STRIP_package-name = "no" and package that single file separately | 17:04 |
mr_science | seems kinda weird to have to do that, so maybe i'm missing something... | 17:05 |
mr_science | lpapp: haven't had a chance to build it yet, but hopefully i'll have a working version in my rpi layer this weekend | 17:06 |
Garibaldi|work | ls | 17:07 |
Garibaldi|work | gah, sorry | 17:07 |
mr_science | looking for vorlons? | 17:07 |
Garibaldi|work | :-) | 17:07 |
mr_science | lpapp: i'll do it as a single commit so it should be easy to cherry-pick, format a patch, etc | 17:09 |
*** belen <belen!~Adium@134.134.139.72> has quit IRC | 17:11 | |
*** seebs <seebs!~seebs@74.122.98.108> has quit IRC | 17:11 | |
*** belen <belen!Adium@nat/intel/x-bhnfunwchnwyoyzf> has joined #yocto | 17:13 | |
*** seebs <seebs!~seebs@74.122.98.108> has joined #yocto | 17:15 | |
lpapp | mr_science: I wanted to do it today. | 17:17 |
lpapp | mr_science: but if you can do it this weekend, that is better. | 17:17 |
lpapp | I can concentrate on other stuff. :p | 17:17 |
mr_science | yeah, i gotta make an upgrade and re-release our hardware test image | 17:17 |
lpapp | good luck to that. | 17:18 |
mr_science | so tomorrow is way better for that stuff... | 17:18 |
lpapp | take your time. | 17:18 |
lpapp | I will not do anything at the weekend other than playing music anyway. :) | 17:18 |
mr_science | i need to put on some new strings | 17:19 |
mr_science | thanks for reminding me i have more stuff to do... ;) | 17:19 |
lpapp | guitar? | 17:19 |
mr_science | nothing else before coffee tho... | 17:19 |
mr_science | yeah, i haven't done much lately but i bought a used ovation from one of the quality guys | 17:20 |
*** belen <belen!Adium@nat/intel/x-bhnfunwchnwyoyzf> has quit IRC | 17:23 | |
lpapp | anyone here knowing if there is a bitbake variable holding the path to the build folder or the config folder in the build dir? | 17:24 |
lpapp | to put that into bblayers.conf | 17:24 |
lpapp | or even the poky project root, etc? | 17:24 |
lpapp | so that it can work on any machine after a checkout? | 17:24 |
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC | 17:24 | |
*** darknighte <darknighte!~darknight@nat-lmt.mentorg.com> has joined #yocto | 17:28 | |
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto | 17:28 | |
*** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 17:29 | |
lpapp | is there a page somewhere with the bitbake variables? | 17:29 |
lpapp | of course I could use $PWD/../../meta-foo or so, but $PROJECT_ROOT/meta-foo would be neater | 17:30 |
*** belen <belen!~Adium@134.134.139.72> has joined #yocto | 17:30 | |
*** pidge_ <pidge_!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto | 17:30 | |
sgw_ | lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-variables-glos | 17:32 |
lpapp | sgw_: thanks. | 17:33 |
lpapp | I actually think that mentioning a path is pretty useless in there. | 17:33 |
lpapp | why doesn't it just take the meta-foo stuff? | 17:33 |
lpapp | it is very unlikely people will refer outside poky... | 17:33 |
*** belen <belen!~Adium@134.134.139.72> has quit IRC | 17:34 | |
lpapp | TOPDIR | 17:40 |
lpapp | This variable is the Build Directory. BitBake automatically sets this variable. The OpenEmbedded build system uses the Build Directory when building images. | 17:40 |
lpapp | this is almost good, but it would be nice to get the one upper, i.e. projectroot. | 17:40 |
*** phdeswer_ <phdeswer_!~phdeswer@a88-113-104-180.elisa-laajakaista.fi> has joined #yocto | 17:43 | |
lpapp | ${TOPDIR}/../meta -> so, that is the best I can come up with, but it is still ugly. :-) | 17:45 |
mr_science | s/friday/fartday/ | 17:53 |
mr_science | did i say that out loud? | 17:54 |
lpapp | I would even claim that if I do not specify a path, it should pick up from the "default". | 17:54 |
lpapp | the oe script will know what the project root is after all. | 17:54 |
*** phdeswer_ <phdeswer_!~phdeswer@a88-113-104-180.elisa-laajakaista.fi> has quit IRC | 17:57 | |
*** zenlinux <zenlinux!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has quit IRC | 18:00 | |
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 18:08 | |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 18:08 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:11 | |
Garibaldi|work | rburton: I'm still stuck on this problem with bitbake hanging on 'parsing recipes' at 99% with 00:00:00 remaining | 18:21 |
Garibaldi|work | I threw --verbose and a few -Ds in there, and the last thing I see is DEBUG: BB .../core-image-base.bb:8: inheriging .../core-image.bbclass | 18:22 |
Garibaldi|work | I did see: DEBUG: while parsing populate_sdk_ipk, unable to handle non-literal command '${POPULATE_SDK_POST_HOST_COMMAND}' | 18:23 |
Garibaldi|work | but it's not clear to me that that's a failure | 18:23 |
Garibaldi|work | and I get two python zombies that were once associated with the run | 18:25 |
Garibaldi|work | and ctrl-C doesn't work | 18:27 |
Garibaldi|work | I have to kill the python processes | 18:27 |
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 18:27 | |
Garibaldi|work | (or if anyone else has any ideas) | 18:30 |
Garibaldi|work | hum, now I caused it and got no zombie processes | 18:31 |
Garibaldi|work | but all of the pythong processes are in a Sleep state | 18:31 |
Garibaldi|work | S+ or Sl+ | 18:31 |
blloyd | lpapp: just for your unlikely case. I have a setup of parentdir/{poky,meta-mycompany,meta-testing}. Note it is OUTSIDE the poky for reference to two metas. I also put the build directory at /embeddedtmp, which is a separate disk, so TOPDIR has nothing at all in relation to the poky directory.... | 18:35 |
blloyd | at should be under, oh, well. | 18:35 |
fray | Garibaldi|work ya, I'e seen the same ctrl-c behavior in the past.. | 18:36 |
fray | it was being worked on at one point, but with Richard on vacation, I'm not sure how much it's being looked at right now.. | 18:36 |
fray | we're also trying to track/reproduce another problem that looks like bitbake is just hanging (appears to be waiting forever for a socket) | 18:36 |
fray | but reproducing this is really difficult, and nothing we've done has been it reliably reproduced | 18:37 |
mr_science | Garibaldi|work: master branch or another? | 18:39 |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 18:48 | |
Garibaldi|work | this is danny | 18:49 |
Garibaldi|work | what's killing me is I can't find the commit in my local repo where it started failing | 18:49 |
Garibaldi|work | it's almost like it's something external | 18:49 |
Garibaldi|work | it doesn't always stop at the same place either | 18:51 |
Garibaldi|work | at least in terms of the debug output | 18:51 |
Garibaldi|work | I guess it could be related to there being multiple processes | 18:51 |
Garibaldi|work | let me try giving it just one process w/ one thread | 18:52 |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 18:52 | |
*** swex__ <swex__!~swex@178.17.203.196> has joined #yocto | 18:53 | |
Garibaldi|work | yeah, looks like it's still doing multithreading behind the scenes | 18:55 |
*** swex_ <swex_!~swex@178.17.193.139> has quit IRC | 18:56 | |
*** blloyd <blloyd!~blloyd@mobile-166-137-146-249.mycingular.net> has quit IRC | 18:58 | |
fray | ahh, ya problems I'm having are all master | 18:58 |
*** blloyd <blloyd!~blloyd@mobile-166-137-146-249.mycingular.net> has joined #yocto | 19:00 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 19:03 | |
*** otavio_ <otavio_!~otavio@debian/developer/otavio> has joined #yocto | 19:06 | |
*** balister_ <balister_!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has joined #yocto | 19:08 | |
*** khem` <khem`!~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net> has joined #yocto | 19:09 | |
mr_science | i love our u-boot config... | 19:10 |
mr_science | Autoboot in 1 seconds, type ctrl-C to interrupt | 19:10 |
mr_science | gotta be quick... | 19:10 |
mr_science | and no, i was not asked to grammar-check the output... | 19:11 |
*** pidge__ <pidge__!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto | 19:19 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 19:20 | |
*** pidge_ <pidge_!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 19:20 | |
*** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC | 19:20 | |
*** khem <khem!~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net> has quit IRC | 19:20 | |
*** Crofton <Crofton!~balister@pool-71-171-36-155.ronkva.east.verizon.net> has quit IRC | 19:20 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 19:20 | |
*** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has quit IRC | 19:20 | |
lpapp | speaking of which, my u-boot change did not enter the mailing list. :( | 19:22 |
lpapp | it is dropped after git send-email if I am not subscribed? :( | 19:22 |
*** blloyd <blloyd!~blloyd@mobile-166-137-146-249.mycingular.net> has quit IRC | 19:25 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 19:26 | |
*** zeddii <zeddii!~ddez@128.224.252.2> has joined #yocto | 19:26 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 19:30 | |
mr_science | nice... | 19:31 |
* mr_science has found a new boot failure mode | 19:32 | |
*** halstead <halstead!~halstead@drupal.org/user/301087/view> has quit IRC | 19:34 | |
*** jukkar <jukkar!jukka@nat/intel/x-qnwsfphmnmrlcmoe> has joined #yocto | 19:38 | |
*** halstead <halstead!~halstead@drupal.org/user/301087/view> has joined #yocto | 19:39 | |
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 19:43 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 19:45 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 19:49 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 20:01 | |
*** nitink <nitink!~nitink@134.134.137.73> has quit IRC | 20:09 | |
*** silviof1 <silviof1!~silviof@ppp-46-244-128-156.dynamic.mnet-online.de> has joined #yocto | 20:13 | |
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto | 20:13 | |
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 20:16 | |
*** Jefro1 <Jefro1!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 20:24 | |
*** fgretief <fgretief!~chatzilla@196-215-192-74.dynamic.isadsl.co.za> has quit IRC | 20:24 | |
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 20:24 | |
*** nitink <nitink!nitink@nat/intel/x-nwyfqcsjnyvglesf> has joined #yocto | 20:30 | |
*** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 20:36 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:36 | |
*** darknighte is now known as darknighte_znc | 20:41 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 20:45 | |
*** nitink <nitink!nitink@nat/intel/x-nwyfqcsjnyvglesf> has quit IRC | 20:48 | |
*** nitink <nitink!nitink@nat/intel/x-tapvxkrisanropre> has joined #yocto | 20:49 | |
*** eren <eren!~eren@unaffiliated/eren> has quit IRC | 20:56 | |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 20:58 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 21:14 | |
*** nitink <nitink!nitink@nat/intel/x-tapvxkrisanropre> has quit IRC | 21:20 | |
*** ant_home <ant_home!~andrea@host36-64-dynamic.8-87-r.retail.telecomitalia.it> has joined #yocto | 21:22 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 21:23 | |
*** davest1 <davest1!Adium@nat/intel/x-sewolfxavaofqzbi> has quit IRC | 21:25 | |
*** nitink <nitink!nitink@nat/intel/x-wztahbxnknwicjys> has joined #yocto | 21:35 | |
*** nitink <nitink!nitink@nat/intel/x-wztahbxnknwicjys> has quit IRC | 21:45 | |
kergoth | has anyone else notice bitbake responds terribly to ^C early on in the build process now that it restarts itself? | 21:46 |
kergoth | hangs up and i ahve to ^Z and kill %1 and pkill -f bitbake to clean up the mess | 21:46 |
seebs | I have not been super happy with bitbake's ^C handling in general. I would, in general, prefer a best effort at "stop running now, that includes child processes". I virtually never want "please continue all the things you're doing now, just don't start new ones". | 21:48 |
kergoth | agreed. | 21:48 |
kergoth | end up just hammering ^C until it goes away | 21:48 |
seebs | And then there's still a ton of stuff running in the background, frequently. | 21:49 |
kergoth | we've worked on it in the past, and changing the server to stop responding to ^C made things more deterministic, but the UI should do a better job of responding to it | 21:49 |
kergoth | well, in the past bitbake itself did okay, but when it was spawned by the shell wrapper, it didn't always get the signal, in my experience | 21:49 |
* kergoth shrugs | 21:49 | |
seebs | Basically, I don't object to an interrupt handler trying to do some sort of cleanup, but the cleanup's priority should be "kill everything as fast as possible" more than "shut down gracefully over time". | 21:49 |
seebs | Ahh, that would make sense. | 21:49 |
kergoth | i had a script that called bitbake and tried to respond gracefully, i had to make the fscking thing try to forcibly kill it and every child it had open at hte time | 21:50 |
kergoth | heh | 21:50 |
kergoth | https://github.com/kergoth/oe-test-scripts/blob/master/bb_test.py#L48-L62 | 21:50 |
*** agust <agust!~agust@p4FDE6832.dip0.t-ipconnect.de> has quit IRC | 21:50 | |
kergoth | i should have checked advanced programming in the unix environment to freshen up though | 21:50 |
kergoth | he | 21:51 |
kergoth | h | 21:51 |
kergoth | seebs: heh, i think python's treatment of the signal as an exception is not ideal. what good is an exception that can show up anywhere, at any time? kind of a pain to handle without making it racey before / after the handled block | 21:53 |
kergoth | course, you can have the same concerns with a signal handler, so many it's not an issue, though its more common to 'handle and recover' from exceptions than from an exceptional signal :) | 21:53 |
kergoth | s/many/maybe/ | 21:54 |
* kergoth shrugs | 21:54 | |
*** davest <davest!~Adium@134.134.139.70> has joined #yocto | 21:55 | |
seebs | Signal handlers strike me as logically a genuinely global thing -- something where it makes sense to be able to specify at a high level that no matter what any other code thinks it might do with the signal, this code here gets it. | 21:56 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mvsurvaccwlrwfck> has quit IRC | 21:56 | |
seebs | Basically, exceptions arise from code execution and propagate up, signals arise externally and propagate down. | 21:56 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-qenztarvfnzrjblv> has joined #yocto | 21:57 | |
kergoth | generally you can only do certain things in a signal handler, its an entirely different context, hiding that behind a generic mechanism to cross that boundary seems questionable, if convenient | 21:57 |
kergoth | anyway... | 21:57 |
kergoth | heh | 21:57 |
kergoth | i think interruption of the initial bitbake psuedo build before its self restart seems to cause problems. it doesn't always stop the second build from running, as though something swallowed the interruption entirely | 21:58 |
* kergoth 'll have to open a bug | 21:58 | |
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC | 21:59 | |
*** walters <walters!~walters@gtsr.mendelu.cz> has joined #yocto | 22:00 | |
*** davest <davest!~Adium@134.134.139.70> has quit IRC | 22:03 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 22:20 | |
tlwoerner | kergoth: if it's not too late to jump in on the signal handling topic... i think i would be nice if there were better handling for ^Z (SIGTSTP) too | 22:25 |
tlwoerner | it would be nice if ^Z stopped the build immediately instead of the "keep doing what you're doing, just don't start anything new" behaviour (IMHO) | 22:25 |
kergoth | you'd think itd propogate the stop down to its children | 22:29 |
tlwoerner | from the cmdline it _looks_ like ^Z stops the build, but looking at the processes (and CPU usage) you can tell the current tasks are still working away | 22:35 |
* kergoth nods | 22:37 | |
kergoth | at a guess, it stops the UI, since the UI is still attached to the tty, but the forked off server process continues along merrily | 22:37 |
* kergoth shrugs | 22:37 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 22:43 | |
*** ant_home <ant_home!~andrea@host36-64-dynamic.8-87-r.retail.telecomitalia.it> has quit IRC | 22:44 | |
*** seebs <seebs!~seebs@74.122.98.108> has quit IRC | 22:56 | |
*** Jay7 <Jay7!jay@176.15.24.149> has quit IRC | 22:58 | |
*** seebs <seebs!~seebs@74.122.98.108> has joined #yocto | 23:01 | |
*** Jay7 <Jay7!jay@176.15.24.79> has joined #yocto | 23:03 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 23:08 | |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 23:34 | |
*** nitink <nitink!~nitink@134.134.139.76> has joined #yocto | 23:42 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-qenztarvfnzrjblv> has quit IRC | 23:47 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!