| 00:03.23 | *** join/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net) |
| 00:06.39 | grg | Crofton|work, people who use autotools should be shot :) |
| 00:06.54 | Crofton|work | heh |
| 00:07.08 | grg | i agree though, there are some bad makefiles out there |
| 00:07.44 | Crofton|work | the i2c-tools ones are not grim, except where they overwrtite the kernel header I need |
| 00:07.55 | Crofton|work | dinner time though, so it will wait until the morning |
| 00:21.07 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-waodaieygdrzllpq) |
| 00:25.43 | *** join/#oe risca (~risca@h167n12-n-a31.ias.bredband.telia.com) |
| 00:27.29 | *** join/#oe risca (~risca@h167n12-n-a31.ias.bredband.telia.com) |
| 00:35.07 | CMoH-notebook | does bitbake need python-pysqlite2 (it's ubuntu package)? |
| 00:35.46 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-hdvfhirzqtblkync) |
| 00:37.49 | CMoH-notebook | i see for 1.8.18 both gentoo and ubuntu add it as dependency |
| 00:38.05 | Tartarus | yes, you need that or something else to provide the db |
| 00:38.16 | Tartarus | bitbake will complain/mention what the choices are if you don't have it installed |
| 00:38.17 | CMoH-notebook | for the cache? |
| 00:38.56 | CMoH-notebook | hmm... i just uninstalled it from my ubuntu machine and bitbake didn't - i know it has a sanity check from the time when i installed it first time |
| 00:39.13 | CMoH-notebook | i'm using the git 1.10.1 tag for testing |
| 00:39.28 | CMoH-notebook | its behavior - therefore my question here |
| 00:43.46 | CMoH-notebook | well... i guess further tests will yield an answer |
| 00:44.01 | ericben | khem: concerning samba compilation problem (tested on armv5) : gcc-4.5 : fails (in fact it's -O2 which makes it fail, compiling rpc_parse/parse_prs. with -O0 works fine) gcc-4.5 without linaro patches : builds fine, gcc-4.5.2-rc (svn 167585) without linaro patches : builds fine. Linaro targets armv7 so maybe we should not include their patches for arm < v7 to avoid trouble ? |
| 00:47.53 | khem | ericben: usually linaro patches are generic arm |
| 00:48.09 | khem | ericben: and if there are issues we find then we should raise it with linaro guys |
| 00:48.19 | khem | eventually those linaro changes are going upstream |
| 00:48.26 | khem | so we will hit it now or later |
| 00:48.44 | khem | ericben: but thank you big for identifying that its a linaro problem |
| 00:48.56 | ericben | khem: ok, I'll try to identify the patch creating the problem |
| 00:49.13 | khem | ericben: if you have time fine otherwise dont bother |
| 00:49.39 | khem | what you can do is send me the preprocessed file which caused the crash |
| 00:49.52 | khem | I will then reduce it and see what can be done |
| 00:50.05 | khem | and meanwhile use -O0 workaround for non armv7 arms |
| 00:50.07 | khem | for samba |
| 00:50.10 | ericben | khem: do you plan to update the linaro patch serie ? there are new svn commits 99421 to 99440 |
| 00:50.10 | khem | if thats ok |
| 00:50.19 | khem | ericben: yes |
| 00:51.05 | khem | ericben: so if you send me the preprocessed output it will make my life easier to verify if its already fixed or not |
| 00:51.30 | ericben | khem: generating the file |
| 00:52.59 | khem | merci |
| 00:56.07 | khem | ericben: I see the patch for gcc 4.5.2 from you |
| 00:56.21 | khem | ericben: better would be identify the false commit |
| 00:56.29 | khem | and we can disable that for non armv7 |
| 00:56.52 | khem | ericben: I want toolchain versions to be manageable its already too many there |
| 00:57.02 | khem | maintaining them becomes a nightmare |
| 00:57.16 | ericben | khem: yes, but isn't it useful to have a gcc-4.5.2 (stable version due next week) instead of having a moving 4.5 ? |
| 00:57.56 | ericben | I understand having many revisions is hard to maintain but shouldn't we at least provide the latest stable ? |
| 01:02.53 | ericben | khem: OK mail sent |
| 01:03.47 | CIA-101 | 03Khem Raj <raj.khem@gmail.com> 07master * ra91b9a2922 10openembedded.git/recipes/gcc/ (7 files): |
| 01:03.48 | CIA-101 | gcc/gcc-cross/gcc-cross-intermediate: Generate libgcc_s.so as a linker script stub |
| 01:03.48 | CIA-101 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 01:03.48 | CIA-101 | Acked-by: Eric Bénard <eric@eukrea.com> |
| 01:06.12 | *** join/#oe grund (~grund@64.244.156.164) |
| 01:08.40 | khem | ericben: as gcc development goes once they start a release branch like 4.4 or 4.5 then its only open for bugfixes |
| 01:09.08 | khem | ericben: and 4.5.1 = 4.5.0 + bugfixes and gcc-4.5.2 = gcc-4.5.1 + bug fixes |
| 01:09.11 | khem | and so on |
| 01:09.20 | khem | at anytime the branch is better than the last rec |
| 01:09.22 | khem | rev |
| 01:09.41 | khem | thats why we decide to track the branch rathar then releases |
| 01:09.57 | khem | and this way we can keep using and moving forward without much hassle at all |
| 01:10.17 | khem | while this is true for gcc other projects may have more radical dev model where we can not do this |
| 01:10.23 | khem | depends on project to project |
| 01:10.46 | khem | ericben: once 4.5.2 release we will move to that |
| 01:10.49 | khem | essentially |
| 01:11.04 | khem | I hope its understandable |
| 01:12.02 | ericben | khem: ok I understand this. The question is are linaro patches as stable & tested as is the gcc branch ? |
| 01:12.21 | khem | ericben: well linaro is a new thing |
| 01:12.30 | ericben | my understanding is that linaro only targets armv7 so I'm not sure they test their optimizations on armv4 v5 or v6 |
| 01:12.32 | khem | it just started this year sometime |
| 01:12.55 | khem | ericben: they target armv7 sure but there goal is also do no harm to other arms |
| 01:13.12 | khem | so we can provide them valuable feedback |
| 01:13.13 | ericben | yes I know this project is recent and thanks to hrw explanation I now understand what is their goal :) |
| 01:13.43 | khem | eventually all linaro patches should land in upstream gcc |
| 01:13.51 | ericben | yes. The only problem is to have a gcc which can be unstable and is used as a default for minimal, angstrom 2010.x and other distros |
| 01:14.15 | khem | ericben: well linaro patches are from CSL toolchain |
| 01:14.22 | khem | so I believe they are high quality |
| 01:14.48 | ericben | some of their patch come from CSL, not all (or it's not marked as this in the log) ? |
| 01:14.52 | khem | and yes there can be regressions like the one with apache that we are seeing |
| 01:14.59 | khem | but we need to help linaro to go forward |
| 01:15.02 | kergoth_ | whee |
| 01:15.17 | kergoth_ | bb.build is completely switched to using a new bb.process module now, finally got the kinks worked out of -D |
| 01:15.18 | khem | ericben: 99% are from CSL |
| 01:15.19 | ericben | btw, do you know the future of CSL now mentor purchased them ? |
| 01:15.26 | ericben | ah ok |
| 01:15.27 | khem | few patches related to version bump are not :) |
| 01:15.31 | khem | believe me |
| 01:15.32 | ericben | :) |
| 01:15.37 | khem | I have seen them 1 by 1 |
| 01:15.53 | khem | kergoth_ is their lord |
| 01:15.56 | khem | ask him |
| 01:15.57 | ericben | :) |
| 01:16.21 | kergoth_ | has no idea what the plans are, never know with acquisitions |
| 01:16.39 | khem | ericben: I wonder whats the perf gain on say armv4 with linaro patches |
| 01:16.54 | khem | ericben: I bet its better than vanilla gcc 4.5 |
| 01:17.14 | khem | leave armv7 where its clear that it will kick ass |
| 01:17.15 | ericben | khem: if I find time I'll try to run nbench to see on an arm920t |
| 01:17.23 | khem | ericben: cool you are my man |
| 01:17.36 | ericben | khem: but I'm quite sure this will be next year :-D |
| 01:17.44 | khem | was delegating benchmarking it to ericben indirectly |
| 01:18.02 | khem | no worries its better than never |
| 01:18.29 | khem | there are two issues right now thats reported against 4.5 in OE |
| 01:18.34 | khem | w.r.t code generation |
| 01:18.37 | khem | one is this one |
| 01:18.43 | khem | and there is another one bugzilla |
| 01:18.48 | khem | which I am verifying against trunk |
| 01:18.56 | khem | and that seems to be generic issue |
| 01:19.21 | ericben | in fact I was quite unluncky today, while a training, I told a guy : look OE is good to compile big things like apache or samba and I tried samba ... and that failed ;-) |
| 01:19.51 | khem | too bad samba issue is known to us |
| 01:19.57 | khem | eFfeM_work ran into |
| 01:20.02 | khem | JaMa also ran into it |
| 01:20.11 | khem | you should follow IRC closely :) |
| 01:20.39 | ericben | khem: unfortunatly 24h/day is not enough :-D |
| 01:20.49 | khem | you can now tell the guy that yes shit happens but we are on top of it |
| 01:21.21 | khem | ericben: I have keyword highlights and I leave it running and it keeps filtering messages for me when I am not here |
| 01:21.23 | ericben | he saw this with the sdk problem that your patch fixed yesterday evening :) |
| 01:21.34 | khem | then I come and read them and I know what I am interested in |
| 01:21.58 | ericben | khem: interesting one day I'll look how to configure irssi to do this kind of thing ;-) |
| 01:22.02 | khem | yeah probably we should start raising bugs in bugzilla |
| 01:22.04 | khem | for reference |
| 01:22.11 | khem | and not leave it here |
| 01:22.14 | ericben | or on the mailing list |
| 01:22.34 | khem | I am not too happy with our ml archiving |
| 01:22.40 | khem | we should do a better job |
| 01:22.42 | ericben | irc is cool for direct discussion but diving in irc archives is quite a pain |
| 01:23.09 | khem | I think using bugzilla more effectly is a good way |
| 01:23.39 | ericben | for mailing list it's easier : you can subscribe and use mail client to search into the mails and use the mails as a big knowledge database :) |
| 01:24.16 | ericben | but yes bugzilla is here to track bugs |
| 01:25.07 | ericben | the only thing is not to be lazy and file the bug into bugzilla |
| 01:26.39 | khem | well bugzilla is same |
| 01:26.50 | khem | and it send mail to ml too |
| 01:27.08 | ericben | so we should use it more |
| 01:28.15 | khem | yes I do think so |
| 01:28.32 | khem | and its on reliable infra |
| 01:29.20 | khem | I consider bugzilla a tool more than just a bug tracker |
| 01:29.34 | khem | you can do nice things using it w.r.t projects |
| 01:36.29 | *** join/#oe _julian (~quassel@hmbg-5f77db04.pool.mediaWays.net) |
| 01:37.43 | ericben | ok bug filed |
| 01:39.06 | khem | :) |
| 01:39.09 | khem | goota go now |
| 01:39.13 | ericben | are you sure the mail goes to the list ? |
| 01:39.26 | ericben | time to go to bed. bye ! |
| 01:39.26 | khem | should if not we can set it up |
| 01:56.45 | kergoth | woot! |
| 01:56.49 | kergoth | does a little dance |
| 01:58.54 | kergoth | i just got past the last issue remaining with the separated ui/server :D |
| 01:59.18 | ka6sox | excellent |
| 01:59.50 | kergoth | fixing bb.build to use subprocess did it, i suspect its the close_fds, something with one of the open fds in the worker |
| 01:59.55 | kergoth | was hoping that was the case |
| 02:05.29 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:15.16 | *** join/#oe kgilmer (~kgilmer@ntngsk052174.ngsk.nt.ftth4.ppp.infoweb.ne.jp) |
| 02:15.22 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 02:32.19 | foerster | kergoth: you got it fixed? |
| 02:32.30 | kergoth | no longer see it with bb.build using subprocess |
| 02:32.55 | foerster | interesting |
| 02:33.21 | kergoth | indeed. i hate doing something like that, not really knowing the root cuase |
| 02:33.22 | kergoth | *but* |
| 02:33.31 | kergoth | i found a thing that stated what can cause a process to stop |
| 02:33.35 | kergoth | it's not just SIGSTOP |
| 02:33.48 | foerster | right, ttin, ttout |
| 02:33.50 | kergoth | there's a different event that stops a process if the process tries to read from a tty while its backgrounded |
| 02:33.51 | kergoth | yeah |
| 02:34.00 | kergoth | thats my working theory, but i have no idea what fd its trying to read or why :P |
| 02:34.06 | foerster | but none of those are backgrounded, are they? |
| 02:34.31 | kergoth | not sure what the definition of backgrounded is, from the perspective of what's sending the signal |
| 02:34.48 | kergoth | either way, the bb.build change had to happen, so we'll see -- if it crops up again we can dive into it again |
| 02:34.59 | foerster | i have a test case here that fails every time for me |
| 02:35.06 | foerster | so i can try your change and see if it fixes it too |
| 02:35.35 | foerster | my local php 5.3.3 recipe goes to sleep every time |
| 02:35.39 | kergoth | that would be good, give me second |
| 02:36.04 | kergoth | okay, the top 3 commits on my github master |
| 02:36.22 | kergoth | was surprisingly painless to get done |
| 02:36.36 | foerster | ok, i'll bring em in and try it |
| 02:37.24 | kergoth | the only real headache was implementing tee in python for the shell tasks |
| 02:37.40 | kergoth | but that was fairly minor |
| 02:38.41 | foerster | fml |
| 02:38.54 | foerster | php didn't fail any more (before bringing in your change) |
| 02:39.02 | kergoth | wtf |
| 02:39.13 | foerster | it was broken 100% every time for the past week |
| 02:39.21 | foerster | i had to keep switching back to master to get past it |
| 02:39.30 | foerster | wait |
| 02:39.31 | foerster | lied |
| 02:39.36 | foerster | i thought it was in do_configure |
| 02:39.41 | foerster | it's in do_compile, just went to sleep |
| 02:39.44 | kergoth | ah |
| 02:39.47 | kergoth | good |
| 02:40.06 | foerster | \_ sh -c pear -q info PHP_Archive 2>/dev/null|grep 'API Version' |
| 02:40.17 | foerster | that is where it's causing problems. |
| 02:40.18 | kergoth | huh |
| 02:40.20 | foerster | ok, let me bring those in |
| 02:40.32 | foerster | php does some crazy shit during compile :) |
| 02:40.57 | kergoth | apparently |
| 02:49.24 | foerster | ok, running again |
| 02:50.28 | *** join/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net) |
| 02:52.03 | foerster | woo |
| 02:52.06 | foerster | kergoth: fixed |
| 02:52.33 | kergoth | nice |
| 02:54.18 | *** join/#oe lostincake (~Aditya@pool-96-255-243-239.washdc.fios.verizon.net) |
| 03:01.12 | *** join/#oe fraxinath (~quassel@p4FD64FE6.dip.t-dialin.net) |
| 03:01.44 | kergoth | we'll have to prep to get it merged in the near future |
| 03:01.50 | kergoth | (the separate branch, that is) |
| 03:01.58 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
| 03:02.09 | foerster | yea |
| 03:02.23 | foerster | most of the commits can probably be squashed |
| 03:03.48 | kergoth | yeah, likely 1) separate into the process server, 2) keyboard interrupt fixes, 3) cache load progress, .. |
| 03:04.04 | kergoth | merge into those |
| 03:04.59 | foerster | ok. How about your latest changes -- just leave in master and rebase separate branch onto it? |
| 03:05.25 | kergoth | yeah, thats what i was planning on doing |
| 03:05.30 | kergoth | since they're fairly independent |
| 03:05.46 | foerster | we still have keyboardint in cooker |
| 03:05.49 | foerster | i'll take that out |
| 03:05.59 | kergoth | ah, yeah, forgot there were still remnants |
| 03:06.04 | foerster | (remnant from rebasing onto master i suppose) |
| 03:06.48 | foerster | i'll try to get the separate branch cleaned up into distinct changes as mentioned |
| 03:07.18 | foerster | might not be til some time this weekend |
| 03:30.53 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 03:31.15 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r5374097752 10bitbake.git/lib/bb/ (build.py utils.py): |
| 03:31.15 | CIA-101 | build: use bb.process instead of os.system |
| 03:31.15 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 03:31.19 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r4262c26d36 10bitbake.git/lib/bb/utils.py: |
| 03:31.19 | CIA-101 | utils: fix calls to close() in the lock/unlock functions |
| 03:31.19 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 03:31.22 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rf99ee4680c 10bitbake.git/lib/bb/ (build.py utils.py): |
| 03:31.22 | CIA-101 | build: use a contextmanager for locks |
| 03:31.22 | CIA-101 | Also don't bother passing logfile to exec_func_python, at least until we start |
| 03:31.22 | CIA-101 | adding the logfile as a file handler to the bitbake logger. |
| 03:31.23 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 03:31.31 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rc63e55564a 10bitbake.git/lib/bb/process.py: |
| 03:31.31 | CIA-101 | process: add subprocess-based bits |
| 03:31.31 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 03:35.12 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r51076c3737 10bitbake.git/lib/bb/build.py: |
| 03:35.12 | CIA-101 | build: fix remnant access of logfile in exec_func_python |
| 03:35.12 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 03:43.23 | foerster | kergoth: added preliminary support for LogRecord in runningbuild (works in goggle) |
| 03:43.27 | kergoth | nice |
| 03:43.33 | foerster | too many messages are printed straight to the screen though |
| 03:43.37 | foerster | instead of sent as log messages |
| 03:44.03 | kergoth | the problem is python functions, they still have access to stdout right now. i'm thinking we should just kill it entirely |
| 03:44.09 | foerster | soon |
| 03:44.31 | kergoth | either that or we send it to bb.plain, but there's no real excuse for doing that, from python you can use teh logging / messaging functions |
| 03:45.36 | foerster | https://github.com/foerster/bitbake/commit/17691054acb54f234d48385d917803317b6f2bbc |
| 03:45.51 | foerster | ok, that's all for tonight. baby gets up early |
| 03:47.09 | kergoth | night |
| 04:13.55 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 04:21.53 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 04:24.14 | *** join/#oe ksinkar (~ksinkar@static-mum-59.181.108.105.mtnl.net.in) |
| 04:28.16 | *** join/#oe Romke|off (~Romke@82-170-233-174.ip.telfort.nl) |
| 04:34.11 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 05:05.25 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 05:06.44 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 05:59.41 | *** join/#oe supernaut (~brian@echo.atld.org) |
| 05:59.51 | *** join/#oe nitink (~nitink@nat/intel/x-roxncbmheeulhwao) |
| 05:59.52 | *** join/#oe zlt_ (~zlt@li146-250.members.linode.com) |
| 05:59.52 | *** join/#oe coreyfro (~coreyfro@dsl092-012-151.sfo1.dsl.speakeasy.net) |
| 05:59.52 | *** join/#oe julianpid (~julianpid@62.200.22.2) |
| 05:59.52 | *** join/#oe Kevin` (~kevin@router.kwzs.be) |
| 05:59.52 | *** join/#oe cpo (~cpo@helix.mybll.net) |
| 06:07.06 | *** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
| 06:21.43 | *** join/#oe dth_ntb (~dth@a89-183-4-63.net-htp.de) |
| 06:26.46 | JaMa|Off | khem: maybe there is one more gcc-4.5 issue, my u-boot doesn't realy start kernel (only reads it) when built with gcc-4.3, when I rebuild same u-boot sources with 4.2.1 it works OK.. trying 4.3 now |
| 06:29.51 | *** join/#oe anarsoul_ (~anarsoul@80.249.90.202) |
| 06:31.26 | khem | JaMa|Off: k |
| 06:31.50 | khem | JaMa|Off: we can look into it if you have some pointers |
| 06:34.48 | JaMa|Off | khem: I'll try to narrow it a bit more first |
| 06:35.06 | JaMa|Off | khem: now I can confirm that angstrom-2008.1 toolchain is OK too |
| 06:36.14 | JaMa|Off | I would try to upgrade binutils to 2.20.1 as sane-toolchain has first |
| 06:36.20 | JaMa|Off | then gcc to 4.4 |
| 06:36.43 | JaMa|Off | and then I'll let you know where it broke |
| 06:39.01 | *** join/#oe rsalveti (~rsalveti@201.82.72.47) |
| 06:53.16 | *** join/#oe B_Lizzard (~havoc@athedsl-432928.home.otenet.gr) |
| 07:05.59 | *** join/#oe mrmoku` (~mrmoku@ppp-188-174-124-83.dynamic.mnet-online.de) |
| 07:08.34 | *** join/#oe vps (~vitus@145.253.169.210) |
| 07:25.54 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 07:29.57 | *** join/#oe guufy (~Guufy@c-24-130-108-191.hsd1.ca.comcast.net) |
| 07:31.05 | eFfeM_work | gm |
| 07:34.25 | *** join/#oe kgilmer (~kgilmer@ntngsk052174.ngsk.nt.ftth4.ppp.infoweb.ne.jp) |
| 07:42.32 | mckoan | good morning |
| 07:44.59 | lostincake | greetings |
| 07:56.13 | khem | eFfeM_work: hey I committed a gcc fix that could help your case with mediatomb |
| 07:56.16 | khem | try it out |
| 07:57.35 | eFfeM_work | khem, will do, just did a pull from head and rebuilt |
| 07:59.24 | B_Lizzard | Why --disable-static in libsdl-x11-1.2.14? |
| 07:59.35 | B_Lizzard | All other sdl libraries build static libs |
| 08:01.39 | *** join/#oe bandwidthcrunch (~quassel@122.166.104.245) |
| 08:06.17 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 08:07.30 | *** join/#oe hansdampf1 (~moritz@212.77.183.72) |
| 08:13.02 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:13.27 | *** join/#oe rschus (~rschus@251.118.101-84.rev.gaoland.net) |
| 08:19.54 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 08:21.48 | hrw | orning |
| 08:22.16 | hrw | khem: thanks for tracking gcc bugs and regressions |
| 08:22.38 | *** join/#oe roza (~ron@nat/cisco/x-piukdzuxbiajxuog) |
| 08:23.28 | ka6sox | morning hrw |
| 08:27.20 | *** join/#oe dth_ntb (~dth@a89-182-14-79.net-htp.de) |
| 08:33.51 | *** join/#oe morphis_ (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 08:34.55 | *** join/#oe GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net) |
| 08:46.30 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 08:48.40 | *** join/#oe kristoffer (~kristoffe@c-1cdce555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 08:51.07 | *** join/#oe bluelightning (~paul@158.43.2.102) |
| 08:51.07 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:04.34 | *** join/#oe Slyon (~lukas@2001:4ca0:0:f202:227:10ff:fe5c:b12c) |
| 09:06.40 | *** join/#oe ksinkar (~ksinkar@static-mum-59.181.108.105.mtnl.net.in) |
| 09:08.20 | *** join/#oe hansdampf (~moritz@212.77.183.113) |
| 09:17.54 | *** join/#oe playya (~playya@93.216.209.196) |
| 09:17.54 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 09:20.07 | *** join/#oe esbenh (~esbenh@77.233.226.4) |
| 09:25.47 | *** part/#oe dth_ntb (~dth@a89-182-14-79.net-htp.de) |
| 09:34.47 | *** join/#oe tws (~Miranda@mm-220-143-84-93.dynamic.pppoe.mgts.by) |
| 09:36.07 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 09:37.28 | *** join/#oe morphis_ (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 09:41.31 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 09:44.36 | *** join/#oe rschus1 (~rschus@88.163.71-86.rev.gaoland.net) |
| 09:46.13 | JaMa|Wrk | khem: fyi u-boot with gcc-4.4.4 still works, next I'll try gcc-4.5 without linaro patches |
| 09:46.49 | JaMa|Wrk | hrw: no known issues with u-boot and linaro gcc-4.5 patches? ^ |
| 09:46.55 | *** join/#oe atiti (~atiti@nbbd.imm.dtu.dk) |
| 09:47.45 | JaMa|Wrk | hrw: it's not hanging at mmc init like this one https://bugs.launchpad.net/gcc-linaro/+bug/616614 |
| 09:48.25 | hrw | JaMa|Wrk: now I have only one device running 24/7 with uboot - pandaboard. and it still uses old 2010.09-rc uboot |
| 09:49.42 | hrw | JaMa|Wrk: and that bug needs update as toolchain changed in meantime |
| 09:51.06 | *** join/#oe rschus (~rschus@88.163.71-86.rev.gaoland.net) |
| 09:54.23 | JaMa|Wrk | I have it with even older u-boot :/ u-boot-nokia900-2010.06+gitr0+bd2313078114c4b44c4a5ce149af43bcb7fc8854-r67.bin |
| 09:54.42 | JaMa|Wrk | not yet in OE, because of this issue.. |
| 09:57.14 | *** join/#oe GarthPS (~quassel@cam44-2-82-235-243-25.fbx.proxad.net) |
| 10:13.26 | *** join/#oe GarthPS (~quassel@cam44-2-82-235-243-25.fbx.proxad.net) |
| 10:20.27 | *** join/#oe denix (~denys@nat/ti/x-ttkyleejdgmeuunh) |
| 10:27.34 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 10:28.26 | *** join/#oe GarthPS (~quassel@2a01:e35:2ebf:3190:21d:e0ff:fe5b:2775) |
| 10:34.02 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:53.05 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
| 10:58.47 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
| 11:11.57 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 11:22.13 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 11:43.42 | *** join/#oe obi (~obi@unaffiliated/obi) |
| 11:53.34 | *** join/#oe rsalveti (~rsalveti@201.82.72.47) |
| 11:54.43 | *** join/#oe rob_w (~bob@217.237.177.190) |
| 12:08.49 | *** join/#oe GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net) |
| 12:09.39 | *** join/#oe CMoH-notebook (~cipi@95.76.74.1) |
| 12:09.39 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 12:26.22 | tasslehoff | I've compiled a uImage and a cpio.gz, but can OE assist me in creating a kernel *with* an initramfs? |
| 12:29.07 | *** join/#oe dth (~dth@a89-182-14-79.net-htp.de) |
| 12:29.17 | grund | tasslehoff: you're doing it to have that initramfs be the final rootfs, right? |
| 12:30.13 | tasslehoff | grund: exactomundo :) |
| 12:30.19 | tasslehoff | has a plan |
| 12:30.32 | grund | yes, it works quite nice |
| 12:31.35 | grund | your recipe is building the cpio.gz for your rootfs? |
| 12:31.51 | *** part/#oe dth (~dth@a89-182-14-79.net-htp.de) |
| 12:32.24 | tasslehoff | grund: yes, I have given cpio.gz as one of the IMAGE_FSTYPES in local.conf |
| 12:32.39 | tasslehoff | OE gave me a 3.1M uImage and a 40M cpio.gz |
| 12:33.32 | grund | us the minimal-image as a starting point |
| 12:35.40 | grund | you can put the IMAGE_FSTYPES right in the .bb, helpful if you don't want every image to be a ramdisk |
| 12:37.11 | tasslehoff | grund: I've been creating and using a tar.bz2 rootfs for some months, so my task now is just figuring out how to get an initramfs instead. |
| 12:37.26 | grund | ahh |
| 12:38.51 | grund | am I missing something? isn't that that cpio.gz your initramfs? |
| 12:40.09 | tasslehoff | grund: yes it is, but on #beagle I was adviced to build a kernel that includes the initramfs, so I just wanted to check if OE could do that. |
| 12:40.59 | *** join/#oe B_Lizzard (~havoc@athedsl-432928.home.otenet.gr) |
| 12:44.46 | grund | ok, I see now |
| 12:45.34 | tasslehoff | grund: Guess I could very well have them separated. I'm just unsure how to decide on addresses and stuff when loading kernel and initramfs to ram from u-boot |
| 12:47.07 | grund | I'm not sure about the built in. You'd have to have the kernel recipe point at the rootfs working directory |
| 12:47.14 | grund | we do the separate file |
| 12:47.58 | tasslehoff | grund: ok. think I'll try that to begin with as well |
| 12:48.20 | grund | and use mkimage to make it easier on u-boot |
| 12:48.23 | grund | ${STAGING_BINDIR_NATIVE}/mkimage -A arm -O linux -T ramdisk -C gzip \ |
| 12:48.23 | grund | + -a 0x0 -e 0x0 -n uInitramfs -d ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.uimage |
| 12:48.50 | grund | (oops, drop that + out of there) |
| 12:49.15 | grund | then depending on the size of your kernel, load the second uimage after the first |
| 12:49.48 | grund | we do 0x81600000 or 0x83000000 |
| 12:50.09 | grund | and then bootm 0x80000000 0x83000000 |
| 12:53.48 | tasslehoff | let's see... that creates a uImage from the cpio.gz? |
| 12:54.51 | *** join/#oe davidlt (~davidlt@90-158.203-62.cust.bluewin.ch) |
| 12:55.17 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 12:57.24 | grund | tasslehoff: that converts the cpio.gz to a u-boot binary, little easier on the boot command |
| 12:57.45 | grund | you're already getting the uImage and cpio.gz, right? |
| 12:57.49 | ericben | good morning |
| 12:58.18 | tasslehoff | grund: yes, so those instructions take me a long way. thanks a lot |
| 12:58.36 | *** join/#oe marcosmamorim (~marcos@187.82.13.99) |
| 12:58.53 | grund | np |
| 13:09.46 | *** join/#oe marcosmamorim (~marcos@187.82.13.99) |
| 13:16.27 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 13:21.00 | ant_work | tasslehoff: if you define an INITRAMFS_IMAGE = "initramfs-xyz-image" this will be embedded in kernel |
| 13:21.35 | ant_work | though, I've never seen a > 40MiB kernel.. |
| 13:21.50 | ant_work | is ok for small images |
| 13:22.13 | tasslehoff | ant_work: yeah. |
| 13:22.31 | ant_work | we actualy have a 54KiB age |
| 13:22.38 | ant_work | *image |
| 13:22.56 | ant_work | I think is recoed in OE ;) |
| 13:23.05 | tasslehoff | hehe |
| 13:24.04 | ant_work | cpio.lzma is 30% smaller than cpio.gz, in our tests |
| 13:25.27 | tasslehoff | I'm exploring ways to have a read-only rootfs. Initramfs and Unionfs are the suggestions I have so far. |
| 13:40.20 | *** join/#oe mems (~rob@87-194-128-93.bethere.co.uk) |
| 13:42.18 | *** join/#oe mnabil (~mnabil@41.34.179.34) |
| 13:43.25 | mems | Hey guys. bitbake is telling me that "multiple .bb files are due to be built which each provide virtual/psplash", but I can't work out exactly what's wrong. |
| 13:47.18 | ant_work | mems: is nothing serious, stll there are some virtual providers issues. Note that anyway the superfluous package will be built but not installed. |
| 13:48.14 | mems | ant_work: hmm, ok. makes me feel like I'm not in control ;) |
| 13:48.25 | ant_work | awaiting a fix in OE soon, you can 'fix' it from your side expliciting the PREFERRED_PROVIDER in your local.conf |
| 13:48.52 | mems | yea, I've got a PREFERRED_PROVIDER for it in my local.conf |
| 13:48.57 | mems | the warning still comes up though |
| 13:49.01 | mems | this is expected? |
| 13:49.13 | ant_work | how did you do it? |
| 13:50.10 | mems | PREFERRED_PROVIDER_virtual/psplash = "psplash-sr" |
| 13:50.20 | mems | (my replacement is called "psplash-sr") |
| 13:51.37 | mems | and I have copied the psplash recipe into my own recipe tree, calling it psplash-sr.bb |
| 13:51.45 | kergoth | morning |
| 13:51.49 | mems | (sorry, psplash-sr_svn.bb) |
| 13:52.08 | ant_work | mems: he he .. I found it .. http://patchwork.openembedded.org/patch/195/ |
| 13:53.05 | mems | reads |
| 13:55.43 | mems | hmm, ok, those guys discussing that patch don't actually resolve on a solution I think |
| 14:00.10 | *** join/#oe DJWillis (djwillis@cpc3-bath5-2-0-cust220.aztw.cable.virginmedia.com) |
| 14:00.18 | ant_work | <PROTECTED> |
| 14:00.24 | ant_work | ;) |
| 14:03.36 | ant_work | btw nowaday distro are setting SPLASH ?= '${@base_contains("MACHINE_FEATURES", "screen", "psplash", "",d)}' |
| 14:03.52 | mems | yup, I've just found that in org.openembedded.dev ;) |
| 14:04.05 | mems | investigating whether I want to port that into our stable branch |
| 14:04.05 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 14:04.33 | kergoth | JaMa|Wrk: good catch on the revision key regression -- i can't wait for the fetcher rewrite.. |
| 14:05.25 | kergoth | did everyone read http://bec-systems.com/site/755/yocto-and-openembedded ? |
| 14:05.30 | kergoth | please do so if you haven't |
| 14:09.35 | mems | speaking of stable branches, is stable/2009 still the "most recent" stable branch, or has another one developed? |
| 14:10.04 | kergoth | as far as i know it is, but it depends on what you're trying to accomplish |
| 14:10.13 | *** join/#oe dth (~dth@a89-182-130-216.net-htp.de) |
| 14:10.19 | foerster | kergoth: one more piece of fun https://github.com/foerster/bitbake/commit/9ea41409ba7f83ec13a9739c15e0920a2c0deee8 |
| 14:10.27 | foerster | has to get back to work work now :) |
| 14:10.29 | mems | kergoth: reasonably infrequent breakage ;) |
| 14:10.30 | kergoth | there's also the release version of OE, but which is at a fixed position, no more fixes going forward, adn there's the ongoing testing branch |
| 14:10.39 | *** part/#oe dth (~dth@a89-182-130-216.net-htp.de) |
| 14:11.03 | mems | are the releases tagged in the repo? |
| 14:11.26 | CIA-101 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r369c3002ab 10openembedded.git/recipes/linux/ (15 files in 2 dirs): |
| 14:11.26 | CIA-101 | linux-omap 2.6.37rc: bump to rc5 |
| 14:11.26 | CIA-101 | Signed-off-by: Koen Kooi <koen@beagleboard.org> |
| 14:11.51 | *** join/#oe marcosmamorim (~marcos@187.82.13.99) |
| 14:12.08 | kergoth | foerster: cool, thanks for the fixes. up next (in addition to the ^C in bin/bitbake thing) we need to make *absolutely certain* that log messages / errors / exceptions seen early in the startup are visible to the user -- its still occasionally possible to run bitbake and have it silently return -- going to revisit how i handle the log handlers today, and likely rework bb.event to stop the worker_pid and ui crap in favor of registering handlers |
| 14:12.08 | kergoth | he events |
| 14:12.15 | kergoth | makes a todo list for the day |
| 14:12.16 | kergoth | mems: yep |
| 14:12.22 | ant_work | kergoth: needs some discussion but imho what is blocking OE from picking each new Poky's core-improvement? |
| 14:12.36 | ant_work | we have people with enough skillz here too |
| 14:12.39 | kergoth | ant_work: not sure what you mean. i'm already syncing poky's bitbake upstream |
| 14:12.49 | kergoth | syncing poky's metadata with OE makes no sense until the yocto decision is made |
| 14:12.49 | ant_work | not bitbake, OE core |
| 14:12.55 | kergoth | because OE may very well base upon poky as its core |
| 14:13.01 | kergoth | so any work there could very well be wasted |
| 14:13.13 | ant_work | yes, see my point |
| 14:13.44 | kergoth | *today* a voting period is starting to grant the board the power to make the call with the tsc's guidance |
| 14:13.46 | ant_work | let say we could have own toolchain and follow behind them |
| 14:13.58 | ant_work | I see |
| 14:14.33 | ant_work | kergoth: sooner or later they will stop to spend time on old hw (read old arm CPU) |
| 14:14.35 | foerster | kergoth: for development, i put the entire bin/bitbake in try/except to catch anything that dies - that's proven useful here. |
| 14:14.37 | kergoth | ant_work: if we do base on them, the idea is poky would be the stable core that we build upon -- another way to put it would be us *using* them, the same way we use bitbake -- OE would consist of layers built upon the poky layers |
| 14:14.41 | ant_work | linaro already did |
| 14:15.02 | ant_work | kergoth: right |
| 14:15.15 | ant_work | ab-using them |
| 14:15.20 | kergoth | foerster: nice, that is useful. in *theory* the 'uncaught exception' handler should work, but it doesn't appear to be |
| 14:15.44 | kergoth | ant_work: imo one of poky's biggest advantages, in addition to the pool of developers being contributed by yocto member companies, is the development model |
| 14:15.54 | kergoth | using a pull model almost guarantees the more stable core |
| 14:15.58 | ant_work | nod |
| 14:15.58 | foerster | kergoth: that's how I figure out what's broken in the various UIs - I catch the exceptions they're throwing and then go fix |
| 14:16.07 | kergoth | but we don't want OE to move that way, because it would sacrifice our flexibility and openness a bit |
| 14:16.12 | ericben | summary of poky/oe : http://bec-systems.com/site/755/yocto-and-openembedded |
| 14:16.22 | kergoth | ericben: yeah :) its a nice writeup |
| 14:16.31 | kergoth | LWN should have an article out shortly about it too |
| 14:16.34 | kergoth | hopefully today |
| 14:16.57 | *** part/#oe mems (~rob@87-194-128-93.bethere.co.uk) |
| 14:17.08 | kergoth | everyone needs to read both, ideally, to make sure everyone understands what exactly yocto is |
| 14:18.04 | ant_work | kergoth: I'm not sure the lack of review for pending patches is due to lazyness |
| 14:18.20 | ant_work | people are usually much busy in Q4 |
| 14:18.24 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 14:18.44 | ant_work | the, khem asked for a slow-down in sight of a 'release' |
| 14:18.49 | kergoth | i don't think its laziness, its just the nature of the beast -- without going *through* people to get into the repo, some things are going to end up in without review, there's no helping that. we can try, but.. |
| 14:19.00 | ericben | I don't think it's lazyness it's that there are so many areas in OE that peoples can't handle avery area of the thing |
| 14:19.27 | kergoth | ericben: personally, 90% of the patches that hit my inbox get muted/archived, because they're to things i just don't know anything about or care about |
| 14:19.31 | kergoth | i'm sure i'm not the only one in that boat |
| 14:19.42 | cbrake | is in that boat |
| 14:19.51 | kergoth | of course, poky's metadata is so much smaller that its easier for the maintainers to have a high level grasp of everything they have to review |
| 14:20.03 | ant_work | imho the ML is hogged by too many commits |
| 14:20.07 | ericben | of course. See micro distro : it was broken and there seems to be 1 user of it ! |
| 14:20.09 | kergoth | so, its not that i think oe's workflow is "bad" necessarily, its just two different ways of working |
| 14:20.16 | ant_work | it was better with bugzilla/ML/patchwork |
| 14:20.52 | eFfeM_work | khem, gcc patch failure on head (everything freshly pulled) failing patch is gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch; see http://pastebin.ca/2015568 |
| 14:20.52 | ant_work | bitrotting bugzilla was a bad decision |
| 14:21.30 | ericben | eFfeM_work: strange it builds fine here |
| 14:21.49 | cbrake | bugzilla seems to need someone to watch it, assign bugs to people, find volunteers to work on things, etc |
| 14:22.08 | Crofton|work | assigning bugs to people without talking to them is a bad idea .... |
| 14:22.09 | cbrake | the same could probably be said for patchwork |
| 14:22.09 | eFfeM_work | ericben: dev head? I did a fresh git pull; this was on our autobuilder which builds really from scratch |
| 14:22.10 | ant_work | sure, but having a huge ML won't help |
| 14:22.17 | eFfeM_work | cbrake: are we starting wiht testing branch again ? |
| 14:22.23 | ericben | eFfeM_work: head of yesterday |
| 14:22.30 | cbrake | eFfeM_work: yikes, its Fri |
| 14:22.34 | Crofton|work | heh |
| 14:22.38 | cbrake | eFfeM_work: yes, the plan is to restart it this week |
| 14:22.42 | cbrake | gets busy ... |
| 14:22.45 | eFfeM_work | cbrake: TGIF |
| 14:22.56 | ant_work | anyway, we all know THE pull-model of reference: linux kernel |
| 14:23.02 | Crofton|work | cbrake, do not rush, I need to push an i2c-tools fix |
| 14:23.28 | cbrake | Crofton|work: ok, let me know |
| 14:25.57 | eFfeM_work | ant_work: ML has indeed quite some patches, underlying cause is probably lack of recipe ownership |
| 14:26.01 | Crofton|work | ant_work, you just became an ev member right? |
| 14:26.06 | foerster | kergoth: uncaught exception handler is using logger - but nothing in bin/bitbake handles the messages. Maybe just add a handler to dump the messages in bin/bitbake? |
| 14:26.06 | ant_work | kergoth: anyway, we should have a separate ring of security for commits touching the core/toolchain |
| 14:26.24 | Crofton|work | once again, divide number of recipes by active community members |
| 14:26.42 | ant_work | Crofton|work: yep |
| 14:26.52 | Crofton|work | did you get added to the members list? |
| 14:27.17 | ant_work | seems not |
| 14:27.28 | ant_work | still 34 items |
| 14:27.31 | Crofton|work | it is not high traffic |
| 14:27.41 | ant_work | not big issue |
| 14:27.52 | kergoth_ | foerster: if you see bb.event, you'll note that it uses atexit to ensure that the ui_queue of events is dumped on exit if its not empty, and the LogHandler which gets added redirects log messages to bb.event, and if bb.event gets events before the ui is started, they go into ui_queue ;) |
| 14:28.22 | ant_work | eFfeM_work: sure, ownership... is like geting married ;) |
| 14:28.24 | kergoth_ | a tad unnecessarily complex... |
| 14:29.05 | otavio | ponders if people is planning a "migration path" for users from "release" |
| 14:29.50 | Crofton|work | for example, today I won i2c-tools because it makes my life painful |
| 14:30.06 | Crofton|work | going forward Iwill jsut watch to make sure people do not break it again though :) |
| 14:30.25 | eFfeM_work | ant_work: I've mentioned this before, and I know some people disagree with this but I feel we have too much old cruft around that no one cares about, and some devs just seem to create new recipes without cleaning up or maintaining the old ones. |
| 14:30.45 | eFfeM_work | Crofton|work: congratulations on your win ;-) |
| 14:31.20 | kergoth_ | foerster: that queue is necessary to ensure that events fired from the server before the UI comes up are held somewhere -- but we should just be able to redirect those into the event_queue instead, since it has its lovely feeder thread sending the bits along.. |
| 14:31.28 | kergoth_ | foerster: yet another area that's simplified by the separation |
| 14:32.08 | foerster | kergoth_: right. |
| 14:32.38 | kergoth_ | of course, bin/bitbake could always set up its own stream handler and formatter to send messages to the console, but really the ui should be doing all of that.. |
| 14:32.55 | foerster | well, the problem is when the UI throws an exception |
| 14:33.00 | foerster | which is sometimes the case early one |
| 14:33.25 | foerster | s/one/on/ |
| 14:33.49 | foerster | having one last safeguard in bin/bitbake seems nice to catch any startup errors |
| 14:34.35 | kergoth_ | well, let's go ahead and kill the uncaught exception handler method entirely, do your try/except as you suggest and send it to stderr |
| 14:34.40 | kergoth_ | definitely simplifies that aspect |
| 14:35.47 | foerster | kergoth_: i'll let you do that for now. I have to work on integrating gearman library into my app :) |
| 14:35.51 | kergoth_ | we still need to just rethink all the exception handling everywhere in bitbake |
| 14:35.57 | kergoth_ | sys.exit is still overused |
| 14:36.22 | kergoth_ | but we still need a clean way to show a traceback for *certain* exceptions, but only a pretty m essage and exit in other circumstances |
| 14:36.28 | kergoth_ | isn't very good with exception handling yet |
| 14:36.36 | kergoth_ | hehe, havef fun |
| 14:36.39 | foerster | isn't good with python, period ;) |
| 14:36.56 | CIA-101 | 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r48e6a06337 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: |
| 14:36.56 | CIA-101 | i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h. |
| 14:36.56 | CIA-101 | Thanks to John Faith for suggesting this approach on the ML. The problem is |
| 14:36.56 | CIA-101 | i2c-tools overwrites the header staged by the kernel. This breaks programs |
| 14:36.56 | CIA-101 | that depend on the kernel header. |
| 14:37.00 | kergoth_ | its always a learning experience, with any language :) |
| 14:37.10 | kergoth_ | i've been using it for years now and i still learn new things on a weekly basis, i swear |
| 14:37.31 | foerster | before this, I used it for a grand total of maybe a week |
| 14:37.36 | foerster | luckily, the basics are very simple |
| 14:38.04 | kergoth_ | nods |
| 14:38.40 | kergoth_ | i think what's taken me the longest is figuring out what's "pythonic" -- stopping tendencies to use, say, C or C++ like constructs in python instead of native mechanisms |
| 14:39.07 | foerster | synchronous gearman worker = cake. aynchronous = fml. damnit. |
| 14:39.13 | kergoth_ | :( |
| 14:39.16 | kergoth_ | reboots |
| 14:42.32 | CIA-101 | 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r9d138846f9 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: i2c-tools : Bump PR after changes to header file staging. |
| 14:43.01 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 14:47.47 | *** join/#oe grund (~grund@host65-17-84-58.birch.net) |
| 14:49.25 | eFfeM_work | cbrake: nice writeup on yocto and openembedded, thanks; ericben, thanks for bringing this to my attention |
| 14:51.23 | JaMa|Wrk | kergoth_: will you revert that fetcher _revision_key change? |
| 14:51.57 | kergoth_ | JaMa|Wrk: yeah, will do for now, we can revisit |
| 14:52.16 | JaMa|Wrk | kergoth_: I don't think it's actually used in OE metadata and if fetcher rewrite is planned then it should be resolved there |
| 14:52.56 | kergoth_ | nods, good point |
| 14:53.10 | kergoth_ | JaMa|Wrk: the fetcher rewrite is in yocto's 1.0 plan, on their wiki |
| 14:53.19 | kergoth_ | richard is planning on taking it on, i assume in the sprint the plan shows it in |
| 14:53.34 | JaMa|Wrk | still has to fix his persistend db :/ |
| 14:53.57 | JaMa|Wrk | <- wrong time to rebuild from scratch hits him again.. |
| 14:54.30 | kergoth_ | really dislikes the fact that autorev, etc exist at all -- better to use srctree if you're doing development, and lock it down if you don't |
| 14:54.38 | kergoth_ | s/don't/aren't/ |
| 14:54.47 | Crofton|work | agrees with kergoth |
| 14:55.13 | *** join/#oe RP (~richard@93-97-173-237.zone5.bethere.co.uk) |
| 14:55.53 | kergoth_ | oh, that srctree patch on the list -- looks solid to me |
| 14:56.07 | kergoth_ | when we switched it from exec_task to exec_func, we forgot that exec_task is what creates stamps :P |
| 14:57.01 | foerster | kergoth: see item 2 :) https://wiki.pokylinux.org/wiki/Yocto_1.0_Schedule#Sprint_B_.28closes_Jan_07.2C_11:59pm_PDT_--_pull_request_sent.2C_initially_reviewed.29 |
| 14:58.08 | kergoth_ | hehe, yeah, richard wanted to work on that, and then i went and stole it from him.. oops ;) |
| 14:58.14 | foerster | nice |
| 14:58.24 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 14:58.26 | kergoth_ | the fetcher rewrite could be fun too though, its always nice to take a crappy api and make it better |
| 14:58.50 | foerster | i looked into the fetcher for a few minutees, and quickly bailed :) |
| 14:59.01 | kergoth_ | i don't blame you |
| 14:59.16 | foerster | I wanted a way to get info from my package's git repo during configure |
| 14:59.25 | foerster | found some hack way somebody was using, seems to work |
| 15:01.39 | RP | kergoth: the fetcher stuff is not fun |
| 15:01.55 | RP | kergoth: I've tried to improve that code at least twice so far :/ |
| 15:02.23 | kergoth_ | ouch :( |
| 15:02.52 | kergoth_ | of course, a simple version is easy, its the corner cases that are problematic -- but what else is new, that's usually the case |
| 15:03.41 | ant_work | RP: there is no two without three, and the four comes by itself ;) |
| 15:04.43 | RP__ | kergoth_: The fetcher is a set of cornercases ;-) |
| 15:05.48 | kergoth_ | ponders |
| 15:08.12 | kergoth_ | RP__: damnit, i thought i had it, but i can't find that email you sent about the fetcher rewrite, do you have a link, or can you forward it? |
| 15:09.06 | kergoth_ | mutters |
| 15:09.58 | RP | kergoth_: https://lists.yoctoproject.org/pipermail/poky/2010-November/000102.html ? |
| 15:10.17 | kergoth_ | thanks |
| 15:11.26 | kergoth_ | RP: thoughts on killing AUTOREV? as i mention above, i'm personally of the opinion that for development, srctree is a better fit, or something like it, and for everything else it should be locked down -- killing it would definitely simplify things |
| 15:11.34 | RP__ | kergoth_: In fixing up some bits of bitbake, bluelightning has a couple of suggested changes I'd like to run by you |
| 15:11.43 | kergoth_ | okay, sounds good |
| 15:11.56 | RP__ | kergoth_: Firstly, adding an expand true/false option to getVarFlag |
| 15:12.43 | RP__ | kergoth_: The other is adding a vardepsexclude flag to variables to allow them to exclude dependencies from the hashes |
| 15:13.14 | RP__ | kergoth_: Also there were the emails on the Poky list about having setVar a special case of setVarFlag - did you see those? |
| 15:13.18 | kergoth_ | an expand flag could be useful in a few different places.. there are multiple flags we use that we need expanded. e.g. lockfiles, dirs, ... |
| 15:13.45 | RP__ | kergoth_: It standardises the API a bit which I think is a good thing |
| 15:14.44 | kergoth_ | i like that from the persective of consolidating the logic. conceptually, the whole implementation of value vs flags feels a bit ugly to me, the use of 'content' and all, meh, but we can revisit that in a future bb.data refactoring or creation of a recipe class, if need be |
| 15:14.52 | *** join/#oe morphis_ (~morphis@p5489B45E.dip.t-dialin.net) |
| 15:16.33 | kergoth_ | vardepsexclude seems conceptually sane -- its just the other side of the variable local version of the blacklist/whitelist, really |
| 15:16.35 | *** join/#oe denix (~denys@nat/ti/x-jbeqqcjhvoktcgdo) |
| 15:17.03 | kergoth_ | so +1 on all of those for right now |
| 15:17.14 | RP__ | kergoth_: agreed and thanks |
| 15:17.23 | bluelightning | kergoth_: cheers |
| 15:17.42 | kergoth_ | does https://github.com/kergoth/bitbake/commit/53ec482 look reasonable sane to you guys? |
| 15:17.42 | RP__ | kergoth_: We'll push into poky and then we can feed into bitbake once we're proven they don't break things :) |
| 15:17.49 | kergoth_ | yeah, sounds good to me |
| 15:18.01 | kergoth_ | i haven't had a chance to look at the new pseudo fork bits yet |
| 15:18.16 | RP__ | kergoth_: Those are still a WIP and don't quite work yet :( |
| 15:18.24 | RP__ | Close to working but something in checksums isn't happy |
| 15:18.34 | RP__ | needs a 36 hour day |
| 15:18.59 | RP__ | taps foot waiting for github |
| 15:19.12 | kergoth_ | ah |
| 15:19.18 | kergoth_ | heh, agreed (re: 36 hours) |
| 15:19.42 | bluelightning | indeed |
| 15:19.44 | kergoth_ | (ignore the change to the import error messages, that shouldn't be in there) |
| 15:19.44 | CIA-101 | 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r39530eb597 10openembedded.git/recipes/i2c-tools/i2c-tools_3.0.2.bb: |
| 15:19.44 | CIA-101 | i2c-tools : Remove legacy staging. |
| 15:19.44 | CIA-101 | Thanks for pointing this out Koen. |
| 15:21.04 | RP__ | kergoth_: That API is much nicer, yes |
| 15:21.28 | *** join/#oe julianpid (~julianpid@62.200.22.2) |
| 15:21.44 | pb_ | morning kergoth_ |
| 15:21.45 | kergoth_ | k, thanks, just wanted a second set of eyes to make sure i wasn't completely insane |
| 15:21.48 | kergoth_ | morning pb_ |
| 15:23.02 | kergoth_ | RP__: notice how it has the factory that extracts the metadata bits and constructs it from that, rather than the classes being bound to the metadata -- i think fetch should work in a similar way for its configuration options |
| 15:26.19 | RP | kergoth_: right, something along those lines would be nicer |
| 15:26.33 | Crofton|work | cbrake, I think I am done screwing around |
| 15:35.03 | CIA-101 | 03Andreas Oberritter <obi@opendreambox.org> 07org.openembedded.dev * rbbd15964c3 10openembedded.git/contrib/oe-stylize.py: |
| 15:35.03 | CIA-101 | oe-stylize: remove trailing newline when printing unknown variable/routine |
| 15:35.03 | CIA-101 | Signed-off-by: Andreas Oberritter <obi@opendreambox.org> |
| 15:46.20 | *** join/#oe mems (~rob@87-194-128-93.bethere.co.uk) |
| 15:47.06 | mems | hey, the handhelds.org cvs is down and my OE build is trying to grab "updates-alternatives-cworth" from it, anyone know of a mirror? |
| 15:53.48 | mems | does anyone even know what this package does? |
| 15:54.16 | kergoth_ | yes, the same thing update-alternatives does in debian, and you won't get a functional image without it :) |
| 15:54.53 | mems | ok, any idea how I can get hold of the source for this, given that the cvs server it references is down? |
| 15:55.30 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r411b808b81 10bitbake.git/lib/bb/fetch/git.py: |
| 15:55.30 | CIA-101 | Revert "bitbake/git.py: Make sure different branches can have different revisions without triggering build count increases" |
| 15:55.30 | CIA-101 | Per Martin Jansa, this breaks compatibility. We can revisit in the future, |
| 15:55.30 | CIA-101 | likely during the fetcher rewrite. |
| 15:55.30 | CIA-101 | This reverts commit f3292fa11723c748ef1b4270384abf6d586a822e. |
| 15:56.01 | *** join/#oe kristoffer (~kristoffe@c-1cdce555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 15:57.49 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r20929afdd8 10bitbake.git/lib/bb/build.py: |
| 15:57.49 | CIA-101 | build: kill stdout in python functions |
| 15:57.49 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 15:58.00 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * ree1cce6ab2 10bitbake.git/lib/bb/ (build.py msg.py ui/knotty.py): |
| 15:58.00 | CIA-101 | build: send logging messages to the log file for python functions |
| 15:58.00 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 15:58.04 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r240d4a7ae8 10bitbake.git/bin/bitbake: |
| 15:58.04 | CIA-101 | Kill the uncaught exception handler |
| 15:58.04 | CIA-101 | We now wrap the main() in a try/except, ensuring that both the main portion of |
| 15:58.04 | CIA-101 | bin/bitbake and the UI raising an exception will be shown to the user. For |
| 15:58.05 | CIA-101 | the server and workers, we can ensure in the server itself that exceptions are |
| 15:58.22 | *** join/#oe dromede (~quassel@93-139-55-106.adsl.net.t-com.hr) |
| 16:01.54 | mems | ok, so please just take note that updates-alternatives-cworth won't build at all at the moment because of the CVS server apparently disappearing |
| 16:02.34 | kergoth_ | the handhelds.org server is down permanently, unfortunately |
| 16:02.56 | mems | oh |
| 16:03.05 | mems | so what happened to the updates-alternatives-cworth source? |
| 16:04.59 | kergoth_ | all the hh.o sources were put on our mirror, i thought, sources.openembedded.org, but i'm not sure, i'm not an admin |
| 16:04.59 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rdb7f960e5f 10bitbake.git/lib/bb/event.py: |
| 16:04.59 | CIA-101 | bb.event: fix MsgBase ref in fire_class_handlers |
| 16:04.59 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 16:05.11 | kergoth_ | starts rewriting bb.event |
| 16:06.05 | ant_work | take a snorkel with you |
| 16:06.19 | ka6sox | kergoth_, I've been unable to verify that we have *all* of it. as I find things that are missing I am gathering them up. |
| 16:07.43 | kergoth_ | ah |
| 16:08.06 | pb_ | what actually happened to hh.org, did george just decide to pull the plug on it in the end? |
| 16:09.05 | *** join/#oe Lopi_ (~Lopi@173-9-230-97-Illinois.hfc.comcastbusiness.net) |
| 16:10.46 | bluelightning | pb_: I'm not sure anyone knows but I suspect the logs just filled up |
| 16:10.55 | kergoth_ | heh |
| 16:11.17 | *** join/#oe denix (~denys@nat/ti/x-pxshwqucigbytldf) |
| 16:11.19 | bluelightning | I see the notice about it coming back on the week of dec 1 is still there |
| 16:11.28 | kergoth_ | heh |
| 16:11.54 | kergoth_ | i don't really miss it, and i'm sure i'm not the only one, but it would have been nice to have retrieved the full cvs repositories for some things, so we could construct new git repositories with history for things like ipkg-utils |
| 16:13.09 | *** join/#oe pespin (~pespin@135.pool85-50-83.dynamic.orange.es) |
| 16:14.11 | pespin | khem, hi, you told me to use LANGUAGES env-var to enable build of fortran cross-compiler, but using that env-var looks like deprecated way of doing it. |
| 16:14.47 | pespin | I've seen in several recipes something like this: --enable-languages=${enable_languages-all} |
| 16:15.27 | khem | pespin: find out why f77 is not being appended to enable-languages ? |
| 16:15.33 | pespin | which looks to me like a var used in OE to tell the languags, but I'm not able to find using grep where it's initialized >.< |
| 16:15.40 | kergoth_ | huh, the bitbake goggle ui is kind of cute |
| 16:15.41 | khem | pespin: may be bitbake -e gcc-cross |
| 16:15.50 | khem | gm all |
| 16:15.55 | kergoth_ | it should really default the trees to expanded though |
| 16:16.03 | kergoth_ | and possibly collapse a tree when it completes |
| 16:16.11 | khem | <PROTECTED> |
| 16:16.20 | khem | is like git revert <rev> |
| 16:16.24 | pespin | khem, what does the "-e" option do? |
| 16:16.24 | foerster | kergoth_: i like goggle so far - but yea, i have other ideas too (coloring of active items would be nice) |
| 16:16.32 | kergoth_ | yeah that would be really nice |
| 16:16.37 | kergoth_ | it took me a second to figure out what the icons were |
| 16:16.43 | ant_work | khem: hello |
| 16:16.48 | foerster | right - that gears are odd |
| 16:16.50 | khem | ant_work |
| 16:16.52 | khem | hi |
| 16:16.54 | kergoth_ | gears makes me think config |
| 16:16.58 | kergoth_ | like i click there to configure it, what? |
| 16:17.07 | foerster | green for "working", red for "dead/error" |
| 16:17.11 | *** join/#oe Lopi (~Lopi@173-9-230-97-Illinois.hfc.comcastbusiness.net) |
| 16:17.29 | kergoth_ | still, its a pleasant change from thousands of lines of log messages flying by :) |
| 16:17.35 | foerster | of note - I didn't see Preparing runqueue,etc coming through any more this morning |
| 16:17.36 | khem | pespin: -e is kind of preprocessing is to C compiler |
| 16:17.37 | foerster | agreed |
| 16:17.42 | ant_work | khem: about the pygtk / pygobject codegen... I tested an hack like this sed http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/python/python-pygtk_2.16.0.bb |
| 16:17.50 | mems | hmmm, {sources,mirrors}.openembedded.org seem to only cover ftp and http, not cvs |
| 16:18.01 | ant_work | khem: is not elegant but is in pygtk... |
| 16:18.04 | khem | ant_work: did you try the patch I suggested |
| 16:18.10 | ant_work | won't work |
| 16:18.17 | ant_work | see the sed ^^^ |
| 16:18.22 | ant_work | taht works (ofc) |
| 16:18.37 | kergoth_ | wtf, git hates me |
| 16:18.39 | kergoth_ | hmm |
| 16:18.51 | kergoth_ | ah! my own fault |
| 16:19.26 | ant_work | khem: there is one more issue, those codegen bits sould now be staged by pygobject (pygtk-codegen is deprecated) |
| 16:20.15 | khem | ant_work: not the best I believe you simply disabled pkg-config |
| 16:20.15 | foerster | kergoth_: when we get the stdout stuff resolved, I'll bring the ncurses UI back to functioning |
| 16:20.51 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rc67b95955d 10openembedded.git/classes/base.bbclass: |
| 16:20.51 | CIA-101 | base: use bb.plain, not print for build_summary |
| 16:20.51 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 16:20.58 | kergoth_ | foerster: the rebased branch and master both include the bits that kill stdout in python tasks, and also redirects logging messages to the log files for python tasks |
| 16:21.07 | kergoth_ | so it should now be in much better shape |
| 16:21.13 | kergoth_ | event handlers can still write to it right now though |
| 16:21.15 | ant_work | khem: the solution other packages have is e.g. http://tinyurl.com/37j2xko |
| 16:21.18 | kergoth_ | hence the above fix for the build summary |
| 16:21.23 | foerster | kergoth_: hm, ok. I still see a ton of "packaged xyz" messages |
| 16:21.30 | kergoth_ | hmm |
| 16:21.36 | foerster | or at least, I did this morning when playing around. |
| 16:21.37 | kergoth_ | that shouldn't be happening |
| 16:21.45 | khem | crap svn |
| 16:21.49 | kergoth_ | kicks off a build with it |
| 16:22.31 | khem | ant_work: thats much better |
| 16:22.57 | ant_work | he he |
| 16:23.16 | *** join/#oe T0mW (~Tom@24.102.196.152.res-cmts.tv13.ptd.net) |
| 16:23.24 | *** part/#oe T0mW (~Tom@24.102.196.152.res-cmts.tv13.ptd.net) |
| 16:23.54 | ant_work | khem: I really have no idea about the whole pygtk stuff...just trying to unbreak 'sugar' build |
| 16:24.15 | ant_work | and in fact I built that damned python-pygtksourceview |
| 16:24.39 | ant_work | but it, and many other, now depend on pygobject and not only pygtk |
| 16:25.03 | ant_work | so, somebody nowing that stuff should fix it.. :/ |
| 16:27.20 | *** join/#oe denix (~denys@nat/ti/x-ihtqntjfmreiasvl) |
| 16:29.33 | pespin | khem, |
| 16:29.34 | pespin | # LANGUAGES=c,c++${OBJC}${FORTRAN}${JAVA} |
| 16:29.34 | pespin | LANGUAGES="c,c++,objc" |
| 16:29.42 | pespin | that might be the problem :P |
| 16:30.00 | *** join/#oe atiti (~atiti@0103ds1-vir.0.fullrate.dk) |
| 16:30.34 | khem | pespin: yes thats what I have telling you to find why thats happening |
| 16:30.45 | khem | and that where bitbake -e will help |
| 16:30.54 | pespin | and FORTAN is not set anywhere, only GFORTRAN_FOR_TARGET |
| 16:31.03 | pespin | khem, yes,i took that from the output :) |
| 16:31.16 | khem | pespin: ok what does FORTRAN set to |
| 16:32.27 | pespin | khem, it's not initialized anywhere |
| 16:32.33 | khem | hmmm |
| 16:32.54 | kergoth_ | http://dl.dropbox.com/u/112715/Pictures/Screenshot-bitbake.png |
| 16:33.00 | kergoth_ | shows a build with the goggle ui, for the curious |
| 16:33.08 | kergoth_ | the gears are active tasks / recipes with active tasks |
| 16:33.16 | khem | pespin: which version of gcc are you using |
| 16:33.29 | *** join/#oe methril (~methril@189.27.129.63.dynamic.adsl.gvt.net.br) |
| 16:33.36 | *** join/#oe GarthPS (~quassel@2a01:e35:2ebf:3190:21d:e0ff:fe5b:2775) |
| 16:33.56 | pespin | khem, gcc-4.5 from OE |
| 16:34.01 | khem | pespin: add FORTRAN_linux-gnueabi = ",fortran" to gcc-4.5.inc |
| 16:34.04 | pespin | here you have the -e outpout -> http://filebin.ca/edwtb/tmp-gcc-cross |
| 16:34.20 | pespin | ok |
| 16:34.33 | khem | you will see # Language Overrides |
| 16:34.34 | khem | FORTRAN = "" |
| 16:34.34 | khem | JAVA = "" |
| 16:34.37 | khem | in that file |
| 16:35.09 | khem | pespin: is it for arm btw. |
| 16:35.23 | pespin | khem, yes |
| 16:35.30 | khem | ok |
| 16:35.32 | kergoth_ | foerster: i suspect os.system bypasses a replaced sys.stdin -- think we might have to resurrect the fd dup'ing madness to kill stdout fully in python tasks |
| 16:35.36 | kergoth_ | investigates |
| 16:35.49 | kergoth_ | think those are the only messages that hit the console right now |
| 16:35.52 | *** join/#oe tdebrouw` (~tdebrouw@91.182.24.72) |
| 16:35.54 | pespin | khem, now bitbake -c rebuild gcc-cross ? |
| 16:36.02 | foerster | kergoth_: bah, figures something crazy would be going on |
| 16:36.06 | khem | pespin: the change I suggested should help you java and fortran are disabled by default |
| 16:36.29 | JaMa|Wrk | khem: small update on u-boot issue: it happens with gcc-4.5 also without linaro patches, and gcc-4.4.4 is safe |
| 16:36.30 | khem | pespin: its not that easy |
| 16:36.42 | khem | JaMa|Wrk: cool. |
| 16:36.47 | pespin | clean && build? :P |
| 16:36.50 | khem | JaMa|Wrk: its a runtime issue |
| 16:36.51 | *** join/#oe GarthPS (~quassel@2a01:e35:2ebf:3190:21d:e0ff:fe5b:2775) |
| 16:36.58 | kergoth_ | foerster: http://bytes.com/topic/python/answers/850960-redirection-file-os-system - confirmed |
| 16:37.16 | JaMa|Wrk | khem: found few issues about u-boot (but build time) and with much newer revisions |
| 16:37.23 | JaMa|Wrk | khem: yes this one is runtime |
| 16:37.27 | khem | pespin: you can bitbake -c clean gcc-cross gcc-cross-initial gcc-cross-intermediate eglibc eglibc-initial |
| 16:37.34 | khem | then bitbake gcc-cross |
| 16:37.47 | JaMa|Wrk | khem: kernel is read OK, but it just says "Starting kernel" and nothing happens |
| 16:37.55 | khem | JaMa|Wrk: ok we need to dig more |
| 16:38.09 | khem | JaMa|Wrk: unfortunately |
| 16:38.25 | *** join/#oe sgw1 (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 16:38.27 | JaMa|Wrk | khem: I'll try to rebase our patches to newer u-boot rev |
| 16:38.29 | khem | JaMa|Wrk: probably try to find the faulty function |
| 16:38.41 | khem | JaMa|Wrk: yeah that wud be first guess |
| 16:39.16 | khem | kergoth_: is there a way that I can create a bitbake -c clean <toolchain> meta target |
| 16:39.18 | JaMa|Wrk | khem: I can give you workdirs for working and not-working build (with gcc-4.4.4 and gcc-4.5-without linaro) if you want but otherwise I'll try to upgrade it first |
| 16:39.54 | khem | JaMa|Wrk: upgrade first I would say |
| 16:40.04 | khem | if it does not happen upstream no point fixing it |
| 16:40.09 | khem | atleast not for free :) |
| 16:40.10 | kergoth_ | khem: not that i know of, no |
| 16:40.33 | khem | kergoth_: how can be achieve something like that |
| 16:40.57 | khem | may be a virtual package |
| 16:41.41 | khem | which cleans and rebuilds toolchain something like that |
| 16:41.42 | kergoth_ | hmmmm |
| 16:41.46 | kergoth_ | actually, yeah, you could do it |
| 16:41.51 | kergoth_ | use the depends flag of the task |
| 16:41.59 | kergoth_ | do_clean[depends] += "otherrecipe:do_clean" |
| 16:42.15 | khem | cute |
| 16:42.18 | khem | should try it out |
| 16:42.20 | JaMa|Wrk | khem: ok, will try, thanks |
| 16:42.25 | khem | brb |
| 16:42.54 | khem | "otherrecipe should it be recipe_pv.bb ? |
| 16:43.07 | khem | or can I just say eglibc:do_clean |
| 16:43.55 | kergoth_ | your meta recipe can just say eglibc:do_clean, and all the others you want cleaned |
| 16:44.05 | JaMa|Wrk | btw is here someone with device supported in recent u-boot and building u-boot with gcc-4.5? |
| 16:44.09 | kergoth_ | the depends flag is space separated list |
| 16:44.21 | kergoth_ | man i love python 2.6 contextlib |
| 16:44.30 | kergoth_ | <PROTECTED> |
| 16:44.32 | kergoth_ | <3 |
| 16:45.00 | kergoth_ | erk, forgot to do the fileno() bit |
| 16:45.08 | kergoth_ | you get the idea |
| 16:45.08 | kergoth_ | heh |
| 16:48.51 | pb_ | kergoth: yeah, exactly. there are/were a few projects on hh.org whose cvs histories would have been nice to have. |
| 16:49.05 | pb_ | oh well |
| 16:49.09 | kergoth_ | :\ |
| 16:49.22 | florian | what happened to it? |
| 16:49.25 | kergoth_ | one would think the disk would still be somewhere |
| 16:49.32 | kergoth_ | but i doubt they'd be cooperative |
| 16:52.32 | *** join/#oe denix (~denys@nat/ti/x-cvyrmnmacprwrsxz) |
| 16:52.38 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 16:56.29 | kergoth_ | foerster: what do you think of killing stdin/stdout/stderr entirely in the entire server process? the workers get them redirected anyway, and anything the server wants to show should go via the UI.. |
| 16:56.33 | kergoth_ | hmm |
| 16:56.53 | foerster | kergoth_: sounds like how it should be, i think. |
| 16:56.56 | kergoth_ | nods |
| 16:57.03 | kergoth_ | okay, will do that |
| 16:57.44 | kergoth_ | is confirming the os.system from python task thing |
| 16:58.08 | kergoth_ | hmm, goggle needs to word wrap the messages too |
| 16:59.53 | kergoth_ | hmm, it should also consider shifting all fully completed recipes (no tasks remaining) into its own section of the tree -- complete, so you don't have to scroll down |
| 17:00.12 | kergoth_ | probably sort currently active to the top as well |
| 17:00.17 | foerster | you're asking a lot :) |
| 17:00.20 | kergoth_ | hehe |
| 17:00.22 | kergoth_ | just musing |
| 17:00.33 | kergoth_ | knows *nothing* about gtk, and barely remembers qt |
| 17:00.38 | foerster | working with treemodels in gui stuff is never fun |
| 17:00.45 | kergoth_ | = user interaction noob |
| 17:01.08 | foerster | for example, just to do cell coloring, you have to start mucking with cellRenderers, etc |
| 17:01.11 | foerster | total PITA |
| 17:01.17 | kergoth_ | ugh |
| 17:01.31 | foerster | that's why it is as it is - it was easy |
| 17:01.51 | kergoth_ | n ods |
| 17:02.04 | kergoth_ | its slick as is, the rest is just polish |
| 17:02.34 | foerster | yea, i really like it |
| 17:02.40 | foerster | could put an input box on it |
| 17:02.42 | kergoth_ | we need to figure out how to implement some sort of configuration UI at some point, likely as a separate script |
| 17:02.43 | foerster | for commands :) |
| 17:03.09 | kergoth_ | the issue there is we need to flag the variables we want the *user* to be able to manipulate, assuming they're not an expert, and we need variable typing to show a nice interface |
| 17:03.14 | kergoth_ | thats a good idea |
| 17:03.43 | foerster | we'll have to set some option in cooker to not bail when done with a normal command or something, right? |
| 17:03.52 | foerster | that is, when using an interactive gui |
| 17:04.24 | kergoth_ | yeah, we'd have to ensure that we *always* send a shutdown, even after a cookercommand failed/completed, and kill the automatic bit |
| 17:04.32 | kergoth_ | should be fairly easy to do |
| 17:04.40 | foerster | yea, UI just does that when done |
| 17:05.09 | kergoth_ | yeah |
| 17:05.41 | *** join/#oe toi (~peter@d54C2AA76.access.telenet.be) |
| 17:06.08 | kergoth_ | now that we're making tangible progress i'm really starting to enjoy this. |
| 17:06.10 | kergoth_ | hehe |
| 17:06.15 | foerster | me too |
| 17:06.31 | *** join/#oe hansdampf (~moritz@212.77.183.113) |
| 17:06.41 | kergoth_ | every time we make a big improvement that took all of a day or two to implement, i think .. what the hell did we wait 7 years for that for? |
| 17:06.44 | kergoth_ | heh |
| 17:06.53 | kergoth_ | so much is just a matter of sitting down and doing it, instead of going 'yeah that would be nice' |
| 17:07.25 | foerster | true. For me, this is a nice departure from the daily grind, so it's enjoyable. |
| 17:07.34 | kergoth_ | nods |
| 17:08.28 | kergoth_ | for me, i need a second hobby. doing this shit at work and when i'm not "at work", and working from home full time, has made things rather fuzzy |
| 17:08.38 | kergoth_ | is my work day over? no idea, i'm messing with bitbake either way |
| 17:08.41 | foerster | i hear ya |
| 17:08.47 | foerster | i started working from home in april |
| 17:08.55 | kergoth_ | nice |
| 17:09.00 | foerster | tend to always be at least reading work stuff |
| 17:09.09 | foerster | even when i get bored |
| 17:09.27 | foerster | though, with the 1 year old here, i have a nice forced removal from the office |
| 17:09.36 | kergoth_ | hehe, i'm sure thats an adventure |
| 17:10.01 | foerster | babysitter leaves around 5-5:30, wife doesn't get home usually til 7, so I'm forced to stop working, which is good. |
| 17:10.17 | kergoth_ | nods |
| 17:11.05 | foerster | i have first pass at putting some colors on active tasks :) |
| 17:11.07 | kergoth_ | the fd redirection for exec_func_python definitely fixed it, it had to be python functions using os.system, figured. now to shift it so the whole server does it |
| 17:11.08 | foerster | kind of neat |
| 17:11.10 | kergoth_ | nice |
| 17:11.26 | kergoth_ | i wonder if we should keep an icon for color blind people, or if the light/dark is sufficient |
| 17:11.35 | foerster | i'm leaving the icon |
| 17:11.44 | kergoth_ | cool |
| 17:11.51 | foerster | b/c it does at least provide some indicator |
| 17:12.26 | foerster | hm. should make the top leve package line show color too |
| 17:12.39 | kergoth_ | eep, tried to ^C a goggle build and it appears to have become unresponsive |
| 17:12.46 | kergoth_ | i did one earlier and it left fine though |
| 17:13.14 | foerster | i haven't tried that, always use the X |
| 17:13.15 | kergoth_ | nods |
| 17:13.23 | kergoth_ | ^C is such a pain in the ass |
| 17:14.51 | XorA | pokes Crofton |
| 17:15.05 | Crofton | urg |
| 17:15.12 | Crofton | next task |
| 17:15.24 | Crofton | after I eat |
| 17:15.41 | XorA | Crofton: no hurry I wont read it now until tomorrow afternoon |
| 17:17.36 | kergoth_ | erk, if the server raises an exception in its process, the UI doesn't know what the hell to do, hangs trying to get stuff from the server |
| 17:17.40 | kergoth_ | hmmmm |
| 17:18.22 | foerster | hmm |
| 17:18.28 | foerster | exception handling is a pain |
| 17:18.33 | kergoth_ | yes |
| 17:19.10 | kergoth_ | i wonder how best to handle that.. should the server catch any exception and send it through the event queue, or should the ui just check and see if the server is still alive, or.. |
| 17:19.12 | foerster | can the server just close the queue on exception (and will the UI get indication of this?) |
| 17:19.43 | kergoth_ | i dno't think the ui gets any knowledge of it -- all queue.close() does is says "feeder thread, when you're done feeding, go away" |
| 17:19.46 | kergoth_ | as far as i know |
| 17:19.51 | foerster | hm |
| 17:19.58 | kergoth_ | but the ui could check the server being active |
| 17:20.04 | kergoth_ | there's a method or something for that |
| 17:20.07 | kergoth_ | but it could be racy |
| 17:20.10 | kergoth_ | hrm |
| 17:20.11 | foerster | we can add an ugly Event |
| 17:20.16 | CIA-101 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rb9539b9e75 10openembedded.git/recipes/ffphonelog/ffphonelog_git.bb: |
| 17:20.16 | CIA-101 | ffphonelog: bump PR after last EFL_SRCREV change |
| 17:20.16 | CIA-101 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 17:20.19 | foerster | wrap it inside server communicator |
| 17:20.24 | foerster | er, wait |
| 17:20.39 | kergoth_ | i was just thinking a ServerDead event |
| 17:20.41 | kergoth_ | hmm |
| 17:20.49 | foerster | or that |
| 17:20.58 | foerster | that's probably cleaner |
| 17:21.52 | kergoth_ | wrap the run() content in a try/except, have it send the server dead event, close the queue, shutdown |
| 17:22.02 | kergoth_ | i already split a main() method from run() for the fd redirection |
| 17:22.21 | foerster | that would probably work |
| 17:24.24 | kergoth_ | hmm |
| 17:25.36 | kergoth_ | the server has that keep_running event which it uses to shut itself down, couldn't the UI operate against that too, and clear the event on exception? |
| 17:25.45 | kergoth_ | course if we did that, the ui wouldn't actually have the exception object to display it |
| 17:26.26 | foerster | yea. As it is, the bin/bitbakek calls server.stop(), which clears that Event |
| 17:26.39 | foerster | if we could get the exception, that would probably be nice |
| 17:26.47 | *** join/#oe guufy (~Guufy@70-35-57-218.static.wiline.com) |
| 17:27.58 | kergoth_ | in the other case, where the ui dies, there's nothing we can do to display it other than stderr, but when the server dies we're in a better position usability wise, best to utilize it |
| 17:28.21 | kergoth_ | the alternative would be to not add a new event, send the exception as a logging message and have the ui also use the running event |
| 17:30.08 | kergoth_ | foerster: ack, exiting the goggle ui doesn't seem to always shut down the server fully |
| 17:30.11 | kergoth_ | i have remnant processes |
| 17:30.23 | kergoth_ | hrm |
| 17:30.24 | kergoth_ | strange |
| 17:30.30 | kergoth_ | that shouldn't be happening |
| 17:30.32 | foerster | hm. wonder why. |
| 17:30.59 | kergoth_ | oh, hmm |
| 17:31.13 | kergoth_ | i think its waiting for the current command t o complete before the server exits |
| 17:31.16 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-hrepjpwxbjhgnvtb) |
| 17:31.22 | kergoth_ | since server.stop() is a completely clean shutdown |
| 17:31.29 | kergoth_ | but that's not what the user will expect hitting a close button |
| 17:31.54 | foerster | how long does it stick around? |
| 17:32.06 | foerster | it is saving the cache, or running something else? |
| 17:32.23 | kergoth_ | i have some that are just sitting there, but one is waiting on a tarball extraction for the kernel :) |
| 17:32.30 | kergoth_ | hence the theory |
| 17:33.29 | foerster | so we actually want to run shutdown/stop within cooker maybe |
| 17:33.44 | foerster | the server just bails out of the run loop when he sees the event cleared |
| 17:34.17 | kergoth_ | ah, right.. runcommand is async, and its polling the command channel not blocking |
| 17:34.24 | kergoth_ | so yeah, i guess all our uis need to start playing nice on exit |
| 17:34.30 | kergoth_ | shut down the cooker |
| 17:37.33 | *** join/#oe denix (~denys@nat/ti/x-kzepyqcgdlloppxy) |
| 17:39.59 | kergoth_ | foerster: server fd killing bits are in on my separated-ui-and-server |
| 17:40.11 | kergoth_ | wanders off |
| 17:40.19 | foerster | ok. I'll pull em down eventually. Screwing with coloring of goggle |
| 17:52.00 | *** join/#oe denix (~denys@nat/ti/x-vurvjbkuawbacuab) |
| 17:57.36 | *** join/#oe rsalveti (~rsalveti@201.82.72.47) |
| 18:09.01 | *** join/#oe denix (~denys@nat/ti/x-kgluwcvtgrmujycg) |
| 18:13.24 | *** join/#oe kevinsc (~a0214685@nat/ti/x-ndbugubfxzzerock) |
| 18:20.30 | obi | khem: i can confirm the build error caused by gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch on clean builds |
| 18:23.20 | *** join/#oe CMoH-notebook (~cipi@95.76.74.1) |
| 18:23.20 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 18:25.51 | kergoth_ | hmmm |
| 18:25.54 | *** join/#oe hillct (~hillct@cpe-174-109-201-200.nc.res.rr.com) |
| 18:28.09 | kergoth_ | RP: https://github.com/kergoth/bitbake/wiki/Design-Thoughts-Event |
| 18:28.47 | kergoth_ | RP: then we register/unregister handlers for 1) worker transmission over the pipe and 2) server transmission to the UI |
| 18:28.53 | kergoth_ | so bb.event doesn't have to know about any of it |
| 18:29.01 | kergoth_ | hacks |
| 18:30.11 | *** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de) |
| 18:31.19 | foerster | kergoth_: ugly, but try it https://github.com/foerster/bitbake/commit/792578406116cbc4ba9f53e813565968d3d9f760 |
| 18:31.36 | foerster | I didn't bring in your changes to that branch yet, will do that later. |
| 18:31.43 | foerster | gonna head out to the gym here soon |
| 18:31.44 | kergoth_ | will do |
| 18:32.01 | foerster | I did notice though, I get build success even though my build target failed |
| 18:32.03 | foerster | found that odd |
| 18:32.34 | foerster | and I don't know wtf is up with sqlite fetching, seems broke all of a sudden (though I haven't sync'ed OE master in a little while) |
| 18:32.36 | foerster | o well. |
| 18:32.47 | kergoth_ | strange |
| 18:33.13 | foerster | i get a garbaged up log message too for sqlite |
| 18:33.56 | foerster | fetch http://www.sqlite.org/sqlite-autoconf-%d%02d etc .tar.gz |
| 18:34.09 | foerster | don't have any idea why the %d%02d still in there |
| 18:34.17 | foerster | ah, shit |
| 18:34.19 | foerster | i'm an idiot |
| 18:34.29 | foerster | i was helping davidlt (i think) debug that |
| 18:34.37 | foerster | i was wondering where the hell sqlite was coming in |
| 18:34.47 | foerster | smacks self for being stupid |
| 18:35.38 | kergoth_ | hehe |
| 18:35.55 | foerster | brain fried, can't remember what i did yesterday :) |
| 18:37.04 | foerster | i'm out, need a break |
| 18:49.58 | kergoth_ | damn, the new event handling is *really* simple |
| 18:53.47 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
| 19:01.11 | tharvey | kergoth_, played with debootstrap/schroot a bit last night. You mentioned you use schroot to get into the chroot. From what I found you use 'chroot' to get 'into' it, and use schroot to execute a command within it (but not get a shell in it) |
| 19:01.19 | kergoth_ | no |
| 19:01.25 | kergoth_ | schroot defaults to dropping you to a shell |
| 19:01.30 | kergoth_ | you *can* use it to run a command |
| 19:01.39 | tharvey | ah.. ok, didn't notice that usage |
| 19:01.42 | tharvey | I'm guessing you spend some time setting up your chroot environment and not recreating them all the time right? |
| 19:02.06 | kergoth_ | i set up a chroot, add a .conf to /etc/schroot.d/, and forget about it until i need to use it to do something |
| 19:02.32 | kergoth_ | i have a few that i use to run bitbake directly, the way you mention you can tell schroot to run a command |
| 19:02.35 | kergoth_ | works well |
| 19:03.05 | tharvey | I did use buildout to build a local python-2.6 for hardy as there wasn't a pkg for it, seemed to work but I couldn't run bitbake in the chroot - it simply returned with no output |
| 19:03.09 | kergoth_ | course, managing your configs across them gets slightly annoying, since the ASSUME_PROVIDED is really per distro |
| 19:03.29 | kergoth_ | what bitbake version? |
| 19:03.41 | tharvey | was using master perhaps a week back |
| 19:03.46 | tharvey | ASSUME_PROVIDED? |
| 19:03.54 | kergoth_ | okay, update to master as of this morning |
| 19:04.06 | kergoth_ | yes, because what build tools are on the build machine varies from chroot to chroot |
| 19:04.15 | kergoth_ | so in one chroot i might require linux-libc-headers-native, but the rest don't |
| 19:04.19 | kergoth_ | a single site.conf won't do it |
| 19:04.31 | kergoth_ | of course, if you use separate build dirs, one per chroot, you're fine |
| 19:04.34 | kergoth_ | i don't, usually |
| 19:04.34 | tharvey | you also said something about liking schroot because it handled binding proc etc? how is that? from what I saw you provide binds in your host /etc/fstab which is also pretty manual - I want to see if I can get a chroot that runs under a user and requires no sudo |
| 19:04.42 | kergoth_ | no, you don't need any of that |
| 19:04.50 | kergoth_ | set the type to 'directory' in schroot.conf |
| 19:04.56 | kergoth_ | it'll automatically run setup and exec scripts for the chroot |
| 19:05.00 | kergoth_ | the setup scripts do all that mounting for you |
| 19:05.08 | kergoth_ | completely painless |
| 19:05.12 | kergoth_ | works under user or root, either way |
| 19:05.34 | kergoth_ | if you run bitbake as of 11am this morning, it should show the exception that was raised instead of exiting silently |
| 19:05.42 | kergoth_ | its likely it failed to import something, missing a package in the chroot |
| 19:05.50 | khem | obi: whats your host OS |
| 19:06.16 | kergoth_ | tharvey: it even automatically bind mounts your homedir |
| 19:06.23 | khem | strange though because noone touched that patch for long |
| 19:06.24 | kergoth_ | and copies passwd/group, iirc |
| 19:07.00 | kergoth_ | so its almost completely transparent, anything you can run in your shell, you can run equally well via schroot, assuming the necessary system bits are installed of course |
| 19:09.21 | kergoth_ | hrm |
| 19:13.44 | kergoth_ | damn, this is so much cleaner |
| 19:13.50 | kergoth_ | unbelievable |
| 19:13.51 | tharvey | hmmm... I'm not seeing any automatic binds or anything, can you look at http://pastebin.com/fxSHYeSd |
| 19:13.55 | *** join/#oe risca (~risca@c-f7f8e253.022-6-6e6b702.cust.bredbandsbolaget.se) |
| 19:13.55 | tharvey | perhaps my config is missing something |
| 19:14.39 | tharvey | kergoth_, what setup/exec scripts does schroot run? sounds like something you had to setup beyond what debootstrap created for you? |
| 19:14.51 | kergoth_ | no |
| 19:14.54 | kergoth_ | its all schroot |
| 19:15.07 | kergoth_ | ls /etc/schroot/setup.d/ |
| 19:15.21 | kergoth_ | see https://gist.github.com/736645 |
| 19:16.07 | tharvey | so are you using automated build scripts that use schroot to kick off commands or are you just entering a shell and using the shell manually? |
| 19:19.29 | kergoth_ | neither |
| 19:19.30 | *** join/#oe rob_w (bob@pD95EE2E7.dip.t-dialin.net) |
| 19:19.51 | kergoth_ | ~oe% schroot -c lucid bitbake task-boot |
| 19:19.57 | kergoth_ | or whatever |
| 19:20.01 | kergoth_ | well, not exactly that, but you get the idea |
| 19:20.28 | kergoth_ | i think i had an alias, since it expects a full path to the binary it wants to run, iirc |
| 19:20.31 | kergoth_ | but thats the idea |
| 19:20.36 | tharvey | so that runs as what user within the chroot? I'm getting hung up on users and environment |
| 19:20.40 | kergoth_ | as me |
| 19:20.48 | kergoth_ | no, like i said, it copies passwd and group and shadow |
| 19:20.52 | kergoth_ | i'm me here, and i'm me there |
| 19:21.00 | kergoth_ | and it bind mounts the homedir, so my files are still there |
| 19:21.06 | kergoth_ | and it doesn't lose teh environment |
| 19:21.14 | kergoth_ | er, i think you need -p for schroot |
| 19:21.20 | kergoth_ | then it will preserve it |
| 19:21.35 | tharvey | debootstrap copied those when you created the chroot? it didn't for me - has a generic one |
| 19:21.37 | kergoth_ | schroot -p -c lucid ./bitbake/bin/bitbake task-boot |
| 19:21.39 | kergoth_ | no |
| 19:21.41 | tharvey | /etc/passwd that is |
| 19:21.44 | kergoth_ | schroot's setup scripts do it. |
| 19:21.47 | kergoth_ | just as they do the bind mounting |
| 19:21.58 | kergoth_ | so the files are always current |
| 19:22.39 | tharvey | hmmm, maybe I have a different schroot or something. I'm using pkg I installed on ubuntu 10.04 whcih is 1.4.0 |
| 19:23.07 | kergoth_ | maybe they aren't in /etc/schroot on older versions, but they're still there, and schroot behaves the same way |
| 19:23.15 | kergoth_ | dpkg -L schroot|grep setup |
| 19:23.53 | tharvey | ya, I see various scripts in /etc/schroot/setup.d but they don't seem to be behaving as you describe - what ver you using on what distro? |
| 19:24.10 | kergoth_ | every version i've used for the past 3 years hsa worked this way. |
| 19:24.21 | kergoth_ | lets see.. teh config format may have changed slightly |
| 19:24.22 | kergoth_ | read the man page |
| 19:24.24 | kergoth_ | man schroot.conf |
| 19:24.26 | tharvey | http://pastebin.com/T7f1qYBv |
| 19:24.36 | kergoth_ | there's variables to explicitly enable the setup and exec scripts |
| 19:24.43 | kergoth_ | so try that, maybe its not automatic for 'directory' in your version |
| 19:24.48 | tharvey | shows the setup files I have - ya I'll spend more time in the man pages - I must be missing something |
| 19:25.23 | kergoth_ | look at /etc/default/schroot |
| 19:25.43 | tharvey | and for the environment bitbake needs, such as BBPATH - are you setting that on your host and useing -p to perserve it in chroot or setting that in your users .bashrc within the chroot? |
| 19:26.01 | kergoth_ | the users .bashrc in the chroot *IS* your ~/.bashrc |
| 19:26.07 | kergoth_ | because, for the third time, it bind mounts ~ |
| 19:26.16 | tharvey | ah right... 'if' it binds mounts, which I don't have using yet |
| 19:26.28 | kergoth_ | again, its just a matter of getting it to run the setup scripts |
| 19:26.36 | tharvey | ok, I'll dig more - thanks for the info - I think the chroot will be very useful |
| 19:26.39 | kergoth_ | ah, here we are |
| 19:26.42 | kergoth_ | see /etc/schroot/default/copyfiles |
| 19:26.51 | kergoth_ | etc |
| 19:27.01 | kergoth_ | the setup scripts are controlled by those default files |
| 19:27.07 | kergoth_ | similar to how init.d are controlled by /etc/default |
| 19:27.23 | kergoth_ | hmm, i dont see passwd there, maybe i'm mistaken, i coudl have sworn.. |
| 19:27.29 | kergoth_ | well, worst case you could add it :) |
| 19:27.35 | kergoth_ | its all quite easy to configure and control |
| 19:27.40 | kergoth_ | definitely check out the man pages though |
| 19:27.43 | kergoth_ | both for schroot itself and schroot.conf |
| 19:27.45 | tharvey | I have /etc/schroot/copyfiles-defaults which contains /etc/resolv.conf and /etc/gshadow, not /etc/passwd |
| 19:27.54 | kergoth_ | nods |
| 19:29.47 | tharvey | ah... perhaps another thing I'm missing. whoami when I'm in chroot is 'root', likely because I run 'sudo schroot -c hardy' - you running it as your user correct? |
| 19:30.18 | kergoth_ | yep |
| 19:30.55 | kergoth_ | you can also use schroot -c hardy -u root, if you configure the groups right in schroot.conf |
| 19:31.05 | kergoth_ | for when you do want to be root, anyway |
| 19:31.32 | kergoth_ | clearly i haven't set up an schroot chroot from scratch in a while, sorry about that |
| 19:31.37 | tharvey | you have to run debootstrap as root thus it creates the chroot dir owned by root, so I couldn't run 'schroot -c hardy' without being root, perhaps I was simply supposed to chown the chroot dir as me? |
| 19:31.46 | kergoth_ | what do you mean? |
| 19:31.54 | kergoth_ | why would you have to own the rootfs to be able to schroot into it? |
| 19:32.03 | kergoth_ | just because you ran it as root doesn't mean the entire rootfs is chmod 0700 |
| 19:32.15 | kergoth_ | it bind moutns your homedir |
| 19:32.20 | kergoth_ | and of course you can do anything in there you like |
| 19:32.32 | kergoth_ | also, pretty sure schroot is setuid |
| 19:32.39 | kergoth_ | which is how it handles the bind mounts, etc, before dropping perms |
| 19:32.54 | kergoth_ | (and of course, the run of chroot itself) |
| 19:32.57 | tharvey | I get all kinds of errors when not running schroot -c hardy as root - still trying to figure out |
| 19:33.02 | kergoth_ | anyway, i don't know how exactly it does it, but it works |
| 19:33.13 | tharvey | still seems to stem from the fact those setup scripts are not doing there thing - got to solve that it appears first |
| 19:33.23 | kergoth_ | yeah, i think you're right |
| 19:33.29 | kergoth_ | might copy passwd/shadow/group manually for now |
| 19:33.30 | tharvey | I'm sure thats causing all my issues |
| 19:33.35 | tharvey | ya |
| 19:33.37 | kergoth_ | can always set those up to copy automaticlaly later |
| 19:33.45 | kergoth_ | without those in place, the perms will be all wrong when it tries to act like you |
| 19:33.49 | kergoth_ | the uids on files won't match up |
| 19:36.09 | tharvey | ya, if I cp passwd/shadow/group manaully and mkdir /var/chroot/hardy/home/tharvey I can 'schroot -c hardy' as tharvey just fine |
| 19:36.43 | tharvey | mount tells me not /etc/mtab and /proc is empty etc - so still get to get those setup scripts working for that |
| 19:36.54 | kergoth_ | okay, yeah, i think your'e close to there |
| 19:37.07 | kergoth_ | probably would be easier to add passwd, group, and shadow to the copyfiles in /etc/schroot/default/copyfiles |
| 19:37.12 | kergoth_ | but i've never tried that |
| 19:37.32 | tharvey | ya, I think setting up the chroot is more involved than you recall |
| 19:37.37 | kergoth_ | tharvey: run-setup-scripts=true |
| 19:37.44 | kergoth_ | tharvey: run-exec-scripts=true |
| 19:37.49 | kergoth_ | add those to your schroot .conf |
| 19:42.38 | tharvey | those are deprecated it appears and don't work - what does your /etc/default/schroot look like (can't find their new replacements)? |
| 19:43.51 | tharvey | mine simply has 'SESSIONS_RECOVER="recover"' and the default /etc/schroot/schroot.conf is completely commented out |
| 19:43.51 | kergoth_ | <PROTECTED> |
| 19:43.55 | kergoth_ | yep |
| 19:44.09 | kergoth_ | again, read the man page for schroot.conf |
| 19:44.12 | kergoth_ | it talks about setup scripts and everything |
| 19:44.38 | tharvey | I did... it talks about setup scripts but not how to 'enable' them - the options you pointed out are deprecated, if I use them it barks at me when I schroot and appears to not run them |
| 19:44.47 | *** join/#oe toi (~peter@d54C2AA76.access.telenet.be) |
| 19:45.22 | kergoth_ | i don't use those |
| 19:45.26 | tharvey | schroot -i -c hardy confirms that they are not enabled |
| 19:45.28 | kergoth_ | i pointed you to them thinking you were using ar eally old schroot |
| 19:45.38 | tharvey | sorry - I know this isn't a 'chroot' channel :P |
| 19:45.49 | kergoth_ | https://gist.github.com/736645 is all i do when it comes to schroot setup |
| 19:46.10 | kergoth_ | see the section of schroot.conf entitled 'Plain and directory chroots' |
| 19:46.32 | kergoth_ | well, its slightly related, in that you can use chroots to do oe builds, and doing so is a very useful thing to be able to do |
| 19:46.38 | kergoth_ | we should put this in a howto on the wiki or something |
| 19:47.03 | tharvey | agreed thats why I was asking the other day when you said it was really simple heh |
| 19:47.12 | tharvey | I'll put up a wiki page when I figure it all out |
| 19:47.17 | kergoth_ | well, i thought it was, but i must have forgotten a step |
| 19:47.39 | kergoth_ | i should install schroot in one of my chroots |
| 19:47.48 | kergoth_ | can you chroot from a chroot? ;) |
| 19:47.51 | tharvey | it almost acts like schroot is broken or misdocumented - the depreated run-setup-scripts=true does not work and I don't see an alternative mentioned in the man pages |
| 19:48.05 | kergoth_ | type=directory does it. |
| 19:48.10 | kergoth_ | or so schroot.conf's man page claims |
| 19:48.26 | tharvey | type=directory is deprecated as well... now you just use 'directory=/var/chroot/hardy' |
| 19:48.42 | kergoth_ | afaik, anyway |
| 19:49.09 | kergoth_ | Note that 'plain' chroots do not run setup scripts and mount filesystems; 'directory' is recommended (see "Plain and directory chroots", below). |
| 19:49.56 | tharvey | ahhhh bingo |
| 19:50.09 | kergoth_ | hence, type=directory |
| 19:50.28 | tharvey | I was wrong - 'type=directory' is not deprecated and thats the magic config that makes it work (as you said not plain) |
| 19:50.40 | tharvey | I thought type=directory location=foo was replaced with directory= |
| 19:50.45 | kergoth_ | how many times did i say that? :P |
| 19:50.55 | tharvey | location= was deprecated but you still need both type=directory and directory= |
| 19:51.01 | kergoth_ | yes |
| 19:51.19 | kergoth_ | i didn't have those in my .conf for no reason :) |
| 19:51.23 | kergoth_ | at any rate, glad you got it |
| 19:51.25 | tharvey | well again I thought the manpage was saying that directory= was shorthand for both of those |
| 19:51.43 | kergoth_ | there are many types |
| 19:51.46 | tharvey | last night when I did that I got a deprecation warning/failure but I guess it was about location and not type= |
| 19:51.47 | kergoth_ | unionfs, mount, directory, etc |
| 19:51.54 | kergoth_ | directory= just points to the path for some of the types |
| 19:52.21 | tharvey | wow... it works much better now heh |
| 19:52.30 | kergoth_ | heh |
| 19:52.38 | tharvey | thanks for putting up with me |
| 19:52.59 | kergoth_ | so, setup chroot with debootstrap, create the schroot .conf for it, then either manually copy passwd/group/shadow or add them to /etc/schroot/default/copyfiles |
| 19:53.03 | kergoth_ | and should be good to go |
| 19:53.15 | tharvey | ya... insert 'properly' in each of those steps above |
| 19:53.21 | kergoth_ | hmm, wait |
| 19:53.32 | kergoth_ | the 'nssdatabases' setup script mentions passwd |
| 19:53.40 | kergoth_ | pokes around |
| 19:53.41 | tharvey | going to re-setup - may not need to manually copy as long as I do it right |
| 19:53.56 | CIA-101 | 03Tom Rini <tom_rini@mentor.com> 07org.openembedded.dev * r7ebbccee5e 10openembedded.git/recipes/lttng/ (5 files in 2 dirs): |
| 19:53.56 | CIA-101 | ust / userspace-rcu: Add recipes |
| 19:53.56 | CIA-101 | Based on Esben Haabendal's recipes. |
| 19:53.56 | CIA-101 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
| 19:53.57 | kergoth_ | yep, nssdatabases copies the passwd |
| 19:54.02 | kergoth_ | no need for the manual stuff there either |
| 19:54.07 | kergoth_ | i thought it did, but second guessed myself |
| 19:54.29 | kergoth_ | 1) setup chroot, 2) schroot .conf 3) profit |
| 19:54.31 | kergoth_ | ;) |
| 19:55.21 | tharvey | so out of curiousity how do you setup your env for bitbake... you set just BBPATH in your .bashrc and thats it? |
| 19:55.39 | tharvey | and make sure proper bitbake is in path of course |
| 19:55.40 | *** join/#oe florian (~fuchs@sign-4d091c94.pool.mediaWays.net) |
| 19:55.40 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:56.40 | tharvey | my goal is to create a schroot that depends upon nothing from the host user env, so I want everything to run as user build or root within the chroot and be completely self contained |
| 20:01.01 | Crofton|work | I source the vars from a script ... |
| 20:01.37 | tharvey | as do I but it seems like kergoth_ does not and I'm curious how he sets it up |
| 20:01.51 | kergoth_ | i use bitbake master |
| 20:01.59 | kergoth_ | which means layers |
| 20:02.01 | tharvey | I have several oe dirs I build from thus my env's all have different BBPATH |
| 20:02.05 | kergoth_ | which means no env vars other than PATH to bitbake |
| 20:02.09 | kergoth_ | i have several oe dirs too |
| 20:02.17 | kergoth_ | all with different bblayers.conf's, i just cd into it and go |
| 20:02.22 | tharvey | right, we had this discussion before and I recall you telling me 'no env vars' emphatically |
| 20:02.38 | kergoth_ | its up to you, but i don't bother with them personally |
| 20:03.30 | tharvey | let me read the documentation for BBLAYERS again - and again, where would I find that? I think its only burried in a maillist post right? |
| 20:04.11 | kergoth_ | for me, in my conf/bblayers.conf, i have: |
| 20:04.15 | kergoth_ | TOPDIR := "${@os.path.dirname(os.path.dirname(d.getVar('FILE', True)))}" |
| 20:04.15 | kergoth_ | BBPATH = "${TOPDIR}:${HOME}/.oe" |
| 20:04.21 | kergoth_ | BBLAYERS = "${TOPDIR}/openembedded" |
| 20:04.26 | kergoth_ | that's it |
| 20:04.31 | kergoth_ | openembedded already has a conf/layer.conf |
| 20:04.35 | kergoth_ | so you don't hav eto worry about that |
| 20:04.49 | kergoth_ | cd into the dir that has conf/bblayers.conf, or any subdir beneath it, and it'll build using that |
| 20:05.20 | kergoth_ | now, you can see that my oe dir is relative to my project area, i keep a new oe dir in each build area personally, but you could always point to a dir outside of TOPDIR |
| 20:05.54 | kergoth_ | of course, you still need a conf/local.conf next to the bblayers.conf, but it no longer has to set BBFILES |
| 20:06.00 | kergoth_ | it just sets your machine, distro, etc |
| 20:06.30 | kergoth_ | there are of course, as with anything else related to bitbake, many ways to do it, thats just what i use |
| 20:09.19 | kergoth_ | hmmm |
| 20:11.05 | tharvey | I do see you have this documented in doc/manual/usermanual.xml but thats in what comes up at bitbake.berlios.de - is that simply because this ver is not released yet? |
| 20:11.25 | kergoth_ | most likely, yes. |
| 20:16.26 | tharvey | got bit yesterday by the 'requires python-2.6' issue, which I didn't notice until I refactored a bunch of metadata to use bbappend instead of amend.inc etc and then realized my nightly build machine didn't have python-2.6 heh |
| 20:17.10 | tharvey | I like the cleanliness of not needing env vars though... I see the light |
| 20:17.36 | kergoth_ | hehe |
| 20:17.48 | obi | khem: debian squeeze |
| 20:18.00 | tharvey | will just add another day or so of work to setup either a chroot or a buildout based python-2.6 on my build machine |
| 20:18.06 | kergoth_ | nods |
| 20:18.36 | kergoth_ | i wouldn't use anything but master nowadays, particularly with parallel parsing, bbappend, and bblayers |
| 20:18.45 | obi | khem: this problem didn't appear on an updated build, only on a clean build |
| 20:18.49 | tharvey | I'll simply explain to management the 5min -> 1min decrease in current bitbakes caching will make up for that day within a week or so ;P |
| 20:19.01 | tharvey | nods |
| 20:19.34 | kergoth_ | damnit, my new event handling is slowww |
| 20:19.35 | kergoth_ | why.. |
| 20:24.18 | kergoth_ | ugh |
| 20:24.19 | kergoth_ | hrm |
| 20:24.50 | kergoth_ | madness due to how the metadata is attached to events.. guess i might have to start over and kill the global event handling 100% instead |
| 20:24.53 | kergoth_ | probably for the best |
| 20:26.16 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
| 20:29.35 | *** join/#oe ka6sox4 (d0360e02@nslu2-linux/ka6sox) |
| 20:30.57 | kergoth_ | hmm |
| 20:31.15 | kergoth_ | i think i see a plan of attack, maybe |
| 20:33.27 | *** join/#oe chase (~chase@nat/ti/x-ffqjgosxzjyznhal) |
| 20:34.26 | *** join/#oe GNUtoo|laptop (~gnutoo@host237-37-dynamic.117-80-r.retail.telecomitalia.it) |
| 20:36.08 | *** join/#oe dth_ntb (~dth@dslb-088-070-027-235.pools.arcor-ip.net) |
| 20:40.11 | *** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
| 20:42.35 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 20:43.49 | *** join/#oe anarsoul (~anarsoul@80.249.95.89) |
| 20:48.31 | kergoth_ | whew, i think i finally have a good way to do this, from beginning to end |
| 20:48.41 | kergoth_ | reviews |
| 20:49.02 | *** join/#oe angelox_123 (~Angelo@201-93-218-46.dsl.telesp.net.br) |
| 20:55.03 | ka6sox4 | tries to remember the opie guy's nick |
| 20:57.25 | kergoth_ | ka6sox4: bluelightning |
| 20:59.15 | ka6sox4 | right...too tired not enough sleep.thanks |
| 20:59.32 | kergoth_ | np |
| 21:07.05 | Jay7 | is trying to design QA-testing for TestBuilder |
| 21:07.46 | Jay7 | runtime qemu testing and may be some static tests (kernel/image sizes check, etc) |
| 21:08.19 | Jay7 | any ideas are welcome |
| 21:08.50 | *** join/#oe Martin_B (~martin@pool-91-65-198-89.dbd-ipconnect.net) |
| 21:11.47 | kergoth_ | Jay7: should talk to the yocto guys, they're already doing runtime testing, though i don't know much about the details |
| 21:12.06 | Jay7 | kergoth_: I've looked into they testing code |
| 21:12.13 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-itwbreywqcyteavh) |
| 21:12.40 | Jay7 | they have runtime testing as part of bitbake run |
| 21:12.59 | Jay7 | I dislike this idea.. bitbake is tool for 'bit-baking' :) |
| 21:13.56 | Jay7 | most of they tests are shell scripts anyway |
| 21:17.32 | kergoth_ | ah |
| 21:17.37 | *** join/#oe reactor16 (~reactor16@static.108.169.4.46.clients.your-server.de) |
| 21:17.41 | *** part/#oe dth_ntb (~dth@dslb-088-070-027-235.pools.arcor-ip.net) |
| 21:18.51 | reactor16 | obi r u here ? |
| 21:22.30 | foerster | kergoth_: i have goggle putting newer tasks at the top of the list |
| 21:22.40 | foerster | kinda cool that way |
| 21:25.43 | kergoth_ | nice |
| 21:26.18 | foerster | hmm. do_package_update_index_ipk failed with : local variable 'lock' referenced before assignment |
| 21:26.37 | kergoth_ | hmm |
| 21:26.48 | kergoth_ | ah, i see it |
| 21:27.48 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rf57f8f3cc9 10bitbake.git/lib/bb/utils.py: |
| 21:27.48 | CIA-101 | utils: fix 'lock' variable reference |
| 21:27.48 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 21:27.57 | kergoth_ | see, my pyflakes vim plugin was busted due to upstream changing their layout |
| 21:28.04 | foerster | ah |
| 21:28.14 | kergoth_ | this resulted in me not seeing the undefined var nicely highlighted in red the way i usually do |
| 21:28.18 | kergoth_ | clearly got spoiled |
| 21:29.24 | foerster | http://erafx.com/tmp/bb-fail-screenshot.png |
| 21:29.26 | foerster | :) |
| 21:29.40 | kergoth_ | nice. |
| 21:29.56 | foerster | since it did os._exit there, my green didn't go away :( |
| 21:30.05 | *** join/#oe timtimred (~meh@79-67-233-212.dynamic.dsl.as9105.com) |
| 21:30.33 | foerster | another half shitty thing (but maybe it's good). |
| 21:30.40 | foerster | when a task fails |
| 21:30.42 | kergoth_ | we need to review exit code handling in general |
| 21:30.47 | kergoth_ | sometimes bitbake returns 0 when a task failed |
| 21:30.55 | foerster | i get task_failed event before the logrecord for failed task |
| 21:31.12 | foerster | so i don't know where to put the failure, and it gets tacked to the top of the list |
| 21:31.16 | foerster | but again, maybe that's not a bad thing |
| 21:31.31 | kergoth_ | i think we should associate the log messages from tasks with the task id they belong to |
| 21:31.41 | kergoth_ | i know logging lets you add extra bits you can use in messages, just not sure how yet |
| 21:31.44 | kergoth_ | need to investigate |
| 21:31.54 | foerster | it has much of it |
| 21:32.01 | foerster | event: {'pathname': '/home/foerster/dev/openembedded/dev/bitbake/lib/bb/runqueue.py', 'threadName': 'MainThread', 'name': 'BitBake.RunQueue', 'thread': 140447366334208, 'relativeCreated': 95620.636940002441, 'process': 6922, 'args': (), 'module': 'runqueue', 'funcName': 'fork_off_task', 'levelno': 50, 'processName': 'ProcessServer-1', 'exc_text': None, 'created': 1292016087.886553, 'msecs': 886.55304908752441, 'msg': "local variable 'loc |
| 21:32.01 | foerster | k' referenced before assignment", 'exc_info': None, 'filename': 'runqueue.py', 'levelname': 'CRITICAL', 'lineno': 1118} |
| 21:32.29 | kergoth_ | hmm, i guess for tasks the process is unique |
| 21:32.32 | kergoth_ | might not always be that way though |
| 21:32.38 | kergoth_ | and doesn't help you associate to task events |
| 21:32.55 | foerster | yea. Well, I do get task set to "do_compile", etc |
| 21:32.59 | foerster | but not tied to a package |
| 21:33.09 | kergoth_ | nods |
| 21:33.26 | foerster | i need package info, or reverse the order of events (logrecord for failure, then taskfailed |
| 21:33.30 | kergoth_ | some of the stuff i'm working on for bb.event might help with this |
| 21:33.36 | kergoth_ | https://github.com/kergoth/bitbake/wiki/Design-Thoughts-Event is the current plan |
| 21:34.35 | kergoth_ | in particular, that it uses a handler in the worker to pass the event back, it could easily inject extra data along the way |
| 21:35.50 | foerster | sounds good |
| 21:36.23 | kergoth_ | my only concern doing it this way is any extra overhead |
| 21:36.28 | kergoth_ | but can profile it after its done |
| 21:38.40 | foerster | https://github.com/foerster/bitbake/commit/189278946b65aa68953186ca5fc991dc865fd9db |
| 21:39.09 | foerster | goggle is cool. Still needs some refinement (should probably say something about building runqueue, etc). It's getting there though |
| 21:39.28 | kergoth_ | yeah, definitely. i already prefer it to running at console, you can actually make sense of the output much more easily |
| 21:39.33 | foerster | i agree |
| 21:39.44 | foerster | it's slick, very useful IMO |
| 21:39.47 | rphillips | kergoth_: will there logging within the dispatcher stack? |
| 21:39.55 | rphillips | be logging* |
| 21:40.13 | kergoth_ | rphillips: we already have a Logging handler that we add to our logger which dispatches LogRecords through bb.event |
| 21:40.29 | kergoth_ | will do the same thing, just to a specific dispatcher instead of bb.event's global bits |
| 21:40.31 | reactor16 | is bitbake work on openvz virtualization ? |
| 21:40.32 | *** join/#oe angelox_123 (~Angelo@189-46-8-174.dsl.telesp.net.br) |
| 21:40.48 | rphillips | great |
| 21:40.54 | *** part/#oe angelox_123 (~Angelo@189-46-8-174.dsl.telesp.net.br) |
| 21:41.11 | kergoth_ | er.. i just realized we're using the slow pickle instead of cPickle for the events between the server/ui |
| 21:41.17 | kergoth_ | wonders if that'd be noticable |
| 21:41.47 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rb16c0c1dc3 10bitbake.git/lib/bb/event.py: |
| 21:41.48 | CIA-101 | event: use cPickle for events |
| 21:41.48 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 21:42.02 | *** join/#oe GarthPS (~quassel@78.250.216.143) |
| 21:42.39 | kergoth_ | tests |
| 21:47.31 | foerster | kergoth_: get rid of the <event> + pickle </event> stuff :) |
| 21:48.37 | kergoth_ | i don't know if loads/dumps is as smart as load/dump, and its using the BBUIEventQueue.send instead of a file-like object |
| 21:48.44 | kergoth_ | shrugs |
| 21:48.55 | kergoth_ | either way we'll get separated merged soon enough |
| 21:49.02 | kergoth_ | i think all the major bugs are gone |
| 21:49.34 | foerster | yea, just some last cleanup wrt ^C in bin/bitbake, and making UIs shut down cooker on exit |
| 21:51.53 | kergoth_ | lets see.. i'm thinking two exception handlers for keyboard interrupt, one surrounding ui_main, in case they hit it right after the loop exits, and that one can server.terminate(), and one at toplevel to catch any during the clean shutdown and just exit |
| 21:52.02 | kergoth_ | either that or the signal() you did |
| 21:52.10 | kergoth_ | signal's probably cleaner |
| 21:52.24 | kergoth_ | but, we should still catch any from ui_main, in case they hit it at the end of the ui loop |
| 21:52.30 | kergoth_ | so maybe not |
| 21:53.02 | foerster | well, if ^C doesn't leave the server hanging, then just let 'em abuse us if they want |
| 21:53.33 | foerster | i put the signal block in b/c (during development) I was getting funny stack traces |
| 21:53.38 | kergoth_ | hmm |
| 21:54.35 | foerster | if we don't catch it, there's a chance server.stop, join won't get called |
| 21:54.41 | foerster | i think maybe that's what I was seeing |
| 21:55.00 | foerster | don't remember exactly. Just know I did the easiest thing to make my problem go away :) |
| 21:55.06 | kergoth_ | yeah, if server.stop isn't called, it'll still try to join at the end, but hang because the server isn't quitting yet necessarily, and then you'd interrupt that join |
| 21:55.09 | kergoth_ | would be my guess |
| 21:55.52 | foerster | so, we want to block it until stop is called for sure. And we could put a timeout on join |
| 21:56.06 | foerster | so it won't stay hung up for eternity |
| 21:58.38 | *** join/#oe mnabil (~mnabil@41.234.70.136) |
| 21:59.49 | foerster | kergoth_: let me know what you come up with, i'm out for now. later |
| 22:07.07 | khem | just bought a car |
| 22:10.06 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 22:14.09 | khem | obi: Do u have quilt-native in your ASSUME_PROVIDED by any chance ? |
| 22:14.27 | khem | madness in gcc |
| 22:16.27 | *** join/#oe dfoley (~dfoley@s207-6-220-230.bc.hsia.telus.net) |
| 22:16.49 | kergoth_ | khem: grats, what car? |
| 22:17.03 | khem | used BMW |
| 22:17.10 | khem | I had to get a second car |
| 22:17.20 | kergoth_ | ahh, nice |
| 22:18.15 | khem | I kind of come to trust BMWs more after the last accident that my wife was in and all came out unhurt it was amazing if you looked at the car you would think worst happened |
| 22:18.38 | khem | someone rammed into her car while she was waiting on a traffic light |
| 22:18.49 | khem | idiots with cell phones |
| 22:20.16 | kergoth_ | damn, bitbake master parsing a collection similar to poky in size parses the recipes as fast as an OE build loads the cache |
| 22:24.24 | *** join/#oe angelox_123 (~Angelo@201-68-254-69.dsl.telesp.net.br) |
| 22:33.39 | Crofton|work | khem, your gcc commit worked fine for me |
| 22:36.28 | khem | Crofton|work: cool thx |
| 22:36.48 | khem | Crofton|work: I wonder if it worked for eFfeM_work too because I think his issue should be solved too now |
| 22:37.08 | khem | Crofton|work: do u attend SCALE ? |
| 22:38.52 | tharvey | kergoth_, do you know if there is a way to create a chroot without root access? debootstrap must run as root, not entirely clear why fakeroot couldn't be used |
| 22:39.28 | kergoth_ | hmm, i'd thought you could do it under fakeroot, does it not work? |
| 22:39.31 | kergoth_ | hasn't tried that in a while though |
| 22:43.27 | dfoley | pretty sure the current bitbake causes gcc-cross-initial to unpack to an incorrect directory name. git bisecting 53740977521bc81ffa37adfa7bbeb8f2a80ea165 is the first bad commit |
| 22:43.44 | *** join/#oe kerim (~kerim@188.3.53.196) |
| 22:44.06 | kergoth_ | hmm |
| 22:44.38 | *** part/#oe kerim (~kerim@188.3.53.196) |
| 22:44.48 | tharvey | khem, whats your thought on using cross-localedef instead of qemu to generate locales? seems like something in your area of expertise? poky does it http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/classes/libc-package.bbclass#n277 |
| 22:45.20 | kergoth_ | dfoley: could you compare the directory names and tell me what they are? |
| 22:45.23 | khem | tharvey: yes I want to do it very much |
| 22:45.36 | dfoley | kergoth_: sure hang on |
| 22:45.37 | khem | just not finding that 25th hour of a day :) |
| 22:45.42 | kergoth_ | dfoley: i'm not seeing how that would happen from looking at the code, that might be informative |
| 22:45.48 | tharvey | this is in reference to a 'localedef returned an error' causing eglibc/glibc failure on release2010.12 |
| 22:46.03 | tharvey | khem, understood |
| 22:46.18 | tharvey | http://thread.gmane.org/gmane.comp.handhelds.openembedded/40416 |
| 22:46.40 | khem | tharvey: I know |
| 22:46.44 | khem | :( |
| 22:47.55 | tharvey | Crofton|work, I've run into your i2c-dev.h issue as well |
| 22:48.27 | tharvey | would love to see that solved - trying to figure out if that header from i2c-tools is even necessary - what do desktop distros do? |
| 22:50.16 | *** join/#oe bluelightning (~bluelight@cpc13-lewi14-2-0-cust559.2-4.cable.virginmedia.com) |
| 22:50.16 | *** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning) |
| 22:51.03 | *** join/#oe zenlinux (~sgarman@c-76-105-143-140.hsd1.or.comcast.net) |
| 22:53.48 | dfoley | kergoth: bad: 53740977521bc81ffa37adfa7bbeb8f2a80ea165 gets unpacked to gcc-cross-initial-4.5-r24.0+svnr167449/gcc-4.5/gcc-4_5-branch |
| 22:54.16 | dfoley | and good: c63e55564a8840083dbd8634b10fe6f76d1f1354 gets unpacked to gcc-cross-initial-4.5-r24.0+svnr167449/gcc-4.5 |
| 22:54.28 | kergoth_ | interesting |
| 22:55.52 | kergoth_ | that doesn't make any sense :( |
| 22:56.16 | kergoth_ | gcc-4.5.inc does a do_unpack_append which runs rename_srcdir, which renames it from gcc-4_5-branch to gcc-4.5.. |
| 22:56.19 | kergoth_ | hmm |
| 22:57.43 | kergoth_ | dfoley: well, you can of course revert for the time being -- i'm looking into it. am able to reproduce it. |
| 22:58.23 | dfoley | sure, no problem |
| 22:58.39 | kergoth_ | thanks for the report |
| 23:03.51 | kergoth_ | ack, i j ust got a traceback from the queue feeder on exit of a bitbake -c clean gcc-cross-initial |
| 23:03.54 | kergoth_ | adds to the list |
| 23:05.34 | Crofton|work | tharvey, it looks like desktop does not install the one from i2c-tools |
| 23:05.44 | Crofton|work | oe now installs it is i2c-tools-user |
| 23:07.17 | kergoth_ | dfoley: bingo, i found the issue :) |
| 23:07.22 | kergoth_ | fixes |
| 23:07.28 | dfoley | kergoth_: cool |
| 23:07.39 | kergoth_ | at least, i think i did |
| 23:07.41 | kergoth_ | lets confirm.. |
| 23:08.46 | tharvey | Crofton|work, was just looking at the same - ubuntu does not have that file in its kernel headers, instead its part of glibc-dev |
| 23:09.22 | Crofton|work | at any rate, OE is no longer overwriting the kernel one |
| 23:09.33 | tharvey | ah, didn't realize you made the change - thx for fixing |
| 23:09.39 | Crofton|work | np |
| 23:09.48 | kergoth_ | dfoley: got it :) |
| 23:09.52 | Crofton|work | it was biting me really hard |
| 23:10.17 | tharvey | I ran into it when I was installing i2c-dev in my sdk - my solution was to take that out of the sdk |
| 23:11.08 | kergoth_ | dfoley: that should do it, please confirm, if you would |
| 23:11.18 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * r8b0753c090 10bitbake.git/lib/bb/build.py: |
| 23:11.18 | CIA-101 | build: don't create ${B} when the 'dirs' flag is unset |
| 23:11.18 | CIA-101 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 23:11.37 | kergoth_ | actually, falling back to ${B} when dirs is unset is pretty lame period |
| 23:11.42 | kergoth_ | it should probably be WORKDIR |
| 23:11.43 | kergoth_ | if anything |
| 23:11.59 | kergoth_ | all our important tasks either set dirs or chdir manually |
| 23:12.03 | kergoth_ | so i don't think anything relies on this |
| 23:12.15 | kergoth_ | will have to test |
| 23:14.08 | dfoley | kergoth_: yes, latest commit fixes it |
| 23:14.21 | kergoth_ | great |
| 23:16.56 | kergoth_ | screw it, i'm merging my persist data api rework |
| 23:18.14 | CIA-101 | 03Chris Larson <chris_larson@mentor.com> 07master * rd9e8b8af30 10bitbake.git/lib/bb/persist_data.py: (log message trimmed) |
| 23:18.14 | CIA-101 | Rework the persist_data API |
| 23:18.14 | CIA-101 | Rather than having to run .addDomain() and then .getValue(domain, key), |
| 23:18.14 | CIA-101 | .setValue(domain, key), etc, now it just works as mappings. |
| 23:18.14 | CIA-101 | As an example: |
| 23:23.28 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
| 23:32.47 | kergoth_ | ugh |
| 23:32.56 | kergoth_ | bb.fetch.fetcher_compare_revisons(d) |
| 23:33.06 | kergoth_ | could we at least spell our functions correctly, please? |
| 23:33.07 | kergoth_ | :) |
| 23:33.48 | Jay7 | Off->On->Suspend |
| 23:33.54 | kergoth_ | heh |
| 23:44.15 | *** join/#oe CMoH (~cipi@95.76.74.1) |
| 23:44.20 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 23:57.29 | ka6sox4 | bluelightning: ping? |
| 23:58.49 | *** join/#oe kerim (~kerim@188.3.53.196) |
