| 00:02.50 | *** join/#oe _julian_ (~quassel@hmbg-4d06ee62.pool.mediaWays.net) |
| 00:06.53 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 00:07.32 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:16.05 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:23.37 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:31.42 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:37.42 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 00:41.15 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:48.58 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:51.11 | *** join/#oe openfree (~dennis@116.228.88.131) |
| 00:58.51 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 00:59.42 | *** join/#oe _julian (~quassel@hmbg-5f77e8ba.pool.mediaWays.net) |
| 01:08.06 | *** join/#oe ynezz (ynezz@ibawizard.net) |
| 01:45.18 | *** join/#oe methril (~methril@189.27.132.143.dynamic.adsl.gvt.net.br) |
| 02:01.46 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 02:02.38 | *** join/#oe lamawithonel (~lucas@pool-96-240-135-33.washdc.fios.verizon.net) |
| 02:04.57 | *** join/#oe devzero_ (devzero@xdsl-78-35-59-152.netcologne.de) |
| 02:20.23 | *** join/#oe zenlinux_ (~sgarman@c-76-105-143-140.hsd1.or.comcast.net) |
| 02:34.55 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 02:36.10 | *** join/#oe rickfoosusa (~chatzilla@99.179.103.49) |
| 03:07.40 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:17.25 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:19.10 | *** join/#oe tdebrouw` (~tdebrouw@91.182.185.247) |
| 03:27.59 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:35.08 | *** join/#oe mrc3 (~ddiaz@189.157.115.88) |
| 03:36.32 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 03:37.30 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:45.35 | *** join/#oe SidH_ (~SidH_@203.101.61.7) |
| 03:45.37 | *** join/#oe lamawithonel (~lucas@pool-96-240-135-33.washdc.fios.verizon.net) |
| 03:46.34 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:56.35 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 03:58.29 | *** join/#oe kannerke (~pvandenb@83.101.83.180) |
| 04:01.04 | *** join/#oe morphis|sport (~morphis@dslb-088-070-159-236.pools.arcor-ip.net) |
| 04:07.38 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 04:09.03 | *** join/#oe kannerke (~pvandenb@83.101.83.180) |
| 04:15.11 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 04:19.04 | *** join/#oe kannerke (~pvandenb@83.101.83.180) |
| 04:29.45 | *** join/#oe kannerke (~pvandenb@83.101.83.180) |
| 04:30.50 | *** join/#oe tasslehoff (~Tasslehof@145.79-161-31.customer.lyse.net) |
| 04:32.00 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 04:34.18 | *** join/#oe SidH_ (~SidH_@203.101.61.7) |
| 04:41.51 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 04:44.41 | *** part/#oe tasslehoff (~Tasslehof@145.79-161-31.customer.lyse.net) |
| 04:48.50 | *** join/#oe SidH_ (~SidH_@203.101.61.7) |
| 04:51.25 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 04:52.57 | *** join/#oe SidH_ (~SidH_@203.101.61.7) |
| 04:54.59 | *** join/#oe duffolonious (~bryan@75-168-75-91.mpls.qwest.net) |
| 04:57.10 | *** join/#oe SidH_ (~SidH_@203.101.61.10) |
| 05:10.42 | *** join/#oe jmpdelos (~polk@cerberus.delos.com) |
| 05:17.28 | *** join/#oe zecke (~ich@91-64-83-241-dynip.superkabel.de) |
| 05:23.07 | *** join/#oe toi (~peter@vrt.nat.ibbt.be) |
| 05:24.33 | *** join/#oe veganadian (~andrew@CPE0013f7b6cfd2-CM0013f7b6cfce.cpe.net.cable.rogers.com) |
| 05:28.51 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 05:34.02 | *** join/#oe openfree (~dennis@116.228.88.131) |
| 05:42.09 | *** join/#oe veli_ (c31df212@gateway/web/freenode/ip.195.29.242.18) |
| 05:45.51 | *** join/#oe rsalveti (~rsalveti@business-89-133-214-120.business.broadband.hu) |
| 05:46.17 | *** join/#oe mrc3 (~ddiaz@189.157.113.140) |
| 05:46.39 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 05:50.09 | *** join/#oe risca (~risca@130.236.250.26) |
| 05:54.39 | *** join/#oe zecke (~ich@91-64-83-241-dynip.superkabel.de) |
| 05:56.56 | *** join/#oe rickfoosusa (~chatzilla@99.179.103.49) |
| 05:58.14 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 06:00.05 | *** join/#oe kannerke (~pvandenb@83.101.12.36) |
| 06:05.06 | *** join/#oe vanner_ (~vanner_@nat2.rnd.stcnet.ru) |
| 06:08.31 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 06:10.22 | *** join/#oe kannerke (~pvandenb@83.101.12.36) |
| 06:12.47 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 06:20.18 | *** join/#oe kannerke (~pvandenb@83.101.12.36) |
| 06:26.36 | *** join/#oe tws (~Miranda@178.120.59.180) |
| 06:30.13 | *** join/#oe kannerke (~pvandenb@83.101.12.36) |
| 06:51.29 | *** join/#oe timtimred (~meh@85.210.138.180) |
| 06:54.18 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
| 06:54.18 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 07:03.04 | bluelightning | morning all |
| 07:08.52 | *** join/#oe rsalveti (~rsalveti@conference/ubuntudevelopersummit/x-afeaxklbckwnqtsr) |
| 07:13.37 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:16.50 | *** join/#oe kannerke (~pvandenb@83.101.12.83) |
| 07:20.47 | *** join/#oe kannerke (~pvandenb@83.101.12.83) |
| 07:22.48 | *** join/#oe roza (~ron@nat/cisco/x-orboakfxfevdqnka) |
| 07:29.15 | *** join/#oe lamikr (~lamikr@192.100.124.156) |
| 07:30.16 | *** join/#oe rob_w (~bob@ppp-188-174-64-141.dynamic.mnet-online.de) |
| 07:31.42 | *** join/#oe kannerke (~pvandenb@83.101.12.83) |
| 07:32.24 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 07:34.55 | *** join/#oe rsalveti (~rsalveti@conference/ubuntudevelopersummit/x-tmvvttqsxgeorjdu) |
| 07:41.14 | *** join/#oe kannerke (~pvandenb@83.101.12.83) |
| 07:45.14 | *** join/#oe florian (~fuchs@217.237.167.130) |
| 07:45.14 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:46.58 | hrw | florian: how goes LT? |
| 07:48.25 | *** join/#oe pespin (~pespin@cisne-cn10.upc.es) |
| 07:48.37 | florian | hi hrw |
| 07:49.05 | florian | hrw: so far not too bad - the first day was comparably quiet as always |
| 07:49.22 | florian | but not that quiet that we could feel bored :) |
| 07:50.01 | hrw | ;D |
| 07:50.07 | hrw | florian: does wrt54gs works? |
| 07:57.46 | florian | hrw: we didn't try it so far :-} we have an official ap ~1m from our table |
| 07:58.11 | hrw | nice |
| 07:59.39 | hrw | wow - checked when I bought that router... 6 years ago: http://marcin.juszkiewicz.com.pl/2005/06/07/i-got-wrt54gs/ |
| 07:59.47 | florian | :-) |
| 08:00.04 | florian | is there some oe based image installed? :) |
| 08:00.21 | hrw | nope |
| 08:00.31 | hrw | never got time to experiment with such |
| 08:03.28 | mckoan | good morning |
| 08:11.29 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 08:12.52 | florian | hi mckoan |
| 08:22.55 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:25.11 | *** join/#oe unclewerner (~unclewern@host-88-217-163-202.customer.m-online.net) |
| 09:01.23 | *** join/#oe GunsNRose (~GunsNRose@113.104.188.69) |
| 09:02.58 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 09:02.59 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:04.14 | *** join/#oe mr_nice (~nice@217.237.167.130) |
| 09:12.12 | *** join/#oe morphis (~morphis@ip-109-40-188-101.web.vodafone.de) |
| 09:18.37 | *** join/#oe zecke (~ich@91-64-83-241-dynip.superkabel.de) |
| 09:21.03 | pb_ | hi zecke, florian, all |
| 09:50.30 | florian | hi pb_ |
| 09:56.00 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 09:59.17 | *** join/#oe dm8tbr (dm8tbr@gw.bfst.de) |
| 10:06.05 | *** join/#oe obi_ (~obi@unaffiliated/obi) |
| 10:31.50 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 10:50.13 | *** join/#oe nitink (~nitink@nat/intel/x-nqxagjhobuzfzsuo) |
| 10:59.56 | *** join/#oe guest6287 (~aarti@122.166.11.13) |
| 11:00.36 | guest6287 | hi all , in temp folder m getting error tht no space left on device.. how can i solve this? |
| 11:01.02 | pb_ | get a bigger hard disk? |
| 11:01.06 | pb_ | or delete some files, perhaps |
| 11:01.52 | guest6287 | pb_, frm temp only? |
| 11:02.25 | pb_ | well, it depends how you have your system set up. it might be sharing a device with other files, or it might not. |
| 11:03.15 | guest6287 | pb_, ok |
| 11:08.12 | *** join/#oe amarsman_nl (~marsman@reehorst11.customer.bit.nl) |
| 11:11.50 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 11:13.08 | pb_ | hi mickey |
| 11:14.09 | *** join/#oe GarthPS (~quassel@166.171.100.84.rev.sfr.net) |
| 11:14.34 | *** join/#oe wondiws (~westwood@ip51cdb28e.speed.planet.nl) |
| 11:40.17 | *** join/#oe risca (~risca@130.236.250.26) |
| 11:54.00 | *** join/#oe GNUtoo (~GNUtoo@host29-10-dynamic.54-79-r.retail.telecomitalia.it) |
| 11:55.23 | GNUtoo | hi, I've the following do_rootfs errors: http://pastie.org/1892780 |
| 11:55.39 | *** join/#oe darknighte (~darknight@unaffiliated/darknighte) |
| 11:55.39 | GNUtoo | distro: angstrom2010 under org.openembedded.dev |
| 11:56.11 | GNUtoo | for dnsmasq I'll look |
| 12:01.09 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 12:01.59 | GNUtoo | note that it worked before |
| 12:02.02 | GNUtoo | I've old images |
| 12:02.10 | davidlt | All my do_postinst does not work on the first boot. |
| 12:03.44 | GNUtoo | that's not the first boot |
| 12:03.47 | *** join/#oe guest6287 (~aarti@122.166.11.13) |
| 12:03.47 | GNUtoo | that's do_rootfs |
| 12:03.54 | GNUtoo | (for my problem) |
| 12:04.37 | JaMa | GNUtoo: dnsmasq-dbus is now in connman rdepends |
| 12:04.53 | davidlt | I just joined, don't know your problem |
| 12:05.06 | GNUtoo | yes I just saw it with bigbke -g |
| 12:05.09 | GNUtoo | *bitbake |
| 12:05.17 | GNUtoo | JaMa, I'm mostly wondered about the rest |
| 12:05.22 | JaMa | so something in task-bug-network pulls conflicting dnsmasq |
| 12:05.52 | GNUtoo | I know that |
| 12:05.56 | GNUtoo | I've fixed already |
| 12:06.04 | GNUtoo | it's connman indeed |
| 12:06.10 | JaMa | ok |
| 12:06.15 | GNUtoo | but there are other errors such as: |
| 12:06.24 | GNUtoo | <PROTECTED> |
| 12:06.31 | GNUtoo | <PROTECTED> |
| 12:07.16 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 12:07.53 | GNUtoo | <PROTECTED> |
| 12:14.08 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 12:14.38 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:16.08 | *** join/#oe dm8tbr (dm8tbr@gw.bfst.de) |
| 12:20.20 | *** join/#oe GarthPS (~quassel@166.171.100.84.rev.sfr.net) |
| 12:20.32 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 12:25.46 | *** join/#oe peter_h_ (~phanger@pc81-146.ict.tuwien.ac.at) |
| 12:28.05 | davidlt | which package would be the best as example for command execution on the first boot? |
| 12:30.05 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 12:33.10 | *** join/#oe darknighte (~darknight@darknighte.xen.prgmr.com) |
| 12:33.10 | *** join/#oe darknighte (~darknight@unaffiliated/darknighte) |
| 12:34.22 | GNUtoo | JaMa, sorry it fix the other errors too.... |
| 12:34.28 | GNUtoo | *fixed |
| 12:34.40 | GNUtoo | it's just that do_rootfs take a huge time on my laptop |
| 12:40.34 | davidlt | Okay, I can't get it to run my commands on the first boot |
| 12:40.43 | davidlt | Here is how postinst looks like: http://pastebin.com/Naa787ic |
| 12:40.52 | davidlt | Any hints why it's not working? |
| 12:41.08 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 12:42.30 | eFfeM_work | davidlt: as as starter I would add an else to the if test with an echo, also i would redirect the echo to e.g. /tmp/mylog |
| 12:42.56 | eFfeM_work | so you know if you get into the then or into the else |
| 12:43.11 | *** join/#oe rphillips (~rphillips@unaffiliated/rphillips) |
| 12:43.44 | davidlt | In the real recipe I have part of code which is executed on rootfs and the rest, few lines should be on first boot. |
| 12:44.00 | davidlt | The lines on rootfs is executed. |
| 12:46.04 | *** join/#oe Darthy (~kvirc@p579A9B5E.dip.t-dialin.net) |
| 12:47.40 | *** join/#oe rphillips (~rphillips@unaffiliated/rphillips) |
| 12:48.42 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 12:49.09 | *** join/#oe woglinde (~woglinde@217.237.167.130) |
| 12:58.44 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 13:07.34 | *** join/#oe GarthPS (~quassel@166.171.100.84.rev.sfr.net) |
| 13:08.33 | *** join/#oe risca (~risca@c-5af9e253.022-6-6e6b702.cust.bredbandsbolaget.se) |
| 13:09.18 | *** join/#oe dm8tbr (dm8tbr@2001:41b8:0:f010::2) |
| 13:13.52 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 13:18.08 | *** join/#oe rsalveti (~rsalveti@conference/ubuntudevelopersummit/x-dyzyvbchrxcdaexk) |
| 13:18.32 | davidlt | eFfeM_work: "x$D" != x -> on do_rootfs. So it executes 'esle' part on rootfs, but 'then' part on first boot is not executed. |
| 13:19.23 | davidlt | I don't see file in /tmp |
| 13:19.24 | *** join/#oe zecke (~ich@91.64.83.241) |
| 13:22.21 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 13:23.29 | *** join/#oe dm8tbr (dm8tbr@2001:41b8:0:f010::2) |
| 13:25.43 | pb_ | davidlt: your "before" version from the pastebin looks more likely to work. the postinst will only run on the device if it did not "succeed" during image construction. |
| 13:26.53 | davidlt | So if I have else and then |
| 13:27.16 | davidlt | If on then I do part of the stuff and it exits with 0, else part on boot would never be executed? |
| 13:27.46 | davidlt | It would already report that it was okay. |
| 13:28.12 | *** join/#oe B_Lizzard (~havoc@athedsl-119886.home.otenet.gr) |
| 13:28.22 | pb_ | correct |
| 13:28.44 | davidlt | pb_: thanks, almost forgot about that (I think it was written on Poky Handbook) |
| 13:28.57 | pb_ | if you inspect rootfs_ipk.bbclass and look for "postinst" you should be able to find the code that does this. |
| 13:32.22 | davidlt | Okay, one question, upgate-rc.d and crontab, will they work on do_rootfs? |
| 13:33.08 | pb_ | update-rc.d should do, it has special code to arrange that |
| 13:33.12 | pb_ | I don't know about crontab offhand |
| 13:33.34 | *** join/#oe Openfree` (~df@61.173.51.77) |
| 13:33.43 | davidlt | from syslog-ng: |
| 13:33.45 | davidlt | 32 if test "x$D" != "x"; then |
| 13:33.45 | davidlt | <PROTECTED> |
| 13:34.30 | davidlt | But I can't find any info about -r arg. |
| 13:34.51 | pb_ | ah yes, bletch. we should really sort that out. |
| 13:35.22 | davidlt | Should I set it or execute just plain update-rc.d as normally I would do? |
| 13:35.32 | pb_ | right now I think you have to set it. |
| 13:35.36 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 13:35.47 | pb_ | but, there's no reason update-rc.d couldn't (and shouldn't) figure that out for itself. |
| 13:35.57 | pb_ | if you wanted to send a patch for that then it would be even better. |
| 13:37.17 | davidlt | I have some recipes which are not submitted to OE, never had enough time to read all the rules and requirements to do that. But I should do it one day. |
| 13:39.37 | *** join/#oe tdebrouw (~tdebrouw@91.182.185.247) |
| 13:39.55 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 13:45.46 | *** join/#oe rob_w (~bob@188.174.64.141) |
| 13:50.27 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 13:56.12 | *** join/#oe rob_w (~bob@188.174.64.141) |
| 14:00.30 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 14:05.37 | *** join/#oe kergoth_ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:05.47 | *** join/#oe devzero_ (devzero@xdsl-89-0-169-56.netcologne.de) |
| 14:06.56 | pb_ | morning kergoth |
| 14:09.03 | woglinde | he pb |
| 14:09.07 | pb_ | hi woglinde |
| 14:14.27 | *** join/#oe kevinsc (~a0214685@192.94.94.105) |
| 14:16.36 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 14:22.56 | ka6sox-away | morning pb_ |
| 14:23.02 | ka6sox-away | morning woglinde |
| 14:23.04 | pb_ | hi ka6sox-away |
| 14:24.32 | woglinde | hi ka6sox |
| 14:28.11 | ka6sox-away | pb_, I just updated the redmine ticket. |
| 14:30.00 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 14:31.24 | pb_ | ka6sox-away: I think it will always show your own username in that link. Nobody else will be seeing your username there. |
| 14:31.38 | ka6sox-away | okay that was my concern |
| 14:32.04 | pb_ | Try logging out and then revisiting the page. I think you should find that it doesn't mention you anymore. |
| 14:36.46 | *** join/#oe hexor (~thehexa@189-19-251-152.dsl.telesp.net.br) |
| 14:38.31 | pb_ | so, today's random oe-core curiosity question: what is recipes-sato, and why is it "core"? |
| 14:38.47 | GNUtoo | sato is an environment based on matchbox |
| 14:39.05 | GNUtoo | I can make screenshots if you want |
| 14:39.38 | GNUtoo | or maybe it's a matchbox theme |
| 14:39.39 | GNUtoo | not sure |
| 14:39.43 | pb_ | Simon Tatham's Portable Puzzle Collection is no doubt a fine thing but I'm not totally convinced it meets my personal definition of core functionality :-} |
| 14:39.48 | GNUtoo | but it's something graphical that has to do with matchbox |
| 14:39.57 | pb_ | GNUtoo: thanks |
| 14:40.30 | *** join/#oe zenlinux_laptop (~sgarman@masterfoo.zenlinux.com) |
| 14:40.57 | *** join/#oe msm (~msm@99.47.177.27) |
| 14:41.10 | GNUtoo | maybe it's there because of legacy things |
| 14:41.21 | GNUtoo | it was the poky default environment |
| 14:43.44 | *** join/#oe vanner (~vanner@195.91.241.19) |
| 14:43.57 | *** join/#oe Jay7 (jay@95.29.102.204) |
| 14:45.15 | *** join/#oe pespin (~pespin@240.pool85-50-64.dynamic.orange.es) |
| 14:45.31 | *** part/#oe peter_h_ (~phanger@pc81-146.ict.tuwien.ac.at) |
| 14:48.06 | *** join/#oe GunsNRose (~GunsNRose@113.104.188.69) |
| 14:49.32 | otavio | Hello ... |
| 14:50.08 | otavio | I want some guidance about what RP meant with the patch details ... |
| 14:50.14 | otavio | RP__: ?? around? |
| 14:50.41 | otavio | Is someone using linux-yocto? I am in doubt how I do to get a configuration done there |
| 14:52.43 | *** join/#oe rickfoosusa (~chatzilla@99.179.103.49) |
| 14:52.45 | fray | otavio if you are referring to patch/commit message guidelines.. I'm delinquent.. life kicked in. I'm working on hopefully the final revision right now.. |
| 14:53.09 | otavio | fray: you're Saul? |
| 14:53.11 | fray | I can send you the document I have if you are interested.. it will be going to the oe-devel, oe-core, and yocto mailing lists.. |
| 14:53.12 | fray | no |
| 14:53.16 | otavio | ah ok |
| 14:53.40 | fray | Saul is working primarly on the yocto side of things.. but I've incorporated his comments into the document.. they just need further explanation |
| 14:53.53 | jconnolly | is interested in that document |
| 14:54.24 | fray | I'm happy to send the 4th revision to anyone.. I just didn't send it out to the lists because I got a bunch of immediate feedback, causing me to want to do a 5th before sending it.. |
| 14:54.33 | fray | msg me an email address and I'll forward it ASAP |
| 14:55.07 | fray | (or wait, and I'll have 5th rev done in a few hours.. I hope) |
| 15:00.55 | *** join/#oe hollisb (~hollisb@24.20.193.174) |
| 15:07.15 | *** join/#oe kristoffer (~kristoffe@host-78-79-20-145.mobileonline.telia.com) |
| 15:09.15 | *** join/#oe xqvp43 (~xqvp43@115.195.143.55) |
| 15:19.00 | *** join/#oe msm (~msm@192.88.168.35) |
| 15:20.30 | *** join/#oe woglinde (~woglinde@217.237.167.130) |
| 15:21.22 | *** join/#oe rsalveti (~rsalveti@conference/ubuntudevelopersummit/x-rtaazpajklrqkels) |
| 15:22.41 | ericben | otavio: hi. Concerning QT4 trnaslations : I think this also doesn't work with 4.6.3 : can you confirm ? |
| 15:23.40 | otavio | ericben: I am using it but from an old snapshot of oe |
| 15:23.59 | otavio | ericben: our product is being ported to new oe and this has been found due that |
| 15:24.37 | ericben | otavio: ok because there is the same sed in 4.6.3 |
| 15:24.45 | ericben | otavio: I'm working on a global fix |
| 15:25.03 | otavio | ericben: that would be great |
| 15:25.04 | ericben | otavio: but I'm only testing on 4.7 for now |
| 15:25.08 | otavio | ericben: this is a blocker for me. |
| 15:25.38 | ericben | otavio: actually this is a blocker for the CPU of my build server qt is quite long to build :-) |
| 15:25.42 | otavio | ericben: one thing you might look is also about doing the same on oe-core. The diff between oe-core and meta-oe is really small (basically database backend support) |
| 15:26.20 | ericben | otavio: I'can't look at oe-core until 2 or 3 month but the fix may be easily ported to oe-core by people using it actually |
| 15:26.43 | otavio | ericben: OK; I can look at doing that |
| 15:27.02 | otavio | ericben: I also want to port the qt4-native change since it is another issue I want fixed. |
| 15:28.28 | bluelightning | otavio: well, I did make quite a lot of cleanups in the qt4 recipes in oe-core |
| 15:28.37 | bluelightning | am currently testing update to 4.7.3 here |
| 15:28.45 | mickey|office | bluelightning: excellent, please keep us posted |
| 15:29.10 | bluelightning | I saw Tom's message about other arches so I'm trying with MACHINE=qemumips atm |
| 15:29.39 | bluelightning | for x86-64, the x11 and embedded variants of 4.7.3 both built just fine |
| 15:30.15 | zecke | mickey|office: will yoi be in berlin tomorrow? |
| 15:30.39 | msm | hi all.. i've seen some discussion bitbake return codes being weird based on QA issues, etc⦠is there any easy way to determine the status of the build? like 'bitbake status' would return something like pass, build error, qa issue, etc? |
| 15:30.47 | otavio | bluelightning: you might port the qt4-native fixes too |
| 15:30.56 | otavio | bluelightning: this is quite important and trivial IMO |
| 15:31.05 | bluelightning | otavio: I saw those but have not yet investigated |
| 15:31.15 | bluelightning | am curious about this libs/tools split... |
| 15:32.07 | otavio | bluelightning: currently tools are build but those mostly depends on the libraries to be build before so basically has no build-time change. But the patch does stage them allowing for native tools to be build against them (one thing I need0 |
| 15:32.11 | otavio | ) |
| 15:32.19 | mickey|office | zecke: i'm not 100% sure yet, it depends on whether i finish some code i'm working on atm. |
| 15:32.31 | bluelightning | otavio: ok, sounds good |
| 15:32.41 | bluelightning | added to todo list :) |
| 15:33.43 | otavio | bluelightning: another thing to look at is to put the database cflags into oe-core so the meta-oe could just append the depends and get the recipes basically on sync with oe-core |
| 15:33.48 | woglinde | he zcke |
| 15:33.59 | bluelightning | otavio: yes, I promised koen I would do that but haven't yet |
| 15:34.12 | otavio | bluelightning: good :-) |
| 15:34.21 | otavio | bluelightning: and thanks by looking at it |
| 15:34.31 | otavio | bluelightning: btw, what is your name? :P |
| 15:34.38 | bluelightning | otavio: Paul Eggleton |
| 15:34.58 | bluelightning | no problem :) |
| 15:35.07 | otavio | bluelightning: pleased to meet you :-) |
| 15:35.19 | otavio | is Otavio Salvador |
| 15:35.20 | otavio | :-) |
| 15:35.29 | bluelightning | otavio: likewise :) |
| 15:36.29 | bluelightning | otavio: you are using qt4 for a project I take it? |
| 15:37.03 | otavio | bluelightning: yes; our embedded OS use it a lot |
| 15:37.30 | otavio | bluelightning: but it has been using an old OE snapshot and we're porting them to oe-core currently |
| 15:37.46 | bluelightning | cool, it's good to have someone using these recipes for real stuff... that's the only way we find out about any problems :) |
| 15:37.49 | otavio | bluelightning: and then we have been working at fix the stuff that we have done locally before |
| 15:38.09 | otavio | bluelightning: you might have noticed the fixes for qmake and cmake done by us too :-) |
| 15:38.26 | otavio | just sent another one ;-) |
| 15:39.25 | bluelightning | just saw it :) |
| 15:40.48 | pespin | hi, why is dbus package depending on glib2? |
| 15:40.59 | pespin | I know someone who's having problems with that |
| 15:41.06 | pespin | as glib needs libdbus |
| 15:41.23 | pespin | he tried removing glib2 dependency in dbus recipe and could build it. |
| 15:42.38 | woglinde | introspetion |
| 15:42.52 | fray | otavio BTW the patch header in the email you just sent to oe-core is correct.. :) |
| 15:42.58 | woglinde | introspection support I guess |
| 15:43.05 | fray | (at least that is what is intended) ;) |
| 15:43.38 | pespin | woglinde, the thing is... afaik glib depends on dbus right? |
| 15:43.51 | otavio | fray: good; I hoped :-d |
| 15:44.25 | woglinde | pespin hm I didnt looked so deep this much |
| 15:44.41 | woglinde | mickeyl mentioned newe glibs has a own dbusd impl |
| 15:44.51 | bluelightning | we've had some back and forth on this dbus/glib dependency loop before IIRC |
| 15:44.57 | woglinde | which you could run instead |
| 15:45.16 | woglinde | bluelightinh hm ah and you know more? |
| 15:45.26 | pespin | yeah, gdbus |
| 15:45.37 | bluelightning | well not really, but I have seen some patches already |
| 15:45.44 | bluelightning | I'll dig in my archives |
| 15:46.02 | florian | mickey|office: trains are mostly the same as an office ;) |
| 15:46.19 | pespin | but it looks like gdbus depends on libdbus too? gdbus-serialization.c:28:23: fatal error: dbus/dbus.h: No such file or directory |
| 15:46.29 | woglinde | *g* |
| 15:46.36 | woglinde | no only headers |
| 15:46.51 | woglinde | so you dont havea diffrent api |
| 15:47.09 | pespin | ? |
| 15:47.46 | pespin | gdbus api is different from that of libdbus afaik |
| 15:48.04 | woglinde | what? |
| 15:48.26 | *** join/#oe incandescant (~joshual@134.134.137.75) |
| 15:48.50 | woglinde | pespin hm but they need to share something |
| 15:49.12 | tharvey | kergoth, I'm getting some 'database locked' errors from bitbake while parsing recipes (possibly while caching) when I invoke bitbake concurrently on mutliple project dirs - some shared database? |
| 15:49.42 | pespin | woglinde, like what? I thought libgdbus was a full rewrite. |
| 15:52.37 | woglinde | sure but for types to serializable and so on |
| 15:52.55 | bluelightning | woglinde / pespin: in oe-core we dropped dbus's dependency on glib-2.0 |
| 15:52.56 | woglinde | its better to use the header which dbus provides |
| 15:53.13 | woglinde | bluelightning hm okay |
| 15:53.29 | woglinde | pespin so make a patch for dev |
| 15:53.37 | woglinde | if your pain is this much |
| 15:53.58 | pespin | woglinde, just remove glib-2.0 in dbus.inc reight? |
| 15:54.01 | pespin | *right |
| 15:54.31 | woglinde | hm yes and you could diff the config.logs and compile.logs |
| 15:54.36 | woglinde | to see what differs |
| 15:58.35 | *** join/#oe GunsNRose (~GunsNRose@113.104.188.69) |
| 16:00.44 | mickey|office | an rgrep doesn't reveal anything |
| 16:00.54 | mickey|office | (glib2 in dbus) |
| 16:01.03 | woglinde | *g* |
| 16:03.22 | *** join/#oe CIA-3 (cia@cia.atheme.org) |
| 16:06.13 | *** join/#oe msm (~msm@192.88.168.35) |
| 16:06.28 | *** join/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
| 16:11.19 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 16:20.05 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 16:25.57 | *** join/#oe Jay7 (jay@95.29.102.239) |
| 16:27.17 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 16:30.11 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 16:30.27 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 16:33.15 | *** join/#oe Heinervdm (~thomas@pD9E17555.dip.t-dialin.net) |
| 16:37.40 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 16:46.44 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 16:47.21 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
| 16:47.23 | *** join/#oe liamMT (~Liam@173-164-164-245-SFBA.hfc.comcastbusiness.net) |
| 16:48.33 | *** join/#oe methril_work (~Rafael@189.114.111.135) |
| 16:55.50 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 16:56.17 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:00.07 | Crofton|work | Tartarus, ping |
| 17:00.44 | Tartarus | pong |
| 17:01.39 | Crofton|work | can you push koen's request for maintenence |
| 17:01.54 | Crofton|work | I beleive 24 hours has elapsed :) |
| 17:02.12 | Tartarus | Hm |
| 17:02.19 | Tartarus | I thought I did |
| 17:02.31 | Tartarus | yeah |
| 17:02.34 | Tartarus | To git@git.openembedded.net:openembedded |
| 17:02.35 | Tartarus | <PROTECTED> |
| 17:03.49 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:03.56 | Crofton|work | hmm |
| 17:03.59 | Crofton|work | I'll check |
| 17:04.11 | Crofton|work | I thought you pushed one, but were waiting on koen's |
| 17:04.49 | Crofton|work | must have in the last hour :) |
| 17:04.52 | Crofton|work | thanks |
| 17:06.58 | *** join/#oe CIA-6 (cia@cia.atheme.org) |
| 17:12.26 | *** join/#oe B_Lizzard (~havoc@athedsl-119886.home.otenet.gr) |
| 17:14.04 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:25.51 | *** join/#oe Jefro (~josiermi@134.134.139.72) |
| 17:28.55 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:29.57 | *** join/#oe amarsman_nl (~marsman@52488909.cm-4-1c.dynamic.ziggo.nl) |
| 17:37.28 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:39.29 | Crofton|work | anyone know of a web based collaborative drawing website? |
| 17:39.52 | *** join/#oe tharvey (~tharvey@adsl-76-205-222-174.dsl.snlo01.sbcglobal.net) |
| 17:39.55 | CcSsNET | crofton, goto anapnea.net |
| 17:40.01 | CcSsNET | the owner has sub site projects |
| 17:40.07 | CcSsNET | i beleive 1 is what u want |
| 17:41.20 | Crofton|work | I need to make a drawing while someone else watches |
| 17:41.23 | Crofton|work | scheamtic |
| 17:42.34 | ReaperOfSouls | Crofton|work: http://gigaom.com/collaboration/25-apps-for-the-virtual-workers-toolkit/ The section on Desktop sharing may be helpful. |
| 17:43.10 | ReaperOfSouls | Might be a little over kill though. |
| 17:44.26 | *** join/#oe rcf (~rcf@88.81-243-81.adsl-dyn.isp.belgacom.be) |
| 17:46.03 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 17:47.21 | *** join/#oe jevin (~jevin@jevinskie-1-pt.tunnel.tserv9.chi1.ipv6.he.net) |
| 17:51.21 | *** join/#oe nitink (~nitink@nat/intel/x-cdvfdlbgxiciuqww) |
| 17:52.29 | *** join/#oe kristoffer_ (~kristoffe@host-78-79-4-254.mobileonline.telia.com) |
| 17:53.03 | *** join/#oe rob_w_ (~bob@ppp-188-174-64-141.dynamic.mnet-online.de) |
| 17:55.57 | jconnolly | hmm, for recipes, can I do FILES_${PN}_machine ? |
| 17:56.28 | jconnolly | so that the files deployed for a given recipe are a subset of those provided by default? |
| 17:56.52 | kergoth_ | of course. there's nothing special about FILES_${PN}, it's just another variable |
| 17:58.12 | *** join/#oe GNUtoo (~GNUtoo@host29-10-dynamic.54-79-r.retail.telecomitalia.it) |
| 18:01.27 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 18:02.50 | *** join/#oe msm (~msm@gate-az1.freescale.com) |
| 18:19.29 | *** join/#oe stefan_schmidt (~stefan@p4FC76979.dip.t-dialin.net) |
| 18:22.12 | *** join/#oe JaMa (~martin@94.230.152.115) |
| 18:22.24 | *** join/#oe toi (~peter@94-226-59-90.access.telenet.be) |
| 18:27.10 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 18:33.23 | tharvey | kergoth_, I'm getting 'database locked' errors while bitbake is parsing/cacheing if I kick off multiple bitbakes in different project dirs at the same time |
| 18:33.34 | tharvey | is there a shared sqlite database somewhere? |
| 18:35.14 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 18:38.09 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:41.16 | *** join/#oe anarsoul (~anarsoul@80.249.81.229) |
| 18:42.57 | *** join/#oe woglinde (~heinold@f052235101.adsl.alicedsl.de) |
| 18:45.18 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 18:55.06 | kergoth_ | tharvey: not shared, no, but it's possible you're putting so much load on the disk that it's taking too long to do the database operations |
| 18:55.22 | woglinde | jo kergoth |
| 18:55.50 | tharvey | hmmm... how long are the database operations retried for? |
| 18:56.09 | *** join/#oe ensc_ (~irc-ensc@p5DF2FD57.dip.t-dialin.net) |
| 18:57.24 | kergoth_ | would have to check the code. see lib/bb/persist_data.py |
| 19:00.02 | *** join/#oe risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 19:00.32 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 19:05.34 | GNUtoo | is that normal: |
| 19:05.35 | GNUtoo | XSERVER_COMMON ?= "xserver-kdrive-common" |
| 19:05.39 | GNUtoo | that is to say |
| 19:05.48 | GNUtoo | angstrom wants to use xserver-kdrive-common? |
| 19:07.54 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 19:09.22 | *** join/#oe reactor16 (~reactor16@76.191.104.153) |
| 19:10.02 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 19:15.26 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 19:23.43 | *** join/#oe CIA-10 (cia@cia.atheme.org) |
| 19:23.52 | JaMa | kergoth_: I have that too (locked database) quite often on virtualized host, never seen them on my faster box |
| 19:27.20 | woglinde | I naver saw it |
| 19:27.22 | woglinde | yet |
| 19:27.36 | kergoth_ | we really need to fix the assume provided handling |
| 19:28.12 | kergoth_ | can't even bitbake -e foo if foo is in ASSUME_PROVDIDED |
| 19:28.13 | kergoth_ | PROVIDED |
| 19:28.24 | kergoth_ | traceback, actually.. |
| 19:28.28 | kergoth_ | mutters |
| 19:28.45 | kergoth_ | also, assume provided should only affect things pulled in via deps |
| 19:28.53 | kergoth_ | if i say bitbake foo and foo was in assume provided, build the fucking thing |
| 19:28.58 | kergoth_ | i told you to build it, build it |
| 19:30.12 | woglinde | hm new versions gstreamer plugins |
| 19:30.14 | woglinde | +of |
| 19:30.40 | kergoth_ | some days bitbake annoys me so much i feel like throwing it out of a damn window and starting over :| |
| 19:30.55 | woglinde | in ruby? |
| 19:32.25 | kergoth_ | just in general |
| 19:32.29 | kergoth_ | its not the language tahts the problem :) |
| 19:32.35 | woglinde | hm |
| 19:32.37 | woglinde | yeah |
| 19:33.20 | Crofton|work | are there any good instructions on using bbppend to add a new config file to base-files and sysvinint? |
| 19:33.54 | woglinde | crofton have a look at systemd |
| 19:33.59 | kergoth_ | new, not existing? just append to do_install to install it and add to SRC_URI |
| 19:34.05 | *** join/#oe GarthPS (~quassel@78.250.203.210) |
| 19:34.06 | Crofton|work | dont want to make that big a change |
| 19:34.16 | kergoth_ | ugh, quilt-native rdepends on things that aren't even in our repository |
| 19:34.17 | Crofton|work | just need to deal with the inittab tty name change on omap |
| 19:34.22 | kergoth_ | patch-native, diffstat-native, .. |
| 19:34.27 | kergoth_ | mutters |
| 19:34.53 | woglinde | kergoth hm yes |
| 19:34.56 | kergoth_ | if it's an existing config file, you'd want to add the bbappend dir to FILESPATHBASE and override it that way |
| 19:35.51 | Crofton|work | ah serial console I can handle from the machine file |
| 19:36.39 | kergoth_ | and now the dependency loop identifier code in bitbake just puked with a bunch of tracebacks |
| 19:36.40 | kergoth_ | lovely |
| 19:37.20 | *** join/#oe woglinde_ (~heinold@g225005156.adsl.alicedsl.de) |
| 19:38.27 | *** join/#oe GarthPS|away (~quassel@166.171.100.84.rev.sfr.net) |
| 19:40.30 | ericben | otavio: do you have one minute concerning qt translations ? |
| 19:42.37 | otavio | ericben: sure |
| 19:43.04 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 19:43.57 | ericben | otavio: can you confirm that the result is a qt4-embedded-translation-qt_4.7.3-r29.1.9_armv5te.ipk packakge containing all .qm files in /usr/share/qtopia/translations/ ? |
| 19:44.06 | ericben | the expected result |
| 19:46.07 | ericben | btw I think we should drop the qtopia name and come back to qt which is a more actual name for the lib |
| 19:46.49 | woglinde_ | ieehks qtopia is dead, dead and dead |
| 19:52.06 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 19:53.57 | otavio | ericben: sure; paste it somewhere |
| 19:56.22 | ericben | otavio: otavio http://pastebin.com/CrFrCb5i |
| 19:57.51 | otavio | ericben: yes, seems perfect :-D yey! |
| 19:58.01 | ericben | otavio: ok last test and I'll post the patches |
| 19:58.30 | otavio | ericben: NICE |
| 19:58.48 | ericben | otavio: a few hacks to get the right bin at the right place and a strange hack in translations.pro which seems to be caused by the shell here |
| 19:59.19 | ericben | bye |
| 19:59.21 | otavio | ericben: send the patch and I take a look on it too |
| 19:59.23 | otavio | ericben: thanks a lot |
| 20:04.12 | *** join/#oe Jefro (~josiermi@nat/intel/x-acyblxeqjfkxpjjn) |
| 20:04.19 | *** join/#oe hexor_ (~thehexa@189-19-251-152.dsl.telesp.net.br) |
| 20:07.52 | *** join/#oe hexor (~thehexa@189-19-251-152.dsl.telesp.net.br) |
| 20:12.04 | pb_ | stabs ccache |
| 20:12.22 | pb_ | spent 20 minutes debugging an autoconf error only to find that it was due to my old enemy. |
| 20:14.26 | woglinde_ | uhu |
| 20:15.09 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 20:16.10 | *** join/#oe soltys (soltys@83.168.118.74) |
| 20:17.12 | pb_ | in other news, though, I nearly have some semblance of a working micro layer on top of oe-core. |
| 20:18.56 | likewise | pb_: that's good news indeed |
| 20:19.09 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 20:19.28 | likewise | seems there is enough momentum behind oe-core, good to see |
| 20:20.05 | pb_ | well, I wouldn't count myself as wholeheartedly enthusiastic about oe-core yet, but it seems worth at least experimenting with. |
| 20:20.23 | woglinde_ | likewise tsc still has not present a plan |
| 20:20.45 | likewise | pb_: what is your biggest concern? (Mine is that we have too many diversion in repos, trees, branches) |
| 20:20.57 | likewise | woglinde_: plan for what? |
| 20:21.13 | woglinde_ | likewise oe-core, meta-oe |
| 20:21.36 | woglinde_ | transition |
| 20:21.48 | *** join/#oe martinmeba (~martin@12.110.139.34) |
| 20:22.00 | likewise | woglinde_: you mean whether or not to move to core? |
| 20:22.15 | woglinde_ | move is clear |
| 20:22.26 | woglinde_ | not to move is stupidity |
| 20:22.35 | martinmeba | I have been playing around with wpa-supplicant and found a glitch in the recipe. It has logic in the wpa-supplicant-0.7.inc file to detect if DBUS is enabled in the .config file |
| 20:22.41 | martinmeba | it does not seem to enter that block |
| 20:22.52 | likewise | woglinde_: please elaborate then what the TSC must plan? |
| 20:22.57 | martinmeba | so none of the config files for dbus ever get placed in /etc/dbus-1/system.d |
| 20:23.05 | woglinde_ | likewise policy? |
| 20:23.10 | martinmeba | it looks like the line above the logic changes the reference directory |
| 20:23.11 | woglinde_ | or policies |
| 20:23.24 | woglinde_ | for now koen and jama made there own policy for meta-oe |
| 20:23.32 | martinmeba | so if the grep tests are modified from .config to ${S}/.config, dbus config files are correctly placed |
| 20:23.54 | woglinde_ | martinmeba send a patch to the list |
| 20:24.10 | martinmeba | will-do |
| 20:25.13 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 20:30.29 | pb_ | likewise: yeah, it does seem a bit fragmentary, though I think there are probably good reasons for that. Some of the particular splits seem a bit weird though, eg this sato stuff in "core". |
| 20:30.50 | pb_ | I'm not sure if that is just some legacy thing and will go away, or whether it is the intent that it should stay there. |
| 20:31.06 | likewise | pb_: this was brought up in an email very recently |
| 20:31.26 | likewise | pb_: no clear outcome yet though |
| 20:32.46 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 20:35.45 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 20:40.15 | tharvey | question about FEED_ARCH and TARGET_CC_ARCH: if your building images for two diff machines that have diff TARGET_CC_ARCH, the packages will both get mixed into same FEED_ARCH - is that really what you want? seems if your going to the trouble to tune gcc flags for a machine you would want it to segregate its packages? |
| 20:45.20 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 20:48.52 | pb_ | I'm also finding some of oe-core's build machinery a little bit fiddly to get to grips with. It seems to want you to use all of its own little scripts, which is probably fine but it's slightly alien compared to regular oe. |
| 20:50.49 | ka6sox-work | pb_, so I'm not the only one who thinks that....good |
| 20:51.01 | pb_ | and, finally (I think) it is slightly disheartening that some of the classes appear to have been forked from quite old versions compared to what's in regular oe. obviously that can be fixed but it's a bit tiresome doing the same work again. |
| 20:53.39 | florian | agrees |
| 20:54.22 | otavio | pb_: I did some sync for cmake and qmake_base classes last week but does indeed seem to have many bug fixes missing on oe-core |
| 20:54.30 | Tartarus | pb_: Yeah, layers requires a little bit of re-thinking and setup |
| 20:54.35 | otavio | | NOTE: QA checking staging |
| 20:54.35 | otavio | | ERROR: Package already staged (/home/otavio/hacking/el/tmp/sstate-control/manifest-x86_64-perl-native.populate-sysroot)?! |
| 20:54.38 | otavio | | ERROR: Function 'sstate_task_postfunc' failed |
| 20:54.40 | otavio | NOTE: package perl-native-5.12.3-r2: task do_populate_sysroot: Failed |
| 20:54.43 | otavio | someone has seen it on today's oe-core? |
| 20:54.57 | Tartarus | And yes, the re-sync of classes still needs help with folks that use the classes in question |
| 20:55.04 | florian | in fact I did not look at the differences of the classes yet but the situation for setting up the build system seems to become worse |
| 20:56.24 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 20:59.56 | *** join/#oe Khem__ (d0dfd0f2@gateway/web/freenode/ip.208.223.208.242) |
| 21:05.25 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:09.19 | kergoth_ | i'm not sure i see how setting up the build system is any more difficult with oe-core than the current state. there are more layers, but its trivial to add them, and there are plenty of tools to manage fetching them |
| 21:11.56 | woglinde_ | not to forget |
| 21:12.08 | woglinde_ | the intel guys not working on oe master |
| 21:15.28 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:16.11 | pb_ | kergoth: well, for example, there seems to be some new requirement for a BUILDDIR environment variable |
| 21:16.24 | pb_ | and this bitbake wrapper script |
| 21:17.01 | pb_ | if I forget to set BUILDDIR then I get obscure errors like: |
| 21:17.11 | pb_ | ../oe-core/scripts/bitbake: line 45: /pseudodone: Permission denied |
| 21:17.11 | pb_ | cat: /pseudodone: No such file or directory |
| 21:17.14 | *** join/#oe ReaperOfSouls (~jpuhlman@nat/montavista/x-curohocprshyjvnc) |
| 21:17.51 | pb_ | the layers aren't a problem, I understand what to do with that. |
| 21:19.29 | fray | BUILDDIR is set by the oe-init-build-env script.. there are a hand full of items set |
| 21:20.42 | fray | values being configured are BB_ENV_EXTRAWHILE, BUILDDIR, and PATH |
| 21:20.50 | fray | 'er.. BB_ENV_EXTRAWHITE |
| 21:21.08 | pb_ | ah, right |
| 21:21.40 | pb_ | so yeah, that is an example of something that wasn't neede d with "classic" oe but apparently is needed with oe-core. |
| 21:22.23 | fray | yes.. builddir is setup because of the need of the wrapper script.. and the wrapper script is needed because of pseudo.. pseudo is needed to resolve the bug of "fakeroot" style control in python functions |
| 21:24.25 | *** join/#oe dijenerate (~dijenerat@204.212.240.167) |
| 21:26.11 | pb_ | yeah. I don't doubt that there are good reasons for this stuff, but it is a little bit of a shame that the amount of external mechanism required is going up again. |
| 21:26.45 | fray | I will say that every time a change like this has occured, there is a lot of discussion around it, and if it's reasonable.. |
| 21:26.52 | pb_ | with classic oe, we had almost reached the point where you didn't need to have any obscure stuff in your env prior to running bitbake, and now oe-core seems to have moved some distance away from that again. |
| 21:26.55 | fray | thats why there are "only" three items touched.. |
| 21:27.40 | fray | the builddir might be able to be removed.. the BB_ENV_EXTRAWHITE isn't needed in a lot of configurations.. and the PATH ensures you are running the wrapper script, not the actual bitbake binry |
| 21:28.05 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 21:28.41 | pb_ | is there any chance we can get whatever magic is currently in the wrapper folded into bitbake itself? |
| 21:28.47 | pb_ | I haven't looked to see what it is actually doing. |
| 21:29.08 | fray | we've been discussing that.. at this time, we can't do it.. |
| 21:29.30 | fray | the wrapper is doing two things.. the primary thing is simply selling LD_PRELOAD=...pseudo |
| 21:29.55 | fray | this way pseudo is always in memory when bitbake or it's sub processes run.. (pseudo, unlike fakeroot) is disabled by default.. and is enabled via an environment variable on fork and/or exec |
| 21:30.23 | fray | but the issue is, you can't reasonably set the LD_PRELOAD, without having pseudo built.. so the wrapper also does a "stage1" build.. the purpose of which is to simply build pseudo-native.. |
| 21:30.27 | fray | stage2 is the "regular" build.. |
| 21:31.02 | fray | there have been some discussions on creating a multi-stage build process that can restart bitbake and such.. but right now the best answer anyone has come up with is a wrapper script, similar to whats there.. (just more extensible) |
| 21:31.31 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:32.14 | fray | there was some early talk about making bitbake be able to setup values adn re-exec itself.. but at least initially that was frowned upon for being overly complex -- compared to a simple shell wrapper |
| 21:33.57 | ReaperOfSouls | wonders how doing the exact thing you would do inside on the outside is a reduction in complexity. :) |
| 21:34.11 | pb_ | oh, right, I see. so you want bitbake itself to be running with pseudo preloaded. |
| 21:35.29 | fray | yup |
| 21:35.41 | Jay7 | forgot again why that wrapper around bitbake was needed.. |
| 21:36.02 | fray | ReaperOfSouls it's to reduce the complexity of bitbake itself |
| 21:36.53 | ReaperOfSouls | fray: *shrug* you can do all the tasks as metadata include. |
| 21:37.09 | fray | there was concern that bitbake is used outside of OE.. and making those changes could affect the other projects and/or the overall maintenance complexity within bitbake.. |
| 21:37.12 | ReaperOfSouls | fray: leave bitbake naked. |
| 21:37.15 | fray | thus moving it external was the next choice |
| 21:37.48 | Crofton|work | is it really used outside oe? |
| 21:38.00 | fray | the LD_PRELOAD and such has to be loaded prior to bitbake itself.. because the python based tasks are run directly.. so it would require a way for bitbake to re-exec itself, after adding LD_PRELOAD to the environment |
| 21:38.23 | fray | plus, there is no current concept within bitbake of a staged build.. i.e. build up to point X.. then do Y.. then continue building... |
| 21:38.37 | Jay7 | export vars, fork + exec $0 |
| 21:38.41 | fray | Crofton|work, I was told it is.. |
| 21:38.43 | ReaperOfSouls | fray: Its pretty straight forward to impliment. When I was playing with it early, I added all that to our collections.inc which already re-execs, and it just worked. |
| 21:39.18 | fray | then I'd certainly suggest people point patches for an enhancement and remove the need for the wrapper.. |
| 21:39.24 | ReaperOfSouls | It was just a POC, but its is not impossible to do. |
| 21:39.32 | Jay7 | or may be some .bbclass |
| 21:39.36 | fray | the wrapper is there purely for the stage 1 & stage 2 builds.. and to setup LD_PRELOAD prior to the python tasks from running |
| 21:39.37 | Jay7 | stage1.bbclass |
| 21:39.43 | Jay7 | stageX.bbclass |
| 21:40.18 | Jay7 | but I'm unsure how it is possible because of lack internals knowledge |
| 21:40.30 | fray | (it also sets BBFETCH2=True so that oe-core can run the fetch2 version.. but thats a minor tweek compred to the others) |
| 21:40.37 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:40.58 | Jay7 | anyway, re-exec'ing itself is wide used afaik |
| 21:41.09 | fray | but not within bitbake, that we could tell.. |
| 21:41.20 | ReaperOfSouls | RP RP__: was there anymore movement on the layer tooling rfc? |
| 21:41.24 | Jay7 | patches are welcome, I know :) |
| 21:41.48 | fray | actually I thought there was an issue in re-execing within a .bbclass item.. because the python chunk is run as a task, so you are not running in the bitbake context.. that would leave two bitbakes running.. |
| 21:41.52 | kergoth_ | collections.inc made bitbake re-exec itself a long time ago. not pretty, but it got the job done |
| 21:42.31 | kergoth_ | aside: anyone seen a really strange sha256sum mismatch when the md5sum doesn't mismatch? |
| 21:42.32 | RP__ | ReaperOfSouls: There is some movement on the wiki pages about it I think |
| 21:42.37 | kergoth_ | i just had apr fail this way, somehow |
| 21:42.38 | kergoth_ | makes no sense |
| 21:42.48 | RP__ | kergoth_: that sounds very odd |
| 21:43.03 | kergoth_ | yeah, i'm confused |
| 21:43.05 | kergoth_ | i think it's one of those days |
| 21:43.06 | Jay7 | kergoth_: it's possible in theory.. but I haven't seen that |
| 21:43.51 | woglinde_ | good nite |
| 21:43.57 | kergoth_ | i mean, yeah, i realize its theoretically possible to get an md5sum collision, but it has to be really really really unlikely |
| 21:43.58 | fray | Just to shorted what bitbake (shell wrapper does).. sets BBFETCH2=True, adds PSEUDO_BUILD & PSEUDO_DISABLED to BB_ENV_EXTRAWHITE.. It runs bitbake pseudo-native -c populate_sysroot.. then runs "mkdir -p PSEUDOBINDIR/../../var/speudo ; PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo bitbake <args>" |
| 21:45.04 | ReaperOfSouls | RP__: So I got approval to open up our content tools. There are some trivial changes to make them work with layering(actually I already have them working internally).. They might be a good starting point for a component if your interested. |
| 21:46.26 | Jay7 | seems pseudo should be better integrated to bitbake |
| 21:46.52 | ReaperOfSouls | kergoth_: with a 256 bit hash shouldn't it be centuries before you collide? |
| 21:47.16 | ReaperOfSouls | At least statisically. |
| 21:47.30 | Jay7 | ReaperOfSouls: that is why it mismatch when md5sum is matched :) |
| 21:47.31 | kergoth_ | yeah, would expect so. i'm thinking this has to be a fluke, or something hokey in the checksumming code |
| 21:47.47 | RP__ | ReaperOfSouls: Certainly I'm interested to see what you have |
| 21:48.11 | RP__ | ReaperOfSouls: This probably needs to be a mailing list discussion (and cool on the approval!) :) |
| 21:48.21 | kergoth_ | speaking of which, i was thinking the other day, i wonder if itd be worthwhile to unwrap the .gz/.bz2 portion of files and checksum the content, since gzips at least can hold timestamps which have nothing to do with what you actually get |
| 21:48.41 | kergoth_ | we already have to read the entire file, would just be a matter of doing it via a gzopen or whatever |
| 21:49.07 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:49.13 | ReaperOfSouls | RP__: Okay l am gonna go through the process of a little bit of de-branding. And Ill try and get them all up early next week. |
| 21:49.20 | fray | usually if the archive has been tampered with, I'd rather not trust the contents.. |
| 21:49.37 | kergoth_ | if the tarfile checksum matches, i don't see why you woudln't trust the content |
| 21:49.38 | RP__ | ReaperOfSouls: I'll ping bluelightning and make him aware this is going to happen |
| 21:49.47 | fray | so simply md5/sha the compressed file should be good enough |
| 21:50.01 | kergoth_ | one could consider gz/bz2 an artifact of the delivery mechanism, not an aspect of the content |
| 21:50.16 | fray | kergoth_ in the past there have been security issues with zlib and such.. if the archive has changed, someone might be trying to exploit it |
| 21:50.25 | kergoth_ | maybe it's not worthwhile, just popped into my head the other day |
| 21:50.32 | RP__ | kergoth_: It sounds like it would complicate things without any useful benefit |
| 21:50.45 | kergoth_ | i've seen upstreams rearchive and change our checksum without changing the content on multiple occasions |
| 21:50.48 | fray | the only reason I could see for osmeone to do that is if they want to change the amount of compression, compared to upstream |
| 21:51.01 | kergoth_ | almost always due to the gzip timestamp (which can be disabled, bu tmost people don't know about it) |
| 21:52.01 | kergoth_ | probably not worth the added complexity, indeed, at a minimum you'd need something else attached to the unpack code in fetch2 to remove the outer layer |
| 21:52.48 | RP__ | We need more time and less things to fix :) |
| 21:53.20 | Jay7 | fray: about possible other projects using bitbake |
| 21:53.36 | Jay7 | fray: using pseudo should be feature, not blocker |
| 21:53.50 | Jay7 | so I see no problem to mainline that behaviour |
| 21:53.53 | fray | ya.. pseudo is not required by bitbake.. you can still ue fakeroot |
| 21:53.57 | Jay7 | just make it configurable |
| 21:54.03 | kergoth_ | it is configurable |
| 21:54.12 | kergoth_ | which is why master works with oe-core and oe |
| 21:54.19 | Jay7 | nice |
| 21:56.06 | Jay7 | so we only need [switcheable] exporting LD_PRELOAD with right path and fork+exec $0 |
| 21:56.39 | Jay7 | well.. a bit more.. |
| 21:56.40 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:56.40 | RP__ | has been considering having bitbake exit with a specific code once its built pseudo-native |
| 21:57.12 | kergoth_ | RP__: https://github.com/kergoth/bitbake/compare/master...exceptions - seem reasonable to you? two pieces, one improves output for a number of parse error cases, and the other shifts the traceback formatting into the UI/formatter, rather than pre-formatting in the server |
| 21:57.33 | Jay7 | if there is no pseudo root was populated then populate it before |
| 21:58.32 | otavio | went to University |
| 21:58.34 | otavio | cya |
| 21:58.41 | kergoth_ | meh, this week needs to be over already |
| 21:58.50 | *** join/#oe Jefro (~josiermi@134.134.139.72) |
| 22:01.10 | Jay7 | yeah... |
| 22:01.27 | Jay7 | should join oe-core development and testing.. |
| 22:02.50 | RP__ | kergoth_: looks reasonable to me |
| 22:03.15 | kergoth_ | there's still a fair bit of work to be done on the exception madness, but its yet another step forward i think |
| 22:03.22 | kergoth_ | heh |
| 22:04.15 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 22:05.46 | kergoth_ | gets caffeine |
| 22:08.37 | *** join/#oe rsalveti (~rsalveti@business-89-133-214-120.business.broadband.hu) |
| 22:12.17 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 22:13.54 | fray | sorry back.... for the pseudo stuff.. if pseudo is not there, certain things will fail.. like rootfs construction, some package building... etc.. |
| 22:14.33 | fray | as for the workaround.. LD_PRELOAD of the pseudo libraries will work.. but call the pseudo binary as a wrapper to bitbake (if we re-exec for instance) is better because that ensures all of the environment variables that pseudo uses are configured and preserved |
| 22:14.59 | *** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
| 22:17.08 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 22:22.33 | Jay7 | fray: as I understand, bitbake may build pseudo-native before |
| 22:22.47 | Jay7 | so I see no problems about missing pseudo |
| 22:23.57 | Jay7 | pseudo should be just enabled in some bitbake config file |
| 22:25.05 | fray | pseudo must be loaded into memory before the bitbake process to build ANY target packages |
| 22:25.13 | fray | pseudo is not used for cross and native packages |
| 22:26.36 | Jay7 | so, if pseudo usage is enabled, then build pseudo-native, populate pseudo root, setup LD_PRELOAD and re-exec itself |
| 22:26.51 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 22:27.00 | fray | yes.. thats a minimum.. better to exec pseudo itself with $0 as the argument |
| 22:27.09 | fray | but LD_PRELOAD + other PSEUDO environment variables will work |
| 22:27.16 | Jay7 | yes, or so |
| 22:28.00 | fray | build through pseudo-native -- including populate the sysroot. have bitbake process exec pseudo $0 $@ |
| 22:28.05 | fray | that will do it.. |
| 22:28.15 | fray | alternative if a "re-exec" is easier is the LD_PRELOAD=...pseudo |
| 22:28.25 | fray | (LD_PRELOAD is more complicated and required more logic) |
| 22:28.28 | Jay7 | it's the same |
| 22:28.32 | fray | no it's not |
| 22:28.35 | Jay7 | fork + exec |
| 22:28.44 | Jay7 | difference is what to exec there |
| 22:28.53 | fray | LD_PRELOAD requires the path setup properly.. calling "pseudo" (the binary) sets up the path for you |
| 22:29.15 | fray | and it's not fork + exec.. it's simply exec from the bitbake context.. _or_ fork + exec -- then on the fork side exit |
| 22:30.01 | fray | (and if we support non Linux hosts, then LD_PRELOAD itself won't work.. pseudo has the logic for other OS preloads as well built in) |
| 22:31.29 | Jay7 | hm.. yes, just exec may be used here.. |
| 22:31.39 | fray | but the normal way that tasks get executed in bitbake (correct be if I'm wrong please) is "bitbake runs -- does work", fork(), task executed (either directly in python or via exec) |
| 22:31.43 | Jay7 | we don't need to wait for completion |
| 22:32.07 | fray | the problem if we do this re-exec of bitbake within a task (i.e. no changed to bitbake) then the original bitbake process is still running.. I'm not sure if that will work or not |
| 22:32.31 | fray | a trigger to kill off the parent process would be fine, but somehow you have to preserve "control" so that anything from the child gets passed back to any scrips or anything calling the original bitbake.. |
| 22:32.35 | fray | thus the exec w/o a fork |
| 22:32.39 | fray | (preserve the pid) |
| 22:33.26 | Jay7 | yes, no fork is needed here |
| 22:33.46 | fray | (or desired).. I'm simply not sure if bitbake (as it's implemented) can do an exec w/o a fork.. |
| 22:33.52 | Jay7 | just exec pseudo with $* |
| 22:33.57 | fray | if we enhance bitbake to give us that capability then it should work fine |
| 22:34.25 | Jay7 | ah.. we have client-server model.. |
| 22:34.29 | fray | at the time, this is one of the sticking points.. it was discussed and decided to not be worth it.. I'm very much open to changing that and getting rid of the wrapper.. but the wrapper was easier to implement |
| 22:34.53 | Jay7 | and server may be at other host |
| 22:35.02 | fray | not sure... |
| 22:35.11 | Jay7 | (in future) |
| 22:35.31 | fray | I know there is a UI component, which is seperate from the task executor.. but I'm not familiar with the details of it |
| 22:35.33 | Jay7 | so, re-execing or execing pseudo may affect client connection |
| 22:35.44 | fray | it's the task executer that has to be run under pseudo control.. |
| 22:35.46 | Jay7 | i.e. UI |
| 22:35.53 | fray | yes, I would think so.. |
| 22:35.54 | *** join/#oe Matth_FA_ (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 22:37.02 | Jay7 | hm.. anyway, wrapper have same possible problem |
| 22:38.01 | fray | I don't know.. other then an external controlling script still sees the output of the single PID that it executed.. |
| 22:38.08 | fray | when that PID dies, the build is over |
| 22:42.29 | *** join/#oe timtimred (~meh@85.210.138.180) |
| 22:42.29 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 22:42.29 | *** join/#oe ensc_ (~irc-ensc@p5DF2FD57.dip.t-dialin.net) |
| 22:42.29 | *** join/#oe jevin (~jevin@jevinskie-1-pt.tunnel.tserv9.chi1.ipv6.he.net) |
| 22:42.29 | *** join/#oe Jay7 (jay@95.29.102.239) |
| 22:42.29 | *** join/#oe incandescant (~joshual@134.134.137.75) |
| 22:42.29 | *** join/#oe rickfoosusa (~chatzilla@99.179.103.49) |
| 22:42.29 | *** join/#oe chase (~chase@nat/ti/x-obnltqeckfvzykbr) |
| 22:42.29 | *** join/#oe Gaston|Home (~Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
| 22:42.29 | *** join/#oe Marex (vasum7am@u-sl.ms.mff.cuni.cz) |
| 22:42.29 | *** join/#oe esbenh (~esben@77.233.226.4) |
| 22:42.43 | *** join/#oe timtim123 (~meh@85.210.138.180) |
| 22:44.54 | *** join/#oe trelane` (trelane@funtoo/staff/trelane) |
| 22:45.03 | trelane` | how do I use make -j in oe's bitbake |
| 22:46.26 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 22:50.33 | kergoth_ | trelane`: PARALLEL_MAKE = "-j5" or whatever, in local.conf |
| 22:52.17 | trelane` | cool |
| 22:55.27 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:05.21 | CIA-10 | 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r036cf3cd11 10bitbake.git/lib/bb/codeparser.py: |
| 23:05.22 | CIA-10 | codeparser.py: Ignore incomplete cache files |
| 23:05.22 | CIA-10 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
| 23:06.14 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:08.16 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 23:15.33 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:16.04 | *** join/#oe rsalveti (~rsalveti@business-89-133-214-120.business.broadband.hu) |
| 23:25.23 | *** join/#oe Jefro (~josiermi@134.134.137.71) |
| 23:26.06 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:35.39 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:45.42 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 23:56.46 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |