| 00:50.01 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 01:59.17 | *** join/#oe vmeson (~quassel@128.224.252.2) |
| 02:17.26 | *** join/#oe kuldeepdhaka_ (~kuldeepdh@117.254.217.54) |
| 02:20.57 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 02:52.51 | *** part/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 02:52.52 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 02:53.09 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 03:01.44 | *** join/#oe silviof1 (~silviof@unaffiliated/silviof) |
| 04:16.24 | *** join/#oe kuldeepdhaka (~kuldeepdh@117.254.221.51) |
| 04:24.10 | *** join/#oe kuldeepdhaka_ (~kuldeepdh@117.254.220.183) |
| 04:51.10 | *** join/#oe Noor (~noor@110.93.212.98) |
| 05:40.11 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) |
| 06:11.14 | *** join/#oe kbart (~KBart@213.197.143.19) |
| 06:49.38 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:04.53 | *** join/#oe g1zer0 (~gizero@host168-65-static.12-87-b.business.telecomitalia.it) |
| 07:05.40 | *** join/#oe tasslehoff (~tasslehof@77.40.182.98) |
| 07:12.39 | *** join/#oe stefan_schmidt (~stefan@p4FC7695D.dip0.t-ipconnect.de) |
| 07:28.03 | *** join/#oe clio (~andrej@85.159.109.222) |
| 07:33.13 | *** join/#oe SorenHolm (~quassel@cpe.ge-0-2-0-950.faaqnqu1.dk.customer.tdc.net) |
| 07:37.38 | *** join/#oe hollisb (~hollisb@nat-dem.mentorg.com) |
| 07:53.11 | *** join/#oe likewise (~likewise@83.232.160.170) |
| 07:56.00 | *** join/#oe Aragua (~fabien@195.200.170.210) |
| 07:57.06 | *** join/#oe clio (~andrej@85.159.109.222) |
| 08:01.30 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 08:02.33 | *** join/#oe fusman (~fahad@110.93.212.98) |
| 08:03.02 | *** join/#oe Noor (~noor@110.93.212.98) |
| 08:15.21 | *** join/#oe likewise (~likewise@83.232.160.170) |
| 08:20.58 | *** join/#oe Zagor (~bjst@sestofw01.enea.se) |
| 08:20.58 | *** join/#oe Zagor (~bjst@rockbox/developer/Zagor) |
| 08:28.20 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
| 08:45.17 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:45.17 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:45.50 | *** join/#oe likewise (~likewise@83.232.160.170) |
| 08:53.25 | *** join/#oe roric (~roric@c-919f70d5.013-177-67626713.cust.bredbandsbolaget.se) |
| 08:58.44 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
| 08:59.40 | *** join/#oe mihai (~mihai@80.97.15.150) |
| 09:06.06 | *** join/#oe silvio_ (~silvio@93-57-17-124.ip162.fastwebnet.it) |
| 09:12.28 | *** join/#oe blitz00_ (stefans@nat/intel/x-jyvhnmmrrtjyulum) |
| 09:15.43 | *** join/#oe blitz00 (~stefans@192.198.151.44) |
| 09:15.43 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 09:35.24 | *** join/#oe likewise (~likewise@83.232.160.170) |
| 09:40.42 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 09:48.39 | *** join/#oe ecloud_ (quassel@nat/digia/x-inasqrgocgwmtfpf) |
| 10:00.19 | *** join/#oe jackmitchell (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 10:04.49 | *** join/#oe anarsoul (~anarsoul@178.124.194.242) |
| 10:05.25 | *** join/#oe airesQ (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 10:11.31 | ndec | hi, is there a 'shortcut' or script to force to regenerate Packages file in tmp/deploy/ipk without rebuilding the entire image? |
| 10:21.04 | *** join/#oe mshakeel (~mshakeel@110.93.212.98) |
| 10:21.19 | rburton | ndec: bitbake package-index |
| 10:24.31 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 10:27.17 | *** join/#oe stefan1234 (~stefan@p4FC769A2.dip0.t-ipconnect.de) |
| 10:30.56 | *** join/#oe jkridner|work (~jkridner@c-98-250-142-42.hsd1.mi.comcast.net) |
| 10:32.59 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 10:37.52 | ndec | rburton: thanks! |
| 10:45.20 | mckoan | good morning |
| 10:50.54 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 10:51.40 | *** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk) |
| 10:54.50 | *** join/#oe hollisb (~hollisb@nat-dem.mentorg.com) |
| 10:55.54 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 11:00.03 | *** join/#oe stefan1234 (~stefan@p4FC769A2.dip0.t-ipconnect.de) |
| 11:07.24 | *** join/#oe Leatherface- (~leatherfa@2001:470:dd7d:0:39cd:a285:80d0:f44a) |
| 11:10.00 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 11:10.25 | *** part/#oe patrickg (~patrick@georgi-clan.de) |
| 11:10.58 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 11:28.38 | pb_ | hi all |
| 11:28.38 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 11:28.54 | rburton | morning pb_ |
| 11:29.18 | bluelightning | morning pb_ |
| 11:31.07 | pb_ | good morning intel |
| 11:31.31 | intel | GOOD MORNING PB_ |
| 11:31.34 | pb_ | heh |
| 11:32.27 | rburton | i hope that doesn't count as speaking in public as intel |
| 11:35.57 | JaMa | morning all |
| 11:38.45 | bluelightning | hi JaMa |
| 12:34.03 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 12:38.25 | *** join/#oe hollisb (~hollisb@nat-dem.mentorg.com) |
| 13:16.27 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 13:33.10 | *** join/#oe quboid (~mac@deneb.mcrowe.com) |
| 13:42.30 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 13:47.29 | *** join/#oe diego (~diego@static-217-133-170-65.clienti.tiscali.it) |
| 13:53.39 | *** join/#oe joeythesaint (~jjm@128.224.252.2) |
| 13:59.46 | *** join/#oe oneQubit (~oneQubit@li439-130.members.linode.com) |
| 14:06.24 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 14:06.42 | *** join/#oe vmeson (~quassel@128.224.252.2) |
| 14:11.27 | *** join/#oe andre_d (~andre_d@164.129.115.76) |
| 14:15.01 | *** join/#oe jkridner (~jkridner@c-68-43-104-104.hsd1.mi.comcast.net) |
| 14:15.01 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 14:27.04 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 14:33.39 | *** join/#oe tgall_foo (~tgall@70.35.96.184) |
| 14:33.39 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 14:34.18 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 14:55.14 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 15:01.54 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 15:26.40 | Crofton|work | rburton, what do you needa native numpy recipe for? |
| 15:28.09 | rburton | Crofton|work: piglit |
| 15:28.14 | rburton | just sent that bit |
| 15:28.34 | rburton | oh, hm, maybe that configure hackery needs to be class-target only |
| 15:29.27 | rburton | piglit is funny, check out the license statement |
| 15:29.29 | Crofton|work | weird, just seemed odd to me :) |
| 15:29.59 | rburton | piglit generates vast numbers of tests at compile time use mako and numpy |
| 15:31.08 | koen | stabs numpy |
| 15:31.52 | rburton | koen: agreed |
| 15:32.29 | koen | I hate how you have to uninstall things like BLAS from your host to get it to build |
| 15:32.35 | koen | then again, it's a python module |
| 15:33.58 | rburton | koen: your "ugly ugly hack" in numpy's configure_prepend would need to be made target-only if the recipe was nativeized, right? |
| 15:34.00 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 15:35.43 | koen | I think so |
| 15:36.28 | *** join/#oe roric (~roric@c-919f70d5.013-177-67626713.cust.bredbandsbolaget.se) |
| 15:39.51 | *** join/#oe blilly (~blilly1@c-67-161-99-149.hsd1.wa.comcast.net) |
| 15:44.40 | *** join/#oe hollisb (~hollisb@nat-dem.mentorg.com) |
| 15:49.20 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 16:01.08 | *** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk) |
| 16:03.54 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 16:13.09 | *** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au) |
| 16:16.42 | *** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au) |
| 16:20.46 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 16:23.56 | *** join/#oe hollisb (~hollisb@nat-dem.mentorg.com) |
| 16:34.40 | *** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk) |
| 16:40.28 | *** join/#oe zenlinux_ (~sgarman@c-24-20-145-95.hsd1.or.comcast.net) |
| 16:43.13 | ndec | rburton: hi, i see you mentioned piglit... are you working on a recipe for piglit? |
| 16:44.12 | *** join/#oe lumag_ (~lumag@ppp89-110-13-128.pppoe.avangarddsl.ru) |
| 16:44.19 | Crofton|work | apparently he sent it in already |
| 16:44.54 | rburton | ndec: sent to meta-oe already |
| 16:45.20 | *** join/#oe KNERD (~KNERD@cpe-68-203-231-86.gt.res.rr.com) |
| 16:46.54 | ndec | oh. ok. i will check the list. |
| 16:55.16 | dv_ | koen: agreed on the numpy issue |
| 16:55.29 | dv_ | problem: opencv seems to have a dependency on numpy |
| 16:57.23 | *** join/#oe kristoffer (~kristoffe@c-e9dce555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 16:57.41 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 16:58.07 | *** join/#oe nitink (~nitink@134.134.139.74) |
| 16:58.14 | *** join/#oe rob_w (~rob@ppp-88-217-92-14.dynamic.mnet-online.de) |
| 16:58.19 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 17:02.44 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 17:07.12 | *** join/#oe mihai (~mihai@80.97.15.150) |
| 17:12.17 | *** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk) |
| 17:14.41 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 17:14.48 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 17:17.18 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 17:22.47 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 17:24.21 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 17:24.58 | *** join/#oe ftonello (~felipe@wsip-70-183-20-162.oc.oc.cox.net) |
| 17:33.54 | *** join/#oe tgall_foo (~tgall@70.35.96.184) |
| 17:33.54 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 17:40.11 | *** join/#oe RP_ (~richard@93-97-173-237.zone5.bethere.co.uk) |
| 17:44.29 | *** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk) |
| 17:47.17 | *** join/#oe mr_science (~sarnold@net-cf9a4e93.cst.impulse.net) |
| 17:47.18 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 18:01.14 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 18:05.50 | *** join/#oe woglinde (~henning@89.204.135.176) |
| 18:17.33 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 18:29.18 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 18:53.38 | *** join/#oe jgi (~textual@173.231.104.26) |
| 18:54.32 | jgi | hi everyone |
| 18:54.49 | jgi | I built a new kernel with some drivers compiled as modules instead of as built-in |
| 18:55.36 | jgi | however, when bitbake generates ipk packages for the kernel and for the kernel modules, the kernel package doesn't depend on the kernel modules |
| 18:55.46 | jgi | is there a way to do this? |
| 18:56.24 | *** join/#oe hillct (~hillct@cpe-071-070-208-078.nc.res.rr.com) |
| 18:58.06 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 19:02.57 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 19:03.27 | mr_science | jgi: RDEPEND_${PN} maybe? |
| 19:03.35 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 19:04.10 | jgi | mr_science: yes, but I'd like the dependencies to be generated automatically, as there are thousands of modules packages |
| 19:04.41 | kergoth | jgi: it generate sa kernel-modules package. if you want all the modules, install that |
| 19:04.41 | JaMa | jgi: use "kernel-modules" which pulls all of them |
| 19:04.49 | mr_science | haven't really looked at that much yet, so ... |
| 19:04.55 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
| 19:04.55 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 19:04.58 | JaMa | kergoth: :) |
| 19:05.01 | kergoth | :) |
| 19:05.50 | JaMa | damn, you should write that smile 3 seconds later :) |
| 19:06.00 | JaMa | s/you/I/ |
| 19:06.00 | jgi | JaMa, kergoth: ok, now will kernel-modules only contain the modules I configured as modules in my defconfig file? Or will it contain all modules, even those that I chose not to use? |
| 19:06.12 | mr_science | in poky all i've done so far is extend the kernel config to enable rt_group_sched |
| 19:06.25 | mr_science | should play around with that more |
| 19:06.30 | JaMa | jgi: only enabled in defconfig |
| 19:06.40 | JaMa | jgi: other modules aren't built so cannot be included |
| 19:07.14 | jgi | JaMa, kergoth: excellent, that should be good enough |
| 19:07.26 | jgi | JaMa, kergoth, mr_science: thank you guys for your input! |
| 19:07.27 | kergoth | jgi: kernel-modules deps are dynamically generated, when it splits up the kernel-module-* packages |
| 19:07.31 | kergoth | np |
| 19:08.08 | jgi | another question: IIRC, kernel doesn't depend on kernel-modules, why is that? |
| 19:08.22 | JaMa | jgi: sane default :) |
| 19:08.44 | JaMa | people like smaller images and "extra" modules can be installed with package manager |
| 19:09.25 | JaMa | machine configs can also add few more mandatory modules to RRECOMMENDS |
| 19:09.58 | JaMa | e.g. om-gta02.conf:MACHINE_EXTRA_RRECOMMENDS = " ... " |
| 19:10.02 | kergoth | it's the same reason we provide such granular packaging to begin with. more control |
| 19:10.13 | kergoth | and flexibility, for that matter |
| 19:13.14 | jgi | ok but then if I configure my new kernel to load a bunch of drivers as modules, I have to make sure, using custom code, that these modules will be installed when I create the image or if someones install the new kernel package |
| 19:20.54 | jgi | kergoth, JaMa: is that the way to do this? I just want to make sure I'm using it as designed |
| 19:22.04 | jgi | kergoth, JaMa: my use case is that I upgrade the system remotely, without user interaction. If I upgrade the kernel package, I want to make sure all potential new modules dependencies are installed as well. |
| 19:23.18 | jgi | kergoth, JaMa: upgrading kernel *and* kernel-modules every time is good enough for me. Adding an additional dependency between kernel and kernel-modules as you mentioned would be fine too |
| 19:26.14 | kergoth | I'd suggest upgrading both, to reduce the delta between what you h ave and upstream, but either would do |
| 19:27.51 | *** join/#oe zenlinux (~sgarman@masterfoo.zenlinux.com) |
| 19:28.44 | jgi | kergoth: that's a good point |
| 19:29.17 | jgi | kergoth, JaMa: thank you again guys, it should allow me to get the ball rolling |
| 19:29.18 | kergoth | the less yo have to maintain yourself in the long term, but lighter your overhead, and the less you have to bring forward every time you upgrade :) |
| 19:29.34 | kergoth | is always trying to minimize our layers, not always successfully |
| 19:34.05 | *** join/#oe florian (~fuchs@sign-4db607bf.pool.mediaWays.net) |
| 19:34.06 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:34.28 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 19:45.52 | *** join/#oe phdeswer (~phdeswer@a88-113-94-60.elisa-laajakaista.fi) |
| 19:45.52 | *** join/#oe espiral (maze@unaffiliated/espiral) |
| 19:50.32 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 20:01.03 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 20:10.34 | *** join/#oe hollisb (~hollisb@80-110-35-42.static.surfer.at) |
| 20:11.23 | pb_ | stabs rm_work |
| 20:12.24 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:13.37 | woglinde | pb stab it hard |
| 20:13.54 | pb_ | yeah |
| 20:14.30 | pb_ | tries to think of an easy way to disable it |
| 20:14.38 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 20:15.08 | pb_ | I guess I could just add an environment variable to turn it off, or something. |
| 20:16.46 | kergoth | i'm guessing you don't want to remove the inherit due tot he change to the task graph? |
| 20:17.08 | pb_ | yeah, ideally not. |
| 20:17.43 | pb_ | also, it's inherited from a file that we keep under revision control, and it's a pain for me to keep carrying around a local modification to that. |
| 20:18.10 | pb_ | have to stash every time I want to rebase, and remember to unstash afterwards (which inevitably I forget), etc |
| 20:18.50 | kergoth | if on dora or newer, could always use INHERIT_remove |
| 20:18.58 | pb_ | oh yes, right |
| 20:18.58 | kergoth | but thats a fair point, i hate keeping around local modimfications too |
| 20:19.08 | JaMa | pb_: what's wrong when using it? |
| 20:19.21 | kergoth | thats assuming bitbake does a finalize on the config metadata boefre it grabs INHERIT :) |
| 20:19.48 | pb_ | JaMa: it deletes all the files that I want to look at :-} |
| 20:19.58 | JaMa | ok :) |
| 20:24.15 | *** join/#oe brm (da653619@gateway/web/freenode/ip.218.101.54.25) |
| 20:24.34 | brm | Hi Guys, anyone have experience with cannman and wifi |
| 20:26.21 | brm | I have to do an "ifup wlan0" to get the interface up, i should not have to right? |
| 20:27.11 | brm | sorry that's "connman" not cannman |
| 20:29.23 | *** join/#oe silviof1 (~silviof@unaffiliated/silviof) |
| 20:29.41 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 20:29.54 | pb_ | hm, this stupid kernel.do_populate_sysroot problem still plagues me |
| 20:30.22 | pb_ | or, more accurately, it plagues my jenkins. if only I could make it happen in my local builds I guess I would have more chance of debugging it. |
| 20:31.08 | pb_ | sort of seems like it's got to be a bitbake bug, maybe I should try bisecting it. |
| 20:32.38 | *** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk) |
| 20:37.23 | kergoth | man, i hate issues like that. we have one of those, at random, only for jenkins, bitbake doesn't pick up the correct vardeps for a shel function and then edoesn't emit functions it needs to run :| |
| 20:37.30 | JaMa | pb_: something like this one? |
| 20:37.31 | JaMa | Exception: OSError: [Errno 2] No such file or directory: '/OE/build/oe-core/tmp-eglibc/work/qemux86_64-oe-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/image/usr/src/kernel' |
| 20:37.59 | JaMa | <PROTECTED> |
| 20:37.59 | pb_ | JaMa: yeah, very like that. seems that bitbake is running do_populate_staging without having done do_install first. |
| 20:38.39 | JaMa | I have it quite often lately on one builder |
| 20:38.43 | pb_ | kergoth: yeah, we've had a few like that. total pita. |
| 20:38.53 | JaMa | and you're right, last task finished before do_populate_sysroot is do_compile |
| 20:40.00 | pb_ | yeah, exactly. if you check "bitbake g", it has do_install as a dependency. but, of course, when I run bitbake by hand it works, so it's unclear whether the -g output matches what jenkins is actually seeing. |
| 20:40.25 | kergoth | yikes, that's worrisome, that shouldn't even be possible |
| 20:40.34 | pb_ | it only happens with the kernel, which is weird. |
| 20:41.02 | pb_ | since, afaict, the kernel doesn't do anything very special with staging. |
| 20:42.08 | kergoth | bitbake's complexity makes debugging such things hard. it's tough to hold a sufficient mental model without nicer abstraction layers, imo |
| 20:42.16 | kergoth | heh |
| 20:42.21 | pb_ | as far as I can see, there is only one place in the system that does "addtask do_populate_sysroot" (in staging.bbclass) and that one does clearly as "... after do_install". |
| 20:42.28 | dv_ | do I hear a desire to clean up bitbake? |
| 20:42.37 | pb_ | kergoth: right |
| 20:42.56 | pb_ | the code that deals with runqueues and dependencies is quite impenetrable |
| 20:43.51 | pb_ | it's not hard to believe that there might be bugs, but the ay it's written makes it quite hard to say where they might be. |
| 20:43.55 | kergoth | it's one thing if something is reproducible, but if not, you need to be able to examine the paths in your head and come up with possible causes |
| 20:43.58 | kergoth | nods |
| 20:44.34 | dv_ | it kinda makes sense that such type of code can easily become unreadable |
| 20:44.52 | pb_ | yeah |
| 20:45.00 | dv_ | since it involves a nontrivial amount of thread synchronization and dependency tracking |
| 20:45.16 | pb_ | one day last week I was seriously considering starting an effort to rewrite bitbake in C++ or something |
| 20:45.31 | dv_ | hear, hear. c++ to make it clearer :D |
| 20:46.00 | dv_ | (although c++11 can be quite readable, if used correctly..) |
| 20:46.54 | pb_ | yeah. well, it was mostly bitbake's slow performance that was irking me on that particular day, though I suspect in reality that the metadata now outweighs bitbake itself in terms of number of lines of python code that get executed during a build |
| 20:47.18 | kergoth | Oh I feel like that pretty often too, usually at the end of the day, just want to throw it out a window and start again |
| 20:47.36 | dv_ | of course, with c++ you have the problem that you need to build something |
| 20:47.51 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 20:47.52 | pb_ | well, that's what we have gcc for. |
| 20:48.25 | pb_ | and, after all, gcc itself is c++ nowadays. whatever's good enough for those guys is good enough for us, I guess. |
| 20:48.49 | kergoth | Go might a decent option too |
| 20:48.58 | dv_ | mentions D |
| 20:49.34 | pb_ | Go would be cute, but I don't think you can rely on everyone having it installed. |
| 20:49.37 | kergoth | Recently I've been mulling over the possibility of just replacing a particular component. I want to create a standalone fetch tool that do_fetch calls to do the heavy lifting, and ditch our legacy fetch bits from bitbake entirely |
| 20:49.51 | kergoth | true, but you could always distribute binaries, they're static after all |
| 20:49.55 | kergoth | lots of options |
| 20:50.06 | pb_ | and, of course, some people might fear that using go will mean that google owns all their source code. |
| 20:50.15 | kergoth | language really isn't the important bit, i think, so much as giving more thought to the design up front |
| 20:50.30 | pb_ | yeah |
| 20:50.49 | kergoth | what bugs me most is how intertwined the components and modules are |
| 20:50.55 | kergoth | it makes it tough to evolve over time |
| 20:51.21 | kergoth | maybe we could focus on separating and making bitbake's pieces more self contained, and then we could replace bits piecemeal easier |
| 20:51.29 | dv_ | I actually think D would be a nice choice here. its a very powerful language, native execution, garbage collector, very flexible, suffers from the chicken-egg syndrom atm |
| 20:51.37 | mr_science | pb_: i own pretty much all of our jenkins builds, but it's oe-classic |
| 20:51.47 | kergoth | ponders |
| 20:52.00 | mr_science | if you have some data to look at i can take a look later |
| 20:52.02 | pb_ | kergoth: yeah, that's certainly true also. |
| 20:52.26 | pb_ | mr_science: if you're on oe-classic then I doubt you would see the same issue. |
| 20:52.26 | kergoth | it'd make it much easier to wrap our heads around, too. god, try separating cooker/runqueue/taskdata sometime |
| 20:52.29 | kergoth | shudders |
| 20:53.03 | mr_science | possibly, but hard (for me) to know with more info |
| 20:53.27 | kergoth | my problem is, when i start thinking about things like this, there's this dillemma about whether to just replace it with something entirely compatible, evole it, or change how it works in a more fundamental way |
| 20:53.32 | pb_ | that do_populate_sysroot thing only started happening with my most recent update of bitbake and oe-core. we've been using oe-core for years (literally) prior to that without seeing it. |
| 20:53.38 | dv_ | kergoth: is bitbake the no.1 problem in oe these days? |
| 20:53.39 | mr_science | i have both a jenkins "job" script and a separate build script for each one |
| 20:53.41 | kergoth | for example, i love that oe-lite has packages as the primary artifact, and the binary pakcages are used to construct the sysroots |
| 20:53.49 | mr_science | the only one that |
| 20:54.03 | kergoth | dv_: that's tough to say, i think, there's a lot of pieces involved |
| 20:54.05 | dv_ | kergoth: a drop-in replacement makes more sense |
| 20:54.08 | mr_science | 's weird is the sdk build (wihtout building an image first) |
| 20:54.46 | dv_ | but assume you write such a replacement in c++, or go, or d, or whatever. how do you deal with the python blocks inside the recipes? |
| 20:54.50 | kergoth | dv_: another thing i'd like to see, is removing some of the bitbake implementation details from the metadata. avoid using addtask in recieps and the like, and instead provide more hooks between tasks up front, so the recipes can be more declarative. just define variables nad functions and that's it |
| 20:55.00 | kergoth | well, python is quite embeddable, it'd be doable |
| 20:55.07 | pb_ | kergoth: right, that rocks. on the other hand, as I've started to get more sensitive to build time, I've started to go off the idea of either doing per-recipe sysroots or building the sysroot from packages. |
| 20:55.14 | mr_science | well, that part sounds reasonable |
| 20:55.17 | dv_ | ok, in c++ there is boost.python for example ... (although I am not a fan of involving too much of boost) |
| 20:55.57 | mr_science | if you have time to describe your build setup at some point, maybe we can come up with a decent workaround |
| 20:56.14 | mr_science | if it doesn't solve itself after an update... |
| 20:56.54 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 20:57.01 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 20:58.58 | *** join/#oe fray (~fray@gate.crashing.org) |
| 21:00.59 | mr_science | damn, i set the trap in the other channel... |
| 21:04.21 | *** join/#oe slapin (~slapin@slapinbuild.ihdev.net) |
| 21:07.27 | *** join/#oe tgall (~tgall@70.35.96.184) |
| 21:07.27 | *** join/#oe tgall (~tgall@linaro/tgall-foo) |
| 21:08.00 | *** join/#oe dvhart (dvhart@nat/intel/x-nugbdhqehpvkmati) |
| 21:08.08 | *** join/#oe tgall_foo (~tgall@70.35.96.184) |
| 21:08.19 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 21:16.30 | *** join/#oe pespin (~pespin@62.pool85-61-255.dynamic.orange.es) |
| 21:25.47 | *** join/#oe tgall (~tgall@70.35.96.184) |
| 21:25.47 | *** join/#oe tgall (~tgall@linaro/tgall-foo) |
| 21:31.00 | pb_ | how tiresome, just broke another phone. I seem to be getting through them at quite a rate just now. |
| 21:31.12 | pb_ | if this carries on I'm going to have to exhume my openmoko gta01 or something. |
| 21:32.37 | mr_science | damn, i'll trade you three phones fro that one... |
| 21:32.42 | mr_science | *for |
| 21:36.34 | *** join/#oe mihai (~mihai@86.126.1.251) |
| 21:43.08 | *** join/#oe lumag_ (~lumag@ppp89-110-13-128.pppoe.avangarddsl.ru) |
| 21:44.41 | *** join/#oe bluelightning (~paul@167.127.187.81.in-addr.arpa) |
| 21:44.41 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:48.48 | *** join/#oe zenlinux (~sgarman@masterfoo.zenlinux.com) |
| 22:02.38 | *** join/#oe vmeson (~quassel@128.224.252.2) |
| 22:04.16 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 22:04.40 | *** join/#oe GusBricker (~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au) |
| 22:10.55 | *** join/#oe ant_home (~andrea@host39-62-dynamic.24-79-r.retail.telecomitalia.it) |
| 22:14.15 | *** join/#oe NightMonkey (~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) |
| 22:14.15 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 22:30.29 | *** join/#oe tgall (~tgall@70.35.96.184) |
| 22:30.29 | *** join/#oe tgall (~tgall@linaro/tgall-foo) |
| 22:32.26 | *** join/#oe shoragan (~jlu@debian/developer/shoragan) |
| 22:36.05 | *** join/#oe kuldeepdhaka (~kuldeepdh@117.254.222.1) |
| 22:39.08 | *** join/#oe kuldeepdhaka (~kuldeepdh@117.254.222.1) |
| 23:01.31 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 23:07.34 | *** join/#oe jkridner (~jkridner@c-98-250-142-42.hsd1.mi.comcast.net) |
| 23:07.34 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 23:10.54 | *** join/#oe jkridner (~jkridner@c-98-250-142-42.hsd1.mi.comcast.net) |
| 23:10.54 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 23:16.01 | *** join/#oe _chase_ (~a0271661@nat/ti/x-zffmlqhsjtmwymrm) |