| 00:00.33 | *** join/#oe HopsNBarley (n=hops@adsl-71-141-85-250.dsl.snfc21.sbcglobal.net) |
| 00:06.09 | *** join/#oe DaKa_ (n=David@irc.thn.edu.stockholm.se) |
| 00:06.21 | *** join/#oe summatusmentis (n=summatus@72.168.202.219) |
| 00:15.13 | *** join/#oe emte_ (n=emte@d64-180-45-14.bchsia.telus.net) |
| 00:37.43 | *** part/#oe mreimer_ (n=mreimer_@luthien.vpop.net) |
| 00:48.08 | summatusmentis | does anyone have issues with beryl going insane on the CPU while running bitbake? |
| 00:54.28 | v8jlene | summatusmentis: no (of course I don't run beryl so my answer is not very useful ;) |
| 00:54.44 | *** join/#oe mwester-laptop (n=mwester@nslu2-linux/mwester) |
| 00:55.14 | summatusmentis | v8jlene: yeah, that's helpful :-P for some reason when I was running bitbake nano, beryl jumped to 86% CPU usage |
| 00:56.18 | v8jlene | That doesn't really make sense... does it always happen or just now and then? |
| 00:57.51 | summatusmentis | I don't know.. it's done it a couple of times now... I'm working on setting up OE |
| 01:06.03 | *** join/#oe jkilb_ (n=jkilb@p5B20A9A1.dip0.t-ipconnect.de) |
| 01:09.12 | *** join/#oe tsdogs (n=twostupi@62.123.180.130) |
| 01:13.09 | *** join/#oe Laibsc1 (n=Laibsch@c-134-232-227.f.dsl.de.ignite.net) |
| 01:15.28 | *** join/#oe tsdogs (n=twostupi@62.123.180.130) |
| 01:38.53 | *** join/#oe benlau (n=benlau@221.125.13.148) |
| 01:56.19 | CIA-4 | 03lenehan 07org.oe.documentation * rfdc83f33... 10/ (1 usermanual/chapters/usage.xml): usermanual: Add some details in the usage section on how to bring up a devshell. |
| 01:59.00 | *** join/#oe wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 02:02.54 | *** join/#oe meister_ (n=meister@82.244.212.29) |
| 02:25.39 | *** join/#oe eno (n=eno@nslu2-linux/eno) |
| 03:10.33 | *** join/#oe xjqia1 (n=gordon@71-85-151-212.dhcp.stls.mo.charter.com) |
| 03:15.35 | *** join/#oe donato_home (n=donato@c9500ec3.bhz.virtua.com.br) |
| 04:52.27 | *** join/#oe HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 05:55.17 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.22.241) |
| 06:01.33 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 06:01.55 | Ifaistos | morning all |
| 06:11.02 | *** join/#oe pgfeller (n=pgfeller@147.88.200.176) |
| 06:23.55 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.27.59) |
| 06:50.19 | *** join/#oe mykilx (n=mykilx@pool-71-98-160-70.tampfl.dsl-w.verizon.net) |
| 06:53.37 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 07:05.06 | *** join/#oe jacques (n=jacques@nslu2-linux/jacques) |
| 07:07.20 | *** join/#oe Marex (n=Marex@85.132.236.161) |
| 07:09.28 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 07:10.13 | koen | goooooooood morning all |
| 07:14.00 | ljp | perl 5.8.7 build is broken.. at least for me |
| 07:14.57 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 07:25.05 | Laibsch | good morning! |
| 07:27.15 | koen | Laibsch: the squashfs images has to create indices and stuff for all the files |
| 07:27.31 | koen | and zillion small files need a lot of space in the index |
| 07:27.58 | koen | I am a bit surprised that it takes ~1GB more than the 7z version |
| 07:28.14 | koen | but a 2g card is like 15 euro nowadays |
| 07:29.12 | Laibsch | 2G would be fine. But I want two wikipedia. So that is a 4G card |
| 07:29.36 | Laibsch | While still being affordable the increase in size stunned me |
| 07:30.20 | koen | OTOH such an index makes finding files really fast |
| 07:41.14 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 07:43.47 | Laibsch | I certainly agree |
| 07:44.05 | Laibsch | The speed is very much necessary on slow embedded devices |
| 07:44.21 | Laibsch | And the money for a bigger card is probably well spent |
| 07:44.35 | Laibsch | Nonetheless, the increase in size is stunning. |
| 07:45.26 | Laibsch | BTW, koen, did you try and gzip or bzip2 the squashfs? If it compressed a lot more then I assume that there was room for improvement in the algorithm. |
| 07:46.04 | koen | bzipping the squashfs defeats the points of it being a filesystem |
| 07:46.16 | Laibsch | koen: I know |
| 07:46.34 | Laibsch | I do not intend to use it |
| 07:46.42 | Laibsch | But I would like to see the numbers |
| 08:01.58 | *** join/#oe mrdata (i=mrdata@dslb-088-074-150-030.pools.arcor-ip.net) |
| 08:15.48 | *** join/#oe jott_ (n=j@unaffiliated/jott) |
| 08:19.50 | koen | http://www.angstrom-distribution.org/unstable/images/collie/20070505/ |
| 08:22.10 | *** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz) |
| 08:25.28 | Laibsch | Boys and girls, bug fixing weekend. We already have a mark of 75 fixed bugs for the last week. So let's push that to at least triple digit, OK? |
| 08:25.37 | Laibsch | koen: Nice, thank you |
| 08:28.21 | Laibsch | koen: There is an entry ZaurusKernels in the component field of the BTS search function. But it is not possible to set the component to that value. |
| 08:28.59 | Laibsch | Sorry, Product field |
| 08:29.55 | *** join/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl) |
| 08:30.12 | likewise | good morning |
| 08:33.01 | koen | hey likewise |
| 08:33.18 | koen | likewise: http://lists.freedesktop.org/archives/cairo/2007-May/010542.html |
| 08:36.17 | likewise | hmm, I should look at the code where they do caching and compare this with the patches for <=1.4.2. |
| 08:42.11 | *** join/#oe TheCan (n=thecan@dslb-084-056-169-076.pools.arcor-ip.net) |
| 09:02.08 | *** join/#oe pvanhoof (n=pvanhoof@d54C0EE14.access.telenet.be) |
| 09:09.42 | *** join/#oe pH5 (n=ph5@p5485EFFB.dip.t-dialin.net) |
| 09:10.58 | Ifaistos | Laibsch : Or at least try not to introduce any new ones ;) |
| 09:20.59 | CIA-4 | 03koen 07org.oe.dev * re757d66b... 10/ (7 files in 3 dirs): |
| 09:20.59 | CIA-4 | linux-ezx 2.6.21: Sync with openezx svn |
| 09:20.59 | CIA-4 | NOTE: the defconfig needs some tweaking |
| 09:21.46 | *** join/#oe jacques_ (n=jacques@nslu2-linux/jacques) |
| 09:22.03 | *** join/#oe polyonymous (n=hacker@pD95398FE.dip0.t-ipconnect.de) |
| 09:34.12 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 09:51.17 | *** join/#oe greentux (n=lemke@tmo-063-185.customers.d1-online.com) |
| 10:00.04 | Laibsch | Can anybody think of a way to complete all steps until do_patch but not the following for package X and the packages it depends on? |
| 10:00.12 | Laibsch | zecke: Can bittest do this? |
| 10:03.44 | koen | try adding a patch_all tasks a la fetch_all |
| 10:04.11 | koen | (and yes, bittest can do that) |
| 10:04.30 | Laibsch | koen: But that will fetch ALL packages, won't it? |
| 10:04.39 | koen | no |
| 10:04.41 | Laibsch | I just want package X and dependencies |
| 10:04.44 | Laibsch | Nice |
| 10:05.06 | koen | bitbake <foo> -c fetchall fetches <foo> + deps |
| 10:05.18 | koen | marcin wrote it for his source mirror |
| 10:07.16 | Laibsch | nice |
| 10:08.18 | Laibsch | where is it defined? |
| 10:15.15 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 10:15.15 | *** join/#oe TheCan (n=thecan@dslb-084-056-169-076.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 10:15.16 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) [NETSPLIT VICTIM] |
| 10:15.16 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 10:15.16 | *** join/#oe DaKa (n=David@nslu2-linux/daka) |
| 10:15.17 | *** join/#oe vervain (n=vervain@74-139-209-151.dhcp.insightbb.com) [NETSPLIT VICTIM] |
| 10:15.18 | *** join/#oe crigo (n=crigo@82.211.45.221) [NETSPLIT VICTIM] |
| 10:15.18 | *** join/#oe hrw|gone (n=hrw@130.89.145.130) [NETSPLIT VICTIM] |
| 10:35.58 | *** part/#oe jkilb_ (n=jkilb@p5B20A9A1.dip0.t-ipconnect.de) |
| 10:38.20 | Laibsch | koen: No further compression with gzip. Trying bzip2 now. |
| 10:43.03 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 10:43.03 | *** join/#oe TheCan (n=thecan@dslb-084-056-169-076.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 10:43.04 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 10:43.04 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 10:43.04 | *** join/#oe DaKa (n=David@nslu2-linux/daka) |
| 10:43.04 | *** join/#oe vervain (n=vervain@74-139-209-151.dhcp.insightbb.com) [NETSPLIT VICTIM] |
| 10:43.04 | *** join/#oe crigo (n=crigo@82.211.45.221) [NETSPLIT VICTIM] |
| 10:43.04 | *** join/#oe hrw|gone (n=hrw@130.89.145.130) |
| 10:56.00 | *** join/#oe psokolovsky (n=psokolov@82.193.98.2) |
| 11:00.50 | *** join/#oe zecke (n=ich@91.64.161.147) |
| 11:00.50 | *** join/#oe TheCan (n=thecan@dslb-084-056-169-076.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 11:00.50 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 11:00.50 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 11:00.50 | *** join/#oe DaKa (n=David@nslu2-linux/daka) |
| 11:00.51 | *** join/#oe vervain (n=vervain@74-139-209-151.dhcp.insightbb.com) [NETSPLIT VICTIM] |
| 11:00.51 | *** join/#oe crigo (n=crigo@82.211.45.221) [NETSPLIT VICTIM] |
| 11:00.51 | *** join/#oe hrw|gone (n=hrw@130.89.145.130) |
| 11:05.44 | *** join/#oe pgfeller (n=pgfeller@147.88.200.176) |
| 11:20.32 | *** join/#oe zecke|away (n=ich@91.64.161.147) |
| 11:20.32 | *** join/#oe TheCan (n=thecan@dslb-084-056-169-076.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 11:20.32 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 11:20.33 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 11:20.33 | *** join/#oe DaKa (n=David@nslu2-linux/daka) |
| 11:20.33 | *** join/#oe vervain (n=vervain@74-139-209-151.dhcp.insightbb.com) [NETSPLIT VICTIM] |
| 11:20.33 | *** join/#oe crigo (n=crigo@82.211.45.221) [NETSPLIT VICTIM] |
| 11:20.33 | *** join/#oe hrw|gone (n=hrw@130.89.145.130) |
| 11:29.16 | *** join/#oe timtimred (n=On3@62-31-181-7.cable.ubr02.chel.blueyonder.co.uk) |
| 11:31.26 | Laibsch | Is do_mrproper working and does it do what I think it does? |
| 11:31.42 | Laibsch | IOW, does it fix |
| 11:31.47 | Laibsch | !oebug 1864 |
| 11:31.48 | cdbot2 | * * Bug 1864, Status: NEW, Created: 2007-02-11 12:07 |
| 11:31.49 | cdbot2 | * * werner(AT)almesberger.net: bitbake -c forget |
| 11:31.50 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=1864 |
| 11:35.03 | polyonymous | morning, there are rumours, is good. |
| 11:36.23 | Laibsch | polyonymous: Are talking to me? |
| 11:37.51 | polyonymous | Laibsch, to everyone who shares the morning :) |
| 11:37.52 | zecke|studying | Laibsch: no, it removes everything from the DL_DIR |
| 11:38.55 | Laibsch | polyonymous: Well, I don't understand your allusion to rumours |
| 11:39.17 | polyonymous | Laibsch, I'm just not being serious. That was a way to say "hi". |
| 11:39.33 | Laibsch | hi |
| 11:40.13 | polyonymous | :))) |
| 11:49.20 | likewise | rumours, therefor are, good. morning |
| 11:52.49 | goxboxlive | Has anyone of you problems to build obexftp lately? |
| 11:53.51 | Laibsch | zecke|studying: Sorry to keep you from studying. Can we close |
| 11:53.54 | Laibsch | !oebug 829? |
| 11:53.55 | cdbot2 | * * Bug 829?, Status: InvalidBugId |
| 11:54.08 | Laibsch | !oebug 829 |
| 11:54.09 | cdbot2 | * * Bug 829, Status: NEW, Created: 2006-04-10 10:42 |
| 11:54.10 | cdbot2 | * * freyther(AT)inf.fu-berlin.de: Meta-Bug: Bitbake "It could suck more" 1.x.y |
| 11:54.11 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=829 |
| 11:54.19 | goxboxlive | pastebin.co.uk/14055 (i have checked bugz) Opie wouldnt build |
| 11:55.57 | polyonymous | hmm |
| 11:56.17 | zecke|studying | Laibsch: if you want to, sure |
| 11:56.41 | polyonymous | goxboxlive, built fine for me... |
| 11:57.06 | goxboxlive | <polyonymous> hmm, strange, i am using a new work directory. |
| 11:57.27 | polyonymous | you mean, you just started afresh? |
| 11:57.38 | polyonymous | Because I've built from scratch recently. |
| 11:57.40 | goxboxlive | yes |
| 11:57.55 | goxboxlive | whole form scratch |
| 11:58.03 | polyonymous | Well, maybe if it was a mess before, then it may help. |
| 11:58.43 | polyonymous | I don't really understand why libiconv_* I thought the symbols are called iconv? But you never know until you have troubles :) |
| 11:58.53 | goxboxlive | right :-) |
| 11:59.11 | polyonymous | how recent that revision is, btw? |
| 11:59.48 | polyonymous | ah, I see. |
| 12:00.04 | polyonymous | That's the most recent I'm updating to now :) |
| 12:00.24 | goxboxlive | ok, i have just pulled so i am using the latest one |
| 12:00.48 | polyonymous | yup. I see. |
| 12:01.12 | polyonymous | Well, I can build opie-kdepim-image for spitz with the recent tree. |
| 12:01.48 | polyonymous | And for poodle too, but I haven't tried the latter. hvontres have, though. |
| 12:03.22 | goxboxlive | ok |
| 12:07.12 | polyonymous | hmm... git on the device should depend on findutils and cpio. |
| 12:10.02 | goxboxlive | <polyonymous> is it also failing for u now after you pulled? |
| 12:10.43 | polyonymous | goxboxlive, haven't tried, but according to updated files they do not affect my build. |
| 12:10.50 | polyonymous | goxboxlive, what is your failure now? |
| 12:11.05 | goxboxlive | It's the same, obexftp |
| 12:11.12 | polyonymous | goxboxlive, because my tree is dirty like the dirtiest slut, but all the patches are in bugzilla :) |
| 12:11.15 | polyonymous | ah... |
| 12:11.20 | polyonymous | No, this one I didn't have... |
| 12:11.24 | goxboxlive | ok |
| 12:11.47 | polyonymous | I can try to rebuild obexftp. I don't feel like doing the whole tree from scratch at the moment... |
| 12:13.37 | polyonymous | goxboxlive, built fine... |
| 12:14.00 | goxboxlive | hmm, then it has something to do with libiconv on my build machine |
| 12:14.08 | polyonymous | goxboxlive, have you included required opie versions in local.conf? |
| 12:14.26 | goxboxlive | yes the .3.inc version |
| 12:14.44 | polyonymous | require conf/distro/include/preferred-opie-versions-1.2.3-pre.inc |
| 12:14.52 | goxboxlive | right |
| 12:15.04 | polyonymous | ok, you just didn't mention -pre. |
| 12:15.19 | polyonymous | Well, maybe it's the host, check your configure log |
| 12:15.31 | goxboxlive | i followd the one psokolovsky made at angstrom wiki |
| 12:15.41 | polyonymous | goxboxlive, yes, that's the one he mentioned. |
| 12:18.48 | polyonymous | mtn status|wc -l : 45 ;-) |
| 12:19.06 | likewise | can I review the incoming diff between mtn pull and mtn update? |
| 12:19.32 | polyonymous | likewise, I think you can, by specifying -r ? |
| 12:20.06 | koen | likewise: mtn diff -r `something with mtn status` -r `something with mtn automate heads` |
| 12:21.28 | koen | polyonymous: if you are foolish enough to build libiconv (not the one internal to glibc), you get what you deserve |
| 12:21.41 | polyonymous | koen, that wasn't me! :) |
| 12:22.07 | koen | no, but I hate repeating myself, so I prefix a random username to get around that |
| 12:22.23 | polyonymous | koen, and for what I understand, he's done the fresh build. |
| 12:22.43 | pH5 | is there already a fix for the libstdc++ RPATH QA error in gcc-cross somewhere? |
| 12:22.58 | psokolovsky | koen: do you have idea about OE feed invariants? Like, would it be possible for OE to generate feed with 2 same packages? Or put same package twice in Depends: ? |
| 12:23.17 | polyonymous | koen, it looks like he has a glibc iconv, but somehow configure came up withe idea of using libiconv. Well, I haven't seen his logs. |
| 12:23.45 | koen | psokolovsky: iirc we fixed that double-depends bug |
| 12:23.54 | koen | psokolovsky: iirc it was likewise's patch |
| 12:24.40 | koen | likewise: I'm still in doubt whether or not to exclude staging/ from the rpath check |
| 12:24.43 | *** part/#oe pierrelux (n=pierre-l@144-125.sh.cgocable.ca) |
| 12:25.03 | psokolovsky | koen: so, would think it will be safe to assume no dups in OE feeds? would it be sane to write a tool with such assumption? Would you personally use it? ;-) |
| 12:25.30 | polyonymous | koen, I hate to nag, but I'm just wondering if my email went though to you or have I somehow managed to goof it up? :) |
| 12:25.32 | koen | psokolovsky: angstrom has all packages in the feeds inside a sqlite db :) |
| 12:25.56 | likewise | pH5: no, no proper fix yet. I can spend some time on this, don't expect anything though... |
| 12:26.11 | pH5 | likewise: ok, thanks. |
| 12:27.02 | psokolovsky | koen: ok, nice, thanks. I have ideas on alleviating ipkg's retardedness |
| 12:27.39 | polyonymous | s/though/through/ |
| 12:27.42 | *** join/#oe Kristoffer (n=Kristoff@80.251.207.37) |
| 12:28.48 | koen | pH5: the gcc one doesn't propagate into the build |
| 12:31.59 | *** join/#oe greentux (n=lemke@tmo-040-207.customers.d1-online.com) |
| 12:35.04 | pH5 | koen: I don't understand. So |
| 12:35.09 | pH5 | ERROR: QA Issue package libstdc++ contains bad RPATH /home/ph5/src/oe/build/angs |
| 12:35.10 | pH5 | trom/staging/i686-linux/lib in file /home/ph5/src/oe/build/angstrom/work/armv5te |
| 12:35.10 | pH5 | -angstrom-linux-gnueabi/gcc-cross-4.1.2-r3/install/libstdc++/usr/lib/libstdc++.so.6.0.8 |
| 12:35.24 | *** join/#oe woglinde (i=woglinde@e178095089.adsl.alicedsl.de) |
| 12:35.31 | koen | ah, heh |
| 12:35.35 | pH5 | is not a problem with the cros libstdc++, but with the fact that it is put into a package at all? |
| 12:35.39 | koen | that will propagate into the package :) |
| 12:36.10 | polyonymous | I think package may benefit from this library :) |
| 12:36.36 | woglinde | hi |
| 12:38.53 | likewise | pH5: we don't know if this is a problem (for this particular case), but we would expect no RPATH in there (I will check another cross-compiler to verify). This one is not bad in the sense that it gives overhead or security issues on the target. |
| 12:39.22 | likewise | pH5: (to be clear: this does not give verhead or security issues on the target) |
| 12:39.59 | koen | psokolovsky: a sanity checker for feed(s) consistency using that sqlite db would be nice |
| 12:42.16 | psokolovsky | koen: yep, I guess, and very likely. I just want to know what people think about exactly such idea - move expensive (awfully expensive as they're implemented now) checks from ipkg, executed on every run, to a separate validator. |
| 12:43.06 | polyonymous | what would be the side effect of this assumption failing in ipkg? |
| 12:43.38 | psokolovsky | polyonymous: I gave examples of assumptions ipkg checks above |
| 12:44.35 | polyonymous | psokolovsky, no, I mean what would happen if ipkg relies on this checks passed, but the feed isn't valid in reality? |
| 12:45.22 | psokolovsky | polyonymous: what would be effect of dup package appearing in feed? now, ipkg always uses just 1st occurance. wih removing unique'ing code, it will still mostly use 1st occurance, but for exampel will dump both instances on "list", which is even more correct |
| 12:46.00 | psokolovsky | polyonymous: make exercise of tracing what would happen w/o dup checks in Depends: and friends yourself ;-) |
| 12:46.01 | polyonymous | then I'd vote for moving the code out of ipkg. |
| 12:46.13 | psokolovsky | polyonymous: in other words, no segfaults expected ;-) |
| 12:46.27 | polyonymous | psokolovsky, yes, that's about what I was thinking of :) |
| 12:46.41 | psokolovsky | polyonymous: cool, thanks ;-) prepare for beta-testing then (w/o any hurry or ETAs ;-) ) |
| 12:46.58 | polyonymous | psokolovsky, "always prepared!" :) |
| 12:56.14 | *** join/#oe gremlin[it] (n=gremlin@217.201.158.254) |
| 13:02.52 | Laibsch | Can I inherit in an include file? |
| 13:06.08 | CoreDump|home | you should probably "require" it |
| 13:06.31 | CoreDump|home | inherit is usually done for .bbclass |
| 13:07.23 | polyonymous | I take it Laibsch asked if he can inherit _IN_ include. |
| 13:07.50 | CoreDump|home | oops, I misread, sorry |
| 13:07.51 | polyonymous | and my guess is yes, although I have no clue what the proper answer is :) |
| 13:08.58 | polyonymous | yup |
| 13:09.08 | polyonymous | grep inherit packages/*/*.inc |
| 13:15.53 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 13:20.47 | likewise | koen: the ptxdist toolchain does not have an RPATH in their cross gcc stdlibc++ |
| 13:21.08 | likewise | koen: so we have got a small bug *and* a known good cross gcc to peek from |
| 13:21.59 | *** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at) |
| 13:33.52 | *** join/#oe Marex_Yggdrasil (n=Marex@85.132.236.161) |
| 13:39.56 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.38.82) |
| 13:45.28 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 13:45.48 | koen | only a few packages need, so the time-cost shouldn't be too much |
| 13:47.22 | cworth | koen: The solid-pattern cache work has landed in cairo now. |
| 13:57.41 | koen | cworth: nice, thanks for the heads up |
| 13:58.34 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 14:02.37 | chouimat | morning |
| 14:03.06 | likewise | koen: ever seen this error? http://rafb.net/p/eMPq6y93.html |
| 14:03.13 | likewise | morning |
| 14:03.32 | koen | likewise: yes |
| 14:05.05 | likewise | koen: do you happen to know the cause? |
| 14:06.07 | likewise | koen: glib needs some locale support in printf I assume |
| 14:07.08 | *** join/#oe benlau (n=benlau@221.125.13.148) |
| 14:09.55 | likewise | koen: ok, --enabling-included-printf solves that. |
| 14:10.10 | *** join/#oe bigd0g (i=bigd0g_u@71-88-108-152.dhcp.oxfr.ma.charter.com) |
| 14:10.10 | koen | 'mtn pull' as well :) |
| 14:11.37 | CIA-4 | 03koen 07org.oe.dev * r01934ad0... 10/ (1 packages/glib-2.0/glib.inc): glib.inc: make printf disable opt-in |
| 14:19.22 | likewise | koen: with that commit I can check the incoming diff approach |
| 14:20.40 | koen | :) |
| 14:21.22 | polyonymous | koen, I hate to nag, but I'm just wondering if my email went though to you or have I somehow managed to goof it up? :) (tried that few hours ago, but you probably didn't notice) |
| 14:21.33 | koen | which mail? |
| 14:21.58 | koen | (so I guess 'no') |
| 14:22.51 | polyonymous | Hmm... koen the monotone key one? |
| 14:23.31 | koen | oh, that one |
| 14:23.37 | koen | I'm waiting for mickeyl |
| 14:23.40 | polyonymous | ah, ok. |
| 14:23.47 | polyonymous | Just wanted to know if I sent it alright. |
| 14:24.15 | polyonymous | never knew for sure if the address on monotonephrasebook is valid. |
| 14:24.32 | koen | if people didn't edit it, they are |
| 14:24.34 | likewise | this shows incoming diffs between a pull and an update: mtn diff -r `mtn automate get_base_revision_id` -r `mtn automate heads` |
| 14:24.47 | polyonymous | koen, Well, now that I know you've got mail, I think they are :) |
| 14:25.19 | koen | likewise: could you add that to the phrasebook? |
| 14:25.44 | polyonymous | likewise, how about getting a diff between pull and working tree? one -r less? |
| 14:26.24 | polyonymous | I mean from working tree to head that is. |
| 14:26.47 | likewise | koen: I think USE_NLS_glib-2.0="yes" ===> --enable-included-printf=yes would work in all cases. |
| 14:27.19 | likewise | polyonymous: I think that is what I meant. |
| 14:27.50 | polyonymous | likewise, but does it take your local modifications in account? |
| 14:28.02 | likewise | polyonymous: ah no. wait. |
| 14:36.27 | likewise | koen: yes will add that to the phrasebook |
| 14:38.52 | likewise | polyonymous: mtn diff -r `mtn automate heads` will show the workspace against the recent pull, but that's a strange thing to do, as incoming changes will be shown as reversed, while your own will not. |
| 14:39.34 | likewise | polyonymous: you're better off showing the incoming changes and outgoing changes seperately, I guess, as patched forward to their common ancestor. |
| 14:50.30 | *** join/#oe florian (n=fuchs@84.245.184.174) |
| 14:56.19 | CIA-4 | 03koen 07org.oe.dev * rad0a43b0... 10/ (4 files in 2 dirs): chrpath: add cross version |
| 14:56.34 | *** join/#oe zecke|studying (n=ich@91.64.161.147) |
| 14:56.38 | koen | hmm, making packaged-staging package-agnostic seems to be more work than expected |
| 14:56.41 | koen | hey zecke|studying |
| 15:02.14 | polyonymous | likewise, Well, I think in revers is already a good deal of useful info, no matter how odd the idea sounds. |
| 15:03.25 | koen | why doesn't clicking on an entry in thunderbird work? |
| 15:03.42 | polyonymous | koen, what entry? |
| 15:03.50 | koen | in autocomplete |
| 15:03.55 | polyonymous | ahh |
| 15:04.06 | koen | if I click on it it will close the popup and *not* select the entry |
| 15:04.20 | polyonymous | hmm... seems to work for me. |
| 15:04.40 | koen | on OSX I have to double click real fast |
| 15:05.22 | polyonymous | seems to work in 1.5.0.10 (on plain old linux) |
| 15:05.48 | koen | I suspect it's the old block-gui-on-everything bug |
| 15:06.32 | victor_rx1950 | somebody can build glibc-2.5-r5? |
| 15:07.36 | victor_rx1950 | on x86_64 |
| 15:07.36 | polyonymous | yes |
| 15:07.36 | koen | r5? |
| 15:07.36 | victor_rx1950 | yep |
| 15:07.36 | koen | it's at r6 now |
| 15:07.37 | *** join/#oe jott (n=j@unaffiliated/jott) |
| 15:07.45 | victor_rx1950 | hmm... |
| 15:07.45 | polyonymous | I have both r5 and r6 built, according to my tmp/work/arm*/ |
| 15:07.45 | victor_rx1950 | need update database |
| 15:07.45 | Crofton|home | hmm, gcc-cross built |
| 15:08.00 | polyonymous | Crofton, how about just gcc? :) |
| 15:08.06 | koen | libc6_2.5-r6_arm-oabi.ipk |
| 15:08.07 | koen | libc6_2.5-r6_armv5te.ipk |
| 15:08.07 | koen | libc6_2.5-r6_armv5teb.ipk |
| 15:08.16 | victor_rx1950 | Crofton|home: yes |
| 15:14.38 | koen | RP, hrw|gone: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-May/002090.html |
| 15:25.49 | *** join/#oe bigd0g (i=bigd0g_u@71-88-108-152.dhcp.oxfr.ma.charter.com) |
| 15:30.49 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 15:35.10 | *** join/#oe rd_ (n=rd@toi.yeu.phu.nu) |
| 15:35.34 | *** join/#oe amaldo (n=amaldo@pdpc/supporter/student/amaldo) |
| 15:39.31 | *** join/#oe rob_w (n=bob@p85.212.6.202.tisdip.tiscali.de) |
| 15:48.58 | *** join/#oe aoe (n=aoe@tigerente.htu.tuwien.ac.at) |
| 16:12.02 | likewise | koen: the rpath in cross gcc is due to gcc-4.1.x/ldflags.patch. I think that is correct and that this RPATH is OK. |
| 16:13.00 | zecke|studying | koen: you leaked information :) |
| 16:13.00 | Crofton|home | I have failed to build madplay :) |
| 16:13.31 | *** join/#oe florian (n=fuchs@dslb-084-060-099-065.pools.arcor-ip.net) |
| 16:13.40 | koen | zecke|studying: yes, I'm a moron |
| 16:14.02 | zecke|studying | koen: yes, but now you are forced to install QtE on yiur hx47xx ipaq :) |
| 16:14.17 | koen | I have qt3 installed for lyx :) |
| 16:14.28 | zecke|studying | koen: you should have this two pages long corporate disclaimer at the end of each mail |
| 16:17.28 | likewise | Crofton|home: why, rpath issues? :-) |
| 16:17.34 | Crofton|home | yeah |
| 16:17.56 | *** join/#oe jott_ (n=j@unaffiliated/jott) |
| 16:20.20 | koen | likewise: yes, the ldflags patch is correct (I found that out the hard way earlier) |
| 16:20.51 | koen | likewise, zecke|studying: so should we special case gcc-cross in insane.bbclass? |
| 16:21.49 | likewise | koen, zecke|studying: re-adding the /work suffix in the test will make it bypass any cross tooling again, which I think is good. |
| 16:22.20 | likewise | (although I now have to learn why other toolchains do not per se link to their own libs). |
| 16:22.36 | *** join/#oe mr_nice (n=mr_nice@p54A9ECA5.dip.t-dialin.net) |
| 16:22.52 | mr_nice | hi all |
| 16:23.16 | likewise | koen: |
| 16:23.17 | likewise | - if bad_dir_test in line: |
| 16:23.19 | likewise | + if bad_dir in line: |
| 16:23.42 | likewise | would be my proposed fix for now, until we figure out if cross tooling need to RPATH to it's own libs. |
| 16:25.11 | Crofton|home | ./configure --help has this option |
| 16:25.22 | Crofton|home | -disable-rpath do not hardcode runtime library paths |
| 16:25.27 | Crofton|home | for madplay |
| 16:25.50 | likewise | Crofton|home: interesting, normally "disable" is default. |
| 16:26.31 | CIA-4 | 03koen 07org.oe.dev * r896c4be5... 10/ (1 classes/insane.bbclass): |
| 16:26.31 | CIA-4 | insane.bbclass: on check for references to WORKDIR in RPATH, instead of WORKDIR and STAGING |
| 16:26.31 | CIA-4 | [18:23] likewise: would be my proposed fix for now, until we figure out if cross tooling need to RPATH to it's own libs. |
| 16:27.27 | Crofton|home | EXTRA_OECONF? |
| 16:27.27 | koen | likewise: I still support the idea of building in a faked cross-chroot :) |
| 16:28.51 | *** join/#oe frank7d (n=afs@p549F9125.dip0.t-ipconnect.de) |
| 16:29.30 | victor_rx1950 | need two harddisks more ^( |
| 16:31.40 | CIA-4 | 03koen 07org.oe.dev * rc7fc7834... 10/ (1 classes/insane.bbclass): insane.bbclass: repair last commit |
| 16:32.19 | Crofton|home | adding the --disable-rpath to EXTRA_OECONF did not solve the problem :( |
| 16:33.40 | Crofton|home | how do I search for RPATH in a binary? |
| 16:33.46 | koen | scanelf |
| 16:33.57 | polyonymous | Is it just me or is it not: Package gcc-cross-locale-ru (4.1.2-r3) is installed on root and has the following files: |
| 16:33.57 | polyonymous | /home/hacker/OE/angstrom/tmp/cross/share/locale/ru/LC_MESSAGES/gcc.mo |
| 16:35.24 | koen | -rw-r--r-- root/root 437802 2007-05-03 14:42 ./data/build/koen/OE/build/tmp/angstrom/cross/share/locale/ru/LC_MESSAGES/gcc.mo |
| 16:35.51 | polyonymous | koen, on device that is. |
| 16:36.10 | *** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz) |
| 16:36.11 | koen | that doesn't matter for the contents of the .ipk |
| 16:36.40 | *** join/#oe Kristoffer (n=Kristoff@80.251.207.55) |
| 16:36.51 | polyonymous | what do you mean? the file /home/hacker/OE/... is packaged in ipk. |
| 16:36.58 | polyonymous | And I'd think this is wrong. |
| 16:38.02 | polyonymous | -rw-r--r-- 1 hacker hacker 437802 May 3 12:10 tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r3/install/gcc-cross-locale-ru/home/hacker/OE/angstrom/tmp/cross/share/locale/ru/LC_MESSAGES/gcc.mo |
| 16:40.07 | koen | and over here /data/build gets packaged |
| 16:40.42 | polyonymous | I'm not sure I understand you. |
| 16:40.56 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 16:41.05 | likewise | Crofton|home: if a userspace binary has a bad RPATH, this can also be due to a library dependency. The library libtool could for example be bad as well. |
| 16:42.50 | likewise | Crofton|home: foobar/rootfs$ scanelf -B -R -r -F '%F has RPATH %r' * | grep -v 'has RPATH -' |
| 16:43.16 | likewise | Crofton|home: that's three spaces between 'RPATH' and '-' |
| 16:48.23 | *** join/#oe greentux (n=lemke@88.128.9.140) |
| 17:04.12 | *** join/#oe HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 17:05.11 | likewise | HopsNBarley: hello there |
| 17:07.02 | HopsNBarley | hi likewise - how's it going? |
| 17:21.26 | *** join/#oe chouimat2 (n=dieu@r2351064.cidc.net) |
| 17:34.08 | *** join/#oe rob_w (n=bob@p85.212.6.202.tisdip.tiscali.de) |
| 17:35.56 | *** join/#oe donato_home (n=donato@c9500ec3.bhz.virtua.com.br) |
| 17:37.48 | *** join/#oe dijenerate (n=dijenera@72.22.141.242) |
| 17:40.51 | *** join/#oe memeruiz (n=memeruiz@e181029164.adsl.alicedsl.de) |
| 17:57.40 | *** join/#oe pierrelux (n=pierre-l@fw.cglapocatiere.qc.ca) |
| 18:05.47 | Crofton|home | likewise, ping? |
| 18:06.01 | Crofton|home | madplay and gnu_tls both fail on RPATH |
| 18:06.14 | Crofton|home | both use libtool to do linking |
| 18:06.26 | Crofton|home | libtool --mode=link |
| 18:06.57 | Crofton|home | the link line contains a rpath-link, no rpath |
| 18:09.55 | *** join/#oe lrg_ (n=liam@lrg2.demon.co.uk) |
| 18:22.15 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 18:25.44 | Crofton | Who is the libtool guru? |
| 18:26.59 | Crofton|home | koen, ping |
| 18:27.23 | koen | Crofton|home: pong |
| 18:27.39 | Crofton|home | Who would be the libtool guru? |
| 18:28.06 | koen | I have no idea |
| 18:28.35 | Crofton|home | I knew you would asy that .. |
| 18:28.43 | Crofton|home | we have libtool 1.5.10 |
| 18:28.55 | Crofton|home | the libtool website has 1.5.22 |
| 18:31.39 | *** join/#oe amaldo_ (n=amaldo@pdpc/supporter/student/amaldo) |
| 18:46.59 | *** join/#oe rob__w (n=bob@p85.212.3.105.tisdip.tiscali.de) |
| 18:54.06 | likewise | Crofton|home: pong, read the backlog. I'm not a autoconf/automake/libtool/configure guru myself. (Damn, forgot to order the books on them with my Amazon order just a min ago..) |
| 18:54.26 | likewise | "read" as in past-tense. |
| 18:54.35 | Crofton | I am windering if there is a pattern here |
| 18:54.51 | Crofton | and I am wondering if updating to the latest libtool will change things |
| 18:55.04 | likewise | Crofton|home: but libtool gives back no rpath, only rpath-link, which is harmless |
| 18:55.39 | Crofton | look at the do_compile log |
| 18:55.56 | likewise | will do, let me see |
| 18:58.48 | *** join/#oe gremlin[it] (n=gremlin@217.201.159.60) |
| 18:59.23 | Crofton | looks like libtool was called in link mode with rpath-link, and then it adds the rpath to the real link command |
| 18:59.53 | likewise | RFC: proposing in conf/bitbake.conf: EXTRA_OEMAKE += " -w" |
| 19:02.12 | koen | "-w Print a message containing the working directory before and after |
| 19:02.12 | koen | <PROTECTED> |
| 19:02.12 | koen | <PROTECTED> |
| 19:02.13 | koen | " |
| 19:02.22 | koen | that one? |
| 19:03.01 | koen | related to that, I still need a volunteer to experiment with -pg to see if our (stripped) binaries get bigger |
| 19:03.31 | likewise | koen: yes |
| 19:04.00 | likewise | koen: curious, bigger compared to what? |
| 19:04.32 | koen | to the situation now |
| 19:04.33 | likewise | Crofton|home: If a add crosstools to my PATH, then run that libtool line manually from the madplay src dir, I get an error. |
| 19:04.53 | koen | if it doesn't make a difference, compiling with -pg would make debugging and profiling a lot easier |
| 19:06.16 | likewise | Crofton|home: false report, I screwed up my PATH... :-/ |
| 19:06.46 | likewise | koen: maybe we should have a DEVELOPER_DEBUG mode in OE for these options? |
| 19:07.39 | likewise | koen: ah, maybe the -pg symbols end up in the -dbg packages, is that a workable solution? |
| 19:09.44 | likewise | wb zecke |
| 19:10.32 | victor_rx1950 | yep this is bug with glibc |
| 19:12.46 | koen | likewise: that's the question :) |
| 19:14.01 | likewise | koen: ok, I see :-) |
| 19:14.39 | likewise | koen: my current todo stack is efika 2.6.21 kernel, madplay rpath, -pg (FIFO ordering) |
| 19:14.53 | koen | I'd like proper function names and line number is gdb |
| 19:14.58 | likewise | koen: and LIKEWISE_PARALLEL=2 |
| 19:15.14 | likewise | koen: use -dbg? |
| 19:15.23 | koen | yes |
| 19:15.36 | victor_rx1950 | psokolovsky: http://bugs.openembedded.org/show_bug.cgi?id=2054 =( |
| 19:15.38 | koen | that gives me function names most of the times |
| 19:15.46 | victor_rx1950 | psokolovsky: same problem |
| 19:21.54 | likewise | Crofton|home: work/ppc603e-angstrom-linux/madplay-0.15.2b-r0/madplay-0.15.2b/powerpc-angstrom-linux-libtool has hardcode_into_libs=yes, strange since the --rpath-disable would typically make this no |
| 19:22.50 | koen | likewise: sed -i -e s:hardcode_into_libs=yes:hardcode_into_libs=no:g ${TARGET_SYS}libtool in autotools.bbclass ? |
| 19:23.05 | koen | (or something similar that is correct sed) |
| 19:23.21 | Crofton|home | I think we should move to libtool 1.5.22 |
| 19:23.24 | likewise | koen: good point. first let's grep where this occurs. |
| 19:23.31 | Crofton|home | first and see if that changes behavior |
| 19:23.53 | likewise | Crofton|home: volunteering? ;-) |
| 19:25.01 | Crofton|home | copying bb files atm :) |
| 19:25.01 | Crofton|home | I'll see what patches fail |
| 19:29.34 | *** join/#oe jott (n=j@unaffiliated/jott) |
| 19:37.14 | koen | Crofton|home: libtool is a can of worms, since they rewrite it every monday |
| 19:37.28 | Crofton|home | heh |
| 19:37.39 | Crofton|home | fighting patches now ... |
| 19:43.49 | likewise | koen: hardcode_into_libs alone seems not enough... |
| 19:44.13 | koen | drat |
| 19:49.40 | Crofton|home | diff -Nurd? |
| 19:50.42 | likewise | Crofton|home: ? |
| 19:50.53 | likewise | Crofton|home: as the preferred options to diff? yes. |
| 19:50.55 | koen | or -Naur, but Nurd is easier to remember |
| 19:50.56 | Crofton|home | trying to remember how to make a patch |
| 19:51.16 | *** join/#oe prasinos (n=prasinos@ppp86-243.adsl.forthnet.gr) |
| 19:51.52 | CIA-4 | 03polyonymous 07org.oe.dev * r17540e9f... 10/ (1 packages/gpe-autostarter/gpe-autostarter_0.12.bb): gpe-autostarter: fix compilation with recent linux-linux-headers, closes #2176 |
| 19:51.56 | CIA-4 | 03polyonymous 07org.oe.dev * r01df3eb8... 10/ (1 packages/prismstumbler/prismstumbler_0.7.3.bb): prismstumbler: fix build against motif and recent linux-linux-headers, closes #2177 |
| 19:52.03 | *** join/#oe z72ka-ntb (n=hermanj@gprs1.vodafone.cz) |
| 19:52.09 | *** part/#oe z72ka-ntb (n=hermanj@gprs1.vodafone.cz) |
| 19:53.22 | Crofton|home | bother |
| 19:53.35 | Crofton|home | how do I get diff to ignore files that are only on one of the dirs? |
| 19:55.56 | psokolovsky | don't pass -N ;-) |
| 19:56.41 | NAiL | Is there any plans at all to clean up the packages/ dir? |
| 19:57.03 | koen | NAiL: clean up in what way? |
| 19:57.27 | NAiL | dunno, make "ls" actually usable in the packages directory? |
| 19:57.54 | koen | We can't really do that due to BBFILES |
| 19:58.02 | koen | we could group stuff a bit better |
| 19:58.22 | koen | (gpe-* -> gpe/, opie-* -> opie/, gnome-* -> gnome/, etc) |
| 19:59.53 | NAiL | yeah |
| 20:00.22 | NAiL | well, gnome is only two directories. gnome and gnome-themes |
| 20:00.39 | NAiL | but still, doing that, there's more than 1200 entries in that directory |
| 20:01.06 | koen | we could add an alphabet layer |
| 20:01.16 | koen | a/, b/, c/ |
| 20:02.08 | NAiL | what about SECTION= |
| 20:02.09 | NAiL | ? |
| 20:02.19 | NAiL | It's just driving me nuts |
| 20:02.26 | koen | our sections are still a mess and random |
| 20:02.38 | NAiL | mmh |
| 20:03.37 | timtimred | that would be a great thing to split up |
| 20:03.47 | NAiL | indeed |
| 20:03.55 | timtimred | categorize it/put it in sections somehow |
| 20:04.20 | timtimred | as a mid to long term project goal perhaps ;) |
| 20:04.21 | koen | we could do the debian alphabet thing |
| 20:04.32 | zecke | koen: well we can complicate BBFILES |
| 20:04.33 | koen | a/, b/ ... liba/ libb/... z/ |
| 20:04.37 | timtimred | i guess theres major breakage involved? |
| 20:04.46 | polyonymous | but it gives no benefits except for filesystem performance, maybe. |
| 20:05.19 | NAiL | polyonymous: filesystem performance, trac performance (ever tried browsing the packages dir through trac? Don't) |
| 20:05.43 | polyonymous | NAiL, No, I haven't :) I thought the issue was making 'ls' usable :) |
| 20:05.46 | timtimred | aye it kills our server for about 10 seconds when someone hits that dir |
| 20:05.57 | NAiL | polyonymous: that's one of the issues |
| 20:06.42 | polyonymous | NAiL, ah ok. Well, I think categorization, would make more sense. Just my very personal opinion. |
| 20:06.50 | polyonymous | Anyway, it's bath time, courtesy of opie-reader it may take a while :) |
| 20:06.56 | NAiL | Well, I'm mostly satisfied any way it's done. |
| 20:07.17 | koen | timtimred: xfs? |
| 20:07.38 | NAiL | zecke: wouldn't it basically being saying /packages/*/*/*.bb instead of /packages/*/*.bb? |
| 20:07.50 | NAiL | koen: no, it's ext3. |
| 20:08.05 | koen | NAiL: yes |
| 20:08.05 | NAiL | xfs is horrible with the packages dir |
| 20:08.17 | Crofton|home | thanks psokolovsky, I guess I could rad the man page |
| 20:08.23 | zecke | NAiL: what is with nonworking, but basicly yes |
| 20:09.04 | NAiL | zecke: hmm... good point. |
| 20:09.38 | NAiL | if done like the debian alphabet thing, add a nonworking dir in each? |
| 20:13.06 | koen | "There's plenty of older hardware that doesn't have the processing power to do WPA, and has to rely on WEP. This is especially true for embedded devices (like print servers and bar code scanners) and PDAs." |
| 20:13.13 | koen | why do I still read slashdot? |
| 20:17.42 | *** join/#oe memeruiz (n=memeruiz@e181029164.adsl.alicedsl.de) |
| 20:18.36 | likewise | Crofton|home: the libtool in madplay, line 2721 is to blame for the rpath. |
| 20:19.18 | Crofton|home | I have libtool-native building |
| 20:21.53 | Crofton|home | If I get the new libtool building, should I push with DEF_PREF set to -1 so likewise can look at it? |
| 20:21.53 | koen | yes |
| 20:22.12 | Crofton|home | curse the number of bb file |
| 20:22.33 | Crofton|home | grep DEFAULT */*bb errors with to many args now |
| 20:22.41 | CIA-4 | 03koen 07org.oe.dev * rd6b64846... 10/ (1 packages/tracker/tracker_0.5.4.bb): tracker: add file to DEPENDS (for magic.h) |
| 20:26.30 | Crofton|home | ok, still have bad RPATH |
| 20:26.31 | Crofton|home | I will go ahead and push newer libtool for testing purposes |
| 20:26.42 | koen | likewise: http://lists.freedesktop.org/archives/cairo/2007-May/010543.html |
| 20:27.09 | likewise | Crofton|home: use DEFAULT_PREFERENCE="-1" on it, I guess? |
| 20:27.30 | likewise | ah yes, see you wrote that... |
| 20:27.31 | Crofton|home | yes |
| 20:27.53 | likewise | Meanwhile, in a secret room, likewise is debugging the current libtool script. |
| 20:28.02 | Crofton|home | If we try and pass fix upstream, we should use current libtool |
| 20:28.09 | likewise | Agreed. |
| 20:28.25 | Crofton|home | hopefully the fix is the same in current :) |
| 20:28.26 | likewise | I just want to learn why madplay goes wrong, and most of the others fail. |
| 20:28.40 | Crofton|home | I think fixing madplay will fix gnutls |
| 20:28.41 | likewise | s/fail/succeed/ - sigh |
| 20:28.52 | Crofton|home | sice both link using libtool --mode=link |
| 20:29.41 | likewise | yes, but libtool makes a decision on when to include the rpath, somewhere around line 2720, and I still do not see why other packages have no rpath. |
| 20:30.00 | Crofton|home | maybe they do not use libtool for linking |
| 20:30.03 | Crofton|home | is my guess |
| 20:30.20 | Crofton|home | I am not sure why madplay uses libtool |
| 20:37.22 | CIA-4 | 03crofton 07org.oe.dev * rbcb26d45... 10/ (13 files in 3 dirs): |
| 20:37.22 | CIA-4 | libtool : Add bb files for libtool-1.5.22. DEFAULT_PREFERENCE set to -1 |
| 20:37.22 | CIA-4 | <PROTECTED> |
| 20:40.02 | NAiL | zecke/koen: but you don't think splitting it up is a bad idea? |
| 20:40.34 | Crofton|home | ok, I am rebuilding with libtool-1.5.22 |
| 20:41.09 | Crofton|home | bbl |
| 20:41.11 | *** join/#oe wookey_ (n=wookey@stoneboat.aleph1.co.uk) |
| 20:41.30 | koen | NAiL: I have no strong opinion about it |
| 20:41.48 | zecke | NAiL: I want to do it since the very beginning :} |
| 20:42.10 | NAiL | well then |
| 20:42.22 | NAiL | I'll send a mail to the list and see |
| 20:43.00 | zecke | night |
| 20:43.06 | NAiL | nite |
| 20:54.30 | summatusmentis | does anyone run beryl? My computer locks up hardcore, beryl CPU usage jumps to 86% when I run bitbake nano, and have beryl running |
| 20:59.24 | polyonymous | summatusmentis, what happens when you run find / ? |
| 20:59.37 | NAiL | heh |
| 20:59.56 | summatusmentis | polyonymous: I'm confused, what do you mean? |
| 21:00.26 | polyonymous | summatusmentis, `find /` is a shell command. I wonder if beryl hogs cpu when you run it in terminal. |
| 21:00.28 | NAiL | summatusmentis: I'll give you a clue. This is #oe.. |
| 21:00.41 | polyonymous | That's also very much so :) |
| 21:01.09 | summatusmentis | NAiL: I know it's #oe. however, emerge -DNatuv world doesn't have this happen, which makes me wonder if it's something in the way OE operates |
| 21:01.19 | CoreDump|home | beryl really doesn't like cpu-intensive tasks. However, your system shouldn't lock up |
| 21:01.19 | summatusmentis | polyonymous: seemingly not |
| 21:01.59 | polyonymous | summatusmentis, well, I've also noted that my plain old x-windows setup doesn't do it neither with emerge, nor with paludis or bitbake :) |
| 21:02.13 | summatusmentis | CoreDump|home: that's what I thought |
| 21:02.29 | summatusmentis | polyonymous: meh... plain onld x-windows isn't pretty-fied :-D |
| 21:02.46 | polyonymous | summatusmentis, well, I find it pretty much fied. |
| 21:03.05 | summatusmentis | ^^ |
| 21:03.10 | polyonymous | CoreDump|home, seriously? |
| 21:03.19 | CoreDump|home | polyonymous: yeah |
| 21:03.39 | polyonymous | My WM is somewhat 3D, because my second head is at an angle with the first one. |
| 21:03.44 | summatusmentis | I guess I'm gonna potentially have to decide if I want to dev or have pretty X. Maybe switch back and forth |
| 21:04.08 | polyonymous | Can't imagine why would I more 3d in my wm... Gotta try it one day. |
| 21:04.42 | CoreDump|home | polyonymous: it's the little things you get used to =) |
| 21:04.47 | summatusmentis | it's nice, assuming you don't go over the top w/ the settings |
| 21:04.58 | polyonymous | CoreDump|home, that's why I'm afraid I will never be able to part with fvwm :) |
| 21:05.19 | polyonymous | I've tried to change it on many wms, but always got back :) |
| 21:05.24 | CoreDump|home | that's what I thought for my beloved windowmaker as well =D |
| 21:06.16 | polyonymous | CoreDump|home, well, I need to try, of course, before I try to defend my point any further :)) |
| 21:06.38 | CoreDump|home | trying doesn't hurt, but to each his own of course |
| 21:06.58 | polyonymous | right. |
| 21:09.09 | likewise | Crofton|home, koen: interesting background read, well written and deep: http://wiki.debian.org/RpathIssue |
| 21:12.44 | polyonymous | koen, I think it was you, who committed prismstumbler and gpe-autostarter? It seems you forgot to add *.patch |
| 21:14.38 | polyonymous | (that is - in addition to modifying .bb files) |
| 21:16.33 | CoreDump|home | polyonymous: summatusmentis: This is beryl on my notebook -> http://hentges.net/tmp/screenshots/AIGLX/aiglx_20070116.avi |
| 21:17.31 | summatusmentis | I'm using aiglx too |
| 21:20.20 | polyonymous | CoreDump|home, transparency is the only think I find useful here. Besides, you have Angstrom MLs in OpenZaurus folder! |
| 21:20.32 | CoreDump|home | lol, right |
| 21:26.13 | *** join/#oe jott (n=j@unaffiliated/jott) |
| 21:28.10 | *** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 21:33.19 | *** join/#oe Speedy2 (n=Javier_6@cpe-66-75-4-134.san.res.rr.com) |
| 21:36.13 | *** join/#oe tsdogs (n=twostupi@62.123.180.130) |
| 21:36.47 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 21:37.14 | *** join/#oe Kristoffer (n=Kristoff@80.251.207.35) |
| 21:39.52 | polyonymous | koen, think you haven't got it: polyonymous koen, I think it was you, who committed prismstumbler and gpe-autostarter? It seems you forgot to add *.patch |
| 21:41.22 | CIA-4 | 03koen 07org.oe.dev * rb5599083... 10/ (3 files in 3 dirs): gpe-autostarter: add missing patch |
| 21:41.26 | CIA-4 | 03koen 07org.oe.dev * r30f2bd37... 10/ (1 packages/prismstumbler/prismstumbler-0.7.3/wireless.patch): prismstumbler: add missing patch |
| 21:41.33 | polyonymous | ah ok :) |
| 21:42.24 | CoreDump|home | I could get used to OM's revision checker thingy |
| 21:42.32 | CoreDump|home | !praise svnnow |
| 21:42.40 | polyonymous | what's svnnow? :) |
| 21:42.59 | CoreDump|home | it's a version tag |
| 21:43.13 | polyonymous | uhm... |
| 21:43.18 | koen | you mean the fetcher improvement, not svnnow |
| 21:43.28 | CoreDump|home | combined w/ the OM patch for bitbake, packages w/ "svnnow" will only e rebuilt when their SVN revision changes |
| 21:43.40 | *** join/#oe SonicvanaJr (n=Garrett@unaffiliated/sonicvanajr) |
| 21:43.45 | polyonymous | I think I fixed building gcc for arm on amd64. |
| 21:44.13 | polyonymous | At least in terms of building the powerful helloworld tool on Z. |
| 21:44.31 | CoreDump|home | !praise polyonymous |
| 21:44.55 | polyonymous | cdbot2 itn't worthy. Where is this world going now. |
| 21:46.27 | chouimat|away | polyonymous: Hell |
| 21:46.29 | chouimat|away | ? |
| 21:46.38 | chouimat|away | wait we are allready there |
| 21:46.43 | polyonymous | Hell. (o, world!) |
| 21:47.11 | CoreDump|home | heh |
| 21:49.32 | likewise | polyonymous: what was broken then? (building for arm on amd64 here for ages) |
| 21:49.42 | polyonymous | likewise, building gcc? |
| 21:50.14 | likewise | polyonymous: sorry, I'm staying up too late. target gcc, right. |
| 21:50.19 | polyonymous | !oebug 1951 |
| 21:50.21 | cdbot2 | * * Bug 1951, Status: REOPENED, Created: 2007-03-07 15:45 |
| 21:50.22 | cdbot2 | * * nail(AT)nslu2-linux.org: gcc fails to build on x86_64 |
| 21:50.23 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=1951 |
| 21:51.30 | likewise | ok |
| 21:52.16 | likewise | I almost never cross-build target toolchains, my targets are too small :-) |
| 21:52.48 | polyonymous | likewise, I wouldn't say that mine is really big one, but I just wanted to do it for the sake of completeness :) |
| 21:53.00 | likewise | polyonymous: very well |
| 21:53.22 | polyonymous | sometimes it's so relaxing to compile helloworld when you're on the road :) |
| 21:56.27 | polyonymous | submitted a patch. |
| 22:09.18 | likewise | polyonymous: Could you describe the problem you fixed and how you fixed it in the header of the patch please? We have a hell of a time maintaining our older toolchain patches, and such a comment might help us in the future. |
| 22:10.06 | polyonymous | likewise, the patch is, basically, a port of the older one in the same bug. |
| 22:11.05 | likewise | polyonymous: ah yes, comment #3 should be the patch header, more or less, when we commit it. |
| 22:11.18 | polyonymous | likewise, yes, that would make sense. |
| 22:11.30 | *** join/#oe summatusmentis (n=summatus@72.168.202.219) |
| 22:12.52 | polyonymous | But the maintenance hell is, I'm afraid, due to something wrong with the approach to the whole toolchain thing. Not that I am able to properly elaborate on my thoughts on the matter or propose any improvement at the moment. |
| 22:28.51 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 22:46.09 | likewise | polyonymous: it's very entangled, and fixes/works around a lot of issues. |
| 22:47.33 | *** join/#oe slapin_nb (n=slapin@143.166.249.ozerki.net) |
| 22:47.54 | polyonymous | likewise, true. |
| 22:58.34 | *** join/#oe Sup3rkiddo (n=sudharsh@59.92.45.115) |
| 22:58.44 | CIA-4 | 03likewise 07org.oe.dev * r256d1626... 10/ (1 packages/db/db_4.2.52.bb packages/db/db_4.3.29.bb): db: Use rm -rf instead of rmdir (which broke re-installation). |
| 22:59.31 | polyonymous | hmm... no http support in subversion on the device... |
| 23:02.33 | polyonymous | well, goodnight everyone |
| 23:05.03 | likewise | goodnite |
| 23:05.50 | koen | 'night all |
| 23:23.21 | *** join/#oe memeruiz (n=memeruiz@e181059254.adsl.alicedsl.de) |
| 23:37.58 | tsdogs | hi all, is anyboy still awake? |
| 23:38.11 | tsdogs | I have a question about OE and icecc |
| 23:39.28 | tsdogs | It seems that the only configuration supported is to have two (or more) identical CPUs |
| 23:39.32 | tsdogs | Is this correct? |
| 23:44.06 | tsdogs | well, night all. |