| 00:08.53 | *** join/#oe jmpdelos (~polk@nat.haverhillcoop.net) |
| 00:18.04 | *** join/#oe jmpdelos (~polk@delos.delos.com) |
| 00:22.36 | *** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |
| 00:28.01 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 01:19.53 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
| 01:22.38 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 01:56.12 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 02:16.22 | *** join/#oe blindvt_ (~brf@85-127-87-161.dynamic.xdsl-line.inode.at) |
| 02:19.17 | *** join/#oe ensc_ (~irc-ensc@p4FEC7CE8.dip.t-dialin.net) |
| 03:05.36 | *** join/#oe devzero_ (devzero@xdsl-89-0-134-98.netcologne.de) |
| 03:06.48 | *** join/#oe Ironnads (~Ironnads@host109-152-247-70.range109-152.btcentralplus.com) |
| 03:32.49 | *** join/#oe galak (~galak@192.88.168.34) |
| 04:24.09 | *** join/#oe kenws (~ken@elliptique.net) |
| 04:47.13 | *** join/#oe erwt (~erwt@114.143.160.125) |
| 04:50.36 | *** join/#oe nitink (~nitink@192.55.55.39) |
| 05:00.59 | wmat | fixes oe wiki new user registration, hopefully |
| 05:41.13 | *** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |
| 05:45.48 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 06:17.05 | *** join/#oe reisei (~reisei@n41-as54-1-ppp206.nordnet.ru) |
| 06:25.23 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
| 06:25.45 | tasslehoff | readelf -d arm-angstrom-linux-gnueabi-gcc: http://pastebin.com/hMRGwtpH |
| 06:26.58 | tasslehoff | does the RPATH there explain why I have to extract my SDK to /usr/local? |
| 06:33.22 | tasslehoff | and: good morning |
| 06:35.02 | *** join/#oe HeinervdmWork (~zimmerman@hsaggate.physik.uni-bonn.de) |
| 06:48.58 | *** join/#oe JaMa (~martin@94.230.152.246) |
| 06:51.04 | *** join/#oe XorA (~XorA@188-220-34-37.zone11.bethere.co.uk) |
| 06:58.48 | ynezz | tasslehoff: I've never used SDKs, but I've seen quite patches for SDK relocation support on the list year or so ago |
| 06:59.16 | ynezz | tasslehoff: I think, that you can change the rpath with chrpath easily |
| 07:00.29 | ynezz | the question is if it's enough :p |
| 07:00.42 | tasslehoff | ynezz: ah. it's a start at least :) |
| 07:00.52 | tasslehoff | khem: ^ |
| 07:01.33 | ynezz | and it might be better to ask on the list |
| 07:05.42 | *** join/#oe DHR (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 07:07.03 | tasslehoff | ynezz: yeah. I'll post a question. |
| 07:22.03 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 07:28.17 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 07:41.12 | *** join/#oe zrafa (~rafa@186.137.0.13) |
| 07:42.29 | mckoan | good morning |
| 07:45.36 | *** join/#oe erwt (~erwt@114.143.160.125) |
| 07:48.08 | *** join/#oe likewise (~chatzilla@095-097-098-131.static.chello.nl) |
| 07:50.55 | *** join/#oe erwt (~erwt@114.143.160.125) |
| 07:52.05 | likewise | gm |
| 07:52.40 | *** join/#oe mr_nice (~guib@83-64-51-210.static.xdsl-line.inode.at) |
| 07:52.47 | *** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 07:52.50 | *** join/#oe mrmoku` (~mrmoku@ppp-188-174-98-230.dynamic.mnet-online.de) |
| 07:54.43 | *** join/#oe mrmoku (~mrmoku@ppp-188-174-98-230.dynamic.mnet-online.de) |
| 08:09.12 | *** join/#oe grma (~gruberm@ip-2-200-72-14.web.vodafone.de) |
| 08:12.55 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 08:17.13 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 08:17.14 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 08:18.05 | *** join/#oe stefan_schmidt (~stefan@2001:638:602:1183:f2de:f1ff:fe62:28f7) |
| 08:25.53 | *** join/#oe rschus (~rschus@253.163.71.86.rev.sfr.net) |
| 08:26.45 | *** join/#oe e-ffi (~cybercom@HSI-KBW-082-212-014-081.hsi.kabelbw.de) |
| 08:27.37 | eFfeM_work | hi likewise, mckoan, all |
| 08:28.05 | eFfeM_work | rstarting pidgin, biab |
| 08:28.10 | *** part/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 08:28.46 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 08:30.18 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 09:04.30 | Jin^eLD | mornin |
| 09:05.24 | *** join/#oe XorA (~XorA@188-220-34-37.zone11.bethere.co.uk) |
| 09:07.09 | *** join/#oe morphis (~morphis@dslb-088-071-179-155.pools.arcor-ip.net) |
| 09:10.40 | *** join/#oe kristoffer (~kristoffe@c-d8dae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 09:11.22 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 09:23.16 | *** join/#oe grma (~gruberm@ip-2-200-232-173.web.vodafone.de) |
| 09:32.09 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
| 09:35.18 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 09:36.44 | *** join/#oe pespin (~pespin@245.pool85-50-65.dynamic.orange.es) |
| 09:43.28 | *** join/#oe pespin (~pespin@245.pool85-50-65.dynamic.orange.es) |
| 09:45.44 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 09:46.26 | *** join/#oe lamikr (lamikr@nat/nokia/x-kglpkemblkrhqgxa) |
| 09:48.58 | likewise | Jin^eLD: (and everyone else): good morning |
| 09:49.24 | Jin^eLD | hey likewise :) |
| 09:50.00 | florian | good morning |
| 09:50.01 | kenws | morning : ) |
| 10:01.09 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 10:01.10 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 10:02.13 | bluelightning | morning all |
| 10:02.47 | Jin^eLD | hi bluelightning |
| 10:06.26 | likewise | bluelightning: good morning |
| 10:08.24 | likewise | JaMa: good morning Martin, could you share your thoughts on this one for a sec, thanks? http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/013897.html |
| 10:17.23 | JaMa | likewise: fine with me :) |
| 10:20.18 | likewise | JaMa: thanks. Is the package name "kexec" and "kdump" ok, or should it be "kexec-tools-kexec" and "kexec-tools-kdump"? I am ok with the first, I just wondered how we approach the namespace in general. |
| 10:21.52 | JaMa | easier if original names are kept (updating only oe-core stuff depending on kexec-tools) IMHO |
| 10:22.15 | JaMa | also users will probably try to opkg install kexec not kexec-tools-kexec |
| 10:22.51 | likewise | JaMa: I agree, it is a different issue and no other package provides it (in contrast with "busybox-<some_tool>" package names). |
| 10:23.16 | likewise | JaMa: I'll test some more and post a patch. Thanks. |
| 10:23.26 | JaMa | yw |
| 10:25.25 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 10:31.59 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 10:38.39 | *** join/#oe mickey_office (~mickey@business-092-079-168-007.static.arcor-ip.net) |
| 10:49.06 | pb_ | hi all |
| 10:54.31 | bluelightning | hi pb_ |
| 11:05.14 | *** join/#oe lamikr (lamikr@nat/nokia/x-zjlntjrgoeqcbzll) |
| 11:05.16 | *** join/#oe GNUtoo (~gnutoo@host42-159-dynamic.51-79-r.retail.telecomitalia.it) |
| 11:15.00 | *** join/#oe erwt (~erwt@114.143.160.125) |
| 11:17.02 | *** join/#oe pepermint (~pepermint@host208-90-dynamic.2-87-r.retail.telecomitalia.it) |
| 11:21.02 | florian | hi pb_ |
| 11:52.47 | *** join/#oe vivijim (~vivijim@unaffiliated/vivijim) |
| 11:54.00 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:41.55 | kenws | Hi there, is there a mechanism to only download the source packages? |
| 12:42.43 | kenws | sometimes my builds are failung due to outdated SRC_URI descriptions or incomplete mirrors (kernel.org) |
| 12:43.25 | kenws | so, it would be nice to have bitbake to fetch things to the downloads dir first |
| 12:46.47 | kenws | hm, maybe I can restict it to the do_fetch task |
| 12:47.43 | XorA | bitbake -c fetch_all I think |
| 12:48.12 | XorA | so bitbake -c fetch_all blah-image |
| 12:48.27 | XorA | is working from foggy memory though |
| 12:50.45 | erwt | hi i am comiling a angstrom-gnome-image but it gives me fail at that point http://pastebin.com/V8NLcgNY |
| 12:50.56 | kenws | XorA: thanks! as from the listtasks output it looks like -c fetchall is the one |
| 12:51.38 | *** join/#oe e-ffi (~cybercom@HSI-KBW-082-212-014-081.hsi.kabelbw.de) |
| 12:52.18 | XorA | erwt: corrupt download from the looks of it |
| 12:52.34 | erwt | how to solve |
| 12:52.48 | XorA | remove from your downloads dir and try again |
| 12:52.58 | XorA | I guess you only got partial file |
| 12:53.14 | XorA | or its just duff on the original source |
| 12:53.21 | XorA | or your network is flaky |
| 12:53.28 | kenws | sometimes the transparent proxies are doing nasty things with gz files |
| 12:53.32 | erwt | fine i will try |
| 12:53.39 | kenws | I'd check what: file /home/rahul/OEBASE/sources/libcdaudio-0.99.12p2.tar.gz |
| 12:53.42 | kenws | gives |
| 12:54.25 | XorA | kenws: yeah Ive seen corporate ones replace random chunks of binary files with html |
| 12:55.01 | kenws | : ) |
| 12:56.22 | kenws | hm, shouldn't the fetch task recognize files that have been manually placed into the downloads dir? |
| 12:59.22 | XorA | md5sum file.tar.gz >file.tar.gz.md5 |
| 13:01.10 | kenws | XorA: in case the md5sum hint was for me, I already checked it and it matches to what the receipt states |
| 13:02.22 | kenws | maybe there's a missing "stamp" or something that tells the build system that it still needs to fetch that file |
| 13:04.46 | XorA | kenws: check again what I wrote the stamp is the md5sum |
| 13:04.48 | XorA | or was |
| 13:04.53 | XorA | unless fetch2 changed all that] |
| 13:05.59 | kenws | XorA: are you saying that the build system recognizes the file.tar.gz.md5 in the downloads directory? |
| 13:06.44 | XorA | it certainly used to signal successful download |
| 13:07.31 | kenws | but there are no other .md5 in that directory |
| 13:07.44 | kenws | and it already downloaded plenty of them |
| 13:07.56 | kenws | hm, I don't get it : ) |
| 13:08.18 | ericben | kenws: hi, isn't there a archive.tar.gz.done file in the download directory ? |
| 13:08.40 | kenws | aah, the .done files |
| 13:08.46 | ericben | kenws: yes this one |
| 13:08.50 | kenws | that seems the "stamp" |
| 13:08.51 | kenws | cool |
| 13:08.55 | kenws | ericben: thanks! |
| 13:09.01 | kenws | XorA: and thank you too! : ) |
| 13:09.48 | XorA | is obviously years out of date and retires |
| 13:10.28 | ericben | from what I see, before the stamp was the checksum file now it's the .done file |
| 13:12.18 | kenws | hmpf, I just did a `touch /path/to/download/file.tar.gz.done` to create the empty -done file but bitbake still tries to download it |
| 13:12.29 | XorA | so you can not wget -R one of the source mirrors and then add the .done files :-D |
| 13:13.22 | Jin^eLD | kenws: download the file, md5sum $file > $file.md5 |
| 13:13.27 | Jin^eLD | then it will not get downloaded |
| 13:13.41 | bluelightning | that can't be right... when I do builds with a preserved downloads directory it does not re-fetch every file |
| 13:14.16 | Jin^eLD | thinks that .md5 files do the trick |
| 13:14.30 | kenws | Jin^eLD: i'll try |
| 13:15.07 | kenws | bluelightning: yeah, there are a plenty of files already in the downloads dir that don't get re-fetched |
| 13:15.16 | bluelightning | I don't think the md5 files are used with fetch2 |
| 13:16.17 | kenws | at least the downloads dir of my oe-core build has only sources and .done files |
| 13:17.02 | Jin^eLD | hmm, no idea why it worked for me then |
| 13:17.48 | kenws | creating the .md5 doesn't seem to have any impact for me (on oe-core) |
| 13:19.27 | Jin^eLD | weird.. I had the problem that I could not fetch some fies, so I just copied them to the downlaods dir from another machine, generated the md5 and they did not get refetched; although I have to admit I did not try it without the md5 thing |
| 13:19.41 | Jin^eLD | I kind of remembered md5 was doing its job in oe classic (but maybe I was wrong there too?) |
| 13:20.14 | kenws | Jin^eLD: yeah,maybe that mechanism has changed recently |
| 13:20.53 | kenws | to be honest I have no idea, I just started with oe |
| 13:21.25 | Jin^eLD | well, copying the tarball to the dl dir worked for me in OE core (md5 was not necessary as we just found out..) |
| 13:22.11 | ericben | kenws: which recipe do you have this problem with ? |
| 13:22.33 | kenws | meta/recipes-graphics/libxsettings-client/libxsettings-client_0.10.bb |
| 13:22.37 | kenws | but I think it was my bad |
| 13:23.19 | kenws | I've got more than one build dir that uses the same downloads dir, but it looks like I've messed up my local.conf in one case |
| 13:23.48 | kenws | so that the build was pulling things from build/downloads rather than my shared downloads dir |
| 13:23.52 | kenws | ducks |
| 13:23.59 | bluelightning | ah, that explains it :) |
| 13:24.05 | ericben | :) |
| 13:29.37 | kenws | setting DL_DIR to the correct value works flawlessly. I don't even have to create the .done file as the build system seems to recognize the existant file and moves on from there |
| 13:29.43 | kenws | sweet! : ) |
| 13:31.20 | bluelightning | I have to admit I'd like to know what the .done file actually does |
| 13:32.14 | kenws | bluelightning: I suspect it's kind of a stamp we have the bitbake sources, so all we need to do is to look at the fetch task : ) |
| 13:32.35 | kenws | s/stamp we/stamp. we/ |
| 13:32.43 | ericben | <PROTECTED> |
| 13:32.44 | ericben | <PROTECTED> |
| 13:32.49 | ericben | this is the comment in bitbake |
| 13:32.56 | kenws | there we go : ) |
| 13:33.00 | kenws | thanks ericben! |
| 13:33.56 | bluelightning | kenws: yeah just checked, it looks to be informational, nothing in fetch2 actually checks to see if it exists (apart from the code that updates it) |
| 13:34.42 | bluelightning | I'm guessing it is currently intended to help find stale files in your downloads dir |
| 13:35.02 | kenws | Isn't the sstate-cache used for stamps and those things that tells the buildsystem which tasks are done? |
| 13:35.17 | bluelightning | no, there's a stamps dir for that |
| 13:35.25 | kenws | ah, ok - sounds reasonable |
| 13:36.03 | bluelightning | but in the absence of that stamp for sstate candidate tasks it will check the sstate cache for an sstate package with the appropriate checksum |
| 13:39.11 | bluelightning | one thing that does annoy me with fetch2 is that interrupted fetches seem to be able to foul things up to the extent that manual intervention is required (-c cleanall) |
| 13:42.31 | kenws | Is there a way to specify some sort of a "fall back" mirror? |
| 13:42.48 | kenws | a good candidate would be: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/sources/ |
| 13:44.32 | *** part/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 13:44.53 | bluelightning | kenws: yep, POSTMIRRORS is the mechanism for that |
| 13:46.12 | bluelightning | kenws: although in poky we use PREMIRRORS so we're trying our mirror first |
| 13:47.04 | *** join/#oe risca (~risca@f-static-78-70-87-29.business.telia.com) |
| 13:50.55 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 13:51.52 | hrw | kenws: it helps to have DL_DIR pointing to outside of build directory |
| 13:52.15 | hrw | and for *.md5 (oe classic) simple touch was enough |
| 13:53.14 | kenws | bluelightning: thanks, I'll add it to my local.conf. |
| 13:54.33 | bluelightning | kenws: FYI there's a special syntax for that variable |
| 13:54.51 | bluelightning | although I think just putting one URI in it does work |
| 13:55.11 | kenws | hrw: yep, the DL_DIR is pointing outside my build dir. Since I have a couple of build dirs I also need to maintain a couple of local.conf files. And in one of the configs I had the stock DL_DIR : ) |
| 13:56.33 | kenws | bluelightning: does the POST/PREMIRRORS work with things like the http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/sources/ ? |
| 13:56.40 | hrw | kenws: you can set such things in build/conf/site.conf and copy it between build dirs (or even symlink) |
| 13:57.23 | kenws | I haven't tried it but I could imagine that the mirror need to reflect the structure (directories) |
| 13:57.47 | kenws | hrw: ok, I'll keep that in mind. thanks! |
| 13:59.08 | bluelightning | kenws: the structure doesn't need to be replicated; my only question is will a single URI work or do you have to set it on a per-protocol basis |
| 13:59.51 | kenws | I see... |
| 14:00.42 | bluelightning | kenws: the structure doesn't need to be replicated; my only question is will a single URI work or do you have to set it on a per-protocol basis |
| 14:00.47 | bluelightning | ah sorry |
| 14:01.51 | bluelightning | kenws: I think you do have to; however you may want to INHERIT += "own-mirrors" and then set SOURCE_MIRROR_URL to that |
| 14:04.45 | erwt | has amyone has the mdz5 no for ca-certificates_20090814+nmu2 |
| 14:04.59 | erwt | plz i am sick of changing them |
| 14:18.07 | *** join/#oe eFfeM_work (~frans@D4B26BC1.static.ziggozakelijk.nl) |
| 14:19.31 | kenws | bluelightning: yes, there doesn't seem to be support for POSTMIRRORS within fetch2, I only saw PREMIRRORS and MIRRORS |
| 14:20.07 | bluelightning | kenws: that might be because I meant MIRRORS and my memory failed me ;) |
| 14:20.10 | GNUtoo | hi ericben |
| 14:20.13 | GNUtoo | hi otavio |
| 14:20.16 | GNUtoo | I've that: |
| 14:20.18 | GNUtoo | WARNING: File '/usr/bin/qt4/examples/sql/drilldown/drilldown' from qt4-x11-free was already stripped, this will prevent future debugging! |
| 14:20.32 | GNUtoo | when building QT |
| 14:20.40 | bluelightning | GNUtoo: I have a fix for that here |
| 14:20.50 | GNUtoo | ok |
| 14:20.59 | bluelightning | probably should post it today |
| 14:21.04 | GNUtoo | ok thanks |
| 14:23.00 | JaMa | mrmoku: time to cleanup few older images.. http://paste.pocoo.org/show/517537/ |
| 14:32.58 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 14:38.05 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 14:38.58 | mrmoku | JaMa: heh, yeah |
| 14:40.33 | JaMa | mrmoku: dropped them all (for armv7 machines.. lets see how 004 works.. :/) |
| 14:40.59 | JaMa | mrmoku: and reopened http://bugzilla.pokylinux.org/show_bug.cgi?id=1711 |
| 14:51.43 | *** join/#oe dos1 (~dos@ajp246.neoplus.adsl.tpnet.pl) |
| 14:51.46 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 15:06.04 | *** join/#oe devzero_ (devzero@xdsl-89-0-172-55.netcologne.de) |
| 15:12.54 | *** join/#oe DHR (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 15:15.20 | *** join/#oe SterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 15:20.38 | *** join/#oe stefan_schmidt (~stefan@p4FC77338.dip.t-dialin.net) |
| 15:25.08 | *** join/#oe joelagnel (~joel@nat/ti/x-rnjurcwjdflwhmnv) |
| 15:31.47 | *** join/#oe galak (~galak@192.88.168.34) |
| 15:34.32 | likewise | gm galak |
| 15:34.54 | galak | likewise: hi |
| 15:38.28 | stefan_schmidt | ao2: you used the openembedded-devel address for an or-core patch. We separated these for oe-core patches going to openembedded-core@lists.openembedded.org |
| 15:38.43 | stefan_schmidt | ao2: just in case you wonder when no review is coming in |
| 15:40.01 | ao2 | stefan_schmidt, thanks, I've been away for a while. Do you know if openembedded-core@lists.openembedded.org requires subscription? |
| 15:40.21 | stefan_schmidt | ao2: afaik it does, moderated I would think |
| 15:40.35 | ao2 | ok, thanks |
| 15:40.39 | stefan_schmidt | ao2: np |
| 15:42.46 | ao2 | I am playing with oe-core, layers and mr (multi repository), I'll share the oe-ezx setup when it's done. The idea is to bring in the all the pieces by just requiring one text file ".mrconfig" |
| 15:43.48 | stefan_schmidt | ao2: we have different approaches for the layering right now. The angstrom setup-scripts are using a script called layerman |
| 15:44.10 | pb_ | yes, oe-core@ is member-posting only. I think all the oe.org lists are set that way. |
| 15:44.17 | stefan_schmidt | and there are also some scripts from yocto and I think otavio is using them as well. Don't remember the name right now |
| 15:44.30 | stefan_schmidt | pb_: thanks |
| 15:45.08 | stefan_schmidt | ao2: I'm undecided on the best approach here but I think we need better tooling to allow easier handling of all the different layers. |
| 15:45.46 | stefan_schmidt | Especially when we start to have releases where branches need to match other release branches. Future though |
| 15:45.57 | *** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
| 15:46.36 | ao2 | I am liking mr so far but I haven't explored all its functions, neither I am able to compare it to alternatives right now. |
| 15:46.51 | bluelightning | stefan_schmidt: combo-layer is the one ke and I worked on |
| 15:47.06 | stefan_schmidt | bluelightning: right, now I remember :) |
| 15:47.29 | *** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |
| 15:47.48 | ao2 | my idea is to use a generic tool, let's see how that comes out |
| 15:49.31 | bluelightning | interesting, this is the first I've heard about mr |
| 16:01.43 | *** join/#oe drw (~Dan@cpe-76-187-60-200.tx.res.rr.com) |
| 16:24.50 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 16:30.07 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 16:30.26 | pb_ | oh drat |
| 16:30.28 | pb_ | stabs rm_work |
| 16:31.05 | pb_ | just spent the last three hours trying to make webkit build and, of course, the moment it succeeded oe went and deleted all the source code that I just modified |
| 16:32.55 | likewise | pb_: ouch. |
| 16:33.22 | bluelightning | doh :( |
| 16:33.32 | likewise | pb_: at these times, I would love to have a filesystem that does snapshots. (so that empty space is used for history rollback). |
| 16:34.30 | pb_ | yeah |
| 16:34.35 | pb_ | I think I am going to turn rm_work off again. |
| 16:35.08 | pb_ | we have a local hack called "rm_old_work" which deletes all versions other than the latest from the workdir, which seems to be good enough to stop the disk usage growing completely without bounds. |
| 16:35.37 | JaMa | pb_: nice, could you share "rm_old_work" |
| 16:35.41 | JaMa | ? |
| 16:35.58 | pb_ | yeah, let me dig it out |
| 16:36.57 | JaMa | with rm_work as it's working now with sstate I would really like to be able to use at least rm_old_work |
| 16:38.08 | pb_ | I checked it into the meta-micro tree. http://git.openembedded.org/meta-micro/tree/classes/rm_old_work.bbclass |
| 16:38.18 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
| 16:38.19 | JaMa | thanks |
| 16:40.04 | *** join/#oe pespin (~pespin@254.Red-88-28-136.staticIP.rima-tde.net) |
| 16:41.47 | hrw | pb_: or override rm_work task in hacked recipe? |
| 16:42.17 | pb_ | well, yeah, but that relies on remembering to actually do it each time |
| 16:42.35 | pb_ | which is exactly where I went wrong on this occasion |
| 16:56.19 | kergoth` | neat |
| 16:56.29 | kergoth` | I wish we did housecleaning on more of our stuff for old versions |
| 16:56.38 | kergoth` | would be nice for downloads, etc |
| 16:56.48 | pb_ | yeah |
| 16:57.24 | bluelightning | the trouble is a lot of that is hard to remove deterministically |
| 16:57.42 | kergoth` | yep |
| 16:57.42 | bluelightning | though a workaround such as pb_'s should be OK most of the time |
| 16:57.42 | pb_ | it is a bit sad (although understandable) that your oe tree gradually gets bigger and bigger until it consumes all available disk space |
| 17:05.27 | khem | pb_: heh webkit, yes that was one who inspired me to use gold |
| 17:05.58 | khem | pb_: its the ld that took like 45 minutes alone |
| 17:06.05 | khem | in my case |
| 17:06.23 | pb_ | oddly, I don't see that problem here |
| 17:06.34 | pb_ | I'm not using gold since I don't think it supports mips yet |
| 17:06.40 | *** join/#oe msm (~msm@192.88.168.34) |
| 17:06.50 | khem | pb_: yes it does not support mips |
| 17:06.55 | pb_ | and I haven't noticed any pathological link times with ld.bfd |
| 17:06.57 | khem | so far arm/x86/amd64 |
| 17:07.38 | khem | hmm webkit-gtk it was in my case and I could see ld using up all of my memory and thrashing |
| 17:08.27 | JaMa | khem: similar times with webkit-* linking here |
| 17:08.47 | khem | JaMa: can you try it with gold ? |
| 17:08.49 | JaMa | adding extra swap just to link webkit-* without oom |
| 17:09.06 | JaMa | not right now |
| 17:10.02 | pb_ | ah, if it was slow due to out of memory then that might explain why I'm not seeing the problem |
| 17:10.15 | pb_ | I do have 20G of RAM and 40G of swap on this machine which might be enough to avoid the oom situation |
| 17:10.21 | khem | JaMa: just add DISTRO_FEATURES += "ld-is-gold" to enable it and then rebuild from scratch whenever you want to try it out |
| 17:10.48 | JaMa | will try when I'll update webkit-efl to newer rev.. |
| 17:10.51 | khem | pb_: hrmm definitely but then why three hours |
| 17:11.12 | pb_ | three hours for me to build webkit, you mean? |
| 17:11.19 | khem | was it just webkit or everything upto webkit |
| 17:11.37 | pb_ | most of that wasn't actual build time, it was me figuring out what changes were needed to make it compile |
| 17:11.59 | khem | pb_: ok |
| 17:12.17 | pb_ | I'm not sure how long it would have taken from clean, probably 15 mins at a guess |
| 17:12.21 | khem | I found that not using rm_work is better for dev work |
| 17:12.29 | khem | but it does eat up lot of space |
| 17:13.00 | pb_ | once I get the sources reinstated I can try timing a build. certainly minutes not hours though. |
| 17:14.22 | khem | pb_: yeah if you have 20G of ram I dont see any issues |
| 17:14.32 | khem | I have 2G of ram on that box |
| 17:14.54 | pb_ | right, I can imagine that would be no good |
| 17:16.13 | khem | pb_: but gold helped me there |
| 17:16.51 | khem | pb_: what mips chip are you targetting at ? |
| 17:18.34 | pb_ | a proprietary one. |
| 17:18.47 | khem | ok cool |
| 17:18.53 | khem | are you using N32 |
| 17:19.01 | khem | ABI |
| 17:19.31 | pb_ | no, we're on 32 bit. o32 |
| 17:19.45 | khem | hmm ok |
| 17:20.11 | khem | all mips above mips1 can support N32 though |
| 17:20.30 | khem | at work we still support mips1 so I am out of luck |
| 17:20.38 | khem | but they do want performance |
| 17:21.48 | *** join/#oe anarsoul (~anarsoul@212.98.189.25) |
| 17:22.32 | pb_ | ah, I thought n32 required mips64. |
| 17:23.08 | khem | only 64bit registers |
| 17:23.12 | khem | which they do have |
| 17:23.31 | pb_ | mips32 doesn't have 64 bit registers, only 32 bit |
| 17:26.09 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 17:30.54 | *** join/#oe risca (~risca@130.236.250.53) |
| 17:34.53 | khem | pb_: yes mips32 is 32bit regs IIRC its reincarnation of mips2 |
| 17:35.13 | pb_ | so no n64, right? |
| 17:35.16 | pb_ | er, no n32 |
| 17:37.05 | *** join/#oe risca (~risca@130.236.250.53) |
| 17:38.09 | *** join/#oe fcooper (~a0273011@nat/ti/x-zvgcehjqzxsmixhj) |
| 17:42.36 | khem | pb_: yep |
| 17:47.10 | *** join/#oe XorA (~XorA@188-220-34-37.zone11.bethere.co.uk) |
| 17:54.21 | *** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl) |
| 18:12.09 | tzanger | quick recipe question... SRC file:// urls, if I have a dozen files, can I use wildcards or do they have to be explicitly mentioned? |
| 18:23.16 | *** join/#oe dhanraj (80e60340@gateway/web/freenode/ip.128.230.3.64) |
| 18:25.03 | dhanraj | hi i am new embedded system developer and I need help on buidling my own embedded linux distro. I am not sure if i should put this question here... bt please guide me on same.. You will be helping future of the linux embedded developer |
| 18:25.34 | kergoth` | there is plenty of documentation, go read it |
| 18:25.43 | kergoth` | we aren't going to hold your hand, I'm afraid |
| 18:25.51 | dhanraj | thank you |
| 18:25.57 | dhanraj | for your reply ... |
| 18:27.18 | dhanraj | yes i know you are not going to hold my hand .. but pointer is what i need .. though thanks |
| 18:30.50 | dhanraj | thanks i found manual on OE.. and it seems perfect for my answer... and thank you for pointing and sorry if my question was silly ....... |
| 18:35.26 | tzanger | hm, I have file:// URIs in my SRC_URI, and my do_install() does "install -m 0644 ${WORKDIR}/stuff_from_file:// ${D}/etc/some/path/here"... install complains that the source dir is empty and thus fails. Is there some secret sauce involved in copying the files listed with file:// in the SRC_URI to WORKDIR? |
| 18:35.42 | tzanger | I'm looking at some of the other recipes that do similar things but it seems to be automatic |
| 18:36.03 | kergoth` | dhanraj: I'd suggest reading the documentation at the yocto project |
| 18:36.13 | kergoth` | dhanraj: most of it also applies to oe proper, and its superior |
| 18:38.23 | tzanger | it looks like the files mentioned in SRC_URI end up in ${WORKDIR} automatically. is there something I'm missing? |
| 18:39.49 | *** join/#oe Heinervdm (~thomas@pD9E1521A.dip.t-dialin.net) |
| 18:41.37 | tzanger | this might have to do with my having SRC_URI including wildcards I guess |
| 18:43.23 | kergoth` | it is automatic. and I have no clue how wildcards are handled right now |
| 18:43.35 | kergoth` | we need some automated testing for the fetch/unpack/patch process |
| 18:47.26 | tzanger | yeah the documentation is pretty weak for local fetchers atm |
| 18:47.27 | tzanger | http://bitbake.berlios.de/manual/ch03s02.html |
| 18:47.51 | kergoth` | the bitbake manual hasn't been touched in years |
| 18:48.03 | kergoth` | the fetcher has been replaced since then |
| 18:48.10 | kergoth` | and unpacking moved into bitbake |
| 18:50.07 | tzanger | hm |
| 18:54.34 | zecke | :( |
| 18:58.00 | tzanger | hm, even specifying the files individually it's not populating WORKDIR |
| 18:58.26 | *** join/#oe pepermint (~pepermint@host208-90-dynamic.2-87-r.retail.telecomitalia.it) |
| 19:04.42 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 19:05.19 | *** join/#oe risca (~risca@f-static-78-70-87-29.business.telia.com) |
| 19:15.49 | kergoth` | Are they patches? |
| 19:16.39 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-iipelsssxtbxvmjz) |
| 19:20.52 | *** join/#oe flo_lap (~fuchs@sign-4db6b00d.pool.mediaWays.net) |
| 19:20.53 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 19:21.24 | florian | re |
| 19:27.43 | tzanger | ah, it seems like 90% of my problems were not -c clean'ing before re-running the recipe |
| 19:47.58 | *** join/#oe galak (~galak@192.88.168.34) |
| 19:48.07 | *** join/#oe ralfw (~blackjack@dslb-088-073-135-039.pools.arcor-ip.net) |
| 19:52.45 | ralfw | help ! im confused, which OE branch to use for collie ? |
| 19:53.07 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 19:54.04 | kergoth` | tzanger: heh, that'd do it |
| 19:54.11 | kergoth` | ralfw: depends on whether you're using oe-core or classic oe |
| 19:54.39 | ralfw | kergoth`: dont confuse me more |
| 19:54.50 | kergoth` | well, that doesn't change the facts |
| 19:56.32 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 19:56.50 | *** join/#oe woglinde (~heinold@g225167089.adsl.alicedsl.de) |
| 19:59.06 | ralfw | fine ill try 2011.03-maintenance, master just doesnt work on collie |
| 20:02.58 | woglinde | fix it |
| 20:26.32 | *** join/#oe kevinsc (~a0214685@nat/ti/x-liobpkiueucetuui) |
| 20:28.34 | Crofton|work | we should start a buy back program for the older devices |
| 20:38.11 | *** join/#oe rcf (~rcf@168.186-243-81.adsl-dyn.isp.belgacom.be) |
| 20:38.40 | tzanger | this makes even less sense |
| 20:38.47 | tzanger | a recipe uses an http:// SRC_URI, no problem |
| 20:38.49 | tzanger | it builds fine |
| 20:39.04 | tzanger | I add a couple patch files (0000-firstpatch-to-use.patch and 0001-secondpatch-to-use.patch) |
| 20:39.17 | tzanger | OE seems to be tryign to apply the patches before it downloads the source |
| 20:39.27 | tzanger | I've definitely -c clean'd this time |
| 20:40.24 | tzanger | is there a problem with the SRC_URI's being processed in a sorted order? |
| 20:46.10 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 20:46.43 | tasslehoff | khem: evening (here at least). I posted the readelf output to the ML |
| 20:47.46 | woglinde | tzanger o.O |
| 20:48.11 | woglinde | I think http first |
| 20:52.15 | GNUtoo | Crofton|work, what do you mean exactly? what about batteries? |
| 20:58.06 | tzanger | woglinde: my reaction too. I'm looking through it |
| 21:06.46 | Crofton|work | GNUtoo, buy up all the older machines we used to support :) |
| 21:07.06 | GNUtoo | some people want to give theses machines for free |
| 21:07.18 | GNUtoo | like mickeyl for instance |
| 21:07.45 | GNUtoo | but the problem is that he doesn't know if they still work or not |
| 21:07.51 | GNUtoo | zauruses and ezx |
| 21:08.59 | GNUtoo | the problem is find new maintainers I guess |
| 21:09.07 | kergoth` | tzanger: no, SRC_URI is alwyas processed in the order it's defined |
| 21:09.14 | Crofton|work | GNUtoo, yes |
| 21:09.32 | Crofton|work | but may be easier on us just to buy up all the outstanding hardware :) |
| 21:09.42 | GNUtoo | yes but to give to whom? |
| 21:09.51 | GNUtoo | how to find new maintainers? |
| 21:11.59 | Jay7 | have lot of Z's but short in time.. |
| 21:12.06 | Crofton|work | no, get tehm out of circulation |
| 21:12.17 | Crofton|work | so people do not have problems, get frustrated and give up |
| 21:12.38 | Jay7 | it would be great to spend 2-3 month on dedicated work on Z's support in OE-core/meta-hh |
| 21:12.46 | Jay7 | but.. real life is so real |
| 21:15.48 | woglinde | hehe |
| 21:16.15 | Crofton|work | yes |
| 21:16.28 | Jay7 | even more.. dedicated work to bring meta-oe to state of oe-classic |
| 21:16.40 | Jay7 | i.e. working and usable gpe and opie :) |
| 21:19.06 | Crofton|work | heh |
| 21:19.08 | Crofton|work | yeah |
| 21:19.45 | Jay7 | hm.. may be someone should try to get CELF founding this year to do this |
| 21:20.04 | Jay7 | s/founding/funding/ |
| 21:21.20 | tasslehoff | has it been decided when oe-classic goes read-only? been a while since I was told "in a short while" :) |
| 21:21.23 | *** join/#oe CMoH (~cipi@95.76.68.223) |
| 21:21.23 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 21:22.04 | Jay7 | tasslehoff: no real date afaik |
| 21:22.25 | Jay7 | TSC should decide |
| 21:24.00 | florian | as long as noone asks me to comment... ;) |
| 21:24.22 | tasslehoff | Jay7: ok. |
| 21:24.36 | CMoH | hey. which script mounts /media/mmcblk0p2 in angstrom? |
| 21:24.52 | CMoH | there doesn't seem to be any entry in /etc/fstab for these |
| 21:24.57 | tasslehoff | mount.sh from udev? |
| 21:25.07 | *** join/#oe likewise (~chatzilla@095-097-098-131.static.chello.nl) |
| 21:25.53 | tasslehoff | will there be more releases from classic? |
| 21:26.06 | CMoH | wouldn't that conflict with /dev/root mounting the same SD card partition rw as well? |
| 21:26.08 | woglinde | tasslehoff no |
| 21:26.14 | woglinde | no releases |
| 21:26.19 | woglinde | didnt you read the ml? |
| 21:26.26 | likewise | msm: Hello Matthew, Leon 'likewise' here, nice to see you on #oe. Do you know if there are Freescale ppl also upstreaming i.MX SoC into oe-core? |
| 21:26.55 | tasslehoff | woglinde: something about it recently? |
| 21:26.57 | CMoH | or is it a bind mount? |
| 21:30.39 | tasslehoff | calls it a day. good night. |
| 21:30.43 | likewise | what is the oe-core way of modifying kernels in work/ ? I used to throw away some stamps file and run the deploy task, but this seems no longer supported. |
| 21:30.46 | likewise | tasslehoff: nite |
| 21:31.15 | CMoH | tasslehoff, thanks for the hint |
| 21:31.43 | msm | likewise: i'm just on the ppc side |
| 21:31.50 | msm | likewise: not sure what the arm side has decided |
| 21:32.08 | likewise | msm: I used to be ppc-only until last week :) |
| 21:33.05 | likewise | msm: ppc is now moving away from ltib to yocto? |
| 21:34.34 | msm | likewise: yes |
| 21:34.45 | msm | likewise: some people have done fsl arm stuff |
| 21:34.50 | msm | for OE/yocto |
| 21:47.30 | *** join/#oe galak (~galak@192.88.168.34) |
| 21:50.02 | *** join/#oe ant____ (~andrea@host181-12-dynamic.60-82-r.retail.telecomitalia.it) |
| 21:53.29 | GNUtoo | msm, hi yes |
| 21:56.00 | tzanger | one last question for the day (I hope) |
| 21:56.19 | tzanger | I've got a recipe that creates <package> but also <package>-default-config. |
| 21:56.51 | tzanger | I have a task that includes that recipe but also an alternate config recipe |
| 21:57.23 | tzanger | the recipes get built just fine, but if I look at the final image I can see that <package>-default-config got included and the alternate config did not, although the alternate is spelled out in the RDEPENDS list |
| 21:58.43 | *** join/#oe Jay7 (jay@78-106-0-75.broadband.corbina.ru) |
| 21:59.08 | tzanger | both the config packages only have CONFFILES defined in them, so one should override the other, should they not? |
| 21:59.37 | *** join/#oe Jefro (~josiermi@nat/intel/x-hsuocyxtwbfmjbfq) |
| 22:00.20 | GNUtoo | tzanger, basically you've got package that include the not-default config? |
| 22:00.50 | GNUtoo | and the ${PN}-default-config has the default config right? |
| 22:01.00 | tzanger | I have a package with the binaries, a package with the default config (all files are CONFFILES) and a recipe that creates a package with an alterante config (again all files CONFFILES) |
| 22:01.01 | GNUtoo | and you want the default config right? |
| 22:01.14 | tzanger | GNUtoo: yes ${PN}-default-config has the default config |
| 22:01.15 | GNUtoo | so you have 3 packages |
| 22:01.31 | tzanger | yes three altogether, but two "control" the same files (the conf files) |
| 22:01.36 | GNUtoo | ok |
| 22:01.47 | tzanger | the -defualt-config has the default config files from the package, and the -custom-config has the customized config |
| 22:01.57 | GNUtoo | ok |
| 22:02.08 | otavio | tzanger: so both ought to provide ${PN}-virtual-config |
| 22:02.17 | otavio | tzanger: or whatever |
| 22:02.24 | GNUtoo | yes indeed you should do something to handle the conflict |
| 22:02.26 | tzanger | hmm, ok, let me see if I can figure out how to encode that |
| 22:02.32 | GNUtoo | and verify if it worked in do_rootfs |
| 22:02.46 | GNUtoo | another option would include RCONFLICTS |
| 22:03.34 | tzanger | will ipk automatically do the right thing if I try to ipk install a package that conflicts with an installed one, or does it error out and let me rmeove it manually? |
| 22:03.54 | GNUtoo | it errors |
| 22:04.02 | GNUtoo | opkg errors on that |
| 22:04.10 | GNUtoo | you have 2 options then |
| 22:04.16 | GNUtoo | remove the old package and install the new one |
| 22:04.19 | *** join/#oe vivijim (~vivijim@unaffiliated/vivijim) |
| 22:04.22 | GNUtoo | or --force-overwrite |
| 22:04.26 | tzanger | right, ok |
| 22:04.32 | tzanger | I think the virtual config is the better way to do it |
| 22:04.34 | GNUtoo | ah conflicts |
| 22:04.36 | otavio | tzanger: your image most probably needs to set preferred provider for it |
| 22:04.38 | GNUtoo | sorry I didn't read well |
| 22:04.40 | GNUtoo | it errors |
| 22:04.51 | GNUtoo | and you have to uninstall the other package |
| 22:04.57 | tzanger | otavio: ok |
| 22:05.14 | GNUtoo | I'm not sure if you can get away with --force-overwrite |
| 22:05.19 | otavio | tzanger: or install it before the package, so the depends will be satisfied |
| 22:05.19 | GNUtoo | I'll have to check |
| 22:07.45 | tzanger | hm, if the recipe is creating ${PN}, ${PN}-default-config etc can you say that one package that the recipe creates provides ${PN}-virtual-config, or does the defult config have to be broken out into its own recipe? |
| 22:09.07 | otavio | tzanger: you need a package that provides it but this cannot be PN otherwise you'll end up without PN installed. |
| 22:09.33 | tzanger | right |
| 22:09.53 | tzanger | but what I'm saying is that one recipe creates two packages. how does one specify only ONE of those packages provides the virtual package? |
| 22:10.26 | tzanger | the recipe creates ${PN} ${PN}-default-config (as well as the ${PN}-debug and whatever else is automatic) |
| 22:10.50 | tzanger | how does one say ${PN}-defualt-config provides ${PN}-virtual-config |
| 22:11.40 | tzanger | it looks like there's just a single PROVIDES variable to be used in the recipe, but that would affect ${PN} as well... I think |
| 22:11.44 | otavio | RPROVIDES_${PN}-default-config = "${PN}-config" |
| 22:11.48 | tzanger | oh |
| 22:11.53 | tzanger | there's a facepalm moment |
| 22:12.02 | otavio | yeah; that's life |
| 22:12.05 | otavio | heh |
| 22:13.59 | tzanger | thanks :-) |
| 22:16.55 | otavio | np |
| 22:17.28 | kenws | Wow, this is strange. The libproxy-0.4.7/libmodman/CMakeLists.txt generates a CMakeFiles/modman.dir/link.txt where the ar (arm-none-linux-gnueabi-ar) command is empty when using a binary cross toolchain. All the other generated link.txt of libproxy seems to be ok |
| 22:18.35 | kenws | I've tweaked the meta/classes/cmake.bbclass to set the CMAKE_AR plus friends and the generated toolchain.cmake is looking good. |
| 22:32.27 | *** join/#oe fcooper (~a0273011@nat/ti/x-bxyardwtbxjoqqlq) |
| 22:33.35 | *** join/#oe nitink (~nitink@192.55.54.42) |
| 22:38.59 | *** join/#oe JaMa (~martin@94.230.152.246) |
| 23:23.24 | *** join/#oe CcSsNET (~CcSsNET@c-98-216-138-179.hsd1.ma.comcast.net) |
| 23:48.17 | *** join/#oe nslu2-log (~nslu2-log@limax.nslu2-linux.org) |
| 23:52.07 | *** join/#oe halstead|away (~halstead@watts.incitedev.com) |
| 23:57.30 | *** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |