| 00:02.06 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 00:05.12 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 00:31.51 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 00:46.26 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 00:49.10 | *** join/#oe sakoman_ (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
| 00:50.55 | *** join/#oe schroedinbug (~schroedin@71-215-121-120.hlrn.qwest.net) |
| 01:00.08 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 01:06.09 | *** join/#oe Kyoron (~815ecfd3@gateway/web/freenode/x-bggihlfwmyzvtdpf) |
| 01:12.40 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 01:21.15 | Kyoron | Hello, is it acceptable to ask help on package building here? |
| 01:29.09 | *** join/#oe lisppaste7 (~lisppaste@common-lisp.net) |
| 01:31.50 | Kyoron | I'd goess not then. |
| 01:33.19 | nullpuppy | i think no ones around... |
| 01:35.16 | Kyoron | oh well :< |
| 01:54.15 | grg | Kyoron, there are plenty of people around. Just ask your question, instead of asking if you can ask. |
| 01:59.18 | *** join/#oe rsalveti (~rsalveti@189.115.175.118) |
| 02:00.31 | Kyoron | cool, I just want to check the rules first |
| 02:01.03 | Kyoron | got a failed build on glib-2.0 |
| 02:01.36 | Kyoron | http://pastebin.com/m4002ddf7 |
| 02:01.47 | Kyoron | google, mailing list turned nothing |
| 02:02.00 | *** join/#oe bbradley_ (~bbradley@87-194-119-230.bethere.co.uk) |
| 02:02.00 | Kyoron | tried cleaning and rebuilding, no avail |
| 02:03.14 | Kyoron | anyone have any idea what to do next? |
| 02:13.36 | *** join/#oe rsalveti (~rsalveti@189.115.175.118) |
| 02:27.40 | CIA-85 | 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r049da16985 10openembedded.git/recipes/eglibc/ (eglibc_2.11.bb eglibc_svn.bb): |
| 02:27.40 | CIA-85 | eglibc: Bump SRCREV to latest for svn and 2.11 recipes. |
| 02:27.40 | CIA-85 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 03:04.35 | sethn | Kyoron: still here? |
| 03:06.50 | sethn | Kyoron: I might be able to give you a hand if you ping me while we're bother around |
| 03:07.06 | sethn | Kyoron: er, both... freudian slip eh? ;-) |
| 03:07.42 | Kyoron | cool |
| 03:08.04 | Kyoron | Still had no success |
| 03:08.47 | Kyoron | (tyhis is in the process of building the helloworld tutorial, Im guessing it's building the crosscompiler or something related) |
| 03:10.00 | *** join/#oe EiNSTeiN_ (~einstein@unaffiliated/einstein/x-615171) |
| 03:14.08 | sethn | Kyoron: So the "-native" there does indeed mean its the process of setting up cross-compilation |
| 03:14.20 | sethn | Kyoron: You're on x86, right? |
| 03:14.52 | Kyoron | a pentium 4, so I suppose so |
| 03:15.29 | sethn | Kyoron: Has it already built pkgconfig-native? (you can check in /home/mavstar/oe/tmp/work/i686-linux/pkgconfig-native-0.24-r7.1 or something like that) |
| 03:15.41 | Kyoron | hang on |
| 03:16.28 | Kyoron | there's no such directory in there |
| 03:16.53 | Kyoron | would that be the problem? |
| 03:16.57 | sethn | Kyoron: Is there any pkgconfig-* directory there? |
| 03:17.09 | sethn | Kyoron: Well PKG_CHECK_MODULES is a macro defined by pkgconfig |
| 03:17.20 | Kyoron | I see |
| 03:17.22 | sethn | Kyoron: So you need a native pkgconfig built before you can build glib |
| 03:17.25 | Kyoron | no pkg* |
| 03:17.57 | sethn | Kyoron: Just so you're learning how I'm thinking about hese problems.... I'm looking at org.openembedded.org/recipes/pkgconfig/pkgconfig-native* next |
| 03:18.13 | sethn | Kyoron: Checking how/if that recipes requests pkgconfig to be built first |
| 03:18.47 | sethn | Kyoron: er, make that glib-native |
| 03:19.07 | Kyoron | hm I didn't think in thet direction before |
| 03:19.23 | Kyoron | since I assume oe would automagically take care of dependencies :/ |
| 03:20.06 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
| 03:20.50 | sethn | Kyoron: Sometimes a package's dependency chain isn't complete |
| 03:21.06 | sethn | Kyoron: It worked in other contexts because SO MANY packages request pkg-config |
| 03:21.13 | sethn | Kyoron: This might not be the problem |
| 03:21.17 | Kyoron | ah, I see |
| 03:21.36 | sethn | Kyoron: But I am noticing glib-2.0-native_2.22.1.bb doesn't directly DEPEND on pkgconfig-native |
| 03:21.43 | sethn | Kyoron: So lets run an experiment on your computer |
| 03:21.49 | Kyoron | sure |
| 03:22.10 | sethn | Kyoron: edit glib-2.0-native_2.22.1.bb |
| 03:23.03 | sethn | Kyoron: Change DEPENDS = "gettext-native gtk-doc-native" to DEPENDS = "gettext-native gtk-doc-native pkgconfig-native" |
| 03:23.03 | Kyoron | add pkgconfig-native to the dependencies or something like that? |
| 03:23.07 | sethn | yup |
| 03:23.20 | sethn | Then go back to your build dir, and run the bitbake command again |
| 03:24.10 | Kyoron | let's see now |
| 03:26.19 | Kyoron | bleh, edited the wrong file |
| 03:33.31 | Kyoron | ....geh, no deal |
| 03:33.45 | Kyoron | it doesn't seem to even try compiling pkgconfig |
| 03:35.26 | Kyoron | I might try compiling the gumstix bootloader since I had successfully built that one once |
| 03:35.33 | Kyoron | (before the hard drive dies) |
| 03:35.49 | Kyoron | thoughts? |
| 03:42.22 | Kyoron | ....and the first thing in the bootloader compilation process is compiling pkgconfig. Doh. |
| 03:44.43 | *** join/#oe EiNSTeiN_ (~einstein@unaffiliated/einstein/x-615171) |
| 03:47.28 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
| 03:54.30 | Kyoron | Thanks for your help sethn! |
| 03:55.13 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 03:56.17 | sethn | Kyoron: did it work? |
| 03:56.26 | sethn | Kyoron: Sorry, went to buy an SD card before everything closed |
| 03:56.34 | Kyoron | lol no worries |
| 03:56.51 | Kyoron | the edit the file method didnt so I tried compiling x-load |
| 03:57.10 | Kyoron | that installed pkgconfig |
| 03:57.22 | Kyoron | which results in glib behaving again |
| 03:57.51 | Kyoron | (something else breaks, but I dont really worry about it atm) |
| 03:58.18 | sethn | Kyoron: weird, I'm surprised the file didn't cut it, but at least you're on your way |
| 03:58.43 | Kyoron | I'll just compile one of the standard packages and then mess with helloworld again |
| 03:58.47 | sethn | Kyoron: You can also just do "bitbake pkgconfig-native" if you run into something like this again and don't want to try tweaking the files |
| 03:58.49 | sethn | nods |
| 03:59.00 | Kyoron | cool |
| 03:59.21 | Kyoron | so bitbake automagically detects if something is already compiled? |
| 03:59.29 | Kyoron | that's awesome |
| 04:02.34 | *** join/#oe EiNSTeiN_ (~einstein@unaffiliated/einstein/x-615171) |
| 04:45.33 | *** join/#oe mrmoku|a` (~mrmoku@ppp-93-104-170-53.dynamic.mnet-online.de) |
| 04:49.24 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 05:21.32 | *** join/#oe Sup3rkiddo (~sudharsh@unaffiliated/sudharsh) |
| 05:27.16 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 05:29.28 | *** join/#oe Aditya__1 (~Aditya@c-69-143-196-44.hsd1.md.comcast.net) |
| 05:32.59 | *** join/#oe polyonymous (~hacker@g230193059.adsl.alicedsl.de) |
| 06:02.45 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 06:04.02 | eFfeM | morning everyone |
| 06:05.10 | *** join/#oe rsalveti_ (~rsalveti@189.115.170.20) |
| 06:41.06 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 06:48.22 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 06:52.35 | *** join/#oe thaytan (~jan@216.112.110.68.ptr.us.xo.net) |
| 07:00.31 | *** join/#oe Weaselweb (~quassel@2001:6f8:9e4:123:21a:92ff:fe5a:1409) |
| 07:01.04 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 07:05.57 | *** join/#oe koobe (~matti@83.150.95.26) |
| 07:15.23 | *** join/#oe thaytan (~jan@216.112.110.2.ptr.us.xo.net) |
| 07:18.35 | *** part/#oe XorA (~XorA@www.xora.org.uk) |
| 07:25.51 | *** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 07:32.25 | *** join/#oe raster_ (~raster@bb121-6-236-4.singnet.com.sg) |
| 07:38.31 | *** join/#oe Hasse (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 08:05.28 | *** join/#oe raster_ (~raster@bb121-6-236-4.singnet.com.sg) |
| 08:08.39 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:30.41 | *** join/#oe Laibsch (~Laibsch@82.113.106.188) |
| 08:31.05 | Laibsch | good morning! |
| 08:33.49 | ynezz | morning |
| 08:37.21 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 08:38.08 | *** join/#oe thebohemian (~rschus@p5DDC5ACB.dip.t-dialin.net) |
| 08:39.49 | *** join/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
| 08:48.25 | *** join/#oe Longfield (~valentin@lsa1pc7.epfl.ch) |
| 08:50.51 | pb__ | hi all |
| 08:51.50 | *** join/#oe pvanhoof (~pvanhoof@d54C0C0BA.access.telenet.be) |
| 08:53.35 | *** join/#oe XorA (~XorA@www.xora.org.uk) |
| 08:54.12 | XorA | morning |
| 08:56.34 | mckoan | good morning |
| 09:00.03 | *** join/#oe Heinervdm (~thomas@pD9E1515E.dip.t-dialin.net) |
| 09:01.50 | *** join/#oe f0QFE (~lDcUWutXP@89-172-65-117.adsl.net.t-com.hr) |
| 09:01.50 | *** part/#oe f0QFE (~lDcUWutXP@89-172-65-117.adsl.net.t-com.hr) |
| 09:04.49 | *** join/#oe ZaPPaS (~moritz@weinberg.pi5.physik.uni-stuttgart.de) |
| 09:05.56 | *** part/#oe lekernel (~azerty0@2001:470:1f09:12:21e:37ff:fed6:7d64) |
| 09:09.48 | *** join/#oe marcosmamorim (~marcos@201-43-35-154.dsl.telesp.net.br) |
| 09:10.00 | CIA-85 | 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r958e674180 10openembedded.git/recipes/subversion/subversion_1.6.5.bb: |
| 09:10.01 | CIA-85 | subversion-1.6.5: missing dependency to sqlite3 added |
| 09:10.01 | CIA-85 | Signed-off-by: Steffen Sledz <sledz@dresearch.de> |
| 09:11.04 | *** join/#oe Laibsch (~Laibsch@82.113.106.188) |
| 09:11.07 | CIA-85 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rdac96029c4 10openembedded.git/recipes/mtd/ (4 files): |
| 09:11.07 | CIA-85 | mtd-utils(-native): add v1.3.1 |
| 09:11.07 | CIA-85 | * also convert mtd-utils(-native) to new-style staging |
| 09:11.07 | CIA-85 | * old-style ubifs commands have been removed in v1.3.1 |
| 09:11.08 | CIA-85 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * r4e6d406d43 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git.openembedded.org/openembedded into org.openembedded.dev |
| 09:15.49 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 09:25.34 | *** join/#oe woglinde (~henning@p5DDC5ACB.dip.t-dialin.net) |
| 09:25.57 | woglinde | hi |
| 09:26.35 | mckoan | hi woglinde |
| 09:28.04 | woglinde | hi marco was your trip home well? |
| 09:28.10 | *** join/#oe raster_ (~raster@ad202.166.85.231.magix.com.sg) |
| 09:28.57 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 09:29.53 | *** join/#oe jeremy_laine (~sharky@188.126-14-84.ripe.coltfrance.com) |
| 09:30.41 | mckoan | woglinde: fine thx and you ? |
| 09:35.28 | *** join/#oe _ProtoN_ (~lcintrat@93.2.234.25) |
| 09:37.41 | woglinde | yeah nice flight back to cold berlin |
| 09:37.46 | woglinde | I hate the snow |
| 09:37.54 | woglinde | last to long |
| 09:40.09 | *** join/#oe mickey|office (~Mickey@dialbs-092-079-168-007.static.arcor-ip.net) |
| 09:40.15 | woglinde | he mickeyl :) |
| 09:58.03 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 09:58.48 | ao2 | hi, meta-toolchain fails to build for me http://tinderbox.openembedded.net/packages/467410/ |
| 10:00.45 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 10:00.54 | woglinde | ao2 hm strange error |
| 10:01.19 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 10:01.47 | ao2 | yep, the build was done after wiping out tmp/, FYI |
| 10:02.19 | ao2 | with "was done" I mean, _launched_, not completed successfully, sorry |
| 10:02.30 | woglinde | tmp or oetmp? |
| 10:03.03 | ao2 | woglinde, OE tmp. |
| 10:05.19 | *** join/#oe jeremy_laine (~sharky@188.126-14-84.ripe.coltfrance.com) |
| 10:05.50 | woglinde | hm sorry |
| 10:11.29 | CIA-85 | 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r344932973d 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 10:11.29 | CIA-85 | sane-srcrevs.inc: bump rev for pyphonelog |
| 10:11.30 | CIA-85 | to a revision which should build again |
| 10:11.30 | CIA-85 | Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de> |
| 10:18.02 | eFfeM | (backreading) morning mickey|office |
| 10:18.45 | eFfeM | mickey|office: how was fosdem, was in your first talk yesterday, but had to move to another talk and didn't manage to catch you later :-( sorry about that |
| 10:20.55 | woglinde | hi effem |
| 10:21.37 | eFfeM | hi woglinde, all |
| 10:22.11 | eFfeM | is already for quite a while in-da-house: (07:03:50 AM) eFfeM: morning everyone |
| 10:22.13 | eFfeM | (ouch) |
| 10:22.55 | eFfeM | btw enjoyed fosdem, made a few pics of our table will try to upload them somewhere tonight |
| 10:22.59 | *** join/#oe ant_work (~andrea@host214-85-static.34-85-b.business.telecomitalia.it) |
| 10:23.22 | eFfeM | if anyone else has piccies please drop them somewhere too |
| 10:31.29 | ant_work | hi eFfeM |
| 10:32.00 | woglinde | hi ant |
| 10:32.32 | mickey|office | eFfeM: hi, no problem, 2nd talk was well received, the demo (interactively calling into the middleware via dbus) got them sold ;) |
| 10:33.14 | *** join/#oe rob_w (~bob@217.237.177.190) |
| 10:33.33 | ant_work | Tartarus: your patch seems have fixed the " install: cannot stat `arch/arm/boot/zImage': No such file or directory" issue. Thx |
| 10:34.04 | ant_work | eFfeM: I can finally report progresses wrt packaged-staging |
| 10:34.32 | woglinde | mickeyl how was the workshop? |
| 10:34.50 | ant_work | eFfeM: at least the 3 images are built and even the fourth one (the initramfs) does not error out anymore |
| 10:34.53 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:34.59 | woglinde | hi cbrake |
| 10:36.20 | pb_ | mickey|office: good morning |
| 10:36.27 | woglinde | he pb |
| 10:37.06 | pb_ | hi woglinde |
| 10:37.09 | mickey|office | good morning pb_ |
| 10:37.17 | *** join/#oe booxter (~booxter@cpmsq.epam.com) |
| 10:37.23 | woglinde | hi booxter |
| 10:37.34 | ant_work | eFfeM: still this "...has no architecture specified, defaulting to i686-linux" for some packages, though. Scary... |
| 10:39.33 | CIA-85 | 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r0feaefef7b 10openembedded.git/recipes/swt/ (6 files): |
| 10:39.33 | CIA-85 | swt-gtk.inc: Properly give OE's LDFLAGS to makefile. |
| 10:39.33 | CIA-85 | swt3.3-gtk: Increased PR. |
| 10:39.33 | CIA-85 | swt3.3-gtk-hildon: Dito. |
| 10:39.33 | CIA-85 | swt3.4-gtk: Dito. |
| 10:39.33 | CIA-85 | swt3.4-gtk-hildon: Dito. |
| 10:41.04 | ant_work | eFfeM: and new findings too! At least 3 (native) packages are found but are 'invalid' so these get rebuilt. They are gettext, glib-2.0_2.24 and libxml-parser-perl. |
| 10:42.16 | RP | morning all |
| 10:42.21 | *** join/#oe toi (~toi@d54C2A96D.access.telenet.be) |
| 10:42.51 | eFfeM | ant_work: nice, did you have to make additional changes? |
| 10:43.04 | *** join/#oe Hasse (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 10:43.12 | ant_work | no, but I didn't yet test the sanity of images |
| 10:43.33 | eFfeM | this no arch specified is indeed odd, I checked the package and the control file does have an Architecture: line. |
| 10:43.57 | ant_work | yes, and this is like in the file suffix...686 |
| 10:44.06 | eFfeM | At one point i did some instrumentation of opkg-native (that is the one spitting out the message) but then I could not reproduce it any more |
| 10:44.29 | eFfeM | no idea if 686 is ok the file name also contains the actual arg |
| 10:44.44 | woglinde | hi rp |
| 10:45.05 | eFfeM | ant_work: eg ./angstromglibc/staging-strace-armv7a-angstrom-linux-gnueabi_4.5.14-r9_i686-linux.ipk |
| 10:45.27 | eFfeM | guess the staging package is to be unpaced on 686 and is for armv7a |
| 10:45.32 | ant_work | yes, this is definetely armv7a |
| 10:45.36 | eFfeM | staging packages contain .ipk's |
| 10:45.55 | ant_work | whose control file should specify the arch |
| 10:46.03 | eFfeM | so it would make sense to say the arch is i686 in the staging ipk and armv7a in the contained ipk |
| 10:46.10 | eFfeM | both have their own control file |
| 10:46.20 | ant_work | I can't believe opkg distinguoshes the buildhost? Why? It could be a web feed |
| 10:46.44 | ant_work | I mean for packages built to run on target |
| 10:47.22 | ant_work | but hey, I avoided as possible to dig inside ipkg/opkg meanders |
| 10:47.29 | *** join/#oe Hasse (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 10:47.54 | ant_work | I ended up building my own images with preinstalled packages :D |
| 10:47.54 | *** join/#oe Hasse (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 10:48.32 | woglinde | ~ping rp |
| 10:48.41 | ibot | pong rp |
| 10:48.54 | ant_work | eFfeM: anyway there is some discrepancy between the packages in /ipk and those in /pstage |
| 10:49.32 | ant_work | really I'm not the opkg man....I'm too biased (portage/emerge) |
| 10:50.10 | eFfeM | ant_work: time permitting I can dig into it but I first need to make sure I get the problem again |
| 10:50.24 | eFfeM | if you have a recipe for that, please let me know |
| 10:52.10 | ant_work | for now, if you have time, just rebuild from stage console-image |
| 10:53.28 | ant_work | check the log and see what about gettext glib-2.0_2.24 and libxml-parser-perl |
| 10:53.57 | ant_work | ..or just parse ./classes and grep for ' but invalid' |
| 10:55.47 | *** join/#oe mario-goulart (~user@67.205.85.241) |
| 10:56.58 | *** join/#oe lkcl (~lkcl@nat66.mia.three.co.uk) |
| 11:00.39 | pb_ | hi rp |
| 11:05.52 | *** join/#oe Sup3rkiddo (~sudharsh@unaffiliated/sudharsh) |
| 11:07.14 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 11:07.49 | eFfeM | ant_work: will try |
| 11:10.14 | ant_work | ok, thx, I'll do more tests this evening |
| 11:11.48 | *** join/#oe toi (~toi@d54C2A96D.access.telenet.be) |
| 11:12.11 | eFfeM | ant_work: wrt the invalid packages, you get that message if the package is out of date if I understand the class code properly |
| 11:12.56 | eFfeM | at least glib is changed recently, packaged staging is conservative and in doubt it will not recover from pstage but instead regenerate |
| 11:18.38 | ant_work | eFfeM: I rebuilt the images after git pull... |
| 11:18.51 | ant_work | only then I rebuilt from pstage |
| 11:19.10 | ant_work | I saw glib-2.0 was rebuilding (XorA commit) |
| 11:19.19 | ant_work | so should have been fresh |
| 11:19.44 | eFfeM | ok will check |
| 11:24.25 | *** join/#oe d_t_h (~dieter@p4FDEAA6E.dip.t-dialin.net) |
| 11:31.43 | XorA | denies it |
| 11:33.12 | RP | morning all |
| 11:33.34 | woglinde | ah re rp |
| 11:33.43 | woglinde | rp we have a question about new staging |
| 11:33.51 | RP | woglinde: go for it |
| 11:35.11 | woglinde | rp hm with swt we have jar's and native libraries |
| 11:35.27 | woglinde | and we want to install the native-libraries in the packages only |
| 11:35.34 | woglinde | not in stagging |
| 11:35.41 | woglinde | how is this achieved |
| 11:36.03 | RP | woglinde: why? |
| 11:36.05 | pb_ | why do you not want to install them in staging? |
| 11:36.07 | woglinde | without legacy staging of courese |
| 11:36.17 | RP | woglinde: can you also define native? |
| 11:36.18 | woglinde | the consume space |
| 11:36.25 | woglinde | they |
| 11:36.26 | woglinde | hms |
| 11:36.34 | woglinde | my english gets worsers and worser |
| 11:36.55 | woglinde | yeah easiest options is to install them |
| 11:36.56 | pb_ | is it enough space to be a real issue? |
| 11:37.00 | woglinde | but maybe there are cases |
| 11:37.12 | pb_ | unless they are really vast it is hard to imagine that the space will be significant compared to the rest of the build tree. |
| 11:37.59 | RP | woglinde: I assume in this case "native" really means "target" since native.bbclass doesn't generate packages |
| 11:38.00 | pb_ | I really don't think it is a good idea to introduce artificial differences between staging and the shipped packages. |
| 11:38.23 | woglinde | rp hm not native |
| 11:38.44 | woglinde | in this sense |
| 11:38.44 | RP | I agree with pb_ in general, however there is a way to make them different |
| 11:38.59 | woglinde | native in java sense |
| 11:39.03 | RP | Have a look in the tree for "preprocess" functions |
| 11:39.11 | pb_ | RP: heh, funnily enough I have just been experimenting with having native.bbclass generate packages. |
| 11:39.17 | woglinde | but its okay we will install them |
| 11:39.28 | RP | These can make the install and staging contents different |
| 11:39.39 | woglinde | swt natvie libs are only used at runtime |
| 11:39.43 | RP | we do already have them differ as we don't stage man pages for example |
| 11:39.59 | RP | pb_: Dare I ask why or don't I want to know? ;-) |
| 11:40.09 | woglinde | sorry for confusion |
| 11:40.21 | pb_ | RP: basically because I want to start populating staging from the actual packages rather than generating it in parallel. |
| 11:40.25 | RP | pb_: Dependency loops would be your main enemy I'd guess |
| 11:40.36 | pb_ | and, obviously, in order to do that for native packages you need to have packages created in the first place :-) |
| 11:41.06 | RP | pb_: We do generate staging from packages? |
| 11:41.43 | RP | pb_: We cheat for package management and use an old version of opkg written in python ;-) |
| 11:41.46 | *** join/#oe Sleep_Walker (~Sleep@nat/novell/x-mhvohxafptbehaqb) |
| 11:42.13 | RP | (stagemanager-native) |
| 11:44.48 | pb_ | RP: yeah, I don't particularly like the way it is done at the moment (with dedicated "staging packages") though. |
| 11:47.01 | RP | pb_: I know. If you want multiple package backends its kind of inevitable though |
| 11:48.05 | pb_ | RP: on that topic, can you remind me whether there is a good reason for having the "cross" directory separate from the rest of staging? |
| 11:48.37 | RP | pb_: You'd suggest the native sysroot I guess? |
| 11:48.38 | pb_ | it seems to remove a lot of complicated (and bogus-seeming) stuff in cross.bbclass and the associated recipes if we can just allow the toolchain to go into staging along with everything else. |
| 11:48.42 | pb_ | RP: right, exactly |
| 11:49.04 | pb_ | I ran a build like that yesterday and it seemed to work fine, but presumably there was some reason for creating cross/ in the first place. |
| 11:49.41 | RP | pb_: I think the problem is largely historic but the layout of the cross stuff is a bit different |
| 11:49.58 | pb_ | yeah, it is a bit different, but it doesn't seem to be different for any useful purpose. |
| 11:50.10 | *** join/#oe zecke (~ich@dsl-62-220-14-162.berlikomm.net) |
| 11:50.16 | RP | pb_: With other gcc and other tools it was useful |
| 11:50.28 | RP | pb_: Now, I can see a case for merging them |
| 11:50.36 | pb_ | okay |
| 11:50.46 | woglinde | hoi zecke |
| 11:50.47 | RP | pb_: I've slowly been moving that way ;-) |
| 11:50.48 | pb_ | I will see if I can separate my patchset for that from the rest of the changes that I have in my tree. |
| 11:50.55 | zecke | woglinde: hey, how was your first fosdem? |
| 11:51.00 | pb_ | iirc, the changes to eliminate cross/ are fairly straightforward |
| 11:51.18 | woglinde | zecke okay |
| 11:51.18 | RP | pb_: The situation is tons better than it was in the the gcc and binutils recipes are cleaner |
| 11:51.23 | pb_ | RP: right |
| 11:51.27 | woglinde | was like the earlier linuxdays |
| 11:51.28 | RP | and actually use the cross code |
| 11:51.43 | pb_ | RP: though, I discovered yesterday that there is still a certain amount of craziness in binutils, heh |
| 11:51.57 | RP | pb_: Check poky, its still ahead in changes :( |
| 11:52.25 | RP | pb_: There is also a work in progress tree in OE somewhere from me which has some poky toolchain stuff I was planning to push |
| 11:52.34 | RP | Sadly the tree will be bitrotten now :/ |
| 11:52.44 | woglinde | hm hm we have a touchbook now |
| 11:53.15 | RP | pb_: http://git.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress |
| 11:54.14 | RP | pb_: Some small binutils bits in there along with gcc |
| 11:56.00 | RP | pb_: One further question for you - what to do with the STAGING_BINDIR_CROSS ? |
| 11:56.18 | RP | pb_: Should that be in the native sysroot or the target one? |
| 11:57.08 | zecke | eFfeM: ping |
| 12:00.50 | eFfeM | zecke: pong |
| 12:01.54 | zecke | eFfeM: thanks for the reply to "tejas" |
| 12:02.24 | eFfeM | ant_work: did a rebuild from pstage over lunch and I indeed have the three invalid packages; will dive into it tonight |
| 12:03.33 | eFfeM | zecke: np, actually recently got a little bit fed up by people sending emails without proper description and without explanation, or with obvious solutions |
| 12:03.58 | eFfeM | like for tejas where it was obviously a network issue (and if you can't see that probably oe is not for you |
| 12:04.14 | eFfeM | not that i do not want to help people, but there are limits |
| 12:06.58 | zecke | eFfeM: yeah. I'm getting upset by these corporations... They should not filter what gets into their network, but what is leaving it. |
| 12:07.29 | eFfeM | zecke: actually had the idea he was a student |
| 12:07.51 | zecke | picus.in seems to be a company |
| 12:08.51 | zecke | obviously for indian's there.. language is not a problem... they are just incredible lazy. |
| 12:08.59 | eFfeM | yeah just googled it: http://www.picus.in/ |
| 12:09.19 | eFfeM | they specialise in dsp sw :-) read the guys' totem messages |
| 12:09.42 | zecke | eFfeM: so someone is paying them $$$ to get OE running on a platform. Maybe even outsourced from Europe because India is cheaper |
| 12:09.57 | eFfeM | btw see a lot of those email messages on beagleboard and hawkboard ML: |
| 12:10.01 | eFfeM | hey, I have a problem help me |
| 12:10.04 | eFfeM | now |
| 12:10.41 | zecke | eFfeM: by helping, you are killing jobs your own job. I'm at a stage where I help friends and FOSS |
| 12:10.43 | eFfeM | zecke: could well be, and from his email I doubt if he has a clue what he's doing |
| 12:11.12 | eFfeM | zecke: agree |
| 12:11.35 | zecke | I wonder if I should create a Django app... Companies Hall of Shame.. |
| 12:12.09 | eFfeM | actually i have no problem giving some help to someone who is doing his homework and needs some guidance, but I assume that people try first |
| 12:12.27 | eFfeM | got quite some advice from Koen when I started with oe several years ago |
| 12:13.03 | eFfeM | zecke, hall of shame :-) guess they will also end up in the GPL hall of shame as they do not understand that part either |
| 12:13.52 | eFfeM | has a lot of experience with Indians, for better and for worse (there are definitely very good and clever guys there too; and for some reason the bad ones didn't really last long in my projects) |
| 12:15.49 | eFfeM | ant_work: the fresh build from staging does not give architecture warnings (beagleboard console-image) |
| 12:16.03 | eFfeM | if you have an idea on how t recreate them drop a msg |
| 12:16.21 | eFfeM | otherwise will look into it tonight, need to do other thigns now so afk for next hour or so |
| 12:16.23 | ant_work | eFfeM: try to rebuild from pstage, from the same rootfs created by first rebuild |
| 12:16.26 | zecke | eFfeM: yeah. I know some incredible indian engineers... It is not avoidable. If you create a "Software Industry" you will have to have people that are not good... |
| 12:16.50 | eFfeM | ant_work: did that |
| 12:17.14 | ant_work | oh, on second run I saw the infamous lines... |
| 12:17.22 | eFfeM | zecke: true and informatics is considered to be a good paying career so it attracts lots of untalented people |
| 12:17.26 | eFfeM | ant_work: define second run |
| 12:17.49 | ant_work | first rebuild from pstage, remove tmp (keep pstage), rebuild |
| 12:18.11 | eFfeM | will try later, really gone now |
| 12:18.19 | ant_work | the 3 invalid were still there |
| 12:18.36 | ant_work | but now, though the warnings, image is created |
| 12:18.44 | ant_work | that's a big progres :) |
| 12:19.32 | zecke | eFfeM: What I have learned in India. Being unfriendly can be helpful to be left alone. FOSS Communities were too helpful to deal with non thinking crowd, we need to get rid of the "free thinking support"... |
| 12:20.41 | ant_work | eFfeM: the stopper was the " install: cannot stat `arch/arm/boot/zImage'. This has been finally fixed (by Tartarus). |
| 12:24.30 | pb_ | RP: thanks, I'll take a look |
| 12:27.08 | pb_ | RP: as for STAGING_BINDIR_CROSS, I'm not entirely clear on what exactly that variable is used for. There don't seem to be many references to it apart from binconfig. |
| 12:27.54 | *** join/#oe matgnt (~matthias@z0701.wist.uni-linz.ac.at) |
| 12:29.28 | *** join/#oe kurre (~tomimo@xdsl-83-150-88-111.nebulazone.fi) |
| 12:29.30 | eFfeM | zecke: fully agree |
| 12:29.58 | eFfeM | ant_work: the cannot stat is because do_deploy is executed for kernel which should not be the case |
| 12:30.06 | eFfeM | could be a timestamp issue |
| 12:30.15 | *** join/#oe hrw-gone-fosdem (~hrw@chello089078170228.chello.pl) |
| 12:30.16 | ant_work | eFfeM: it has disappeared now |
| 12:30.22 | eFfeM | haven't seen tartarus patch |
| 12:30.32 | ant_work | btw the recipe had empty do_stage and do_istall |
| 12:30.45 | ant_work | so it wasn't recipe fault apparently |
| 12:32.22 | ant_work | it was: kernel.bbclass: Fix pstaging do_deploy. |
| 12:33.05 | ant_work | http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=8dc84badb1d772f5953492c4022c1f644c4fe278 |
| 12:33.11 | *** join/#oe rkirti (~oespirit@203.199.213.3) |
| 12:33.59 | eFfeM | ant_work: ah ok didn't see that one |
| 12:36.05 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 12:36.41 | *** join/#oe marcosmamorim (~marcos@201-43-35-154.dsl.telesp.net.br) |
| 12:41.37 | eFfeM | ant_work: managed to reproduce the problem; rm tmp; bitbake console-image; bitbake -cclean virtual/kernel;bitbake virtual/kernel |
| 12:41.49 | eFfeM | will see if I can find something |
| 12:42.27 | *** join/#oe Laibsch (~Laibsch@82.113.106.188) |
| 12:47.31 | *** join/#oe hansdampf (~moritz@rgnb-4d04b027.pool.mediaWays.net) |
| 12:51.10 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 12:52.15 | florian | good morning |
| 12:53.08 | woglinde | florian robert worried |
| 12:53.48 | XorA | hey dudes, now your all back anyone going to write a report on FOSDEM |
| 12:54.26 | woglinde | time |
| 12:55.37 | florian | yes e should have something like this |
| 13:01.34 | woglinde | hm we should update qemu-natvie |
| 13:03.49 | XorA | heh picus.in are hiring :-D |
| 13:04.27 | JaMa|Gone | yeah, they evidently need someone :) |
| 13:04.49 | zecke | pb_: well done. incredible how relaxed you can deal with that. were you forced to ever work in tech support? |
| 13:04.50 | *** join/#oe marcosmamorim (~marcos@201-43-35-154.dsl.telesp.net.br) |
| 13:06.04 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 13:09.05 | *** join/#oe marcosmamorim (~marcos@201-43-35-154.dsl.telesp.net.br) |
| 13:16.14 | hrw | morning |
| 13:16.40 | woglinde | hi hrw |
| 13:17.00 | eFfeM | florian, hrw, wb, had a good trip back? |
| 13:17.55 | eFfeM | XorA: I don't think they can afford either of us |
| 13:18.02 | hrw | eFfeM: was fine |
| 13:20.12 | Crofton | The phrase "please guide me" is over used |
| 13:24.30 | woglinde | crofton I will pay for guide me |
| 13:24.35 | woglinde | that would be good |
| 13:24.44 | woglinde | hi btw. |
| 13:26.07 | Crofton | hi |
| 13:26.08 | Crofton | yeah |
| 13:26.47 | *** join/#oe B_Lizzard (~havoc@athedsl-427294.home.otenet.gr) |
| 13:26.52 | XorA | I wish someone would guide me to fix my gobject-introspection recipe :-D |
| 13:28.06 | Crofton | heh |
| 13:30.42 | *** join/#oe toi (~toi@d54C2A96D.access.telenet.be) |
| 13:34.22 | XorA | guide me Crofton I demand! |
| 13:35.29 | ynezz | picus is pussy in czech :p |
| 13:36.05 | XorA | ynezz: now that made me laugh |
| 13:36.30 | woglinde | ynezz *g* |
| 13:37.05 | *** join/#oe zecke (~ich@dsl-62-220-14-162.berlikomm.net) |
| 13:47.22 | florian | eFfeM: yep... |
| 13:47.57 | woglinde | florian hm query? |
| 13:50.33 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
| 13:58.23 | RP | pb_: Its used to place binaries generated by target packages which are safe to run on the build (native) system |
| 13:58.40 | RP | pb_: binconfig scripts are one example, there are others |
| 13:59.18 | RP | pb_: It presents an interesting dilemma for the staging packages as in thery target packages should be 32/64 bit agnostic for example |
| 13:59.30 | RP | s/thery/theory/ |
| 13:59.54 | RP | and STAGING_BINDIR_CROSS "binaries" can currently be actual binaries |
| 14:00.30 | pb_ | RP: ah, right, I see. so yeah, I would say that those belong in the native sysroot. If they are intended to run on the build host but they are in some way specific to the target system, then they should go in staging/BUILD_SYS/TARGET_SYS/ or some such. |
| 14:00.39 | pb_ | the latter is what binutils naturally does with things like the target "as" |
| 14:00.51 | *** join/#oe GNUtoo (~GNUtoo@host78-158-dynamic.54-79-r.retail.telecomitalia.it) |
| 14:00.53 | pb_ | er, cross "as" that is |
| 14:02.35 | RP | pb_: Currently we put them in BUILD_SYS/TARGET_SYS/ in the native sysroot as you mention |
| 14:02.36 | *** join/#oe fraxinas (~quassel@cl-2561.ham-01.de.sixxs.net) |
| 14:02.55 | RP | pb_: The problem is the package is then build system specific |
| 14:03.17 | RP | and touches two different sysroots :/ |
| 14:03.30 | pb_ | yeah, I see what you mean. |
| 14:03.44 | pb_ | how many packages are there that actually have this issue? It is tempting to say that we should just try to eliminate them. |
| 14:04.10 | RP | pb_: 50 in my usual builds of 600 recipes maybe? |
| 14:04.15 | RP | Just a guess mind... |
| 14:04.23 | pb_ | and of those 50, do you know how many are actual binaries rather than binconfig scripts? |
| 14:04.38 | RP | we only have a small number of actual binaries I think |
| 14:04.38 | pb_ | I guess I should run a build and find out for myself. |
| 14:05.03 | RP | Most are scripts, thankfully |
| 14:05.35 | RP | Ripping out some of the configure scripts would actually be nice |
| 14:05.40 | RP | er, binconfig scripts |
| 14:05.52 | RP | That was a Freudian slip :) |
| 14:05.53 | pb_ | for the ones that are really binaries, I suppose the "right" answer would be to make a separate foo-utils-native package to build those binaries. |
| 14:06.07 | RP | pb_: Probably, yes |
| 14:06.21 | pb_ | if it's only a small number of packages then that might not be too awful to arrange. |
| 14:06.40 | pb_ | for the binconfig bits, those are a bit less toxic to start with but in theory most/all of them could be replaced with a suitable pkg-config arrangement. |
| 14:06.53 | pb_ | maybe even in an automated way, I suppose |
| 14:07.02 | RP | pb_: Most of the binconfig providers also have .pc files now and we'd just have to make sure all the users were happy with .pc files |
| 14:07.28 | XorA | luckilly PKG_CHECK_MODULES is real easy to add to configure.in |
| 14:07.43 | RP | XorA: right. and much less error prone |
| 14:08.15 | RP | has tested the latest pkgconfig from git and made sure the next release will support sysroots correctly |
| 14:08.16 | pb_ | RP: right, that sounds like it should be easy enough. and, if that proves intractable, I think one could write a little stub script which translates "foo-config --libs" into "pkg-config --libs foo" easily enough. |
| 14:08.41 | RP | pb_: Its even something we could push at upstream |
| 14:08.53 | pb_ | yeah |
| 14:09.04 | pb_ | -> meeting |
| 14:09.05 | pb_ | bbl |
| 14:09.05 | *** join/#oe aloisiojr (~aloisio@200.184.118.130) |
| 14:12.10 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 14:13.16 | ant_work | ehm..sorry for the strange question: is it possible to run qemu on an arm machine and emulate x86, isn't? |
| 14:13.37 | XorA | yes |
| 14:14.30 | hrw | http://marcin.juszkiewicz.com.pl/2010/02/08/fosdem-x/ |
| 14:16.06 | ant_work | XorA: would you imagine testing the boot of some x86 BIOS images on arm? |
| 14:16.33 | hrw | ant_work: qemu uses bochs bios |
| 14:16.54 | kergoth | hrw: nice post |
| 14:17.22 | hrw | kergoth: thx |
| 14:17.53 | XorA | thanks hrw |
| 14:17.59 | kergoth | minix 3 looks like it could be fun to play with, just for fun |
| 14:18.09 | kergoth | i don't know that i'd actually use it for anything, but.. |
| 14:18.44 | hrw | pushed few languages fixes |
| 14:19.10 | zecke | kergoth: hehe, is this not a bit late? |
| 14:19.27 | hrw | kergoth: I am thinking about fetching usb version just to check it on my machine. will probably nearly not work but worth check |
| 14:19.46 | kergoth | i grabbed the iso, figured I'd see if it boots in vmware fusion |
| 14:20.07 | kergoth | actually, should poke around its kernel, probably easier to grasp in its entirety than the Linux one |
| 14:20.09 | kergoth | heh |
| 14:28.38 | ant_work | hrw: thx. Do you think one could test own bios images? |
| 14:29.48 | hrw | rather not |
| 14:31.55 | toi | hrw: you shouldn't be worried about me knowing you better as you know me :) |
| 14:35.51 | hrw | toi: ;D |
| 14:36.45 | toi | You can not really know me because I'm not an OE developer. |
| 14:37.30 | toi | But I follow OE already from the days of oemae/oebuild, so thats why I always (try to) make the joke |
| 14:38.09 | toi | Real life and other projects keep me away from doing embedded stuff, but one day... |
| 14:38.17 | hrw | mkey |
| 14:38.26 | toi | So no worries :) |
| 14:38.46 | toi | But I will buy you a beer next year to make up! |
| 14:43.29 | *** join/#oe ctusar (~ctusar@router2.videon-central.net) |
| 14:43.33 | *** join/#oe dth (~dieter@p4FDEAA6E.dip.t-dialin.net) |
| 14:49.02 | CIA-85 | 03Thomas Zimmermann <ml@vdm-design.de> 07org.openembedded.dev * rb165d5c23e 10openembedded.git/recipes/evopedia/evopedia_git.bb: |
| 14:49.02 | CIA-85 | evopedia: new recipe |
| 14:49.02 | CIA-85 | * evopedia is an offline wikipedia viewer |
| 14:49.02 | CIA-85 | Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de> |
| 14:49.23 | kergoth | hmm, oe-bakery looks interesting |
| 15:00.39 | Laibsch | sends a friendly Hello to toi |
| 15:01.11 | toi | Hi Laibsch :) |
| 15:01.51 | toi | Possibly we have met, but I can't put a face on the name atm, too much people in so little time... |
| 15:02.25 | toi | Brain is still much in recovery mode for now. |
| 15:08.06 | XorA | the amount of alcohols consumed at FOSDEM normally effects memories |
| 15:09.53 | toi | XorA: Only had 1 beer during the whole event, so that's not the problem, lack of sleep is... |
| 15:10.41 | toi | And manning the info desk for almost 2 whole days drains a lot of energy. But is totally worth every second of it :) |
| 15:11.37 | toi | But the beer event was indeed again enormous, seems there where about 1100 people (countesd by the security). |
| 15:11.50 | XorA | heh |
| 15:12.13 | XorA | prefers the other Delirium bar |
| 15:12.23 | ynezz | good name |
| 15:12.40 | *** join/#oe Laibsch1 (~Laibsch@184.121.113.82.net.de.o2.com) |
| 15:12.54 | Laibsch1 | toi: wallet |
| 15:13.19 | toi | wallet? |
| 15:14.24 | GNUtoo | no alchool either(I prefer to see things cleanly,and it sometimes gives me headaches) but lack of sleep didn't help |
| 15:15.09 | XorA | there is pictures of me recovering from rum last year :-D |
| 15:15.14 | GNUtoo | lol |
| 15:19.04 | *** join/#oe sudharsh (~sudharsh@unaffiliated/sudharsh) |
| 15:19.25 | Crofton|work | http://www.flickr.com/photos/32615155@N00/3260848665/ |
| 15:20.39 | GNUtoo | lol |
| 15:21.05 | toi | lol indeed. |
| 15:21.24 | toi | Don't worry, you're not the only one :) |
| 15:21.33 | *** join/#oe Sup3rkiddo (~sudharsh@unaffiliated/sudharsh) |
| 15:22.14 | toi | People arrive friday to not miss the saturday morning, but are to late anyway because of the beer event :) |
| 15:22.28 | toi | But it's more fun for sure. |
| 15:22.33 | GNUtoo | lol ok |
| 15:22.43 | *** join/#oe FOM (~jeffs@rrcs-74-219-98-111.central.biz.rr.com) |
| 15:25.00 | XorA | I was physically on time |
| 15:27.41 | *** join/#oe hrw (~hrw@chello089078170228.chello.pl) |
| 15:36.43 | ynezz | :D |
| 15:44.08 | *** join/#oe willer_ (~willer@189.2.128.130) |
| 15:57.38 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 16:01.15 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 16:01.53 | *** join/#oe dcordes (~dccordes@unaffiliated/dcordes) |
| 16:02.12 | mckoan | GNUtoo: :-D |
| 16:03.29 | *** join/#oe kristoffer_ (~kristoffe@94.191.150.179.bredband.tre.se) |
| 16:06.00 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 16:06.58 | *** join/#oe sgh_ (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 16:15.58 | *** join/#oe dth (~Dieter@p4FDEAA6E.dip.t-dialin.net) |
| 16:15.59 | *** join/#oe recalcati (~5e51e963@gateway/web/freenode/x-ftjxoefyasatsokf) |
| 16:20.38 | recalcati | g.m. |
| 16:21.13 | recalcati | thx to FOSDEM ! |
| 16:21.58 | *** join/#oe ZaPPaS (~moritz@weinberg.pi5.physik.uni-stuttgart.de) |
| 16:22.55 | florian | hi recalcati |
| 16:23.23 | *** join/#oe ZaPPaS (~moritz@weinberg.pi5.physik.uni-stuttgart.de) |
| 16:23.33 | recalcati | hi florian. I'm back to real world |
| 16:23.55 | *** part/#oe XorA (~XorA@www.xora.org.uk) |
| 16:24.18 | florian | too... trying to play with a new toy and making customers happy at the same time |
| 16:24.48 | recalcati | ** right, I'm trying to do impossible things |
| 16:27.53 | mckoan | recalcati: hi, was your trip home well? |
| 16:28.21 | GNUtoo | recalcati, impossible things? such as cross-compile openoffice? |
| 16:28.33 | woglinde | gnutoo hm |
| 16:28.36 | GNUtoo | lol |
| 16:28.41 | woglinde | touchbook has openoffice 3.0 |
| 16:28.45 | GNUtoo | yes I know |
| 16:28.52 | GNUtoo | I also know how they built it |
| 16:28.54 | woglinde | somehow compiled with gentoo |
| 16:28.59 | GNUtoo | qemu...+ chroot |
| 16:29.00 | woglinde | hm oh? |
| 16:29.01 | woglinde | lol |
| 16:29.39 | GNUtoo | 1 week of compilation |
| 16:29.44 | woglinde | lol |
| 16:30.02 | GNUtoo | I bet if I do it this way...maybe I'll have to compile for one month because of slow build computer |
| 16:31.03 | GNUtoo | woglinde, anyway I decided against buying touchbook because some people(tuxbrain) told me that it was not solid/good quality product |
| 16:32.24 | pb_ | RP: fwiw, I pushed the bits that I have been playing with to http://git.openembedded.org/cgit.cgi/openembedded/log/?h=pb/toolchain-desuck |
| 16:32.34 | GNUtoo | but I think I still want openoffice under my eeepc701 |
| 16:32.34 | woglinde | gnutoo hm yes partly |
| 16:32.43 | woglinde | gnutoo we have one here now |
| 16:32.51 | GNUtoo | ok |
| 16:33.17 | GNUtoo | and it seem easy to accidentaly break? like when beeing in a travel bag and traveling? |
| 16:33.35 | *** join/#oe hrw (~hrw@chello089078170228.chello.pl) |
| 16:33.40 | pb_ | meeting again now |
| 16:33.45 | GNUtoo | but I bet I'll find another arm netbook that permit to run angstrom |
| 16:34.14 | recalcati | mckoan: very well. two leffe blonde at airport!!! |
| 16:34.34 | recalcati | GNUtoo: as doing what I'm doing ... clear? |
| 16:35.07 | GNUtoo | mmm |
| 16:35.17 | recalcati | and also create a new develop in OE without knowing enough it |
| 16:36.37 | kergoth | ooh, toolchain-desuck, that sounds nice |
| 16:36.38 | recalcati | but doing something else in the same time |
| 16:38.00 | GNUtoo | ok |
| 16:39.17 | *** join/#oe guillaum1 (~gl@AMontsouris-153-1-50-243.w86-212.abo.wanadoo.fr) |
| 16:41.21 | *** join/#oe pb__ (~pb@castle.reciva.com) |
| 16:41.29 | mckoan | recalcati: me too LOL |
| 16:41.52 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 16:42.17 | mckoan | recalcati: the smoothest flight I've ever done :-D |
| 16:45.03 | CIA-85 | 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * re69880e5c9 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: |
| 16:45.03 | CIA-85 | sane-srcrevs-fso.inc: bump rev of libframeworkd-glib |
| 16:45.03 | CIA-85 | Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de> |
| 16:59.43 | recalcati | I slept perfectly ... and then I saw malpensa, the foggiest airport in the world |
| 16:59.59 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 17:01.43 | *** join/#oe likewise (~likewise@82-171-51-231.ip.telfort.nl) |
| 17:04.44 | *** join/#oe thaytan (~jan@192.18.41.196) |
| 17:08.34 | mckoan | have a nice rest of the day |
| 17:12.52 | *** join/#oe XorA (~XorA@www.xora.org.uk) |
| 17:15.44 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 17:17.29 | woglinde | jo khem |
| 17:17.57 | RP__ | pb_: Interesting. That actually packages the toolchain bits ok? |
| 17:19.10 | *** part/#oe thebohemian (~rschus@p5DDC5ACB.dip.t-dialin.net) |
| 17:19.49 | kergoth | wtf.. screen -r doesn't work to join the screen session spawned by devshell under cygwin |
| 17:19.52 | kergoth | does nothing |
| 17:19.54 | kergoth | weird. |
| 17:21.02 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 17:22.12 | khem | hi woglinde |
| 17:22.44 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 17:24.14 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 17:30.25 | blindvt | woglinde, hi |
| 17:30.35 | woglinde | hi blinder |
| 17:39.19 | hrw | -> off |
| 17:46.28 | *** join/#oe marcosmamorim (~marcos@201-92-134-222.dsl.telesp.net.br) |
| 17:52.06 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 18:01.33 | blindvt | doesn't bitbake have a facility to error out on non-applied patches? say foo-0.8.15/barf.patch isn't applied but in the tree, barf? I'd guess that this could (potentially, didn't try) cut off 10% of the whole repo, no? |
| 18:02.34 | blindvt | s/repo/oe repo/ |
| 18:06.46 | *** join/#oe marcosmamorim (~marcos@201-43-36-61.dsl.telesp.net.br) |
| 18:08.39 | *** join/#oe dvermd (~roudoudou@78.234.93.192) |
| 18:12.25 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 18:17.36 | *** join/#oe sgh_ (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 18:20.38 | kergoth | blindvt: uh, bitbake doesn't magically know about patches that aren't listed in SRC_URI |
| 18:21.22 | khem | blindvt: and sometimes overrides apply patches selectively from a dir too |
| 18:22.11 | khem | blindvt: I know you want to get rid of unused patches :) |
| 18:22.12 | khem | is using ssl connection to freenode now |
| 18:22.34 | zecke | khem: ssl? how? |
| 18:23.11 | *** join/#oe eFfeM1 (~frans@j200125.upc-j.chello.nl) |
| 18:23.23 | kergoth | zecke: port 7000 |
| 18:23.29 | kergoth | they mentioned it in the blog posts about the new ircd |
| 18:23.37 | kergoth | is connected that way now too |
| 18:26.47 | khem | yes or port 7070 |
| 18:27.18 | khem | anybody who uses irssi I can help :) |
| 18:27.55 | blindvt | kergoth, i was thinking about a post-parser. Parse .bb and barf on anything not in SRC_URI |
| 18:28.04 | kergoth | but that doesn't make any sense. |
| 18:28.08 | kergoth | FILESPATH includes any number of locations |
| 18:28.13 | kergoth | some of which apply to multiple recipes |
| 18:28.28 | kergoth | you'd have to parse every recipe, gather a list of every patch everything refers to, then gather a list of every patch in the reposiitory and compare the two |
| 18:28.28 | blindvt | kergoth, and some of which are never applied |
| 18:28.36 | kergoth | possible, yes, but its not a per recipe thing |
| 18:28.41 | kergoth | yes, no shit |
| 18:28.42 | blindvt | indeed |
| 18:28.44 | khem | blindvt: its as complex as gcc's unused variable warning trust me |
| 18:29.25 | kergoth | you're right, I'm sure it is worthwhile, just not entirely trivial |
| 18:29.49 | blindvt | khem, i've written a use-counter for gcc decls, and it wasn't _that_ hard ;) |
| 18:29.54 | kergoth | also, there are patches which aren't named .diff/.patch, you'd likely have to see if 'file' can identify them |
| 18:30.01 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 18:30.08 | *** join/#oe pb__ (~pb@85.210.8.8) |
| 18:30.49 | khem | blindvt: decl is different unused/unintialized variables is different 10 out of 100 times gcc is wrongly warning about somethinhg |
| 18:30.53 | blindvt | kergoth, i understand, sure. I just think that there is some cruft accumulated over time, and it really hurts anybody, not only, let's say modem-users |
| 18:31.03 | blindvt | khem, see set but not used PR |
| 18:31.06 | kergoth | it doesn't hurt anyone. |
| 18:31.14 | kergoth | a clone will still pull down that data |
| 18:31.21 | kergoth | due to the history in the git repository |
| 18:31.26 | kergoth | the only difference will be local space in the checkout |
| 18:31.26 | khem | yeah true |
| 18:31.29 | kergoth | trivial |
| 18:31.52 | blindvt | kergoth, it hurts folks who are bandwidth limited (and yes, only clone but particularly hard on that one) |
| 18:31.58 | kergoth | no |
| 18:31.59 | pb__ | RP: mostly, yeah. the toolchain bits seem to come out with the wrong PACKAGE_ARCH, for reasons I haven't yet fully determined, and I haven't exactly tested the packages in great detail, but they seem to be basically correct. |
| 18:32.04 | kergoth | you can't reduce the amount of shit a clone pulls |
| 18:32.11 | pb__ | rp |
| 18:32.14 | kergoth | removing it from the head branch doesn't remove the objects from the repository |
| 18:32.19 | kergoth | so it DOES NOT benefit modem users |
| 18:32.24 | kergoth | it has zero effect |
| 18:32.26 | pb__ | RP: the resulting sysroot tree does seem to work for compiling things against, at least. |
| 18:32.58 | khem | pb__: it is about do_install and do_stage integration ? |
| 18:33.16 | pb__ | RP: oh, I know there is one outstanding issue with things like libgcc1, which don't currently get packaged correctly with those changes. per what I wrote on the mailing list the other day, I think the right way to deal with that is to have a separate recipe which builds (just) the gcc runtime for the target. |
| 18:33.47 | blindvt | kergoth, for initial cloners it does make a difference if you clone like 659M or 10% less, but ok. Non-issue for well-connected core |
| 18:33.47 | kergoth | what? |
| 18:33.52 | kergoth | it will always be the same |
| 18:34.01 | blindvt | kergoth, --depth=1 |
| 18:34.19 | kergoth | thats a tiny, tiny portion of the userbase |
| 18:34.24 | kergoth | again, trivial |
| 18:34.30 | khem | blindvt: you get everything with a clone even once there now deleted files |
| 18:34.31 | blindvt | okok |
| 18:34.41 | kergoth | he's talking about shallow clones |
| 18:34.47 | kergoth | i don't think I've ever talked to anyone that's done one |
| 18:34.49 | kergoth | i certainly haven't |
| 18:35.00 | khem | oh --depth=` |
| 18:35.08 | khem | hmmm interesting |
| 18:36.22 | blindvt | khem, kergoth, i back out on the bandwidth and disk-footprint. Not relevant ATM |
| 18:36.25 | kergoth | like i said before, I'm sure its worthwhile, but i don't think we should overstate the benefits, either. bandwidth and disk are both cheap, and it only reduces the bandwidth for shallow cloners. |
| 18:38.16 | blindvt | let's see if RP or somebody else applies any of the two trivial or two "but, but.." patches to bb |) |
| 18:39.51 | kergoth | fights cygwin some more |
| 18:41.03 | blindvt | kergoth, my sympathy ;) |
| 18:41.12 | kergoth | I'm clearly a glutton for punishment |
| 18:41.45 | *** join/#oe B_Lizzard (~havoc@athedsl-427291.home.otenet.gr) |
| 18:43.35 | *** join/#oe soltys (soltys@soltys.soad.pl) |
| 18:46.23 | *** join/#oe stefan_schmidt (~stefan@p5B033F8B.dip.t-dialin.net) |
| 18:46.24 | blindvt | kergoth, in contrast. you're keeping the bridge alive which is as cumbersome as worthwhile. fore! |
| 18:46.49 | kergoth | heh. well, there's a definite need for windows support of some kind, so what the hell |
| 18:47.51 | *** join/#oe Martin-B (~martin@pool-233-65-198-89.dbd-ipconnect.net) |
| 18:48.20 | blindvt | indeed, i suppose there is :) |
| 18:51.37 | eFfeM1 | in a bbclass file is there a way to enable bb.debug for that function only ? |
| 18:52.00 | *** join/#oe robtow (~robtow@dsl092-218-034.sfo2.dsl.speakeasy.net) |
| 18:52.20 | otavio | When stable will be branched? |
| 18:52.34 | woglinde | otavio ask the TSC |
| 18:52.41 | eFfeM1 | or change the bb.debug into something that will echo |
| 18:54.29 | eFfeM1 | nevermind went for -D will weed out the junk |
| 18:57.12 | pb__ | khem: yeah |
| 19:02.04 | blindvt | khem, as you may have read, busybox restructure downloads yesterday. Would you (eventually) accept xz handling, updated busybox paths, md5sum, sha256 sums and toggle to .bz2 for busybox? |
| 19:02.24 | blindvt | khem, via ML, that is |
| 19:02.47 | blindvt | restructured even |
| 19:08.04 | *** join/#oe mickeyl (~mickey@80.81.242.146) |
| 19:08.32 | *** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey) |
| 19:09.48 | woglinde | so tschau |
| 19:10.59 | mickeyl | hrw|gone: i have tab completion for mdbus2 ! |
| 19:11.03 | mickeyl | hrw|gone: you will love it |
| 19:11.19 | mickeyl | took me the whole train ride from BRU to FRA |
| 19:13.53 | blindvt | btw.. ASSUME_PROVIDED.. is there a facility (that i manage to miss, apparently) that goes like "which foo || type -p foo || foo-native" with, perhaps, a minimum required version? |
| 19:14.21 | kergoth | no such facility exists. you'd also have to differentiate between the patched and unpatched natives |
| 19:14.25 | kergoth | would be nice, though |
| 19:15.25 | blindvt | i find myself in dependency loops concerned about git/{busybox,coreutils}/libtool/{xz,bunzip,...decompressors} and other heck like that which i didn't expect from something like oe 8) |
| 19:16.22 | blindvt | kergoth, mhm. i see |
| 19:20.44 | blindvt | kergoth, boils down to configure-like checks i fear. But get_assumed(package=None, version=None) would be a good start, imho |
| 19:21.54 | kergoth | that's why we avoided it from the beginning, didn't want to take on the whole 'running tests' thing the way autoconf does from a scope standpoint.. but it'd be nice |
| 19:23.13 | blindvt | nods kergoth |
| 19:23.24 | pb__ | kergoth: yeah, you could imagine a script (perhaps even an autoconf-generated script) which would test your build host and output a suitable .conf file containing a bunch of ASSUME_PROVIDED lines. |
| 19:23.38 | pb__ | might be a neat project for someone |
| 19:24.04 | pb__ | waits patiently for his 19:00 appointment to show up |
| 19:24.06 | blindvt | at least a rudimentary checker for versions (i.e. no runtime-tests) would be of tremendous help for me |
| 19:25.46 | *** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning) |
| 19:25.59 | hrw|gone | mickeyl: git url please |
| 19:29.49 | mickeyl | bitbake mickeydbus2 |
| 19:29.51 | mickeyl | ;) |
| 19:30.00 | mickeyl | http://git.freesmartphone.org/?p=cornucopia.git;a=tree;f=tools/mdbus2;h=75294ec89c55a112f598eae18edfe3669230847f;hb=507a51ea045d0fd2ee717e501a19ac624798e951 |
| 19:30.28 | ynezz | Is it safe to switch to different git branch while building another one? |
| 19:30.28 | mickeyl | some things still missing, but you can already enjoy |
| 19:30.39 | hrw|gone | mickeyl: th |
| 19:30.39 | hrw|gone | x |
| 19:31.54 | hrw|gone | ynezz: no |
| 19:32.19 | blindvt | ynezz, i wouldn't do it unless you're really sure that you don't change stuff under self |
| 19:32.35 | ynezz | recipes are parsed so what can happen? |
| 19:32.52 | ynezz | I mean, I'm building org.openembedded.dev |
| 19:32.57 | hrw|gone | -> off |
| 19:33.00 | blindvt | ynezz, patches, new versions, classes changes. Put short.. alot |
| 19:33.04 | ynezz | git branch fix org.oe.dev |
| 19:33.07 | ynezz | git checkout fix |
| 19:33.26 | ynezz | vim something.bb; git commit... |
| 19:33.47 | ynezz | this should be safe, right? |
| 19:35.43 | ynezz | blindvt: ok, I understand what you mean |
| 19:42.07 | *** join/#oe hansdampf (~moritz@rgnb-4d04b027.pool.mediaWays.net) |
| 19:51.25 | eFfeM1 | RP__, all noticed another issue with packaged staging (ok ant_work did, but I am analysing it) |
| 19:52.21 | Tartarus | Anyone around that's used the external-toolchain stuff? |
| 19:52.31 | eFfeM1 | when restoring packages that have BBCLASSEXTEND="native" in the recipe, packaged staging complaind, with -D -D it says: |
| 19:52.40 | *** join/#oe hrw|gone (~hrw@chello089078170228.chello.pl) |
| 19:52.55 | eFfeM1 | DEBUG: Checking /home/frans/oe/tmp_angstrom/stamps/i686-linux/gettext-native-0.17-r5.do_fetch |
| 19:52.55 | eFfeM1 | DEBUG: Result None |
| 19:52.55 | eFfeM1 | NOTE: Staging package found but invalid for /home/frans/oe/openembedded/recipes/gettext/gettext_0.17.bb |
| 19:52.55 | eFfeM1 | Done. |
| 19:53.30 | eFfeM1 | anyone an idea? |
| 19:53.37 | Tartarus | Kinda.. |
| 19:53.49 | eFfeM1 | Tartarus: shoot :-) |
| 19:53.55 | Tartarus | Well, thinking how to phrase it |
| 19:54.05 | Tartarus | That error msg means that some stamp file was found, but not deemed OK |
| 19:54.33 | Tartarus | That said, I'd swear it works here |
| 19:54.42 | Tartarus | But I can't quickly check, got a buncha other builds going |
| 19:54.50 | eFfeM1 | the NOTE line gives the name of the recipe but we are restoring a -native package |
| 19:55.08 | Tartarus | Yeah |
| 19:55.14 | Tartarus | print is for recipe used, not PN |
| 19:55.15 | eFfeM1 | for "classic" native packages (without BBCLASSEXTEND) it works fine |
| 19:55.35 | Tartarus | Does it work fine the second time? |
| 19:55.42 | eFfeM1 | will try |
| 19:55.42 | Tartarus | Or every time, does it decide to rebuild |
| 19:55.53 | Tartarus | I'd imagine that changing to that, yes, you need to make a new cache |
| 19:55.57 | Tartarus | Since that changes a few things around |
| 19:56.09 | GNUtoo | eFfeM1, compiling for eeepc701? |
| 19:56.17 | eFfeM1 | GNUtoo: no this is for beagle |
| 19:56.20 | GNUtoo | ok |
| 19:56.26 | GNUtoo | ah indeed |
| 19:56.43 | GNUtoo | i686-linux not i686-angstrom-something |
| 19:58.34 | eFfeM1 | Tartarus: trying to build a 2nd time, expect it to go ok as it has now rebuild the package and it is in the work/i686-linux dir |
| 19:59.02 | *** join/#oe rednul_ (~rednul@host-69-145-170-110.bln-mt.client.bresnan.net) |
| 20:00.20 | Tartarus | yeah, then try a new just caches test |
| 20:00.22 | Tartarus | Should be OK |
| 20:00.40 | Tartarus | wonders if external-toolchain* really expects the user to modify PATH outside of OE... |
| 20:03.25 | kergoth | this is very odd. the cvs fetcher errors out saying gzip doesn't exist, from the tar.gz process run by bb.fetch.. yet a tar -czf worksf ine outside of bitbake, and even works fine in a devshell |
| 20:03.28 | kergoth | scratches head |
| 20:03.33 | kergoth | time to compare environments, i guess |
| 20:03.48 | Tartarus | kergoth: ubuntu? |
| 20:04.01 | eFfeM1 | what do you mean with a new just caches? do you expect it to go ok now (after i rebuild a 2nd time ?) |
| 20:04.01 | kergoth | naw, still screwing around with cygwin. weird behavior, though |
| 20:04.05 | Tartarus | Ah, hmm |
| 20:04.18 | Tartarus | Er, yeah, not found, not the pipe thing |
| 20:04.38 | Tartarus | eFfeM1, yes, I expect that now a valid cache would be found |
| 20:05.05 | Tartarus | kergoth, have you used the external-toolchain stuff denix pushed? :) |
| 20:05.28 | kergoth | not yet, i need to sit down and spend more quality time with external-toolchain in general, haven't messed with it much |
| 20:05.34 | Tartarus | k |
| 20:05.39 | kergoth | adds to his todo for this week |
| 20:05.45 | Tartarus | heh |
| 20:05.59 | Tartarus | Seems to be pretty OK, just doesn't automatically add to PATH |
| 20:25.42 | Tartarus | Ah good, PATH_prepend := adds it in like I want |
| 20:25.47 | RP__ | Tartarus: It can add to PATH, I'm sure at least something in poky does |
| 20:26.13 | RP__ | Tartarus: you shouldn't need := |
| 20:29.18 | Tartarus | hmm, checking |
| 20:30.40 | *** join/#oe woglinde (~heinold@g225072075.adsl.alicedsl.de) |
| 20:30.42 | woglinde | re |
| 20:31.57 | RP__ | Tartarus: I think there is already a PATH_prepend in bitbake.conf so you may want .= or something similar. I can't remember whether mutiple _prepends stack or not :/ |
| 20:32.03 | Tartarus | also worked |
| 20:32.11 | Tartarus | yeah, it's stacking |
| 20:32.14 | RP__ | Tartarus: cool :) |
| 20:32.17 | Tartarus | .= is what i was thinking i wanted, heh |
| 20:34.50 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:37.13 | florian | re |
| 20:37.58 | *** join/#oe zecke (~ich@92.116.199.44) |
| 20:47.01 | tharvey | anyone know why 2.6.31/32 is not preferred for overo/beagle? |
| 20:47.20 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 20:47.53 | Crofton|work | no one has made one for Angstrom that supports the dsp/sgx demos? |
| 20:48.25 | woglinde | crofton hm? |
| 20:48.48 | woglinde | ti breaks wit the next hardware the dsp api again |
| 20:48.48 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 20:48.55 | Crofton|work | not sure |
| 20:49.11 | Crofton|work | I suspect because the one we have works :) |
| 20:50.11 | tharvey | thats fair... |
| 20:50.22 | woglinde | crofton I was at the dsp talk at fosdem |
| 20:50.29 | Crofton|work | how was that? |
| 20:50.32 | woglinde | that was the only new think I got out of it |
| 20:50.44 | Crofton|work | any idea if anyone taped it? |
| 20:50.55 | woglinde | there were some cameras |
| 20:51.15 | woglinde | but he mostly talked about programming with dsp-bridge |
| 20:51.33 | Crofton|work | yeah |
| 20:51.59 | woglinde | I am personal likes dsp-link more |
| 20:52.14 | woglinde | but didnt programm something yet |
| 20:52.30 | Crofton|work | yeah |
| 20:52.35 | Crofton|work | I am in the smae boat |
| 20:52.57 | woglinde | but dsp-link will not hit main kernel tree |
| 20:53.21 | Crofton|work | this problem needs fixiing |
| 20:53.32 | woglinde | lol |
| 20:53.46 | woglinde | that problem is a minefield like poulsbo driver |
| 20:54.02 | Crofton|work | yeah |
| 20:54.15 | Crofton|work | I wish I was smart enough to figure it out |
| 21:00.35 | kergoth | hmmm |
| 21:00.51 | woglinde | kergoth yes? |
| 21:01.18 | woglinde | Crofton but the guy who held the talk, made *sigh* his own oe-overlay again |
| 21:02.30 | *** join/#oe fraxinas (~quassel@cl-2561.ham-01.de.sixxs.net) |
| 21:03.38 | kergoth | this gzip execution failure under cygwin is fucking weird. doesn't happen at a shell, even if i filter the same env vars out. hmm |
| 21:04.19 | woglinde | what? |
| 21:04.40 | woglinde | hm has cygwin now the new auth mechanism? |
| 21:04.48 | woglinde | which handles kerberos/AD right? |
| 21:05.12 | ynezz | :p |
| 21:07.35 | GNUtoo | woglinde, indeed(for problem with ploubseau and dsp-things) |
| 21:08.15 | GNUtoo | woglinde, do you have any infos on the license of dsp-link and the other that was not bridge on the dsp side? |
| 21:08.33 | eFfeM1 | Tartarus:when gettext-native gets rebuild and I remove the tmp dir again and then bitbake console-image again, the "invalid" error remains |
| 21:14.28 | pb__ | kergoth: very weird. same tar? |
| 21:14.57 | kergoth | there's no tar or gzip in tmp at all |
| 21:15.08 | kergoth | works fine in devshell |
| 21:15.10 | kergoth | scratches head |
| 21:15.11 | kergoth | NOTE: Update cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20050701 |
| 21:15.12 | kergoth | tar (child): gzip: Cannot exec: No such file or directory |
| 21:15.12 | kergoth | tar (child): Error is not recoverable: exiting now |
| 21:15.12 | kergoth | NOTE: Task failed: Fetch failed: config |
| 21:15.35 | kergoth | maybe its not gzip itself its not finding |
| 21:15.36 | pb__ | hm. cygwin, so no strace. bummer. |
| 21:15.44 | kergoth | guess it could be the directory its in went away, or something |
| 21:15.53 | kergoth | but i dont see why itd only happen under cygwin |
| 21:16.19 | woglinde | pb??? |
| 21:16.23 | woglinde | cygwin has strace |
| 21:16.26 | woglinde | I used it |
| 21:16.47 | pb__ | I think that message is diagnostic of not being able to find gzip. sounds like tar has a screwed-up $PATH or something. |
| 21:16.52 | pb__ | woglinde: oh, does it? very good |
| 21:16.57 | pb__ | in that case, kergoth just needs to use it :-) |
| 21:17.03 | kergoth | it's just an os.system() call from bitbake's python |
| 21:17.10 | kergoth | no mangling of any env vars other than the usual filtering |
| 21:17.14 | kergoth | heh, i'll try that |
| 21:17.36 | kergoth | course, in this case, there's no reason it couldn't just use tarfile.TarFile & friends, but.. :) |
| 21:18.13 | pb__ | heh |
| 21:18.15 | pb__ | true |
| 21:19.47 | pb__ | hrm, still can't figure out where my toolchain packages are getting this bogus PACKAGE_ARCH from |
| 21:19.50 | pb__ | stabs oe |
| 21:20.13 | pb__ | Packaged contents of gcc-cross-arm-oe-linux-uclibceabi into /home/pb/oe/build-qemuarm/tmp/deploy/ipk/armv5te/gcc-cross-arm-oe-linux-uclibceabi_4.4.2-r2.1_armv5te.ipk |
| 21:20.14 | pb__ | heh |
| 21:20.43 | woglinde | hm whats wrong? |
| 21:20.46 | woglinde | with this? |
| 21:20.55 | *** join/#oe ant__ (~andrea@host222-251-dynamic.9-87-r.retail.telecomitalia.it) |
| 21:24.32 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 21:25.39 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 21:35.16 | *** join/#oe GNUtoo|oeee (~GNUtoo@host56-48-dynamic.21-79-r.retail.telecomitalia.it) |
| 21:35.59 | *** join/#oe GNUtoo (~GNUtoo@host56-48-dynamic.21-79-r.retail.telecomitalia.it) |
| 21:42.32 | *** join/#oe denix0 (~denix@pool-71-251-51-225.washdc.east.verizon.net) |
| 21:46.58 | *** join/#oe zecke (~ich@109.250.222.12) |
| 21:49.29 | pb__ | woglinde: it should be _x86-64.ipk |
| 21:49.54 | pb__ | since it is a cross compiler, not a target-native compiler |
| 21:50.52 | woglinde | oh right |
| 21:51.20 | eFfeM1 | bedtime here, back tomorrow, stay well! |
| 21:51.26 | woglinde | nite effem |
| 21:55.04 | ant__ | oh eFfeM quit... |
| 21:55.26 | ant__ | this is the best msg of the serie ;) |
| 21:55.29 | ant__ | <PROTECTED> |
| 21:55.58 | ant__ | opkg = ko pkg |
| 22:00.12 | pb__ | yeah, opkg is teh suck |
| 22:00.43 | pb__ | I was a bit disappointed that nobody in the FOSDEM distro showdown session mentioned a better package manager as something that different projects could cooperate on :-} |
| 22:01.30 | Tartarus | pb__: yay for toolchain-desuck |
| 22:03.51 | *** join/#oe jolt (~jolt@p5B3DDCC3.dip.t-dialin.net) |
| 22:04.15 | pb__ | Tartarus: heh, yeah, it is surprising how much bogus stuff is lurking in those recipes. |
| 22:04.50 | pb__ | Tartarus: I might have a go at doing the $ORIGIN thing for gcc-cross as well. I take your point about it being slightly annoying to calculate the right relative paths for things like cc1, but it doesn't seem like that should be completely intractable. |
| 22:06.28 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 22:07.00 | RP__ | People have been doing $ORIGIN stuff? Is that on the OE list? |
| 22:08.01 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 22:08.08 | pb__ | RP__: I don't think anybody has actually been doing it, but Tartarus and I had a brief discussion (indeed on the list) about using that to make gcc more relocatable for hosts that don't ship libmpfr |
| 22:08.52 | RP__ | pb__: Its something I've been thinking about too... |
| 22:09.05 | pb__ | if I understand the issue correctly, you can't currently move the sysroot containing gcc on a non-libmpgr-equipped host, because then gcc stops being able to find its local copy of that library. |
| 22:09.31 | pb__ | but, it seems like a suitably constructed "--rpath $ORIGIN/../../.." kind of thing would fix that. |
| 22:10.31 | RP__ | pb__: Right. It would be lovely if we could get the compiler/linker to work that out for us... |
| 22:11.09 | Tartarus | pb__: Lemme point you at the patch for gcc |
| 22:11.24 | Tartarus | gcc/binutils suck due to the multiple reruns on configure |
| 22:11.40 | pb__ | RP__: yeah, that is an interesting idea. of course, the immediate problem with that is that the compiler doesn't know where you are going to install the binary, but I guess it could be given that information. |
| 22:11.51 | Tartarus | gcc-cross needs a few ..'s then staging/${host_arch}/... added |
| 22:11.55 | Tartarus | which is ugly, but fixes it |
| 22:12.41 | pb__ | Tartarus: you mean due to the cygnus configure arrangement with multiple subsidiary configures? |
| 22:12.52 | pb__ | afaik, they only run each configure script once each, though I could be wrong about that |
| 22:13.18 | RP__ | pb__: I think we could teach it some kind of sane assumptions... |
| 22:13.44 | *** join/#oe matgnt (~matthias@z0701.wist.uni-linz.ac.at) |
| 22:13.59 | Tartarus | pb__: Er, yes? sec... |
| 22:16.22 | khem | pb__: I dont have any gcc-cross in my deploy dir |
| 22:16.33 | pb__ | RP__: true, though in most of the cases where the sane assumptions would hold, I think "$ORIGIN/../lib" would probably be good enough |
| 22:17.08 | pb__ | i.e. you could do that statically without needing any help from gcc :-} |
| 22:17.08 | pb__ | khem: what branch are you on, .dev? |
| 22:17.12 | khem | yes |
| 22:17.24 | pb__ | yeah, this is only on the toolchain-desuck branch at the moment |
| 22:17.38 | Tartarus | ah |
| 22:17.41 | khem | oh |
| 22:17.43 | Tartarus | can't find the patch url yet |
| 22:17.57 | khem | pb__: what is all planned on that branch |
| 22:18.33 | pb__ | khem: ideally, what I want to achieve is making the toolchain bits all properly packageable, with no custom do_stage() methods. |
| 22:18.37 | Tartarus | OK, maybe I made it a patch |
| 22:18.38 | Tartarus | based on |
| 22:18.43 | Tartarus | http://sourceware.org/ml/binutils/2009-05/msg00252.html |
| 22:19.20 | pb__ | LDFLAGS="${LDFLAGS//\$ORIGIN/\\\\\$$\\\$$\\\\\$$\\\$\$ORIGIN}" |
| 22:19.21 | pb__ | hah |
| 22:19.34 | Tartarus | http://pastebin.com/m22698880 |
| 22:19.52 | Tartarus | That is what I had to do, to get gcc to use $ORIGIN in the end |
| 22:20.00 | Tartarus | ~curse whoever made $ORIGIN use a $ |
| 22:20.00 | ibot | May you be reincarnated as a Windows XP administrator, whoever made $ORIGIN use a $ ! |
| 22:20.10 | pb__ | Tartarus: cool, thanks |
| 22:20.17 | Tartarus | as-is works on binutils |
| 22:20.26 | Tartarus | but that's missing the magic bit for getting libmpfr from staging |
| 22:20.36 | *** join/#oe hrw|gone (~hrw@chello089078170228.chello.pl) |
| 22:20.42 | Tartarus | needs to poke folks about committing more frequently |
| 22:22.32 | Tartarus | I wonder if say CS just forces static link vs libmpfr & co or what |
| 22:22.32 | Tartarus | haven't bothered to ldd |
| 22:22.43 | pb__ | yeah, that'd be another option of course |
| 22:23.05 | RP__ | would like something we could roll over all the native packages |
| 22:23.07 | khem | Tartarus: put libmpc libgmp and libmpfr under gcc src tree during build |
| 22:23.09 | khem | thats it |
| 22:23.26 | Tartarus | RP__: All of the native packages is easy |
| 22:23.35 | Tartarus | it's just gcc/binutils that get that shit |
| 22:23.52 | Tartarus | khen, pb__, maybe we want to look at that then.. |
| 22:24.12 | khem | I do it for non OE builds here |
| 22:24.19 | khem | it works well and is less of a headache |
| 22:25.18 | RP__ | Tartarus: due to the extra directory level? This assumes everything ends up in usr/bin and needs libs from usr/lib? |
| 22:25.29 | Tartarus | http://pastebin.com/m6167f3e4 |
| 22:25.52 | Tartarus | catches everything else, except perl, and needs a python 2.6.x with a patch i think that is in .4 but not .2 |
| 22:26.02 | Tartarus | RP__: yes, there is an assumption about layout in these too |
| 22:26.43 | Tartarus | Could just kinda fake it and always do ../lib, ../../lib and ../../../lib |
| 22:26.49 | Tartarus | (and lib64 too?) |
| 22:26.58 | RP__ | Tartarus: hmm. This all seems rather evil :/ |
| 22:27.06 | Tartarus | RP__, yes, a little bit |
| 22:27.10 | khem | actually same problem can happen if you dont have zlib installed on the targeted host where the toolchain is relocated to |
| 22:27.14 | RP__ | Tartarus: for the gcc/binutils that might be a sane solution... |
| 22:27.17 | Tartarus | that said, staging/host-arch/lib is always empty, yes? |
| 22:27.40 | RP__ | Tartarus: Poky's sdk ships glibc and the dynamic loader now |
| 22:27.51 | Tartarus | RP__: gcc/binutils just get stuck being needing an evil patch :( |
| 22:28.01 | Tartarus | everything else is sane enough to obey global flags |
| 22:28.05 | Tartarus | RP__: That's, er, interesting |
| 22:28.13 | Tartarus | Why that over just LSB linking? |
| 22:29.02 | RP__ | Tartarus: I wanted to solve the incompatibilities once and for all... |
| 22:30.49 | Tartarus | Did you go the LSB route and still get bit? |
| 22:30.54 | Tartarus | That seems a tad excessive... |
| 22:31.16 | RP__ | Tartarus: It just turned out to be very simple to implement |
| 22:31.49 | RP__ | Tartarus: and meant you can do candian builds properly (32 and 64 bit sdks from the same build machine) |
| 22:32.02 | pb__ | yeah, that probably is an easier solution than trying to lean on LSB. not very pretty, but I can see it being attractive. |
| 22:32.05 | RP__ | Since you're shipping all the libs, I guess it doesn't matter mind :) |
| 22:32.23 | Tartarus | RP__: is that all relocatable too? |
| 22:32.25 | pb__ | of course, it's a bit of a disaster for non-linux build hosts, but then LSB doesn't help you there either so you are still no worse off. |
| 22:32.35 | *** join/#oe woglinde (~heinold@f052231055.adsl.alicedsl.de) |
| 22:32.52 | RP__ | Tartarus: No, but if OE has changes to make things reclocatable, this will be too if I merge them |
| 22:34.22 | Tartarus | RP__: It's pretty close right now |
| 22:34.27 | khem | it seems building toolchain statically is the better solution |
| 22:34.30 | *** join/#oe jmpdelos_ (~polk@outgoing.delos.com) |
| 22:34.41 | Tartarus | *-cross-sdk just needs to use $ORIGIN and binutils/gcc need that extra hell |
| 22:34.51 | Tartarus | or rebuild differently so the mpfr thing is a non-issue |
| 22:34.58 | RP__ | khem: This wasn't just for the toolchain, it was for other tools too |
| 22:35.46 | khem | We could package host tools |
| 22:36.06 | pb__ | RP: I don't think there is any good way to make your sysroot relocatable if you have a custom dynamic linker. Unless you wrap all your binaries in shell scripts of course. |
| 22:36.43 | pb__ | presumably, right now all your binaries have a hardwired PT_INTERP pointing to somewhere inside your sysroot. |
| 22:37.05 | khem | PT_INTERP should be appended to --sysroot= |
| 22:37.11 | khem | by ld |
| 22:37.16 | RP__ | pb__: That is indeed a potential problem |
| 22:37.29 | RP__ | pb__: It doesn't support $ORIGIN ? |
| 22:37.42 | pb__ | RP: no, ld.so is the thing that processes $ORIGIN :-) |
| 22:37.59 | pb__ | PT_INTERP itself is processed by the kernel, and I don't think it understands $ORIGIN at all. |
| 22:38.21 | pb__ | of course, you could hack it so that it did, but then your sdk would need to ship a custom kernel and I suspect that might be a bridge too far |
| 22:38.24 | RP__ | pb__: Thats what I was asking... |
| 22:38.40 | RP__ | pb__: A custom kernel is not on the agenda |
| 22:39.46 | pb__ | afaik, PT_INTERP can only be a simple absolute path. I don't think the gABI admits anything beyond that, and I am pretty sure the kernel just calls open() directly on the string it finds there. |
| 22:40.43 | RP__ | pb__: That sounds sane (unfortunately). |
| 22:40.50 | pb__ | doing the wrapper script thing would not be impossible, though, and I suspect that is probably your best option in this situation. |
| 22:40.59 | RP__ | wonders about a relative path |
| 22:42.18 | khem | hmm ORIGIN is interesting |
| 22:43.02 | pb__ | RP: I have a feeling that, if you put a relative path there, the kernel will just interpret it relative to the cwd of the exec()ing process rather than the location of the binary. |
| 22:53.12 | RP__ | pb__: Looking at the kernel code, I think you're right |
| 22:54.21 | *** join/#oe zecke (~ich@109.250.204.41) |
| 22:57.45 | khem | pb__: are you also going to move cross into the host staging area ? |
| 22:58.25 | pb__ | khem: yes |
| 22:58.37 | pb__ | in fact, that is already (mostly) done |
| 22:58.43 | khem | pb__: cool |
| 22:58.53 | pb__ | if you build from the branch, you should find there is no cross/ subdir anymore |
| 22:58.57 | khem | I should look at the branch |
| 23:01.40 | khem | pb__: I guess http://git.openembedded.org/cgit.cgi/openembedded/commit/?h=pb/toolchain-desuck&id=ebe7729f6d056b4de17342e5010f1cfe27f90546 is the reason for the bogus PACKAGE_ARCH |
| 23:03.12 | pb__ | no, actually, it's unrelated to that. it turns out that tune-arm926ejs.inc (for example) forces BASE_PACKAGE_ARCH to "armv5te", overriding the default of ${HOST_ARCH} |
| 23:03.47 | pb__ | so, that sucks, but it is fairly easy to work around it by just forcing {BASE_}PACKAGE_ARCH back to the right value in cross.bbclass |
| 23:04.36 | *** join/#oe Martin-B (~martin@pool-233-65-198-89.dbd-ipconnect.net) |
| 23:05.11 | pb__ | I still don't entirely understand what that deleted code in cross.bbclass was trying to accomplish, but I am fairly sure that we are better off without it. |
| 23:05.12 | *** join/#oe robtow (~robtow@dsl092-218-034.sfo2.dsl.speakeasy.net) |
| 23:06.15 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 23:06.17 | khem | I dont either but I think it was trying to use PACKAGE_ARCH = HOST_ARCH for cross packages and save original PACKAGE_ARCH |
| 23:08.12 | khem | mm I think it evaluates the current value of the variable with := and reassigns it |
| 23:08.28 | khem | right there |
| 23:08.49 | RP__ | its saving the original value and then forcing that value to remain |
| 23:09.13 | RP__ | We needed the value of HOST_ARCH before the class messed around with it. |
| 23:09.16 | khem | I guess the value is influenced by other parameters so it evaluates it as it goes |
| 23:09.30 | RP__ | I suspect I was even responsible for some of that :/ |
| 23:09.34 | khem | and saves it |
| 23:09.57 | khem | right RP:) |
| 23:10.32 | RP__ | Originally it was just PACKAGE_ARCH, then we had BASE_PACKAGE_ARCH to worry about too |
| 23:10.39 | khem | yeah |
| 23:10.59 | khem | pb__: that commit really is than the one which changes it for you |
| 23:12.06 | *** join/#oe Martin_B (~martin@pool-233-65-198-89.dbd-ipconnect.net) |
| 23:12.20 | RP__ | This was all stuff for mutlimachine. Changing PN looks like a nicer way to do it |
| 23:12.54 | RP__ | I'm not sure I'd bother with the horrible PROVIDES though |
| 23:14.08 | RP__ | pb__: That form of package name will also probably upset the BPN code which does things line PN.endswith("-cross") |
| 23:16.08 | pb__ | khem: no, I think you have it backwards. if that OLD_BASE_PACKAGE_ARCH thing was left in place, it would also cause me to get the wrong value. |
| 23:16.22 | pb__ | removing it is necessary, but not sufficient due to the tune-xx thing. |
| 23:16.47 | pb__ | RP__: ah, yeah, right. I will have a look at that in the morning and see what I can do about it. |
| 23:17.17 | pb__ | RP__: the most annoying thing about changing PN for the toolchain bits is that it breaks all the PREFERRED_PROVIDER rules in the .conf files. But I can't think of any good way to avoid that really. |
| 23:17.28 | Crofton|work | urg, off to home improvement store for supplies to work on plumbing, suspeted clogged pipe |
| 23:17.33 | Crofton|work | and store for beer |
| 23:18.24 | pb__ | horrible PROVIDES is just there for some measure of backwards compatibility. I suspect it is probably not necessary. |
| 23:18.44 | RP__ | pb__: Yes, I was wondering about that and I see what you mean about compatibility now. Hmm :/ |
| 23:19.04 | RP__ | pb__: It would be nice to take a step back and solve some of this properly |
| 23:19.29 | RP__ | rather than continually trying to retain compatibility and digging a deeper hole |
| 23:19.42 | RP__ | which is what I see packaged-staging as :/ |
| 23:20.17 | pb__ | yeah, I think I am on the point of throwing packaged-staging away and writing a new replacement for it from scratch. |
| 23:20.31 | pb__ | it doesn't really seem to solve my problems in a way that I want to have them solved :-} |
| 23:21.00 | RP__ | pb__: I hate the thing :( |
| 23:21.19 | RP__ | Its just what circumstances dictated was necessary |
| 23:21.45 | RP__ | pb__: but we also disagree on the package reuse thing :/ |
| 23:22.18 | kergoth | when i was experimenting with private staging, i combined the packaged-staging functionality with the sysroot/staging bits in base.bbclass, moved it all into a staging.bbclass, and pulled that in from base. probably a decent way to go for a replacement for the regular thing too |
| 23:22.21 | kergoth | heh |
| 23:23.02 | kergoth | aside: cygwin just keeps biting me in the ass with new and fun issues.. did you know that a 'install.exe' will fail to run due to lacking permissions unless its run via uac / administrator, just because it has "install" in the name? |
| 23:23.05 | RP__ | kergoth: It was always intended to merge it into base or similar... |
| 23:23.16 | RP__ | kergoth: scary :/ |
| 23:23.28 | kergoth | very.. gotta love silly heuristics based on executable name |
| 23:23.29 | kergoth | pukes |
| 23:23.35 | pb__ | kergoth: hah, cute |
| 23:23.40 | kergoth | the cygwin /usr/bin/install.exe has a /usr/bin/install.exe.manifest that says "i really don't want administrator, thanks" |
| 23:23.59 | kergoth | think i'll patch coreutils-native to automatically provide it when targeting cygwin.. |
| 23:24.01 | kergoth | shakes head |
| 23:25.34 | woglinde | *g* |
| 23:25.47 | pb__ | RP__: incidentally, it occurs to me that if you are going to end up wrapping your binaries anyway to solve the PT_INTERP thing, you can also handle the library path in the wrapper and not need to bother with $ORIGIN at all. might even be a better way of solving the problem, since you can do it as a single post-process step once all the binary paths are fixed. |
| 23:26.09 | pb__ | no need to guess at compile time where the binaries and libs are going to land relative to each other. |
| 23:26.42 | pb__ | and, no monster $$$$$$$$$$$$\\\\\\\$$$$$$$$$$$$$$$$$$$$$$$$$$$ style stuff in the makefile, which has got to be a win |
| 23:27.36 | *** join/#oe robtow (~robtow@dsl092-218-034.sfo2.dsl.speakeasy.net) |
| 23:27.36 | RP__ | pb__: I must admit that monster expression makes me feel ill |
| 23:29.48 | pb__ | yeah, I can't help wondering whether the next autoconf release will require you to add an extra backslash somewhere |
| 23:30.00 | pb__ | (or an extra ten backslashes, of course) |
| 23:30.03 | *** join/#oe bluelightning_ (~bluelight@pdpc/supporter/professional/bluelightning) |
| 23:30.46 | RP__ | pb__: or introduce a new character representing ten backslashes which needs to be specified in triplicate for correct expansion |
| 23:30.50 | woglinde | hi bluelightning |
| 23:30.56 | pb__ | heh, right, or that |
| 23:31.40 | pb__ | bedtime now |
| 23:31.41 | pb__ | night all |
| 23:32.09 | RP__ | 'night pb__ |
| 23:32.17 | woglinde | nite pb |
| 23:32.32 | RP__ | -> Zzzz too |
| 23:40.09 | *** part/#oe XorA (~XorA@www.xora.org.uk) |