| 00:00.27 | polyonymous | I'll got for a getpagesize(). |
| 00:00.44 | polyonymous | I'm afraid there will be too many packages depending on virtual/kernel otherwise :) |
| 00:28.17 | polyonymous | psokolovsky__, http://bugs.openembedded.org/show_bug.cgi?id=2201 |
| 00:32.26 | *** join/#oe mwester-laptop (n=mwester@nslu2-linux/mwester) |
| 00:45.45 | *** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 00:50.37 | *** join/#oe vervain__ (n=vervain@74-139-209-151.dhcp.insightbb.com) |
| 01:02.38 | *** join/#oe Sonic|Laptop (n=Garrett@cblmdm72-240-97-94.buckeyecom.net) |
| 01:07.56 | *** join/#oe jkilb_ (n=jkilb@p5B20CB8E.dip0.t-ipconnect.de) |
| 01:11.38 | *** join/#oe wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 01:13.11 | *** join/#oe Laibsc1 (n=Laibsch@c-134-230-233.f.dsl.de.ignite.net) |
| 01:48.25 | *** join/#oe jacques (n=jacques@nslu2-linux/jacques) |
| 01:50.27 | *** join/#oe greentux (n=lemke@pd956a57b.dip0.t-ipconnect.de) |
| 02:28.03 | *** join/#oe emte__ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 02:28.36 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 02:31.06 | xjqian | (09:11:03 PM) xjqian: the README in the opie-1.2.3 reads OPIE II, but I though the opie-1.2.3 is just a minorly improved (release frozen) version of opie-1.2.2 (a.k.a opie I) |
| 02:31.06 | xjqian | (09:11:10 PM) xjqian: now I'm confused |
| 02:31.06 | xjqian | (09:14:51 PM) xjqian: the qtopia/qt files in the opie-1.2.3 do look like newly released version from Trolltech. hence it does indicate OPIE II from the perspective it uses new qtopia libraries |
| 02:31.06 | xjqian | (09:16:26 PM) xjqian: so does opie-1.2.3 mean a mixture of new qtopia libraries with old qtopia applications, which implies that most of the application will be broken and need to be rewritten? |
| 02:31.52 | xjqian | sorry, but nobody in the opie channel responded. so I'm trying my luck here |
| 02:44.14 | *** join/#oe jacques (n=jacques@nslu2-linux/jacques) |
| 02:44.50 | *** join/#oe jacques (n=jacques@nslu2-linux/jacques) |
| 02:59.59 | *** join/#oe tank17 (i=ariel@gateway/tor/x-d1d690db0965a7df) |
| 03:00.22 | xjqian | never mind, I found the answer |
| 03:07.22 | xjqian | Note that this will build packages with version "1.2.2+cvs2007xxxx", which uses the old qtopia or QT/embedded-2.3.10 Note that this is not the OPIE II project (which unfortunately labeled itself opie-1.2.3 after svn checkout): http://www.linuxtogo.org/gowiki/OpieProject., which uses the new qtopia-4.2.1. |
| 03:07.31 | xjqian | updated wiki here: http://www.linuxtogo.org/gowiki/OpieWithAngstrom |
| 03:36.34 | *** part/#oe mreimer_ (n=mreimer_@luthien.vpop.net) |
| 03:39.13 | psokolovsky__ | xjqian: your update reverted, please read the page, or at least intro, before making random changes. thanks. |
| 03:46.46 | xjqian | psokolovsky: that's fine and yes i've read the intro |
| 03:47.36 | xjqian | psokolovsky: could you link the opie II page to the intro, so people know which one is which. |
| 03:48.02 | psokolovsky__ | xjqian: then it must have been clear taht it's not opie2, as intro makes that pretty unambiguous |
| 03:48.37 | psokolovsky__ | xjqian: I will some next time, or you're welcome to do that |
| 03:48.38 | xjqian | psokolovsky: what seems confusing to me is http://www.linuxtogo.org/gowiki/OpieProject?highlight=%28opie%29 has the title OpieProject |
| 03:50.12 | psokolovsky__ | xjqian: this issue was already raised to opie2 organizer. he's response was along the lines that creating confusion among the users would be one of his aims. so, enjoy your flight. |
| 03:50.44 | psokolovsky__ | xjqian: there's extensive discussion on opie-devel list if you're interested |
| 03:51.42 | xjqian | ugh. i see. another confusion is after svn checkout svn://projects.linuxtogo.org/svn/opie/trunk opie II creates a directory opie-1.2.3 by default |
| 03:52.06 | xjqian | thanks for the pointer |
| 03:55.08 | *** join/#oe Marex (n=Marex@85.132.236.161) |
| 03:58.34 | *** join/#oe jamie (n=jamie@pdpc/supporter/active/jamie) |
| 04:14.44 | *** join/#oe tank17 (i=ariel@gateway/tor/x-f30ee3c43541ac12) |
| 04:16.51 | ljp | i dont think opieII labeled itself as opie 1.2.3 |
| 04:21.45 | xjqian | ljp: your're right. sorry my mistake |
| 04:23.24 | *** part/#oe pierrelux (n=pierre-l@144-125.sh.cgocable.ca) |
| 04:23.26 | xjqian | ljp: indeed, interesting reading in the opie mailing list. ljp, I see your point. But I'm on psokolovsky's side for the confusion in naming. |
| 04:24.26 | ljp | whats the confusion? |
| 04:24.50 | ljp | t would have been confusing if opieII was just opie |
| 04:26.57 | xjqian | then why not register opie as opieII |
| 04:27.05 | ljp | i never said one of my aims was creating confusion among users, thats just bs |
| 04:27.29 | ljp | the name IS opieII |
| 04:27.33 | xjqian | and in serveral wiki pages, http://www.linuxtogo.org/gowiki/GettingOpieSources, this for example |
| 04:27.42 | humsat | morn :) |
| 04:27.52 | xjqian | i was linked to this page from the mailing list |
| 04:28.01 | ljp | quite less confusiong than the whole GPE hubbub |
| 04:28.19 | xjqian | and there's no indication at all this is to fetch opieII |
| 04:28.46 | xjqian | not a single sign until I got the source and read the README in the trunk |
| 04:29.20 | xjqian | i know it's not your intension to confuse people, but how the wiki pages are written is really confusing |
| 04:32.04 | xjqian | esp to people new to opie |
| 04:32.28 | ljp | ok, well. i will clean tham up when i get the chance |
| 04:33.32 | xjqian | thanks |
| 04:34.41 | psokolovsky__ | ljp: of course you didn't say that. you said that you don't care, and did it confusing way. so don't be surprised that people start to think that you want the confusion. |
| 04:35.28 | ljp | well, someone telling them that wont help |
| 04:35.42 | *** part/#oe _law_ (n=_law_@213.173.86.202) |
| 04:36.17 | *** join/#oe Gerrath (n=Gerrath_@unaffiliated/gerrath) |
| 04:36.20 | psokolovsky__ | ljp: and as for gpe then again, it seems like there's funky inclination to follow that way. and that strange - while working on opie2, wouldn't it be good idea to keep opie1 users warm and not dissatisified with confusion? |
| 04:37.57 | ljp | i still dont see where any confusion is. |
| 04:38.26 | ljp | i could have committed the code to handhelds.org, but i didnt |
| 04:53.30 | psokolovsky__ | ljp: you decide where to host. but if you consistently used opieII/opie2 name everywhere (including project/repo internal names), that would be helpful for people |
| 04:57.10 | *** join/#oe donato_home (n=donato@c9501fd2.bhz.virtua.com.br) |
| 05:14.59 | *** join/#oe _law_ (n=law@mail.stiftadmont.at) |
| 05:18.08 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 06:06.36 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.13.37) |
| 06:12.59 | *** join/#oe Ironnads_ (n=Ironnads@host86-135-183-103.range86-135.btcentralplus.com) |
| 06:13.29 | *** join/#oe mithro (n=tim@lester.mithis.com) |
| 06:18.52 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 06:20.46 | koen | good morning all |
| 06:23.41 | zecke | moin |
| 06:30.48 | zecke | koen: you pay taxes? |
| 06:31.07 | koen | yes, but since I'm a student, I get it all back |
| 06:31.24 | koen | my employers pay taxes for me automagically |
| 06:34.59 | *** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz) |
| 06:36.57 | Laibsc1 | psokolovsky__: qemu-native compilation with the patch finished fine. |
| 06:37.30 | Laibsch | Good morning |
| 06:37.36 | psokolovsky__ | morning! |
| 06:37.55 | psokolovsky__ | Laibsch: cool, now just tell us that it aslo able to generate working locales ;-D |
| 06:43.05 | Laibsch | psokolovsky__: That is all the testing I was going to do on that one. |
| 06:43.29 | Laibsch | I already reversed the patch and cleaned out that qemu-native |
| 06:43.44 | Laibsch | The working locale part is left up to you ;-) |
| 06:44.26 | Laibsch | psokolovsky__: I interrupted the bitbake clean |
| 06:44.37 | Laibsch | How do I find out if it generates working locales? |
| 06:44.40 | psokolovsky__ | lol. as if somebody doubted it does compile ;-) |
| 06:44.51 | Laibsch | psokolovsky__: I thought you did |
| 06:45.00 | Laibsch | I at least was not sure. |
| 06:45.14 | Laibsch | If that does not help, then fine |
| 06:45.22 | Laibsch | Not my problem |
| 06:45.29 | psokolovsky__ | Laibsch: first step is apparently try to build locale(s) at all. if it won't segfault, good sign |
| 06:45.35 | Laibsch | I got a solution I deem superior for me |
| 06:45.59 | Laibsch | psokolovsky__: "bitbake glibc" ? |
| 06:46.06 | psokolovsky__ | Laibsch: then, you can just save generated packages and compare with gcc3-compiled-qemu later (or uplaod so someone else did that) |
| 06:46.16 | Laibsch | I am sorry but I don't have the time for that |
| 06:46.19 | psokolovsky__ | Laibsch: yep |
| 06:46.34 | Laibsch | Nah, you will have to do that. |
| 06:46.38 | psokolovsky__ | Laibsch: but you'd need to do anyway, right? |
| 06:46.46 | psokolovsky__ | ok |
| 06:47.22 | Laibsch | psokolovsky__: I do *not* want anything compiled that I will use later on while this untested patch is applied |
| 06:47.22 | psokolovsky__ | my whole idea of asking you was that you do a clean rebuild on a new machine, and could follow thru all that |
| 06:47.30 | psokolovsky__ | ok |
| 06:47.39 | Laibsch | psokolovsky__: That takes me several days as you know |
| 06:47.47 | Laibsch | an image might even take a week |
| 06:47.57 | Laibsch | I am not cleaning out tmp to test a single bug |
| 06:49.08 | psokolovsky__ | Laibsch: with GLIBC_GENERATE_LOCALES locale generation alone takes 10mins max, add ~1-2hr compiling glibc |
| 06:49.22 | Laibsch | not my machine |
| 06:49.28 | Laibsch | not on my bb machine |
| 06:49.40 | psokolovsky__ | ok, sorry to bother you then ;-) |
| 06:49.45 | Laibsch | And I don't even want to spend ~1-2 hours |
| 06:49.51 | Laibsch | np |
| 06:49.55 | zecke | later |
| 06:50.12 | Laibsch | zecke: Still up? Later |
| 06:50.26 | Laibsch | Seems like everybody skipped sleeping last night |
| 06:52.42 | CIA-4 | 03koen 07org.oe.dev * rf93b1c50... 10/ (1 packages/cairo/cairo_git.bb): cairo-git: update PV |
| 07:04.47 | *** join/#oe dhr (n=hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 07:14.57 | *** join/#oe Laibsch (n=Laibsch@c-134-230-233.f.dsl.de.ignite.net) |
| 07:18.32 | *** join/#oe likewise (n=chatzill@atwork-186.r-212.178.104.atwork.nl) |
| 07:18.46 | likewise | hello all |
| 07:19.13 | koen | hey likewise |
| 07:19.25 | likewise | hey koen |
| 07:19.42 | koen | likewise: http://ewi546.ewi.utwente.nl/tmp/eabi-eb.diff |
| 07:20.43 | likewise | koen: yup, something like that should do it (finger crossed still) |
| 07:21.12 | likewise | koen: haven't been able to test yet, my nightly build was broken |
| 07:22.07 | koen | I have a toolchain now |
| 07:23.21 | likewise | I'm still having problems that every package and then some gets pulled in my images... at least in the build |
| 07:28.10 | koen | you can avoid that by giving each task-* in task-base.bb its own recipe |
| 07:29.57 | CIA-4 | 03polyonymous 07org.oe.dev * rb896e366... 10/ (6 files in 3 dirs): |
| 07:29.57 | CIA-4 | qte, qte-mt 2.3.10: Fix build with recent kernel headers. |
| 07:29.58 | CIA-4 | * Closes #2201. |
| 07:30.01 | CIA-4 | 03pfalcon 07org.oe.dev * ra2852adc... 10/ (4 files in 3 dirs): |
| 07:30.01 | CIA-4 | opie-todo cvs: Unbreak system-wide logging. |
| 07:30.01 | CIA-4 | * A specific app may not override system-wide parameter on a whim - it's |
| 07:30.01 | CIA-4 | under user control. |
| 07:30.07 | CIA-4 | 03pfalcon 07org.oe.dev * r388abcdc... 10/ (3 files in 3 dirs): (log message trimmed) |
| 07:30.07 | CIA-4 | opie-taskbar cvs: Don't bother to start qss from C++ code. |
| 07:30.08 | CIA-4 | * Because it's useless - to have a separate process for sound server, |
| 07:30.10 | CIA-4 | and then have mishacks to start/keep alive it hardcoded in C++. That doesn't |
| 07:30.12 | CIA-4 | work somehow (h4000, hx4700, etc. machines have issues), and then it |
| 07:30.14 | CIA-4 | completely non-debuggable. |
| 07:30.16 | CIA-4 | * So instead, qss should be started separately, of course from a shell script. |
| 07:30.18 | CIA-4 | 03pfalcon 07org.oe.dev * r686b8a7b... 10/ (1 packages/tasks/task-opie.bb): |
| 07:30.20 | CIA-4 | task-opie: Add opie-qss, an OPIE sound server, essential component. |
| 07:30.22 | CIA-4 | * Fixed #2211. |
| 07:30.26 | CIA-4 | 03pfalcon 07org.oe.dev * rc3d8d21c... 10/ (3 files in 3 dirs): |
| 07:30.28 | CIA-4 | opie-init: Start qss daemon. |
| 07:30.30 | CIA-4 | * Fixes #2211. |
| 07:30.32 | CIA-4 | 03pfalcon 07org.oe.dev * rdb859e25... 10/ (1 packages/opie-init/opie-init/opie): opie-init: Actually daemonize qss. |
| 07:30.37 | CIA-4 | 03koen 07org.oe.dev * r4bc8cc04... 10/ (4 files in 3 dirs): gcc 4.1.2: fix 800-arm-bigendian.patch |
| 07:40.33 | koen | likewise: updated patch is in |
| 07:45.32 | likewise | koen: starting a fresh build then for ixp4xxbe/angstrom |
| 07:48.00 | *** join/#oe zecke (n=ich@dsl-62-220-14-162.berlikomm.net) |
| 07:49.47 | likewise | zecke: good morning |
| 07:50.10 | *** join/#oe greentux (n=lemke@ip-217-18-181-130.static.reverse.dsi.net) |
| 07:50.31 | zecke | moin |
| 07:50.35 | zecke | Laibsch: now I'm here |
| 07:52.50 | koen | you're not here, you're in berlin |
| 07:54.24 | *** join/#oe rd_ (n=rd@vnsecurity.net) |
| 07:57.47 | zecke | koen: what makes you believe that? |
| 07:58.01 | koen | your sith powers |
| 08:05.07 | zecke | ;) |
| 08:05.12 | zecke | ~snack for koen |
| 08:05.21 | ibot | ACTION throws for koen a doggy treat |
| 08:07.47 | *** join/#oe obergix[work] (n=olivier@inf-berger.int-evry.fr) |
| 08:16.34 | CIA-4 | 03koen 07org.oe.dev * r2b2a9e8b... 10/ (3 files in 3 dirs): linux-ezx 2.6.21: update to r1996, fixes some oopses |
| 08:20.33 | *** join/#oe univac (n=univac@suita.chopin.edu.pl) |
| 08:35.39 | *** join/#oe univac (n=univac@suita.chopin.edu.pl) |
| 08:39.09 | *** join/#oe univac (n=univac@suita.chopin.edu.pl) |
| 08:39.27 | *** join/#oe pH5 (n=ph5@e178202105.adsl.alicedsl.de) |
| 08:43.14 | *** join/#oe zecke (n=ich@dsl-62-220-14-162.berlikomm.net) |
| 09:00.03 | *** join/#oe lrg (n=liam@lrg2.demon.co.uk) |
| 09:12.25 | *** join/#oe univac (n=univac@148.81.191.193) |
| 09:20.13 | *** join/#oe polyonymous_ (n=hacker@pD953907D.dip0.t-ipconnect.de) |
| 09:33.44 | *** join/#oe Kristoffer|afk (n=Kristoff@81-233-95-80-no75.business.telia.com) |
| 09:42.52 | *** join/#oe z72ka-ntb (n=hermanj@tux2.software602.cz) |
| 09:42.58 | *** join/#oe ade|desk (n=adavey@194.200.143.249) |
| 09:43.52 | *** join/#oe woglinde (n=heinold@leningrad.mi.fu-berlin.de) |
| 09:43.53 | ade|desk | monring |
| 09:43.56 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 09:54.30 | *** join/#oe goxboxlive (n=goxboxli@195.159.97.196) |
| 09:54.48 | *** join/#oe pleemans (n=peter@d5152D19B.access.telenet.be) |
| 09:54.54 | woglinde | hi ade |
| 09:58.33 | *** join/#oe florian (n=fuchs@217.146.132.69) |
| 10:06.05 | polyonymous | mood gorning. |
| 10:06.28 | woglinde | hi polyonymous |
| 10:06.37 | polyonymous | hi. |
| 10:07.58 | polyonymous | Laibsch, I wouldn't say that 'opie in angstrom' metabug depends on the dual gpe/opie image bug ;-) |
| 10:10.41 | Laibsch | My interpretation as creator of the meta-bug is "all bugs related straight to opie" which is true. |
| 10:12.57 | Laibsch | to rephrase it, koen should be able to safely ignore any bug that is blocking it ;-) |
| 10:14.21 | likewise | Could this be a dash/bash issue? | make[3]: Leaving directory `/home/leon/sandbox/ixp4xxbe-eabi/openembedded/build/tmp/work/x86_64-linux/perl-native-5.8.7-r5/perl-5.8.7/x2p' |
| 10:14.23 | likewise | | ../makedepend: 1: Syntax error: Unterminated quoted string |
| 10:14.45 | koen | likewise: probably |
| 10:14.49 | zecke | likewise: yes, makedepend of perl is broken :) |
| 10:14.54 | koen | I built 5.8.8, which is dash-safe |
| 10:15.13 | polyonymous | Laibsch, I just stated my opinion, I'm not feeling like fighting for it :) |
| 10:15.15 | likewise | ok, tnx. |
| 10:15.22 | Ifaistos | morning all |
| 10:15.34 | likewise | morning Ifaistos |
| 10:15.47 | likewise | ***good*** morning Ifaistos |
| 10:16.20 | koen | likewise: http://www.openembedded.org/~koen/ARM-eb-EABI-rootfs.tgz |
| 10:21.08 | likewise | koen: got it. need to prep some h/w setup here. |
| 10:22.41 | likewise | hmm. no. need to build an EABI kernel first |
| 10:22.48 | polyonymous | Laibsch, tried to hack around your collie psplash (bug 2149), yet? |
| 10:33.32 | polyonymous | opie-todo doesn't build, hmm... |
| 10:39.03 | koen | likewise: Lennert: Yep, werkt perfect. Dus toch __ARMEB__-issues.. |
| 10:46.23 | psokolovsky__ | Hi! |
| 10:46.40 | polyonymous | hey |
| 10:46.47 | psokolovsky__ | koen: So, can you link http://linuxtogo.org/gowiki/AngstromFaq for word "FAQ" on angstrom site? |
| 10:46.55 | *** join/#oe rd__ (n=rd@toi.yeu.phu.nu) |
| 10:47.22 | psokolovsky__ | koen: or do you leave that as an exercize to a reader - read wiki and discover faq? |
| 10:47.36 | *** part/#oe rd__ (n=rd@toi.yeu.phu.nu) |
| 10:47.37 | psokolovsky__ | koen: please don't, *many* people will fail it ;-) |
| 10:47.43 | polyonymous | if ti was hard to write it should be hard to understand :) |
| 10:48.11 | psokolovsky__ | koen: and thanks and congrats on the facelift of the site ;-) |
| 10:56.37 | likewise | koen: what works perfectly? your rootfs? |
| 10:56.48 | koen | likewise: yes |
| 10:57.07 | likewise | koen: ok, so the missing patch hunk was the root of all evil? |
| 10:57.18 | koen | likewise: it seems that way |
| 11:00.19 | *** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz) |
| 11:03.50 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 11:12.27 | chouimat | morning |
| 11:12.33 | koen | hey chouimat |
| 11:13.42 | *** join/#oe woglinde (n=heinold@leningrad.mi.fu-berlin.de) |
| 11:33.25 | xjqian | psokolovsky__: bitbake -c clean only cleans up stuff in tmp/work. Are there any other bitbake -c command that cleans up stuff in tmp/staging (or I have to clean those manually). (I've read the bb manual and can't find any enlightenment, btw) |
| 11:34.19 | *** join/#oe blayne (n=blayne@dsl093-039-078.pdx1.dsl.speakeasy.net) |
| 11:37.44 | *** join/#oe Marex (n=Marex@85.132.236.161) |
| 11:45.58 | psokolovsky__ | xjqian: no. finish "packaged staging" thing if you want it ;-) |
| 11:46.42 | *** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 11:46.45 | *** join/#oe grma_ (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 11:46.55 | xjqian | psokolovsky__: got it. thanks |
| 11:47.04 | koen | psokolovsky__: expect some updates to packaged-staging during GUADEC :) |
| 11:47.17 | psokolovsky__ | koen: cool! |
| 11:47.53 | *** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 11:48.58 | *** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 11:49.06 | polyonymous | psokolovsky__, just FYI - on my Z sound in opie works on initial start as well. |
| 11:49.33 | psokolovsky__ | polyonymous: since when? |
| 11:50.38 | polyonymous | psokolovsky__, don't know, I've just tested with a fresh image. |
| 11:50.38 | polyonymous | the one that doesn't build (2224:)). |
| 12:06.47 | koen | RP: the install patch works fine, the only exception being do_deploy |
| 12:07.44 | polyonymous | psokolovsky__, regarding 2224 - I think the patch was older than your recent cvs bump? |
| 12:08.54 | psokolovsky__ | polyonymous: no. please describe the exact issue you have, not ideas what it might be |
| 12:09.16 | polyonymous | psokolovsky__, what is there to describe? The patch doesn't apply, because it's already there after checkout. |
| 12:09.29 | likewise | NOTE: <type 'exceptions.TypeError'>:argument of type 'NoneType' is not iterable while evaluating: |
| 12:09.31 | likewise | ${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']} |
| 12:10.00 | psokolovsky__ | polyonymous: link to upstream please |
| 12:10.20 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 12:11.08 | *** join/#oe svolpe_gerrath (n=Gerrath_@unaffiliated/gerrath) |
| 12:11.17 | *** join/#oe hwtechnik (n=hwtechni@f1.globalcore.net) |
| 12:11.39 | *** join/#oe benlau (n=benlau@221.125.13.148) |
| 12:12.41 | polyonymous | psokolovsky__, heck, it's two years old, but it DOES contain the patch: http://handhelds.org/cgi-bin/cvsweb.cgi/opie/core/pim/todo/main.cpp?rev=1.11&content-type=text/x-cvsweb-markup |
| 12:13.32 | polyonymous | hmm.. |
| 12:13.34 | likewise | koen: Now this can be reversed I guess? http://www.openembedded.org/viewmtn/revision.psp?id=f342c01c457224ae016d92fea9fbf40b24d88f32 |
| 12:13.35 | psokolovsky__ | polyonymous: ok, let's start from the start. which patch? |
| 12:13.49 | koen | likewise: yes |
| 12:13.55 | polyonymous | psokolovsky__, hang o. |
| 12:13.55 | polyonymous | n |
| 12:14.11 | *** join/#oe nm (n=hongtd@222.252.102.104) |
| 12:14.52 | polyonymous | psokolovsky__, forget it. |
| 12:15.05 | CIA-4 | 03pfalcon 07org.oe.dev * re51f8fd8... 10/ (3 files in 3 dirs): |
| 12:15.05 | CIA-4 | libqpe-opie cvs: Unbreak logging. |
| 12:15.05 | CIA-4 | * Again, it's bad idea to randomly disable some logging sources based on |
| 12:15.05 | CIA-4 | obscure compile-time defines (QT_DEBUG is not mentioned in qte-2.3.10, so |
| 12:15.05 | CIA-4 | how could it get such name at all?). OE OPIE is going to have logging facility |
| 12:15.05 | CIA-4 | helping to resolve issues, not obfuscate them. |
| 12:16.02 | CIA-4 | 03koen 07org.oe.dev * ra8e33b18... 10/ (1 conf/machine/ixp4xxbe.conf): ixp4xxbe: the gcc patch is in, so no need for this workaround anymore |
| 12:17.19 | koen | likewise: there you go |
| 12:17.42 | polyonymous | psokolovsky__, not exactly forget it - the patch doesn't apply. I don't know what I was looking at, when I said it doesn't apply, because it's already there. |
| 12:18.15 | likewise | koen: and http://www.openembedded.org/viewmtn/revision.psp?id=bc8cfed5e37f251070c62f9cef49b1db7aa86264 |
| 12:18.32 | psokolovsky__ | polyonymous: yes, that's true. reasons not true. first rule of system enginering - don't trust anything, verify ;-) |
| 12:18.58 | polyonymous | psokolovsky__, Yes, I do not have much to say in my defense :) |
| 12:19.22 | psokolovsky__ | and now I wonder who on earth was such smart as to stuff some gnome crap for patch conflict resolution?! |
| 12:19.26 | koen | likewise: right |
| 12:19.27 | polyonymous | psokolovsky__, it's todo/ path, have you fixed it yet? |
| 12:19.41 | psokolovsky__ | shame, shame! people forgot what unix is! they use some |
| 12:20.03 | psokolovsky__ | "leenooks" crap with dwarfs and stuff, instead of commandline! |
| 12:20.05 | psokolovsky__ | shame! |
| 12:21.15 | psokolovsky__ | # Set a default |
| 12:21.15 | psokolovsky__ | TERMCMD ?= "${GNOME_TERMCMD}" |
| 12:21.17 | psokolovsky__ | b/s |
| 12:21.27 | polyonymous | psokolovsky__, I'm running away now. I don't know if you fixed that patch, just in case: http://rafb.net/p/khF9fi12.html |
| 12:22.20 | likewise | koen: thanks. |
| 12:22.37 | koen | likewise: could you revert the patch, I'm about to run off |
| 12:22.44 | likewise | I am hitting a bitbake problem here or something else? http://www.pastebin.ca/468837 |
| 12:22.56 | likewise | koen: yes, will do |
| 12:23.03 | likewise | koen: cu |
| 12:23.13 | koen | likewise: no TARGET_OS? |
| 12:24.12 | koen | (armeb-INVALID vs armeb-linux) |
| 12:24.12 | likewise | koen: using MACHINE=ixp4xxbe with DISTRO=angstrom-2007.1 |
| 12:24.12 | likewise | koen: lemme check eb vs be |
| 12:25.06 | likewise | koen: ixp4xxbe |
| 12:31.19 | *** join/#oe z72ka-ntb (n=hermanj@tux2.software602.cz) |
| 12:33.13 | *** join/#oe marcan (n=marcanso@160.10.7.121) |
| 12:48.28 | CIA-4 | 03lenehan 07org.oe.documentation * ref06b87a... 10/ (1 usermanual/reference/image_types.xml): (log message trimmed) |
| 12:48.28 | CIA-4 | usermanual: Update image types to match recent changes: |
| 12:48.28 | CIA-4 | - ext3 and ext3.gz have been added |
| 12:48.28 | CIA-4 | - cpio and cpio.gz have been added |
| 12:48.28 | CIA-4 | - default options for jffs2, squashfs and squashfs-lzma have been changed |
| 12:48.29 | CIA-4 | - ext2.gz now deletes tmp files so leftovers don't break next run |
| 12:48.31 | CIA-4 | - tar has been changed to make tars instead of tar.bz2's |
| 12:48.41 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 12:49.34 | *** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 13:08.07 | RP | psokolovsky__: What is your problem? |
| 13:10.35 | psokolovsky__ | RP: Well, mail should describe it well enough - no rc check for "terminal" command, out-of-hand default for such command. I leave interpretation of the rest to you ;-) |
| 13:11.12 | RP | psokolovsky__: You just succeeded in massively pissing me off... |
| 13:12.08 | psokolovsky__ | RP: I'm sorry, but I tried to make it both funny and "cognitive" |
| 13:12.38 | psokolovsky__ | RP: it's also pissing off for me to understand that I could been building broken images for a month now %) |
| 13:13.31 | *** join/#oe daurnimator (i=daurn@unaffiliated/daurnimator) |
| 13:13.38 | RP | psokolovsky__: I can understand that being frustrating. We are all trying to develop various things and with the best will in the world, things do break though |
| 13:14.34 | ade|desk | hmm OT: can you break broken glass ? |
| 13:15.55 | psokolovsky__ | RP: yeah, but I clear added humoresque shade to that "report", no? maybe just too "vivid", because I'm not sure I could argue to success that such a tool like bitbake should *not* depend on nay GUI stuff ;-I |
| 13:16.40 | psokolovsky__ | RP: otherwise, I of course didn't intend to make you frown in a day ;-) |
| 13:17.10 | polyonymous | It's my fault, I made psokolovsky__ mad today :) |
| 13:17.20 | polyonymous | probably, he passed the piss :) |
| 13:18.08 | psokolovsky__ | polyonymous: well nope, but I wonder if you had the same issue. I initially thought you did |
| 13:18.20 | polyonymous | psokolovsky__, the same like what? |
| 13:18.49 | polyonymous | psokolovsky__, I indeed goofed twice today. |
| 13:19.02 | psokolovsky__ | polyonymous: like silent failure to patch, though I now guess it wasn't your case |
| 13:19.11 | *** join/#oe TheCan (n=thecan@dslb-084-056-185-005.pools.arcor-ip.net) |
| 13:19.31 | polyonymous | psokolovsky__, maybe it's just my setup, but it wasn't quite failure. It was quite audible. |
| 13:19.50 | polyonymous | psokolovsky__, but.. |
| 13:19.54 | RP | psokolovsky__: I've replied to the mail with some hints |
| 13:20.02 | polyonymous | ahhh now I know what this GUI stuff you're talking about. |
| 13:20.11 | polyonymous | psokolovsky__, yes, I've had terminal popup. |
| 13:20.13 | RP | psokolovsky__: automated builds are why we shouldn't depends on GUI functionality |
| 13:20.27 | RP | psokolovsky__: but that doesn't mean we shouldn't have optional GUI functionality |
| 13:21.18 | polyonymous | RP, If I get it right, the problem is that it's not optional enough. The rest is emotional miscommunication :) |
| 13:22.09 | RP | polyonymous: See the reply, it is optional, you just need to know how to configure it. There sounds to be some kind of error propagation bug somewhere too |
| 13:22.11 | psokolovsky__ | RP: optional, sure! (especially if you need it). but the change goes towards requiring GUI by default, and I couldn't appreciate that, and I'm sure there're few people around who would agree. |
| 13:22.39 | polyonymous | I haven't even read original mail :) |
| 13:22.52 | RP | psokolovsky__: Its just a bad default for PATCH_RESOLVER. FWIW, I didn't set that default |
| 13:23.15 | RP | psokolovsky__: If we want to change it to noop, I'm fine with that |
| 13:23.36 | polyonymous | But without looking at it (I will in half a minute) I think the solution is comething along the lines `${TERM} || ${BASH}`. |
| 13:23.37 | RP | I do want to find the underlying bug though as command failures should abort the build |
| 13:24.18 | RP | polyonymous: No, that breaks under multithreading. I've given this a lot of thought and there have been several mails to the mailing list about it |
| 13:24.21 | psokolovsky__ | RP: apparently, that's what should be done, right. thanks for proposing that. |
| 13:24.55 | polyonymous | RP, yes, that makes sense, indeed.... then, maybe `|| ${FAIL}`. |
| 13:24.57 | RP | psokolovsky__: I want to find that underlying bug though - don't just take the simple solution ;-) |
| 13:25.41 | psokolovsky__ | RP: yeah, I guess |
| 13:25.52 | polyonymous | well, anyway. I think you can do without my intervening :) |
| 13:26.01 | psokolovsky__ | RP: I will try to do that too a bit later, if you won't beat me on that |
| 13:26.32 | RP | psokolovsky__: I have other things to do atm. It'll probably be the weekend before I can think about it |
| 13:26.42 | *** join/#oe mr_nice (n=mr_nice@p54a9fb9f.dip.t-dialin.net) |
| 13:26.58 | mr_nice | hi all |
| 13:27.17 | polyonymous | psokolovsky__, do I reopen todo bug, or is it not necessary? |
| 13:27.39 | psokolovsky__ | RP: ok. again, sorry, if I pulled you from important thing and added unneeded headache. wasn't intended. |
| 13:27.48 | woglinde | hi mr_nice |
| 13:27.56 | mr_nice | hi woglinde |
| 13:28.02 | psokolovsky__ | polyonymous: I committed it, feel free to try buidl again |
| 13:28.22 | polyonymous | psokolovsky__, ok. on last pull I've had multihead hydra :) |
| 13:29.28 | polyonymous | psokolovsky__, And I've just tested the getpagesize() fix - seems to work fine. |
| 13:30.34 | psokolovsky__ | polyonymous: nice. I'll commit as soon as I'll do next code session ;-) |
| 13:30.58 | polyonymous | good. just letting you know, not hurrying you up :) |
| 13:31.31 | *** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 13:47.13 | *** join/#oe mr (n=mr_nice@p54A9FF6C.dip.t-dialin.net) |
| 14:14.32 | likewise | Aarrgh. qemu: uncaught target signal 11 (Segmentation fault) - exiting (this is natively installed qemu on Feisty 7.04) |
| 14:16.32 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.93.226) |
| 14:28.26 | *** join/#oe CosmicPenguin (i=nobody@nat/amd/x-3d1d0f014f7ea603) |
| 14:30.08 | *** join/#oe z72ka-ntb (n=hermanj@tux2.software602.cz) |
| 14:30.08 | *** join/#oe vervain (n=vervain@mail.somat.com) |
| 14:45.36 | *** join/#oe aoe (n=aoe@tigerente.htu.tuwien.ac.at) |
| 14:49.31 | *** join/#oe jipi (n=jipi@cm128.delta240.maxonline.com.sg) |
| 14:53.01 | *** join/#oe _law_ (n=_law_@213.173.86.202) |
| 14:55.07 | *** join/#oe benlau (n=benlau@221.125.13.148) |
| 14:57.45 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 15:13.32 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 15:16.11 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 15:27.22 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 15:44.22 | *** join/#oe tnb (n=tnb@sdgsystems.net) |
| 15:50.03 | *** join/#oe den-ros (n=den@ppp85-140-69-227.pppoe.mtu-net.ru) |
| 15:51.51 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 15:53.00 | *** join/#oe ozstinger (n=ozstinge@216.143.234.167) |
| 16:00.22 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 16:04.32 | *** join/#oe hvontres|poodle (n=hvontres@68.120.74.196) |
| 16:10.49 | hvontres|poodle | polyonymous: morinng :) |
| 16:15.48 | *** join/#oe TheCan (n=thecan@dslb-084-056-185-005.pools.arcor-ip.net) |
| 16:18.58 | *** join/#oe HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 16:21.03 | polyonymous | hvontres|poodle, yes :) |
| 16:23.06 | polyonymous | hvontres|poodle, got /msg? |
| 16:28.27 | hvontres|poodle | polyonymous: got it, thanks :) I'll grab it when I get home tonight |
| 16:29.03 | polyonymous | Good. It will be there waiting for you :) |
| 16:39.04 | *** join/#oe greentux (n=lemke@Z5a36.z.pppool.de) |
| 16:42.45 | *** join/#oe svolpe (n=Gerrath_@unaffiliated/gerrath) |
| 16:47.04 | *** join/#oe florian (n=fuchs@217.146.132.69) |
| 17:00.46 | *** join/#oe vervain (n=vervain@mail.somat.com) |
| 17:14.32 | *** join/#oe dalurka_ (n=dalurka@holly.bsnet.se) |
| 17:17.59 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 17:41.36 | *** join/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl) |
| 17:42.10 | *** join/#oe mr_nice (n=mr_nice@p54A9FF6C.dip.t-dialin.net) |
| 17:43.39 | HopsNBarley | hi likewise! |
| 17:52.27 | Ifaistos | Can anyone suggest the best method of creating a single file image with kernel+jffs2 as rootfs with u-boot ? |
| 17:52.28 | *** join/#oe xuumbi (n=jim@70.90.111.225) |
| 17:52.52 | Ifaistos | paste the files together with dd or use mkimag -T multi option ? |
| 17:56.16 | *** join/#oe lfn (n=fredric_@130.216.171.66.subscriber.vzavenue.net) |
| 17:58.21 | *** join/#oe jott (n=j@unaffiliated/jott) |
| 18:03.58 | likewise | HopsNBarley: hi! |
| 18:04.01 | likewise | hi all |
| 18:04.07 | NAiL | hi likewise |
| 18:04.23 | likewise | koen: did not commit the revert yet, I didn't have my key with me... |
| 18:04.41 | koen | and I'm playing with a new toy :) |
| 18:05.24 | likewise | koen: the cam you saw on ebay or something else? |
| 18:05.44 | likewise | koen: but will commit in a moment. |
| 18:05.46 | NAiL | koen: what toy? |
| 18:06.08 | koen | new image stabilised lens |
| 18:06.19 | NAiL | ah |
| 18:06.24 | NAiL | not my kind of toy then ;) |
| 18:06.30 | koen | doens't run linux :) |
| 18:06.43 | NAiL | nope |
| 18:06.46 | NAiL | shame ;) |
| 18:08.19 | likewise | koen: what's the best way to commit? disapprove or just a reverse patch? |
| 18:08.47 | koen | remove the patch from SRC_URI and mtn rm -e it |
| 18:09.19 | koen | DaggyFixes would involve disapproving it and merging, but that makes my brain hurt |
| 18:10.19 | koen | http://www.venge.net/mtn-wiki/DaggyFixes |
| 18:10.33 | *** join/#oe mmp (n=mmp@TheWide.ubyt.sdjls.uniba.sk) |
| 18:12.07 | lfn | i have a question about building packages that are subsets of other packages |
| 18:12.40 | lfn | for example, if i tried creating a diffutils-minimal that only included diff and cmp (omitting sdiff and diff3) |
| 18:13.28 | lfn | however, when i build my final image, diffutils is added to it to 'satisfy runtime diffutils-minimal' |
| 18:13.54 | lfn | any thoughts on what i need to do to break this dependence? |
| 18:18.56 | CIA-4 | 03likewise 07org.oe.dev * rd8cede68... 10/ (4 files in 4 dirs): glibc: Remove armeb strlen workaround. We now have the GCC PR16350 patch, take 3 in GCC. |
| 18:28.04 | *** join/#oe timtimred (n=On3@62-31-181-7.cable.ubr02.chel.blueyonder.co.uk) |
| 18:28.16 | *** join/#oe gremlin[it] (n=gremlin@217.202.67.189) |
| 18:32.46 | polyonymous | psokolovsky__, ping? |
| 18:32.56 | psokolovsky__ | polyonymous: pong |
| 18:33.09 | polyonymous | psokolovsky__, why no-builtin-qss-startup.patch ? |
| 18:33.53 | psokolovsky__ | polyonymous: read commit message |
| 18:34.00 | polyonymous | psokolovsky__, good point :)) |
| 18:34.01 | polyonymous | sorry |
| 18:34.37 | psokolovsky__ | polyonymous: btw, possible, it in fact will be reverted, but instead shell wrapper will be called |
| 18:35.12 | psokolovsky__ | polyonymous: of course, unless you have better ideas: a) why pocketpc/palms don't work; b) how to make it all more debuggable |
| 18:35.47 | polyonymous | psokolovsky__, hmm... when it started autmatically there's no way to kill it and restart elsewhere? |
| 18:35.48 | *** join/#oe Crofton (n=balister@hc65216ca.dhcp.vt.edu) |
| 18:36.13 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 18:36.25 | polyonymous | psokolovsky__, I'd be glad to find out why pocketpc/palms don't work, but I do not have it :) |
| 18:36.44 | psokolovsky__ | polyonymous: no. it stupidly keeps restarting its own instance. that's exactly why that patch - better control by externalizing |
| 18:37.06 | koen | rwhitby: EABI/BE is working now |
| 18:37.11 | polyonymous | psokolovsky__, I see... The thing is that this 'sleep 1' isn't always enough. |
| 18:38.20 | psokolovsky__ | polyonymous: yep, I guess ;-). how much? |
| 18:38.47 | polyonymous | psokolovsky__, I haven't tried to find out, it depends on device. _sometimes_ sleep 1 _is_enough.. |
| 18:39.39 | polyonymous | psokolovsky__, as for debugging you can rename file for debugging. |
| 18:39.52 | psokolovsky__ | polyonymous: again, why I think that maybe calling it from qpe would be better after all - it *knows* when to start it ;-) |
| 18:40.15 | psokolovsky__ | polyonymous: no, there're should decend diagnostics means w/o any hacks |
| 18:40.24 | psokolovsky__ | should be |
| 18:40.26 | polyonymous | that's basically the only reason why I raised the issue :) |
| 18:40.41 | polyonymous | well, debugging _is_ hacking, anyway :) |
| 18:41.24 | polyonymous | I'd that that externalizing for debugging isn't the reason, because debugging is not the primary purpose of running software :) |
| 18:42.17 | polyonymous | So, I'd rather run it from qpe... But naturally, the issues should be solved... |
| 18:42.30 | psokolovsky__ | polyonymous: that's why I call it "diagnostics" after all. Diagnostic support *is* important feature of any complex system. |
| 18:42.57 | polyonymous | psokolovsky__, "diagnostics" as in "logging" should work from qpe, no? |
| 18:43.08 | psokolovsky__ | polyonymous: try it ;-) |
| 18:43.20 | polyonymous | psokolovsky__, If you say no, I'd believe you :) |
| 18:43.31 | psokolovsky__ | and compare with decent solution, like log4j ;-) |
| 18:44.11 | psokolovsky__ | polyonymous: it's adhoc, inconsistent, and fragmented. was scarse at all w/o my recent patches |
| 18:45.05 | polyonymous | psokolovsky__, well, I'm not going to defend this thing, it's just that I doubt the solution is good. |
| 18:45.30 | psokolovsky__ | polyonymous: which one? external startup of qss? |
| 18:45.47 | polyonymous | yes, I'm only talking about his. I do not propose redoing the whole opie :) |
| 18:47.50 | polyonymous | psokolovsky__, what about a little compromise: do not restart qss? :) |
| 18:48.28 | psokolovsky__ | polyonymous: yep, that's the problem - opie indeed could use cleanup not only in intergration, but in design. external qss startup is of course rigth thing, but given funky deps on other semi-services, it doesn't work good ;-\ |
| 18:49.12 | psokolovsky__ | polyonymous: dunno. as I say, plan is to run script, and script can bother with such stuff. |
| 18:49.28 | polyonymous | What would be in the script? |
| 18:49.41 | polyonymous | I don't understand how would that help. |
| 18:49.57 | psokolovsky__ | polyonymous: "qss >log &" ? |
| 18:50.01 | *** part/#oe den-ros (n=den@ppp85-140-69-227.pppoe.mtu-net.ru) |
| 18:50.01 | polyonymous | ah |
| 18:50.28 | polyonymous | psokolovsky__, well, I think that's not needed in "production". |
| 18:50.55 | polyonymous | I think this kind of debugging stuff can be better achieved by renaming qss and running it externally for debugging purpose. |
| 18:52.01 | polyonymous | psokolovsky__, and, anyway, I'd propose no-builtin-qss-restart.patch. It will be shorter too :) |
| 18:52.09 | psokolovsky__ | polyonymous: see above - "no, there're should decend diagnostics means w/o any hacks" |
| 18:52.30 | polyonymous | There will be no decent diagnostics means, anyway :) |
| 18:53.06 | polyonymous | and, again, see above - debugging IS hacking and debugging is not the primary goal of development. For us it may be, but not for user :) |
| 18:54.00 | psokolovsky__ | polyonymous: didn't I "infect" you with idea and you'd go to move qte adhoc logging from libqpe-opie to libopie2 (where "opie" logging lives)? ;-) |
| 18:54.39 | psokolovsky__ | polyonymous: yeah. diagnostics is. so, debugging with renames is out. diagnostics with script is in ;-) |
| 18:55.44 | polyonymous | well, I do not really see how is it better in production and that is the primary criterion... But it sure is better than what we have now. |
| 18:56.00 | psokolovsky__ | polyonymous: and that attitude is mistake of many commercial vendors (withink one well-known OS vendor). But we don't build terminators here. We'd known there's something wrong long before they will decide to conquere the Earth ;-) |
| 18:56.25 | polyonymous | what attitude? |
| 18:57.02 | psokolovsky__ | "not part of production" |
| 18:57.45 | polyonymous | psokolovsky__, wait, what about autostarting qss with -nodaemon? |
| 18:58.31 | polyonymous | Well, I somewhat agree with you on this one. |
| 18:58.36 | psokolovsky__ | polyonymous: autostarting where? and I answered - qss.sh |
| 18:58.49 | polyonymous | psokolovsky__, nah, in opie-taskbar. |
| 18:58.53 | polyonymous | qpe that is. |
| 18:59.29 | psokolovsky__ | polyonymous: yes, current idea is to make opie-taskbar run qss.sh. sounds good? |
| 18:59.59 | polyonymous | psokolovsky__, sounds acceptable. But I was thinking about adding it to qpe, instead of wrapper script. |
| 19:01.01 | psokolovsky__ | polyonymous: bit it was in qpe, undiagnostable. I offered you - tell me what's wrong with it on pocketpcs/palms. have answer? |
| 19:01.45 | *** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 19:02.04 | polyonymous | psokolovsky__, you know already I have no pocketpcs/palms. Well... why is undiagnostable? Where does the output go when run in qpe? |
| 19:03.45 | psokolovsky__ | polyonymous: /dev/null? and important thing from which legs of thsi stuff grow - we must make it such, that we - and not only we - could be able to diagnoze it w/o access to devices. |
| 19:04.34 | polyonymous | psokolovsky__, who redirects it to /dev/null? You mean it goes there even if qpe is run with -nodaemon? |
| 19:05.31 | psokolovsky__ | polyonymous: it goes "somewhere", where you can't find it. didn't I mentioned "adhoc, inconsistent, and fragmented; was scarse" logging? |
| 19:05.54 | polyonymous | What about solving exactly this problem? |
| 19:06.32 | psokolovsky__ | polyonymous: and at this I already joked and hinted ;-) |
| 19:06.52 | polyonymous | Okay, I'll play around with it. |
| 19:07.20 | psokolovsky__ | polyonymous: it == consistent and centralized means of logging, I hope ;-) |
| 19:07.45 | polyonymous | it == making sure that if you run qpe -nodaemon you get qss messages along with other crap. |
| 19:08.20 | polyonymous | I doubt it produces any output, though... :) |
| 19:08.36 | polyonymous | For me it's just silent unless it can't connect top qpe :) |
| 19:08.41 | polyonymous | s/top/to |
| 19:09.46 | psokolovsky__ | polyonymous: well, you miss the fact that *that* already was done for me. we need general logging support now, not waste time patchinh here and there. ymmv |
| 19:11.16 | polyonymous | psokolovsky__, I have nothing against logging as long as it doesn't prevent qss from starting up as a side effect :) Or what are you talking about? If you suggest that I just further develop opie, I don't think I'm ready to go for it :) |
| 19:12.02 | *** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 19:12.02 | polyonymous | Not unless I see where the whole opie thing goes. So far having my trivial patches sitting there for ages doesn't really encourage further enhancements :) |
| 19:12.32 | psokolovsky__ | polyonymous: rejigger logging and clean up machine support are two things which would be required to get OPIE to the decent state. note, I even don't mention unit tests ;-) |
| 19:13.24 | polyonymous | psokolovsky__, well, you're talking from opie's POV. And from that perspective you're absolutely right. But we're on #oe now :) |
| 19:13.46 | psokolovsky__ | polyonymous: I fully agree. But for me - I subscribed to maintain opie in OE, and I want to being able to do that, not waste days of my time on each semi-trivial issue. |
| 19:14.11 | psokolovsky__ | polyonymous: nope, I speak exactly from OE perspective ;-) |
| 19:14.54 | polyonymous | from OE perspective we want to get opie running on as many devices as possible. Well, the usual thing - world domination :) |
| 19:16.01 | psokolovsky__ | aim of OPIE in OE - provide well-ingrated system and easy support for new machines. w/o those 2 thinsg above, it's firefighting, not maintenance |
| 19:16.01 | slapin_nb | hi, all! |
| 19:16.03 | psokolovsky__ | slapin_nb: hello, lazyboy! |
| 19:16.03 | slapin_nb | about that commit access, again... |
| 19:16.05 | polyonymous | psokolovsky__, yes, but that's in fact opie issue, not oe. |
| 19:16.06 | slapin_nb | psokolovsky__, btw, I think I finish that thing tomorrow. |
| 19:16.10 | polyonymous | I do not mind enhancing opie if I see where it's headed, of course. |
| 19:16.21 | psokolovsky__ | slapin_nb: *What* thing? Let me dream!! ;-D |
| 19:16.43 | *** part/#oe _law_ (n=_law_@213.173.86.202) |
| 19:16.50 | slapin_nb | psokolovsky__, m-k applet, do you still remember it? :) |
| 19:17.07 | slapin_nb | psokolovsky__, or that's irrelevant yet? |
| 19:17.11 | *** join/#oe law|ibook (n=_law_@213.173.86.202) |
| 19:17.35 | polyonymous | speaking of commit access... :) |
| 19:17.46 | slapin_nb | polyonymous, yes? |
| 19:18.01 | polyonymous | slapin_nb, nah, that remark wasn't exactly for you :) |
| 19:18.15 | polyonymous | What's with m-k applet, btw? |
| 19:18.20 | slapin_nb | polyonymous, :( |
| 19:18.23 | *** join/#oe z72ka (n=hermanj@r5af183.net.upc.cz) |
| 19:18.39 | polyonymous | slapin_nb, I didn't mean to offend you. |
| 19:18.41 | slapin_nb | polyonymous, that's psokolovsky__ to discuss whole idea |
| 19:18.51 | polyonymous | ah ok |
| 19:18.57 | slapin_nb | psokolovsky__, |
| 19:19.06 | *** join/#oe psokolovsky (n=psokolov@82.193.98.2) |
| 19:19.13 | polyonymous | wb |
| 19:19.14 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 19:19.38 | slapin_nb | psokolovsky, |
| 19:19.42 | psokolovsky | these mips routers do hang sometimes, you know... |
| 19:19.46 | psokolovsky | <psokolovsky__> slapin_nb: yep, I just didn't even try to ping you about it, to not be put down! well, you're cool! |
| 19:20.27 | *** join/#oe woglinde (i=woglinde@e178091232.adsl.alicedsl.de) |
| 19:20.32 | slapin_nb | psokolovsky, I got time now, so I'm going to flush my TODO, and this one is near top of it. |
| 19:21.16 | slapin_nb | psokolovsky, so I ask if it's still needed |
| 19:21.28 | psokolovsky | slapin_nb: cool, thanks. on my side, I only cleaned up my older patches for mb-kbd, and put stuff in hg. what's left is exactly to use results of your applet's work ;-) |
| 19:21.42 | psokolovsky | slapin_nb: absolutely and desperately!! |
| 19:22.15 | slapin_nb | psokolovsky, ok |
| 19:23.09 | slapin_nb | any commit access possibilities for me, btw? (I mean OE.dev) |
| 19:24.08 | psokolovsky | slapin_nb: well, collect your bug submissions and send list to koen/hrw ;-). I'd be glad to vote for you ;-) |
| 19:24.48 | polyonymous | psokolovsky, what was the outcome of my voting, if this what you'd call voting, btw? :) |
| 19:25.20 | psokolovsky | polyonymous: I'm not core developer, so have no idea of such questions |
| 19:25.29 | slapin_nb | psokolovsky, ok, thanks! |
| 19:25.58 | psokolovsky | polyonymous: in your place, I'd waite few days more, and send mail to those folks asking for commit, referncing that oe-devel topic |
| 19:26.12 | polyonymous | psokolovsky, okay, just wondering. I'm quite content with submitting bugs, but now that I have quite a few some of which are definitely safe to commit, it would make sense. |
| 19:27.08 | psokolovsky | polyonymous: I may only agree. the number of submissions increases, and we need more committers to keep up |
| 19:27.23 | polyonymous | psokolovsky, They're well aware, as hrw said, "speaking of giving commit access to polyonymous" before proposing the other dev for commit access :) Well, I'm not in a hurry anyway - I'd have to learn mtn better. Now I can live with my knowledge :)) |
| 19:28.19 | xuumbi | how does bitbake become aware of new package versions, and recompile when a newer version of a package is available for an image/task? |
| 19:28.21 | psokolovsky | polyonymous: well, just keep in mind, that you should be proactive ;-) |
| 19:28.48 | polyonymous | psokolovsky, or active at the very least, I know. That's always my problem :) |
| 19:29.01 | psokolovsky | xuumbi: latest available version is used, unless masked/pinned. how? by scanning all versions ;-) |
| 19:29.51 | psokolovsky | polyonymous: well, you're active regarding bugs submissions, now be ready to calmly nag OE maintainers ;-) |
| 19:30.29 | xuumbi | psokolovsky: as an experiment I tried changing "r0" to "r1" in my .bb file, but when rebuilding my image it doesn't see the change and rebuild the package |
| 19:30.52 | xuumbi | psokolovsky: so then I changed the version number of the .bb itself, and that didn't get picked up either :( |
| 19:30.58 | polyonymous | psokolovsky, I prefer patching to nagging :) before I go for two weeks to Moscow, I don't think I'll be pushing it myself. It would be silly - to get access and immediately get off :) |
| 19:31.12 | psokolovsky | xuumbi: it should - PR's are almost never pinned. |
| 19:31.39 | xuumbi | psokolovsky: ok I'll dig deeper, thanks |
| 19:32.14 | psokolovsky | xuumbi: try to build exactly that recipe as initial measure, not the whole image |
| 19:34.00 | xuumbi | psokolovsky: ah, ok, when bitbak'ing the package itself the new version does get picked up |
| 19:34.28 | polyonymous | psokolovsky, http://rafb.net/p/P99pJD32.html - what about this then? :) |
| 19:35.03 | xuumbi | psokolovsky: I was looking for an easy way of checking to see if a package had a newer version, then automatically rebuilding it when generating a new image, I guess I'll have to write a script for that... |
| 19:35.10 | psokolovsky | polyonymous: that's kinda cool, real unix way ;-) |
| 19:35.18 | polyonymous | psokolovsky, worksforme :) |
| 19:35.32 | polyonymous | Maybe it should be limited to some finite amount of iterations |
| 19:35.55 | polyonymous | like for attempt in 0 1 2 3 4 5 6 7 8 9 a b c d e f ; |
| 19:36.17 | psokolovsky | xuumbi: well, it should work with image too, of course, it's just recipes for images should be done right. use existing gpe-image, opie-image as templates |
| 19:36.38 | psokolovsky | polyonymous: works as in tested? |
| 19:36.51 | polyonymous | psokolovsky, this is a copy'paste from ssh to Z :) |
| 19:37.11 | psokolovsky | nice! please submit patch ;-) |
| 19:37.21 | polyonymous | yup. Will attach it to the sound bug. |
| 19:40.56 | goxboxlive | Why isent libgcc.so installed in the imegaes anymore? I have to add it manually. |
| 19:41.58 | polyonymous | goxboxlive, have you had rpath failure on gcc-cross? |
| 19:42.20 | goxboxlive | no |
| 19:42.39 | goxboxlive | should i? How do i do that? |
| 19:42.50 | polyonymous | goxboxlive, ah, are you talking about binary images? |
| 19:42.58 | polyonymous | or do you bitbake yourself? |
| 19:43.11 | goxboxlive | Yes |
| 19:43.29 | polyonymous | if 'yes' was about binaries, then I have no idea :) |
| 19:43.32 | goxboxlive | I am talking about ansgtrom-images |
| 19:44.00 | goxboxlive | it isent installed in console-image or openmoko-image. Haventtried opie yet . |
| 19:44.09 | goxboxlive | I have started with a fresh image today |
| 19:44.31 | polyonymous | dunno about images. I know what could make me end up without half of gcc in my own build. But I doubt it's in "official" binaries. |
| 19:44.46 | goxboxlive | ok |
| 19:45.02 | polyonymous | hmm... haven't tried opie? But there's no opie image available? |
| 19:47.24 | goxboxlive | yes there is |
| 19:47.40 | goxboxlive | bitbake opie-image (voila) |
| 19:47.56 | polyonymous | ah, so you DO bake it yourself, not talking about binary images for download. |
| 19:48.19 | polyonymous | goxboxlive, well, are you absolutely sure you didn't have failure on gcc-cross which you had to restart? |
| 19:48.35 | goxboxlive | hmm that might be yes |
| 19:48.44 | polyonymous | goxboxlive, then, that's it. |
| 19:48.44 | goxboxlive | should i rebuild it? |
| 19:48.53 | polyonymous | it will fail again :) |
| 19:49.07 | goxboxlive | so, wath to do then? |
| 19:49.16 | polyonymous | goxboxlive, I had to comment one 'return False' in insane.bbclass to make it non-fatal. |
| 19:49.41 | goxboxlive | ok |
| 19:49.43 | goxboxlive | thx |
| 19:52.15 | *** join/#oe donato_home (n=donato@201.80.134.122) |
| 19:57.19 | polyonymous | psokolovsky, I attached the patch, but forgot to checke the 'patch' box. Hope, you won't have me resubmit :) |
| 19:57.47 | psokolovsky | polyonymous: you can edit attachment properties after submit ;-) |
| 19:57.52 | polyonymous | nevermind, it's changable |
| 19:57.56 | polyonymous | yeah, I know. |
| 19:58.09 | polyonymous | I believe at some point it wasn't possible, though :) |
| 19:58.25 | polyonymous | Okay, it's in 2211 now. |
| 19:59.49 | *** join/#oe Crofton (n=balister@hc65216ca.dhcp.vt.edu) |
| 20:00.32 | psokolovsky | thanks! |
| 20:00.41 | polyonymous | you're welcome :) |
| 20:01.18 | polyonymous | I'm afraid 16 seconds aren't enough, though... |
| 20:02.10 | likewise | goxboxlive, polyonymous: if insane failed, make sure you rebuild the package from start (first -c clean, then build) |
| 20:02.12 | polyonymous | psokolovsky, or there's another problem... maybe the socket is left after reboot - don't commit yet. |
| 20:02.29 | polyonymous | likewise, it won't help, it will fail again :) |
| 20:02.48 | polyonymous | likewise, unless you torture insane itself, that is. |
| 20:02.48 | likewise | Yes, but not with the return commented out. |
| 20:02.56 | polyonymous | yeah. |
| 20:03.14 | polyonymous | and yes, in this case you'd better -c rebuild it. |
| 20:03.23 | likewise | Ah ok, it will fail again now every time? good. |
| 20:03.38 | polyonymous | likewise, no, no, only after clean. |
| 20:03.48 | polyonymous | Wish it would fail consistently. |
| 20:04.06 | likewise | Me too, the current approach is not deterministic. |
| 20:04.18 | polyonymous | quite deterministic, but I don't like the determination :) |
| 20:04.23 | *** join/#oe marciom (n=marcio@200.184.118.132) |
| 20:05.00 | likewise | if it now fails on a package, and you issue the same bitbake again, will it fail again? |
| 20:05.38 | polyonymous | likewise, no. That's the determination I don't like. |
| 20:06.18 | polyonymous | I would expect something less predictable from nondeterministic approach that is. |
| 20:06.36 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 20:07.35 | likewise | polyonymous: yes, that's the issue I'ld like to fix first. Either never fail (warn only), or fail every time. |
| 20:07.52 | polyonymous | likewise, I don't think we're in any disagreement here :) |
| 20:08.07 | likewise | polyonymous: which one would you prefer? |
| 20:08.19 | *** join/#oe Crofton (n=balister@hc65216ca.dhcp.vt.edu) |
| 20:08.28 | polyonymous | likewise, I'd prefer gcc-cross fixed :) |
| 20:08.53 | polyonymous | likewise, if I knew how to do it I'd prefer fail consistently. Since I don't - I prefer warn-only :) |
| 20:08.59 | likewise | gcc-cross is of our least concent, it does not arrive on the target. |
| 20:10.07 | polyonymous | likewise, partially, it does. And failure to build it prevents the whole thing, anyway. |
| 20:10.56 | likewise | koen: I desperately need a working config for a buildable ARM EABI BE image :-/ Now perl won't build for me. I wonder if I have some host-deps or something. |
| 20:11.11 | likewise | polyonymous: Replace if bad_dir_test in line: by if bad_dir in line: will at least pass gcc-cross for the moment. |
| 20:12.07 | polyonymous | likewise, well, I'm content with warn behaviour I have now, so I'd rather not mess with it and move on to something more productive :) |
| 20:12.12 | likewise | koen: could you please show me the config that built the uploaded EABI BE image for you? |
| 20:12.21 | likewise | polyonymous: ok |
| 20:14.09 | *** join/#oe florian (n=fuchs@84.245.184.207) |
| 20:14.50 | koen | likewise: remove 'gdb' for debug apps, bitbake angstrom-console-image |
| 20:14.54 | koen | s/for/from/ |
| 20:15.13 | koen | likewise: and I removed all !5.8.8 perl versions |
| 20:15.59 | koen | (mkdir packages/obsolete/perl ; mtn add packages/obsolete/perl ; mtn mv -e *5.8.4* *5.8.7* ../obsolete/perl) |
| 20:19.19 | *** join/#oe pierrelux (n=pierre-l@144-125.sh.cgocable.ca) |
| 20:23.11 | likewise | koen: ah, that explains a bit. But shouldn't we just be simply able to remove the dependency on perl? Or is that the task-* split-up in several *.bb you mentioned? |
| 20:23.15 | likewise | whoops, too late |
| 20:30.25 | *** join/#oe W8TVI (n=me@166.166.11.175) |
| 20:52.03 | *** join/#oe pierrelux (n=pierre-l@144-125.sh.cgocable.ca) |
| 21:09.10 | *** join/#oe NAiL_ (n=repvik@sql.kynisk.com) |
| 21:13.30 | Laibsch | polyonymous: I think you can consider yourself approved. I recollect thumbs up from psokolovsky, hentges, koen and me (maybe more). No objections. You need to create your keys and send them to both mickey and koen. |
| 21:13.53 | Laibsch | If you are indeed not approved, they will let you know ;-) |
| 21:15.27 | polyonymous | Laibsch, okay, will do. <name>@openembedded.org from the phrasebook doesn't really imply @openembedded.org? |
| 21:15.37 | Crofton | yes it does :) |
| 21:16.14 | polyonymous | Crofton, but I don't have @oe.org address |
| 21:16.20 | Crofton | We know |
| 21:16.51 | polyonymous | Umm... would you elaborate a bit on it so that it makes sense to me? :) |
| 21:16.54 | Crofton | I am not sure why it is that way, but I am pretty sure that is how it is |
| 21:17.22 | polyonymous | Hmm.. |
| 21:17.28 | polyonymous | It's not that I object it, but I don't quite understand it either. |
| 21:17.48 | Crofton | me niether |
| 21:18.15 | polyonymous | that makes me feel better, of course :) |
| 21:18.30 | Crofton | I am crofton@openembedded.org keywise |
| 21:19.00 | polyonymous | But you have no corresponding email address? |
| 21:19.04 | Laibsch | yes, this is just the key |
| 21:19.13 | Laibsch | There sometimes no adresses behind it |
| 21:19.19 | Laibsch | Me, for example |
| 21:19.33 | polyonymous | Yeah, I understand. I thought the purpose of using email is to ensure no collisions. |
| 21:19.46 | Laibsch | I think that is suboptimal since of course everybody assumes this is a mail address and might try to contact the committer there. |
| 21:20.01 | Laibsch | Especially is this has worked with others in the past |
| 21:20.03 | polyonymous | that too. |
| 21:20.21 | Laibsch | But no, this is not always an email address |
| 21:20.22 | likewise | Laibsch: same here... maybe email forwarding is possible? |
| 21:20.37 | Laibsch | I don't know |
| 21:20.40 | Crofton | I am sure there is a cunning plan |
| 21:20.44 | Crofton | :) |
| 21:20.46 | Laibsch | and I don't really care *too* much |
| 21:20.57 | Laibsch | the plan is world domination |
| 21:21.01 | Crofton | right |
| 21:21.06 | polyonymous | I think it just ruins uniqueness constraint. |
| 21:21.09 | *** join/#oe marcan_ (n=marcanso@160.10.7.121) |
| 21:21.16 | polyonymous | working email is of no real concern here. |
| 21:21.33 | Crofton | contact info is in maintainers |
| 21:21.38 | Laibsch | mtn list keys will list one non-oe.org address |
| 21:21.40 | polyonymous | but I think if I go for polyonymous I won't collide with anyone :) |
| 21:22.00 | polyonymous | nslu2-linux.org that is |
| 21:22.10 | Laibsch | I think there is another one |
| 21:22.12 | polyonymous | no, way more |
| 21:22.28 | polyonymous | 8 keys |
| 21:22.47 | polyonymous | mtn list keys|grep -v openembedded.org :) |
| 21:23.02 | polyonymous | http://rafb.net/p/9Et0Kr79.html |
| 21:26.46 | polyonymous | Well, if it's a custom here, I don't mind it. Just wanted to make sure, because it didn't make enough sense to me at the first glance. |
| 21:28.13 | rwhitby | morning |
| 21:28.20 | polyonymous | good one, I hope. |
| 21:28.35 | Laibsch | Can we add somebody to the MAINTAINERS file who has no RW access to .dev but who is actively reporting and fixing bugs? |
| 21:29.05 | polyonymous | being in maintainers implies some responsibility, doesn't it? |
| 21:29.23 | Laibsch | It is not 100% clear what it implies |
| 21:29.45 | Laibsch | The only thing certain to me is that you volunteered to take care of XY |
| 21:29.46 | polyonymous | that's true :) |
| 21:29.55 | likewise | polyonymous: yes, you at least fix what you break :-) |
| 21:30.05 | Laibsch | There is also no screening really where you would have to pass some kind of test |
| 21:30.07 | polyonymous | likewise, and vice versa :)) |
| 21:30.15 | likewise | sssssh... |
| 21:30.37 | polyonymous | Laibsch, there is a stress-test of actually doing some work. |
| 21:30.43 | likewise | Laibsch: then why did I have to buy two rounds of beer? :-) |
| 21:30.43 | Laibsch | likewise: Well, that would lead to the question of somebody "external" as MAINTAINER |
| 21:30.59 | Laibsch | likewise: Where? |
| 21:31.04 | Laibsch | I did not get any! |
| 21:31.05 | likewise | just kidding |
| 21:31.22 | Laibsch | likewise: Whatever it is you were proposing: DENIED |
| 21:31.24 | Laibsch | ;-) |
| 21:31.51 | likewise | Actually, we (undetermined group of OE ppl) did have a few beers in FOSDEM. |
| 21:33.12 | polyonymous | I don't like beer. |
| 21:35.28 | polyonymous | psokolovsky, I submitted the right patch. |
| 21:35.34 | polyonymous | Now I can generate some keys :) |
| 21:37.44 | polyonymous | I don't need to do anything with OE.mtn, do I? Just wonder why right before generating keys it states how to mtn db init OE.mtn... |
| 21:38.24 | zecke | polyonymous: keys are saved in .monotone/ |
| 21:39.00 | polyonymous | zecke, that's good. I was just thinking how do I preserve my private key if it goes to db :) |
| 21:39.12 | zecke | polyonymous: it used to be in the db :) |
| 21:39.21 | zecke | polyonymous: I think mtn 0.23 changed that |
| 21:39.26 | polyonymous | Oh ... Exportable at least? :) |
| 21:39.33 | polyonymous | Or just keep a backup of the whole thing? :) |
| 21:39.41 | zecke | polyonymous: exportable :) |
| 21:40.06 | polyonymous | that's better :) Well, not that it matters now that it goes to ~/.monotone. |
| 21:40.18 | polyonymous | umm... it's ~/.monotone, not .monotone, I suppose? |
| 21:40.32 | zecke | probably |
| 21:41.03 | polyonymous | hmm.. why specify database for genkey ? |
| 21:41.46 | zecke | dunno |
| 21:41.54 | polyonymous | ok. just wondering |
| 21:42.40 | polyonymous | zecke, I think it's outdated info. |
| 21:42.59 | zecke | probably |
| 21:43.13 | polyonymous | just looking at monotone's doc. |
| 21:43.27 | polyonymous | I'm sorry for asking questions, just like knowing things I'm doing :) |
| 21:46.49 | polyonymous | and email addresses in the phrasebook are correct, I take it? |
| 21:56.11 | CIA-4 | 03pfalcon 07org.oe.dev * rc3da8ddf... 10/ (3 files in 3 dirs): opie-todo cvs: Fix unbreak-logging.patch |
| 21:56.15 | CIA-4 | 03polyonymous 07org.oe.dev * r63574aab... 10/ (6 files in 3 dirs): |
| 21:56.15 | CIA-4 | qte 2.3.10: Fix lack of PAGE_* in latest linux-headers properly: use getpagesize() |
| 21:56.15 | CIA-4 | * Closes #2201. |
| 22:01.04 | *** part/#oe xjqian (n=gordon@71-85-151-212.dhcp.stls.mo.charter.com) |
| 22:08.39 | *** join/#oe vervain_ (n=vervain@74-139-209-151.dhcp.insightbb.com) |
| 22:16.37 | polyonymous | sent it. |
| 22:23.37 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 22:37.16 | *** part/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl) |
| 22:37.42 | *** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 22:47.22 | Laibsch | !oebug 717 |
| 22:47.23 | cdbot2 | * * Bug 717, Status: NEW, Created: 2006-02-23 01:16 |
| 22:47.24 | cdbot2 | * * Robert.Demski(AT)wp.pl: Include amule package bb files |
| 22:47.27 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=717 |
| 22:47.43 | Laibsch | koen, we need to add SlugOS to VERSION field |
| 22:48.01 | *** join/#oe xjqian (n=gordon@71-85-151-212.dhcp.stls.mo.charter.com) |
| 22:48.32 | Laibsch | Crazy, 72 bugs fixed in the last week. |
| 22:48.41 | Laibsch | Well done! |
| 22:57.58 | *** part/#oe ozstinger (n=ozstinge@216.143.234.167) |
| 23:06.56 | polyonymous | Laibsch, how're your qemu experiments? |
| 23:29.44 | *** join/#oe CIA-30 (n=CIA@208.69.182.149) |
| 23:33.39 | *** join/#oe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 23:33.43 | xjqian | polyonymous: how to make sure an old version of, e.g. glibc_intermediate, gets cleaned in tmp/staging |
| 23:34.22 | polyonymous | xjqian, why me? :) I don't know. I think staging doesn't keep track of files staged. |
| 23:34.34 | Laibsch | polyonymous: you mean the qem-native stuff? |
| 23:34.37 | polyonymous | so, maybe rm -rf tmp/ is the way to go :) |
| 23:34.40 | polyonymous | Laibsch, yes. |
| 23:34.47 | polyonymous | Laibsch, I know it compiled, but did glibc build? |
| 23:35.14 | Laibsch | polyonymous: I did not try. |
| 23:35.25 | polyonymous | Laibsch, ah ok. I did and it failed (with that patch). |
| 23:35.25 | Laibsch | I don't have the CPU cycles to spare at the moment |
| 23:35.36 | Laibsch | polyonymous: OK, good to know |
| 23:35.39 | polyonymous | qemu segfaulted on glibc. |
| 23:35.49 | Laibsch | Please make a comment to that effect in the bug report |
| 23:35.51 | xjqian | polyonymous: you seems awake:) |
| 23:35.51 | polyonymous | It would be better if it didn't fail, though :) |
| 23:36.05 | Laibsch | (S) |
| 23:36.07 | Laibsch | Later |
| 23:36.17 | JustinP | xjqian: just address the channel for general questions |
| 23:36.18 | polyonymous | xjqian, awake and knowledgeable are different things :) |
| 23:36.33 | polyonymous | Okay, Laibsch, I'll comment. |
| 23:36.43 | JustinP | xjqian: packaged-staging *might* do it but I don't know. I've never gotten the damn thing to work. |
| 23:42.43 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 23:48.55 | xjqian | JustinP: ok. thanks. My question is I'm not sure what's the best practice if a lib in the tool chain gets updated. How to make sure the old version is cleaned and not used anymore? |
| 23:51.08 | JustinP | xjqian: the right way would be for packaged-staging to work correctly and "upgrade" the packages in the stage environment |
| 23:51.13 | JustinP | xjqian: packaged-staging uses package management to install files to the staging folder(s) |
| 23:51.35 | JustinP | xjqian: like I said, though, it has never worked correctly for me. The author, koen, also doesn't seem interested in debugging the problem... |
| 23:53.58 | xjqian | JustinP: so the current practice for the devs are: cleaning up tmp, starting from a clean slate everytime anything important, e.g. glibc, gets an update? and for not so critical stuff, find a way (e.g. manually) to get by? Is my understanding correct? |
| 23:54.10 | Crofton | yep |
| 23:54.52 | xjqian | Crofton: thanks. I am all clear now8-) |
| 23:55.25 | Crofton | basically, when you have time rm -rf tmp |
| 23:55.29 | Crofton | and rebuild |
| 23:55.36 | JustinP | we would love someone else to work on packaged-staging...after koen's SoC project he seems to have abandoned it |
| 23:55.48 | Crofton | hopefully he has time this summer |
| 23:55.57 | JustinP | as far as I'm concerned it has never worked |
| 23:57.02 | *** join/#oe Gerrath (n=Gerrath_@unaffiliated/gerrath) |
| 23:59.55 | polyonymous | rm -rf is a good thing - you can test if the fresh build works :) |