| 00:03.56 | *** join/#oe geekoid (n=geekoid@adsl-75-4-38-128.dsl.emhril.sbcglobal.net) |
| 00:04.16 | *** join/#oe geekoid_ (n=geekoid@adsl-75-4-38-128.dsl.emhril.sbcglobal.net) |
| 00:21.42 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 00:27.54 | *** join/#oe ScytheBlade1 (n=Death@about/pxe/ScytheBlade1) |
| 00:31.04 | *** join/#oe upload (i=da@cpe-76-179-85-181.maine.res.rr.com) |
| 00:36.52 | *** join/#oe mzb (n=ubernut@ppp108-88.static.internode.on.net) |
| 00:44.40 | rwhitby | koen: angstrom-minimal-image works for nslu2le, and rootfs is only 56% full after boot :-) |
| 00:47.17 | rwhitby | trying again now with normal bootstrap-image and MACHINE_TASK_PROVIDER set to "task-boot dropbear sysconf" so my network settings come up automatically. |
| 01:04.39 | *** part/#oe ozstinger (n=ozstinge@216.143.234.167) |
| 01:09.51 | *** join/#oe jkilb_ (n=jkilb@p5b209b36.dip0.t-ipconnect.de) |
| 01:16.56 | *** join/#oe tank17 (i=ariel@gateway/tor/x-b60f25612044d6ab) |
| 01:27.34 | *** join/#oe concept10 (n=concept1@ppp-70-247-162-218.dsl.rcsntx.swbell.net) |
| 01:34.39 | *** join/#oe Sonic|Laptop (n=Garrett@cblmdm72-240-97-94.buckeyecom.net) |
| 01:36.48 | *** join/#oe jmau (n=jmau@p54a5b2b5.dip0.t-ipconnect.de) |
| 01:39.22 | *** join/#oe Zero_Chaos (n=zero@c-71-60-239-40.hsd1.pa.comcast.net) |
| 01:54.16 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 01:56.41 | *** join/#oe W8TVI (n=me@166.165.156.251) |
| 01:59.41 | *** join/#oe jacques (n=jacques@nslu2-linux/jacques) |
| 02:04.32 | *** join/#oe wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 02:17.32 | VoodooZ | which package provides libstdc++.so.6?? |
| 02:17.32 | VoodooZ | odd. I see a libstdc++ entry in work directory... |
| 02:17.32 | *** join/#oe benlau (n=benlau@221.125.13.148) |
| 02:24.45 | *** join/#oe W8TVI_ (n=me@166.166.7.202) |
| 02:47.09 | *** join/#oe mithro (n=tim@lester.mithis.com) |
| 02:48.22 | *** join/#oe greentux__ (n=lemke@p54b32296.dip0.t-ipconnect.de) |
| 02:49.32 | *** part/#oe W8TVI_ (n=me@166.166.7.202) |
| 03:01.33 | *** join/#oe JustinP (n=papercra@c-69-181-11-251.hsd1.ca.comcast.net) |
| 03:23.58 | *** join/#oe concept10 (n=concept1@ppp-70-247-162-218.dsl.rcsntx.swbell.net) |
| 03:32.20 | *** join/#oe kb7sqi (i=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 03:59.41 | *** join/#oe W8TVI (n=me@157.sub-70-200-194.myvzw.com) |
| 04:04.29 | *** join/#oe geekoid (n=geekoid@adsl-75-4-40-58.dsl.emhril.sbcglobal.net) |
| 04:14.35 | *** join/#oe xjqian (n=gordon@71-85-151-212.dhcp.stls.mo.charter.com) |
| 04:34.10 | *** join/#oe geekoid_ (n=geekoid@adsl-75-4-37-62.dsl.emhril.sbcglobal.net) |
| 04:47.25 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 04:47.53 | *** part/#oe concept10 (n=concept1@ppp-70-247-162-218.dsl.rcsntx.swbell.net) |
| 04:51.54 | *** join/#oe humsat (n=NoNoNoNo@0x5358a937.kd4nxx8.adsl-dhcp.tele.dk) |
| 04:52.06 | humsat | morn :) |
| 05:01.02 | *** join/#oe hvontres|home (n=hvontres@adsl-75-22-170-32.dsl.sndg02.sbcglobal.net) |
| 05:02.34 | *** join/#oe dion (n=dion@inhex.net) |
| 05:19.44 | *** join/#oe kb7sqi (i=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 05:23.56 | *** join/#oe HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 06:32.46 | *** part/#oe W8TVI (n=me@157.sub-70-200-194.myvzw.com) |
| 06:40.47 | *** join/#oe geekoid_ (n=geekoid@adsl-71-155-235-2.dsl.emhril.sbcglobal.net) |
| 06:50.27 | *** join/#oe v8jlene (n=lenehan@nynaeve.twibble.org) |
| 06:56.44 | Ifaistos | morning all |
| 06:58.13 | *** join/#oe gremlin[it] (n=gremlin@217.201.2.48) |
| 07:03.19 | Ifaistos | rwhitby : The angstrom-minimal-image needs to be trimmed down a bit to fit in a 4MB flash |
| 07:04.19 | *** join/#oe mrdata (i=mrdata@dslb-088-074-151-010.pools.arcor-ip.net) |
| 07:04.21 | rwhitby | The rootfs comes out at 3538944 bytes for me. So yes, a bit big for 4MiB total. |
| 07:04.43 | Ifaistos | rwhitby : which is constant with what you found on the nslu2 that has 8MB |
| 07:05.15 | rwhitby | nslu2 can take up to about 6MB rootfs. |
| 07:06.42 | Ifaistos | the only image that was ok was the squashfs-lzma but my kernel could not load it |
| 07:07.51 | Ifaistos | cpio , which is even smaller failed with a "bad magic numbers" errors |
| 07:09.17 | Ifaistos | this is what i get with 2 different types of minimal-image i tried -> http://rafb.net/p/gITsW196.html |
| 07:17.58 | Ifaistos | is there a way to apply a patch only when building for uclibc and not glibc ? |
| 07:20.31 | *** join/#oe Marex (n=Marex@85.132.236.161) |
| 07:29.48 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 07:33.01 | *** join/#oe geekoid__ (n=geekoid@adsl-71-155-235-3.dsl.emhril.sbcglobal.net) |
| 07:33.06 | CIA-11 | 03koen 07org.oe.dev * rf9c3925d... 10/ (3 files in 3 dirs): |
| 07:33.06 | CIA-11 | linux-gta01: update to moko10 |
| 07:33.06 | CIA-11 | * should fix sound and bluetooth |
| 07:36.40 | koen | good morning all |
| 07:36.49 | koen | rwhitby: that's good to hear (minimal image) |
| 07:37.39 | rwhitby | koen: should task-base.bb have a PROVIDES = "${PACKAGES}" in it? I couldn't set MACHINE_TASK_PROVIDE to "task-boot" without making task-base.bb PROVIDE task-boot ... |
| 07:38.01 | rwhitby | s/MACHINE_TASK_PROVIDE/MACHINE_TASK_PROVIDER/ of course .. |
| 07:38.10 | koen | I don't think MACHINE_TASK_PROVIDER is suppossed to work like that |
| 07:38.27 | koen | (and PACKAGES should be in PROVIDES automagically iirc) |
| 07:39.11 | rwhitby | Hmm. What's the recommended way to use bootstrap-image to get something smaller than task-base then? |
| 07:39.50 | rwhitby | (I'm assuming bootstrap-image.bb is still the canonical "default" image creation recipe?) |
| 07:40.10 | koen | I stopped using bootstrap-image eons ago |
| 07:40.26 | rwhitby | there seems to be an explosion of images ... |
| 07:40.40 | rwhitby | all doing roughly the same thing |
| 07:40.42 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 07:40.45 | *** join/#oe pro-rsoft (n=pro-rsof@unaffiliated/pro-rsoft) |
| 07:40.46 | koen | yep |
| 07:40.51 | *** part/#oe pro-rsoft (n=pro-rsof@unaffiliated/pro-rsoft) |
| 07:41.27 | rwhitby | should it be possible for all distros to use a common image creation .bb, with distro variables and tasks determining what actually goes into the image? |
| 07:41.32 | koen | "I have this new machine <foo>, with new distro open<foo> and open<foo>-image" was the guilty part in the past |
| 07:41.57 | koen | rwhitby: it should be possible, but might now be sensible |
| 07:42.01 | rwhitby | koen: agreed, that's why I'm trying to do it correctly this time around instead of using angstrom-minimal-image ... |
| 07:42.21 | koen | s/now/not/ |
| 07:42.43 | rwhitby | surely there's nothing "angstrom-ish" about angstrom-minimal-image.bb, right? |
| 07:43.02 | koen | there was till I removed ANGSTROM_EXTRA_INSTALL |
| 07:43.24 | rwhitby | right, which can be done by a DISTRO_EXTRA_RDEPENDS, right? |
| 07:44.04 | koen | it could, but with that it wouldn't be minimal, right? :) |
| 07:44.07 | rwhitby | So I'm now confused - what should MACHINE_TASK_PROVIDER be used for, if not to select which task forms the basis of your image? |
| 07:44.32 | rwhitby | (since everyone currently sets MACHINE_TASK_PROVIDER to task-base) |
| 07:45.37 | koen | right now it should be hardcoded to task-base |
| 07:45.52 | koen | till someone documents valid (read working) options for it |
| 07:46.06 | rwhitby | and what are some examples of what those options would be? |
| 07:46.17 | rwhitby | (I thought an option was task-boot, for instance) |
| 07:46.22 | koen | atm only task-base and task-boot |
| 07:46.41 | Ifaistos | since a lot of embedded systems have 4MB what about having an image that fits that |
| 07:46.45 | rwhitby | but you said before "I don't think MACHINE_TASK_PROVIDER is suppossed to work like that" |
| 07:47.07 | koen | I can see the "I set MACHINE_TASK_PROVIDER to task-wifi and it doesn't boot" problems coming |
| 07:47.14 | rwhitby | I assumed you were saying that I shouldn't be using MACHINE_TASK_PROVIDER to swap from task-base to task-boot |
| 07:47.17 | koen | rwhitby: yes, sorry, I wasn't fully awake yet |
| 07:47.21 | *** join/#oe mithro (n=tim@lester.mithis.com) |
| 07:47.24 | rwhitby | ok, no problem. |
| 07:48.36 | rwhitby | so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size. Then I add other stuff to it using other tasks (like task-wifi). |
| 07:49.07 | sirfred | Good morning |
| 07:49.31 | rwhitby | and if I do that, then I can use bootstrap-image.bb unchanged. |
| 07:49.57 | rwhitby | Is there a different, preferred way to achieve the same result? |
| 07:51.16 | koen | I'm not sure if we should allow multiple entries in MACHINE_TASK_PROVIDER |
| 07:51.33 | rwhitby | yeah, that's what I was concerned about. |
| 07:51.44 | koen | *lightbulb* |
| 07:51.49 | koen | that's what I meant before :) |
| 07:52.36 | rwhitby | So I still need a "generic" image.bb, in which I can use MACHINE_TASK_PROVIDER to switch between task-boot and task-base only, and which has some other variable that I can use to then add stuff to the image on a distro-policy basis. |
| 07:52.46 | koen | I think DISTRO_EXTRA_R* is for things like that |
| 07:53.42 | keesj | Hi! |
| 07:53.47 | koen | I do fear that the contents of <foo>-image can now vary wildly depending on what you set for MACHINE_TASK_PROVIDER |
| 07:53.49 | koen | hey keesj |
| 07:54.11 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 07:54.12 | rwhitby | but DISTRO_EXTRA_R* is only added to task-base. There is (currently) no way I can use DISTRO_EXTRA_R* and angstrom-minimal-image.bb to add stuff to task-boot. |
| 07:54.27 | koen | ah, right |
| 07:54.42 | rwhitby | what is MACHINE_TASK_PROVIDER really meant to be used for? |
| 07:55.00 | koen | to distinguish between task-bootstrap and task-base |
| 07:55.25 | rwhitby | does task-bootstrap still exist? |
| 07:56.03 | keesj | it is easy to assume gcc and glibc proviced? |
| 07:56.09 | koen | rwhitby: I hope not |
| 07:56.29 | rwhitby | koen: so MACHINE_TASK_PROVIDER has no current reason for existence then? |
| 07:56.43 | koen | keesj: like http://www.openembedded.org/user-manual&dpage=commonuse_prebuilt_toolchain ? |
| 07:56.58 | rwhitby | (and no definition of what it should be used for if it did have a current reason for existence) |
| 07:57.01 | koen | rwhitby: not that I know off, but your task-boot suggestion would make sense |
| 07:57.09 | keesj | yes! |
| 07:58.24 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 07:58.25 | __blue119__ | Hi Dear all |
| 07:58.25 | rwhitby | koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something? |
| 07:58.47 | rwhitby | (since it doesn't have anything to do with MACHINEs) |
| 07:59.10 | koen | nor with BOOTSTRAP |
| 07:59.28 | rwhitby | ok, so IMAGE_FOUNDATION_TASK then? |
| 07:59.29 | koen | something like DEFAULT_TASK_PROVIDER? |
| 07:59.51 | rwhitby | yep, DEFAULT_TASK_PROVIDER floats my boat. |
| 08:00.22 | __blue119__ | could anyone help me <(_ _)>? |
| 08:00.23 | koen | do you want to write an RFC for that? |
| 08:00.29 | rwhitby | koen: is there a reason why angstrom-minimal-image has a DEPENDS on task-base but RDEPENDS on task-boot? |
| 08:00.46 | rwhitby | (and does it work for you if you change task-base to task-boot in the DEPENDS?) |
| 08:01.39 | koen | I ran into the provides problem you mentioned and was too lazy to debug that |
| 08:02.16 | rwhitby | ok, so you worked around it there, and I worked around it by setting PROVIDES to ${PACKAGES} in task-base.bb |
| 08:02.49 | koen | yes |
| 08:04.47 | rwhitby | koen: here's a reason for MACHINE_TASK_PROVIDER/DEFAULT_TASK_PROVIDER to accept multiple packages - for mokoslug, I want to set DEFAULT_TASK_PROVIDER to task-boot, but for the nslu2 machine only, I want task-boot *and* sysconf. |
| 08:05.19 | rwhitby | (so that the network comes up out of first boot correctly, since the nslu2 has no console you can use to set the network info) |
| 08:06.41 | __blue119__ | when i build gpe-image, it occur error whcih libxdamage_X11R7.1-1.0.3.bb be compiled |
| 08:10.31 | __blue119__ | i look over error log as if con't find X11.h, but I do not find libx11 in org.openembedded.dev |
| 08:11.19 | koen | rwhitby: it's a reason, but a very bad one |
| 08:13.29 | *** join/#oe TheCan (n=thecan@dslb-084-056-144-220.pools.arcor-ip.net) |
| 08:15.12 | XorA | mroning |
| 08:16.02 | __blue119__ | i don't know how to result the problem that someone can tell me how to do. |
| 08:16.19 | *** join/#oe rd_ (n=rd@segfault.net) |
| 08:16.26 | sirfred | Hey XorA |
| 08:17.24 | XorA | hey sirfred |
| 08:18.15 | sirfred | If someone is interested, I've created recipes for o-hand sato gtk-engine, theme and matchbox theme, as bug 2182 |
| 08:18.52 | rwhitby | koen: RFC sent. |
| 08:19.18 | rwhitby | koen: I specified in the proposal that DEFAULT_TASK_PROVIDER take a singular task value. |
| 08:20.14 | koen | rwhitby: yes, otherwise we end up with another task-bootstrap like variable that includes everything + the kitchensink |
| 08:20.39 | rwhitby | So now I need to write a "generic-image.bb" which uses DEFAULT_TASK_PROVIDER, MACHINE_EXTRA_TASKS, and DISTRO_EXTRA_TASKS. |
| 08:21.15 | koen | sounds like a plan |
| 08:21.36 | rwhitby | koen: you've always said that the distro.conf sets policy. should there be any policy in an image.bb file? |
| 08:21.57 | koen | rwhitby: that's a very good question :) |
| 08:22.13 | rwhitby | (i.e. what characteristic should differentiate one image.bb file from another?) |
| 08:23.09 | rwhitby | currently, most of the existing image.bb files seem to be "<foo>-image.bb = task-base + task-<foo>" |
| 08:23.15 | *** join/#oe pH5 (n=ph5@p5485C01F.dip.t-dialin.net) |
| 08:23.48 | rwhitby | Is that basically how it is supposed to be? |
| 08:25.23 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 08:25.49 | CIA-11 | 03koen 07org.oe.dev * r6f521003... 10/ (3 files in 3 dirs): xtscal: Sharp seems to use Dogname instead of DOGNAME for newer models |
| 08:27.08 | koen | rwhitby: I'm not aware of anyone putting any thought into that |
| 08:27.48 | rwhitby | So there is no definition of how distro, task and image should be differentiated to achieve an intended result/ |
| 08:28.00 | rwhitby | s|/|?| |
| 08:28.09 | XorA | koen: does awk have a toupper/tolower command, it might make more sense to normalise all names :-) |
| 08:29.07 | koen | rwhitby: we have a pretty good picture what goes into distro and machine, but beyond that..... |
| 08:29.12 | koen | XorA: right |
| 08:29.13 | *** join/#oe geekoid_ (n=geekoid@adsl-71-155-232-126.dsl.emhril.sbcglobal.net) |
| 08:30.03 | rwhitby | i.e. whether it is better to have a mokoslug.conf which includes angstrom.conf and then sets DEFAULT_TASK_PROVIDER differently, from which you can build a generic-image.bb to get what you need; or whether one should just use angstrom.conf directly, and put the differences in task-mokogateway and mokogateway-image.bb ? |
| 08:30.54 | rwhitby | ok, I gotta run to catch a bus home, but my dircproxy will keep logging this for me to read (and respond to) in about an hour. |
| 08:31.04 | koen | I'm allergic to 'distros' that just include another distro |
| 08:31.07 | koen | but that's just me |
| 08:33.04 | rwhitby | well, in this case I include angstrom, and then change some policy that I don't agree with. |
| 08:34.04 | rwhitby | (and no, that's not an attempt to start an argument. there may or may not be good reasons to disagree on policy in this case, but there will always be reasons to have different policy in the general case) |
| 08:41.11 | goxboxlive | I had a srange problem. I was trying to compile some stuff, but it failed. I saw there where some updates to GLIBC for couple of days ago, and it seems like wireless.h is missing to defienes. Like #include <linux/ifh> and #include <linux/types.h>. After i dadded it to the wireless.h it compiled. |
| 08:45.58 | sirfred | goxboxlive: I had the same problem, and even opened a bug. |
| 08:46.16 | goxboxlive | sifred: Great, then it is beeing taken care of. |
| 08:46.32 | sirfred | goxboxlive: But someone said that it worked for him, so I was confused. I thing I didn't have that problem on angstrom |
| 08:47.32 | sirfred | goxboxlive: bug 2095 |
| 08:47.50 | sirfred | goxboxlive: It happened to me for openzaurus distro |
| 08:47.51 | goxboxlive | sirfred: Strange, i talked to another person and he had the problme he self when i tried to build a opie image (distro Angstrom). I was trying to compile Opie2 (using crosscompiler in OE) |
| 08:48.36 | sirfred | goxboxlive: Perhaps the patch could be any useful to you |
| 08:48.47 | goxboxlive | sirfred: But he also told me that a console image wherent afected of it, just the Opie image. He didnt tried out x11 though |
| 08:49.11 | goxboxlive | sirfred: I just added the two defines and it compiles for me now. |
| 08:49.38 | goxboxlive | And now, the compilation is finished. Have to try it out. |
| 08:50.09 | sirfred | +#include <linux/types.h> |
| 08:50.09 | sirfred | +#include <linux/if.h> |
| 08:50.09 | sirfred | <PROTECTED> |
| 08:50.14 | sirfred | goxboxlive: That was my patch. |
| 08:50.31 | sirfred | The same you did, I see. |
| 08:51.17 | goxboxlive | yes |
| 08:56.19 | sirfred | Hmm, recent gpe-mini-browser svn versions doesn't seem to work. |
| 08:56.48 | sirfred | I write an url, hit enter and it just sits in front of me, eating all my cpu |
| 08:59.41 | sirfred | Was someone able to build recent mozilla minimo on oe? Impressions? |
| 09:01.16 | koen | not me :) |
| 09:01.17 | XorA | sirfred: if you copy the crap I did for firefox minimo should build |
| 09:01.25 | koen | maybe minimo .2 stands a chance of compiling |
| 09:01.40 | XorA | sirfred: I managed to get it to build a while ago, but then I got disgusted at the really crappy code quality of mozilla |
| 09:02.49 | *** join/#oe psokolovsky_ (n=psokolov@empty-crossing.volia.net) |
| 09:03.25 | sirfred | I tried bitbake minimo and failed in what seemed to be a confusion between host and target libraries |
| 09:03.44 | sirfred | But curiously, their web page recommends oe to build it. |
| 09:04.01 | sirfred | They say to run just "bitbake minimo" |
| 09:04.14 | *** join/#oe Laibsch (n=Laibsch@c-134-177-35.d.dsl.de.ignite.net) |
| 09:04.40 | koen | sirfred: dougt@meer.net for all minimo problems :) |
| 09:05.42 | sirfred | Well, it was that I would like to have a web browser in the zaurus. But I think I'm going back to gstreamer land, more interesting. |
| 09:06.09 | koen | NOTE: package firefox-2.0.0.3-r1: task do_compile: started |
| 09:06.23 | *** join/#oe lrg (n=liam@lrg2.demon.co.uk) |
| 09:06.42 | sirfred | Perhaps the switch to angstrom (and so, NPTL) was good for gstreamer performance |
| 09:07.19 | XorA | sirfred: mozilla code is allergic to EABI :-( |
| 09:07.40 | koen | probably beacuse they hardcode *fpa assumptions |
| 09:07.41 | sirfred | XorA: Uff, enough for me of this, so. |
| 09:08.00 | XorA | koen: I managed to fix that thanks to pb_ patch, but it still segfaults somewhere else |
| 09:08.51 | koen | XorA: I wonder when the debian dudes are going to fix it for armel |
| 09:09.11 | *** join/#oe gremlin[it] (n=gremlin@217.201.2.48) |
| 09:09.15 | sirfred | koen: firefox.. but what is the minimum amount of memory needed to run that? |
| 09:09.24 | sirfred | koen: 1Gb? |
| 09:09.32 | koen | 2Gb |
| 09:09.48 | sirfred | koen: Well, I meant only visiting about:mozilla |
| 09:10.44 | sirfred | If you go for real pages, 2Gb could be short |
| 09:11.27 | XorA | koen: no idea, bet I noticed there is no .deb last time I checked |
| 09:12.09 | XorA | sirfred: C860 |
| 09:12.18 | sirfred | XorA: 64Mb RAM? |
| 09:12.21 | XorA | sirfred: with you accellerated driver firefox runs nicely |
| 09:12.29 | sirfred | XorA: Swap enabled? |
| 09:12.32 | XorA | sirfred: nope |
| 09:12.36 | sirfred | XorA: Nice to hear that |
| 09:13.36 | sirfred | XorA: I've found an interesting thing about the overlay surface. If you place only in 8 pixel multiple places, it's more stable. |
| 09:14.31 | XorA | sirfred: do you mean only on 0,8,16,24,32.... |
| 09:14.43 | sirfred | XorA: Yes. Sorry for my english. :-( |
| 09:15.08 | sirfred | XorA: I have a WIP xserver with that restriction. |
| 09:15.13 | XorA | sirfred: no its fine, I was just checking I was reading it right |
| 09:15.24 | XorA | sirfred: that is a very common restriction in overlays |
| 09:15.38 | XorA | sirfred: so I would say upload the new patch when you are happy with it |
| 09:15.55 | sirfred | XorA: I will update the recipe. yes. |
| 09:16.10 | sirfred | Well, the patch, actually. :) |
| 09:16.37 | sirfred | XorA: I was experimenting with a mplayer gpe frontend, using the mplayer slave mode. |
| 09:17.47 | sirfred | XorA: You mean the w3220 ? |
| 09:18.00 | sirfred | XorA: What's a 3200 ? |
| 09:19.28 | koen | sirfred: zaurus slc-3200 |
| 09:19.35 | koen | that has pxa270fb instead of w100 |
| 09:19.40 | sirfred | koen: And what chip is it wearing? |
| 09:19.43 | sirfred | Ah, ok. |
| 09:19.47 | *** join/#oe polyonymous (n=hacker@pD9539D33.dip0.t-ipconnect.de) |
| 09:20.05 | sirfred | But there's some overlay support for that, true? |
| 09:20.14 | koen | yes |
| 09:20.24 | sirfred | So, what's the problem? |
| 09:20.34 | sirfred | Perhaps there's not an xv port? |
| 09:21.32 | koen | no, only a mplayer vo plugin |
| 09:21.35 | sirfred | Sure there's no less documentation than for the w100 |
| 09:21.48 | sirfred | I'm thinking about assalting ati headquarters and stole the docs. |
| 09:22.19 | sirfred | It's probably less dangerous that the amount of time I've passed looking at disassembled arm code. |
| 09:22.19 | koen | XorA: I had a talk with Justin Treon at ELC, and he said he doesn't have the time to work on pxa270 overlay |
| 09:22.33 | koen | (and we was jumping up and down on hwo great bvdd is) |
| 09:22.56 | XorA | koen: we have working overlay |
| 09:23.10 | koen | XorA: but only in mplayer, right? |
| 09:23.32 | XorA | koen: yes, but all I need is probably a day to merge that with sirfreds excellent work |
| 09:24.03 | sirfred | XorA: Humm, it seems you didn't take a look at it yet. :) |
| 09:24.11 | XorA | koen: what I hadnt managed to figure out on my own was the magic sequence to get it turned on right, my overlay was a black square |
| 09:24.28 | sirfred | XorA: I'm thinking about rewriting some of the xv code. |
| 09:24.39 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 09:24.40 | XorA | koen: now I have an example of how it is turned on right it should be easier |
| 09:24.57 | XorA | who is Justin Treon? |
| 09:27.15 | sirfred | XorA: I was thinking that perhaps a mplayer recipe with just the xv vo driver could be nice, just to save some flash. |
| 09:27.42 | sirfred | Because now, it need some dependencies that are not actually used (libaticore, libw100,...) |
| 09:27.59 | sirfred | Well, at least if you want to use it on X, perhaps a new mplayer-xv package. |
| 09:28.13 | XorA | sirfred: I was thinking of just removing aticore stuff from mplayer |
| 09:29.09 | sirfred | XorA: And leave libw100 ? |
| 09:29.23 | XorA | sirfred: well the opie guys might want some video output |
| 09:29.32 | sirfred | XorA: And what about two packages? |
| 09:29.41 | sirfred | XorA: The opie guys are not interested in xv driver, I suppose. |
| 09:31.20 | XorA | sirfred: pity mplayer doesnt have a plugin interfacve |
| 09:31.36 | sirfred | XorA: Yes, and who dares to add something to it... |
| 09:33.18 | XorA | two packages would be fine by me |
| 09:33.20 | sirfred | XorA: But what's the problem in having two different packages? |
| 09:33.30 | sirfred | XorA: ok |
| 09:33.46 | XorA | sirfred: just need to abstact stuff into mplayer.inc |
| 09:34.36 | XorA | sometimes I think it would be nice to be able to loop a build in a .bb with different args/packages produced each time |
| 09:35.19 | sirfred | XorA: meta-bb !! |
| 09:35.56 | koen | XorA: like collie-kernels did? |
| 09:36.12 | XorA | koen: did they? |
| 09:36.27 | koen | XorA: sort of |
| 09:36.41 | koen | it depended on all the permutation recipes |
| 09:37.33 | XorA | foreach ARG in $ARGS; do_tasks(); done |
| 09:37.39 | sirfred | Since some time ago, /etc/init.d/gpe-dm seems to not store the right PID to perform correctly the 'stop' command |
| 09:38.16 | sirfred | It seems that someone is forking before expected, because the stored PID uses to be one less than the real one. |
| 09:40.50 | sirfred | Humm, looking at the source code, I see a if (! nodaemon) daemon(0, 0); after create_pidfile(). |
| 09:41.19 | sirfred | And that daemon call, I will bet it needs to fork. |
| 09:42.39 | sirfred | Looking at the manual page, yes, it forks. So, I think the create_pidfile should be moved after daemon. |
| 09:43.52 | *** join/#oe lazy_marmot (n=lgopher@85.233.43.112.static.cablesurf.de) |
| 09:46.33 | *** join/#oe florian_ (n=fuchs@87.193.42.183) |
| 09:47.42 | rwhitby | koen: so to change policy, but remain binary compatible with Angstrom, how else should I do it instead of including angstrom.conf in mokoslug.conf and then overriding what needs to change (especially when there is no -= operator in bitbake yet) ? |
| 09:48.15 | koen | rwhitby: I didn't say it was wrong, just that I'm allergic to it |
| 09:48.53 | rwhitby | ok, it's good to understand that difference, cause you react the same way in both cases :-) |
| 09:50.15 | rwhitby | I've learnt not to copy and global replace on conf files, and I've learnt not to add lots of new DISTRO_FOO variables to conf files. the only option left is include and override standard variables. |
| 09:50.40 | rwhitby | (assuming it can't be done in the "parent" distro, like the -= case) |
| 09:50.50 | koen | rwhitby: http://rafb.net/p/nnypQR86.html |
| 09:50.56 | koen | (read around the dutch) |
| 09:52.08 | rwhitby | ok, I will re-check arm-kernel-shim at that point, cause I truly think I remember seeing the truncation problem on armel too for arm-kernel-shim cmdline processing. |
| 09:53.32 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 09:59.02 | sirfred | Hmm, that seemed to be the reason, I've delayed the create_pidfile after daemon() and it works fine now. |
| 09:59.18 | sirfred | I've opened a bug in the gpe bugtracker. |
| 09:59.59 | florian_ | sirfred: thanks |
| 10:00.05 | sirfred | florian_: np |
| 10:00.38 | florian_ | sirfred: the fix in svn already for a while i need to make a new release |
| 10:01.07 | sirfred | florian_: I've also seen that the higher available version in the bugtracker is 0.48 |
| 10:01.21 | sirfred | florian_: And I'm using 0.50 |
| 10:01.52 | florian_ | sirfred: right, i need to run the script that creates the versions again |
| 10:01.55 | sirfred | florian_: I was tempted to check the svn code, but was too lazy. |
| 10:02.32 | *** join/#oe geekoid_ (n=geekoid@adsl-75-4-44-99.dsl.emhril.sbcglobal.net) |
| 10:03.12 | florian_ | sirfred: right, the problem was quite obvious and trivial to fix... |
| 10:03.36 | sirfred | florian_: Yes, even easier than browsing the svn. :) |
| 10:07.04 | florian_ | sirfred: indeed |
| 10:09.06 | CIA-11 | 03hrw 07org.oe.dev * r57d2b2fc... 10/ (1 packages/xorg-lib/libice_1.0.3.bb): libice: added 1.0.3 |
| 10:09.10 | CIA-11 | 03hrw 07org.oe.dev * r1e0fdf5f... 10/ (1 packages/xorg-lib/libxaw_1.0.3.bb): libxaw: added 1.0.3 |
| 10:09.15 | CIA-11 | 03hrw 07org.oe.dev * r0a8ed31e... 10/ (1 packages/xorg-lib/libxfont_1.2.8.bb): libxfont: added 1.2.8 |
| 10:09.19 | CIA-11 | 03hrw 07org.oe.dev * r0bacc074... 10/ (1 packages/xorg-lib/libxi_1.1.0.bb): libxi: added 1.1.0 |
| 10:09.23 | CIA-11 | 03hrw 07org.oe.dev * r0ebfce61... 10/ (1 packages/xorg-lib/libxinerama_1.0.2.bb): libxinerama: added 1.0.2 |
| 10:09.27 | CIA-11 | 03hrw 07org.oe.dev * rc8eec3ec... 10/ (1 packages/xorg-lib/libxrandr_1.2.1.bb): libxrandr: added 1.2.1 |
| 10:09.36 | CIA-11 | 03hrw 07org.oe.dev * ra3f21934... 10/ (1 packages/xorg-lib/libxt_1.0.5.bb): libxt: added 1.0.5 |
| 10:09.46 | CIA-11 | 03hrw 07org.oe.dev * r0a229750... 10/ (1 packages/xorg-lib/libxv_1.0.3.bb): libxv: added 1.0.3 |
| 10:09.59 | CIA-11 | 03hrw 07org.oe.dev * r02fe531a... 10/ (3 files in 2 dirs): mkfontdir: added 1.0.3 |
| 10:10.08 | CIA-11 | 03hrw 07org.oe.dev * r84d6d7cf... 10/ (1 packages/xorg-app/xdm_1.1.4.bb): xdm: added 1.1.4 |
| 10:10.12 | hrw|gone | all should build. did not tested on device. some need versioned dependencies to build (xrandr for example) |
| 10:10.17 | hrw|gone | bye all - have a nice day |
| 10:10.20 | CIA-11 | 03hrw 07org.oe.dev * rb034fcc5... 10/ (1 packages/xorg-app/xrandr_1.2.0.bb): xrandr: added 1.2.0 |
| 10:10.28 | CIA-11 | 03hrw 07org.oe.dev * r44641351... 10/ (1 packages/xorg-app/xrdb_1.0.3.bb): xrdb: added 1.0.3 |
| 10:10.36 | CIA-11 | 03hrw 07org.oe.dev * r59404f96... 10/ (1 packages/xorg-driver/xf86-input-evdev_1.1.5.bb): xf86-input-evdev: added 1.1.5 |
| 10:10.41 | CIA-11 | 03hrw 07org.oe.dev * rf1e95d09... 10/ (1 packages/xorg-driver/xf86-input-keyboard_1.2.0.bb): xf86-input-keyboard: added 1.2.0 |
| 10:10.49 | CIA-11 | 03hrw 07org.oe.dev * r1f5dfd28... 10/ (1 packages/xorg-driver/xf86-input-mouse_1.2.1.bb): xf86-input-mouse: added 1.2.1 |
| 10:10.54 | CIA-11 | 03hrw 07org.oe.dev * r81b96598... 10/ (1 packages/xorg-driver/xf86-video-siliconmotion_1.5.1.bb): xf86-video-siliconmotion: added 1.5.1 |
| 10:22.32 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 10:25.38 | *** join/#oe xjqian (n=gordon@71-85-151-212.dhcp.stls.mo.charter.com) |
| 10:27.20 | *** join/#oe zecke (n=ich@dsl-62-220-14-162.berlikomm.net) |
| 10:45.21 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 10:49.59 | koen | hey zecke |
| 10:50.36 | zecke | ho |
| 10:53.53 | *** join/#oe geekoid__ (n=geekoid@adsl-75-4-45-68.dsl.emhril.sbcglobal.net) |
| 11:01.13 | *** join/#oe shreyas (n=Shreyas@59.92.222.207) |
| 11:02.13 | *** join/#oe lrg_ (n=liam@lrg2.demon.co.uk) |
| 11:31.37 | *** join/#oe ade|desk (n=adavey@194.200.143.249) |
| 11:32.11 | ade|desk | morning all |
| 11:33.19 | CIA-11 | 03bero 07org.oe.dev * r33db0448... 10/ (4 files in 3 dirs): |
| 11:33.19 | CIA-11 | perl-native: Patch perl's makedepend.SH to work with gcc 4.2. Shouldn't be |
| 11:33.19 | CIA-11 | needed for perl since it doesn't run makedepend.SH. Closes #2168 |
| 11:37.31 | chouimat | morning |
| 11:42.56 | *** join/#oe rob_w (n=bob@p85.212.17.38.tisdip.tiscali.de) |
| 11:55.50 | CIA-11 | 03lenehan 07org.oe.dev * r147dd5eb... 10/ (3 files in 3 dirs): (log message trimmed) |
| 11:55.51 | CIA-11 | perl 5.8.8: Allow perl to build when using an external toolchain. |
| 11:55.51 | CIA-11 | This is done by allowing gcc to search for errno.h by itself instead |
| 11:55.51 | CIA-11 | of manually searching for. The manual search was looking in |
| 11:55.51 | CIA-11 | STAGING_INCDIR and that's not where the external toolchains headers |
| 11:55.51 | CIA-11 | are. This whole test is really for handle other compilers and |
| 11:55.55 | CIA-11 | operating systems, so the simple make gcc do itself should be fine |
| 11:59.28 | *** join/#oe TheCan (n=thecan@dslb-084-056-144-220.pools.arcor-ip.net) |
| 12:10.47 | *** join/#oe mr_nice (n=mr_nice@p54A9DDD8.dip.t-dialin.net) |
| 12:11.42 | *** join/#oe svolpe_gerrath (n=Gerrath_@unaffiliated/gerrath) |
| 12:13.22 | koen | ~lart htc universal people |
| 12:13.22 | ibot | send killer squirrels to attack htc universal people |
| 12:14.13 | CIA-11 | 03koen 07org.oe.dev * r53e01bb2... 10/ (3 files in 3 dirs): |
| 12:14.13 | CIA-11 | xtscal: reinstate tr toupper filter so everything works again. |
| 12:14.14 | CIA-11 | NOTE: it would be nice if machine maintainers run the script on their device |
| 12:14.14 | CIA-11 | instead of pasting a line from /proc/cpuinfo. If the htc universal people had |
| 12:14.14 | CIA-11 | done so, they would have noticed everything comes up in *uppercase*. So xtscal |
| 12:14.14 | CIA-11 | wasn't broken |
| 12:18.57 | v8jlene | Hmm.. bitbake's 1.8.2's parsing of all RDEPENDS in task-base, including those that aren't being used, is annoying. I now need to pull in several hundred more packages (which are not going to be used) just to parse that file ;( |
| 12:19.42 | *** join/#oe svolpe (n=Gerrath_@unaffiliated/gerrath) |
| 12:22.21 | koen | v8jlene: that's the side-effect of needing to now how to rename libraries when using debian.bbclass |
| 12:23.39 | koen | and indeed very annoying |
| 12:24.34 | v8jlene | koen: Ok. I guess I don't re-parse all that often. I've gone from have 800 recipes to 4500 so parse - definitely a bit slower! (I just added them all since figuring out what I needed isn't a job for now). |
| 12:24.55 | Crofton|home | anyone know much about rpath? |
| 12:25.03 | Crofton|home | I am looking at gcc-cross |
| 12:29.56 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 12:29.57 | zecke | Crofton|home: rule of thumb, all rpath's on linking are bad |
| 12:29.57 | zecke | CoreDump|afk: only -rpath-link makes sense and is fine |
| 12:30.29 | Crofton|home | hmm |
| 12:30.29 | Crofton|home | I am trying to figure out where it comes from and how we can remove |
| 12:30.29 | Crofton|home | for example, this is from run.do_configure.22111 |
| 12:30.30 | Crofton|home | for gcc-cross |
| 12:30.31 | Crofton|home | export LDFLAGS="-L/home/balister/oe/tmp/staging/i686-linux/lib -Wl,-rpath-link,/ |
| 12:30.33 | Crofton|home | home/balister/oe/tmp/staging/i686-linux/lib -Wl,-rpath,/home/balister/oe/tmp/sta |
| 12:30.33 | Crofton|home | ging/i686-linux/lib -Wl,-O1" |
| 12:31.11 | Crofton|home | so rpath-link does not impact runtime? |
| 12:31.12 | *** join/#oe florian (n=fuchs@87.193.42.183) |
| 12:31.35 | zecke|food | right |
| 12:32.16 | zecke|food | is gcc-cross packaged and installed? if it is a sort of -native tool I would the rpath is okay for now as well |
| 12:32.31 | zecke|food | well, the rpath should be okay for now, for packaged staging this would need fixing |
| 12:32.55 | Crofton|home | toolchain production is black magic to me |
| 12:33.41 | zecke|food | Crofton|home: well, I assume the lib will be installed into that dir /home/balister/oe/tmp/staging/i686-lib. |
| 12:34.04 | Crofton|home | well, then insane shouldn't care about the RPATH |
| 12:34.52 | zecke|food | Crofton|home: well, you might be right |
| 12:35.03 | zecke|food | Crofton|home: I though only to be packaged files will be checked |
| 12:35.30 | Crofton|home | http://bugs.openembedded.org/show_bug.cgi?id=2152 |
| 12:35.34 | Crofton|home | Here is the bug report |
| 12:36.07 | Crofton|home | who are the toolchain gurus? |
| 12:36.30 | Crofton|home | The problem with rpath is we all know it is bad, but we aren't real good at fixing the problem :) |
| 12:36.55 | *** join/#oe stevenh (n=lews@65.167.23.2) |
| 12:37.19 | zecke|food | bbl |
| 12:53.21 | *** join/#oe osas (n=osas@CABLE-72-53-75-252.cia.com) |
| 12:55.42 | *** join/#oe concept10 (n=concept1@ppp-70-247-162-218.dsl.rcsntx.swbell.net) |
| 12:57.48 | *** join/#oe vervain (n=vervain@mail.somat.com) |
| 12:59.12 | *** part/#oe concept10 (n=concept1@ppp-70-247-162-218.dsl.rcsntx.swbell.net) |
| 13:11.20 | *** join/#oe x29a (n=x29a@unaffiliated/x29a) |
| 13:15.32 | *** join/#oe wrobbie (n=rob@cm74.kappa84.maxonline.com.sg) |
| 13:20.50 | *** part/#oe x29a (n=x29a@unaffiliated/x29a) |
| 13:20.55 | *** join/#oe psokolovsky__ (n=psokolov@82.193.98.2) |
| 13:21.07 | *** join/#oe xuumbi (n=jim@70.90.111.225) |
| 13:21.52 | keesj | oe look very promissing. what feature will I first miss? what part of OE is ugly? |
| 13:22.45 | polyonymous | you will miss the feature you need which isn't implemented, I guess. And the uglies part of OE is the one you dislike the most. |
| 13:24.19 | xuumbi | how do I make a list of packages get built when I run "bitbake my-image", but not be dependencies of the resulting root file system? |
| 13:24.54 | xuumbi | right now I have "export PACKAGE_INSTALL" setting a list of packages in my image .bb file |
| 13:25.30 | xuumbi | but if I run "bitbake my-image" it's not building that list of packages first, so it can't find them when it tries to install them in the image |
| 13:26.19 | xuumbi | I used to set DISTRO_EXTRA_RDEPENDS to my package list, but that made the packages dependencies of the root file system, so if I tried to remove them from the target I had to use "ipkg remove -force-depends" |
| 13:26.52 | polyonymous | xuumbi, I'd guess you need RDEPEND in my-image.bb |
| 13:26.55 | xuumbi | there must be an easy way to have a list of packages built during the image creation process |
| 13:27.06 | polyonymous | hm. |
| 13:27.16 | polyonymous | well, I haven't tried it yet :) |
| 13:28.06 | xuumbi | polyonymous: yeah that would make sense... let me try |
| 13:28.40 | *** join/#oe likewise (n=chatzill@atwork-186.r-212.178.104.atwork.nl) |
| 13:30.28 | likewise | hello all |
| 13:32.14 | keesj | what I don't like is that I can't perform some actions because I am behind a firewall |
| 13:32.37 | keesj | git and mtn just won't work :( |
| 13:33.02 | keesj | for mtn I use a ssh tunnel , for git I carry my hd home |
| 13:38.13 | *** join/#oe rd_ (n=rd@segfault.net) |
| 13:48.44 | keesj | was image_ipk renamed to image? |
| 13:49.35 | Crofton|home | gm |
| 13:50.29 | Crofton|home | likewise, for bug 2152, does it matter that RPATH exists |
| 13:50.39 | Crofton|home | doesn't gcc-cross run only on the build amchine? |
| 13:50.43 | vervain | Is there a general guide to bitbake and the org.openembedded repository structure? |
| 13:51.13 | vervain | I think I've exhausted the documentation but I feel as if there is a large gap between the docs and the implementation. |
| 13:52.46 | likewise | Crofton|home: yes, it's no problem there, might even be desirable. However, I'm wondering what a target gcc and its lib looks like. |
| 13:53.15 | Crofton|home | can we fix insane.bbclass so it doesn't report the gcc-cross as an error? |
| 13:53.24 | likewise | vervain: If that's true, complain here, or on the mailing list. |
| 13:53.43 | likewise | Crofton|home: yes, about to do so (if I have my mtn key here... lemme check) |
| 13:53.57 | Crofton|home | ok |
| 13:54.04 | Crofton|home | that fixes one bug at leat :) |
| 13:54.30 | Crofton|home | I disabled insane.bbclass in my school machine so I can do OSK builds |
| 13:54.49 | Crofton|home | but at home I will leave it enabled and try to sovle problems as I can |
| 13:54.56 | likewise | Crofton|home: "if bad_dir in txt |
| 13:54.58 | likewise | 'whoops |
| 13:56.53 | likewise | Crofton|home: A bit of a workaround, but replacing "if bad_dir_test in txt:" by "if bad_dir in txt:" will only check against RPATHs that have "work/" in them, which skips the cross/ items AFAIK. |
| 13:57.08 | cbrake | vervain: feel free to ask questions. OE makes a lot of sense once you get your mind around it. But, in my experience this usually takes developers several weeks of working with it before this happens. |
| 13:57.58 | likewise | cbrake: yes, but any comments vervain has now helps us to smoothen the learning curve, which is steep and too bumpy. |
| 13:58.41 | zecke|food | likewise: if these newcomers would contribute to the documentation :) |
| 13:59.23 | *** join/#oe tomimo (n=kurre@a80-186-77-174.elisa-laajakaista.fi) |
| 13:59.24 | likewise | zecke|food: being unsure about how things work (which is common for all beginners here) often does not make on commit documentation fixes. |
| 14:00.41 | zecke|food | unsure -> ask -> answer -> update documentation -> review -> unsure :) |
| 14:00.41 | likewise | zecke|food: but I feel guilty about not having committed doc fixes myself. |
| 14:00.57 | likewise | exactly :-) |
| 14:01.18 | zecke|food | but most people do unsure -> ask -> answer -> unsure without giving back :) |
| 14:02.24 | cbrake | reading through the documentation, we do seem to be lacking in tutorial type documentation. Something that starts with simple concepts and gradually exposes the user to more advanced concepts. |
| 14:03.07 | cbrake | will Mickey's book accomplish this? |
| 14:03.27 | zecke|food | I don't know |
| 14:03.37 | zecke|food | it could |
| 14:05.24 | *** join/#oe AMDPenguin (i=nobody@nat/amd/x-36632f7716b1d3d9) |
| 14:06.52 | keesj | Can I have a wiki account? |
| 14:09.04 | Laibsch | keesj: Sure. http://www.openembedded.org/user/login |
| 14:09.15 | Laibsch | Should have an option so sign up |
| 14:09.42 | koen | since when does one need an account for the wiki? |
| 14:09.45 | zecke|food | you can edit the wiki without an acocunt |
| 14:10.58 | vervain | I am willing to help with documentation but I'm trying to avoid re-inventing wheels. |
| 14:11.44 | keesj | Laibsch can't find it |
| 14:12.26 | vervain | I find myself often not knowing if my answer should lie inside OE, BitBake or on of the other projects GPE/Familiar/Etc. |
| 14:13.11 | koen | vervain: familiar is dead |
| 14:13.30 | Laibsch | koen: The point, though, is still valid |
| 14:13.36 | vervain | Is bb used on any other significant projects other than OE... perhaps that would give me mroe insight into bb. |
| 14:13.49 | cbrake | vervain: probably not, but it could be |
| 14:15.20 | cbrake | vervain: bitbake is general purpose and mainly handles things parsing bb files, managing variables, dependencies, tasks, and executing tasks. |
| 14:15.28 | vervain | koen: Really - So no more development for H5500 etc... I still have one ;-) |
| 14:16.00 | koen | vervain: why so? |
| 14:16.08 | koen | vervain: h5xxx is supported by angstrom |
| 14:16.26 | vervain | koen: Aha.. I didn't know that. |
| 14:17.05 | keesj | hmm , I can edit the wiki , I just did not try before I ran "edit" , just pressed login and did not get an account. Ooops |
| 14:17.36 | vervain | cbrake: I think I'll 'walk through' the bb process for say bootstrap-image from local.conf through and write down what I find... understanding what all get's pulled in and why is the part I'm missing. |
| 14:20.09 | cbrake | vervain: in a nut shell, the various *.conf files are combined to create a bunch of env variables (see <oe>/conf/bitbake.conf), and then bitbake parses *.bb & *.class files to come up with a bunch of packages to build and tasks to run. Dependencies determine what gest build and can be viewed by running running bitbake with the -g option and looking at the resulting *.dot files. |
| 14:22.53 | vervain | cbrake: ya - I think it's the -g option that I need to start playing with more... |
| 14:23.03 | vervain | This link http://www.openembedded.org/wiki/HowToCheckForExistingPackagesn seems broken. |
| 14:23.06 | keesj | I guess OpenEmbeded is ready for a book! |
| 14:23.17 | vervain | From: http://www.openembedded.org/wiki/DirectoryStructure |
| 14:26.27 | *** join/#oe lrg (n=liam@lrg2.demon.co.uk) |
| 14:31.35 | *** join/#oe kb7sqi (i=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 14:36.19 | keesj | where do want documentation contributions for the manual? |
| 14:36.28 | keesj | (not the wiki but the manual) |
| 14:36.38 | xuumbi | polyonymous: no luck, setting RDEPENDS in my image bitbake file doesn't work :( |
| 14:38.11 | xuumbi | if anyone else can help... I'm trying to setup a custom image bitbake file that builds a list of packages, but doesn't make them dependencies of the resulting image |
| 14:42.31 | *** join/#oe zecke_ (n=ich@dsl-62-220-14-162.berlikomm.net) |
| 14:43.49 | Laibsch | keesj: check out the org.openembedded.documentation branch from mtn |
| 14:44.26 | Laibsch | make your changes and attach the output of "mtn diff org.openembedded.documentation" to the bug tracker |
| 14:44.33 | Laibsch | Let me know if you need help with that. |
| 14:45.49 | polyonymous | Laibsch, are you bugs.*@rolf.*? ;-) |
| 14:46.13 | keesj | thanks I will |
| 15:00.51 | *** join/#oe Gerrath (n=Gerrath_@unaffiliated/gerrath) |
| 15:05.06 | Laibsch | polyonymous: yes, thought you knew |
| 15:05.21 | polyonymous | Laibsch, Yes, I guessed, but wanted to make sure. |
| 15:05.31 | Laibsch | <PROTECTED> |
| 15:05.36 | polyonymous | For no apparent reason, just to complete the picture |
| 15:05.39 | Laibsch | removes any doubt |
| 15:05.57 | polyonymous | no, it doesn't. |
| 15:06.17 | Laibsch | Indeed, it does not |
| 15:06.20 | polyonymous | ;-) |
| 15:06.29 | Laibsch | and better so. I never liked it |
| 15:06.40 | Laibsch | Must have fixed that in the meantime |
| 15:06.57 | polyonymous | Anyway, let me apologize for all my future submissions as well :) I mean, I'll try to be more specific, but I can't promise I will succeed :) |
| 15:07.40 | polyonymous | notwithstanding, I think it's better that I continue submissions instead of just shutting up :) |
| 15:07.50 | Laibsch | bugzilla usually has these steps lined out "What were you doing?", "what do you think should have happened", "what happened", etc. |
| 15:08.02 | Laibsch | polyonymous: that is for certain |
| 15:08.32 | polyonymous | Yes, I'll try. It's just that I think that patches are really self-descriptive, but you're right - you first read summary, not a patch. |
| 15:08.57 | polyonymous | Laibsch, do you think I should also submit fixes for unsupported opie part of angstrom as well? |
| 15:09.02 | Laibsch | But it would be nice if you sometimes stepped back and asked yourself "If I read this would I be able to understand what the other person was doing and what they were trying to achieve and failed"? |
| 15:09.17 | polyonymous | Yes, I agree. |
| 15:09.23 | Laibsch | opie is only unsupported in one person's mind |
| 15:09.37 | polyonymous | Okay, then it won't hurt if I submit patches. |
| 15:09.38 | Laibsch | It really is supported |
| 15:09.48 | Laibsch | OK, it would be very nice if you did. |
| 15:09.58 | Laibsch | No, it would be very nice if you did. |
| 15:10.21 | polyonymous | My tree is dirty like hell, I even think maybe I should branch locally (guess mtn supports that, otherwise what's distributed about it:)) |
| 15:10.41 | polyonymous | Okay, I'll go for yet another submission now :) |
| 15:11.08 | Laibsch | polyonymous: "mtn ls changed" "mtn ls unknown" are of great help |
| 15:11.15 | Laibsch | It keeps me sane |
| 15:11.21 | polyonymous | Laibsch, yes, as well as mtn status |
| 15:11.43 | *** join/#oe vivijim (n=vivijim@200.184.118.132) |
| 15:11.47 | polyonymous | I think mtn status makes more sense that mtn ls changed even. |
| 15:12.09 | Laibsch | You can also use quilt to keep your OE tree "clean" when you need it clean |
| 15:13.08 | polyonymous | Yes, but that you can do with any vcs, it doesn't take a distributed one. I think mtn should support local branches. I'm not familiar with mtn, but I guess it shares concepts with git which I use a lot. |
| 15:14.03 | Laibsch | psokolovsky__: What were you trying to say with "consequently" in your last bug comment? |
| 15:14.43 | psokolovsky__ | Laibsch: consequently it's not really a libopie2 problem ;-). at least, not only it could break. |
| 15:14.52 | Laibsch | polyonymous: Yes, it works. But I prefer KISS whenever possible. A branch was too complicated for me until now. |
| 15:15.08 | polyonymous | Laibsch, one step at a time :) |
| 15:15.14 | Laibsch | psokolovsky__: So what package is the problem in? |
| 15:15.21 | Laibsch | Can you reassign? |
| 15:15.32 | *** join/#oe marcan (n=marcanso@160.10.7.121) |
| 15:15.36 | Laibsch | I mean update the summary? |
| 15:15.43 | polyonymous | what is not libopie2 problem? Did I submit a patch for it yet? :) |
| 15:16.01 | Laibsch | polyonymous: no |
| 15:16.13 | Laibsch | !oebug 2193 |
| 15:16.14 | cdbot2 | * * Bug 2193, Status: NEW, Created: 2007-05-01 04:43 |
| 15:16.15 | cdbot2 | * * bugs.openembedded.org(AT)rolf.leggewie.biz: libopie2 fails do_compile for MACHINE="qemuarm" and angstrom |
| 15:16.16 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=2193 |
| 15:16.16 | polyonymous | Laibsch, maybe I should. I have a patch for a wireless problem. |
| 15:16.24 | psokolovsky__ | Laibsch: no, I don't think reassign is need, the problem with linux-headers, or how it is called, apparently. I'm investigating. In the end, we'd of course patch libopie, not linux ;-) |
| 15:16.59 | polyonymous | aha |
| 15:17.04 | polyonymous | I have a patch for this problem. |
| 15:17.10 | polyonymous | Not that I LIKE the patch... |
| 15:17.10 | Laibsch | OK, as long as it works (which is my main concern (I am glad most devs around here are not like that)) |
| 15:17.44 | Laibsch | polyonymous: You are welcome to attach the patch to the BTS |
| 15:17.46 | polyonymous | http://rafb.net/p/9XxJsw68.html |
| 15:17.55 | *** join/#oe svolpe (n=Gerrath_@unaffiliated/gerrath) |
| 15:18.10 | polyonymous | Yes, that's a option. For the time being feel free to look at it. |
| 15:18.21 | polyonymous | ah, no, this patch is ok. |
| 15:18.29 | polyonymous | I've had the other patch which I don't like... |
| 15:18.32 | Laibsch | polyonymous: I think you miss file://include.pro |
| 15:18.51 | polyonymous | what do you mean I miss? It's there, isn't it? |
| 15:18.58 | Laibsch | Is it? |
| 15:19.07 | polyonymous | you mean in my patch? |
| 15:19.13 | polyonymous | lines 34/35 |
| 15:19.15 | Laibsch | I assumed it was added by you since it was not in the recipe |
| 15:19.23 | Laibsch | OK, don't worry |
| 15:19.33 | polyonymous | no, it was |
| 15:19.37 | Laibsch | psokolovsky__: What do you think? |
| 15:19.40 | polyonymous | the line is changed to add a \ at the end. |
| 15:19.51 | Laibsch | Oh, right |
| 15:20.06 | polyonymous | The uglier patch was to qte-mt, I think... |
| 15:20.22 | psokolovsky__ | Laibsch: I'm out of context, sorry |
| 15:20.58 | Laibsch | polyonymous: Would you care to be "official opie maintainer" in angstrom? |
| 15:20.58 | Laibsch | psokolovsky__: Just forget anything but the last line from me. |
| 15:21.29 | polyonymous | Laibsch, I'm not sure if I will have time for it, but as long as I have time I'll do my best to contribute. |
| 15:21.30 | Laibsch | psokolovsky__: What do you think about http://rafb.net/p/9XxJsw68.html, a patch to 2193 from polyonymous |
| 15:21.37 | psokolovsky__ | Laibsch: there's big urge to have second maintainer, that's presupposition for opie to actually be in angstrom |
| 15:22.03 | Laibsch | psokolovsky__: You know there already *are* two maintainers |
| 15:22.08 | Laibsch | You and me |
| 15:22.24 | Laibsch | Some stuff is less actively being worked on. |
| 15:22.33 | psokolovsky__ | Laibsch, polyonymous: looks good, but needs to be submitted upstream ;-) |
| 15:22.49 | polyonymous | psokolovsky__, I can submit it to both trackers. |
| 15:22.52 | Laibsch | psokolovsky__: Commit locally until committed upstream? |
| 15:23.00 | *** join/#oe kurre2_ (n=tomimo@a80-186-77-174.elisa-laajakaista.fi) |
| 15:23.01 | psokolovsky__ | Laibsch: I'm glad you out it like that. let's let Koen know about that ;-) |
| 15:23.05 | polyonymous | should I attach it to bugzilla? |
| 15:23.13 | psokolovsky__ | Laibsch: sure |
| 15:23.24 | psokolovsky__ | polyonymous: please do, for any patch ;-) |
| 15:23.32 | polyonymous | will do. |
| 15:23.42 | Laibsch | psokolovsky__: I (and others) have told him numerous times. But you know he only hears what he wants to |
| 15:23.46 | polyonymous | and submit to mantis as well? |
| 15:24.51 | psokolovsky__ | polyonymous: yes, exactly, I'm sorry about that duplication, but that's what we have now. |
| 15:25.01 | polyonymous | no problem. |
| 15:25.06 | polyonymous | I attached it to bugzilla. |
| 15:25.32 | psokolovsky__ | polyonymous: and please-please submit all patche sto tracker - they will never be lost. because at any given time someone may be not around, or busy with sth else. |
| 15:26.06 | polyonymous | psokolovsky__, I do, most of the time (poor Laibsch:)). |
| 15:26.37 | psokolovsky__ | ok ;-) |
| 15:27.06 | Laibsch | polyonymous: you know about PR (the variable)? |
| 15:27.10 | polyonymous | psokolovsky__, Is libopie2 considered 'core' ? |
| 15:27.15 | polyonymous | Laibsch, yes :) |
| 15:27.23 | Laibsch | OK |
| 15:27.31 | Laibsch | I will commit your patch tonight |
| 15:27.32 | polyonymous | But I think it only needs to be bumped when you add functionality fix. |
| 15:27.37 | psokolovsky__ | polyonymous: core of opie, yep, apparently |
| 15:27.49 | polyonymous | I mean, if you already have it built, you don't need to upgrade. |
| 15:28.02 | polyonymous | psokolovsky__, Ok. Just to make sure I submit it properly. |
| 15:28.02 | psokolovsky__ | polyonymous: when package would change |
| 15:28.34 | polyonymous | psokolovsky__, yes, package. As in, e.g., ipk. But if you add a build fix, then what's the use of bumping PR? You can't possibly have older revision. |
| 15:29.39 | psokolovsky__ | polyonymous: is package contents or metadata change, bump PR. otherwise, ipkg won't notice new package, or at least, that it's in fact new package |
| 15:29.44 | polyonymous | in fact, I think the patch should be submitted upstream to kernel, wouldn't it make sense for wireless to include type definitions? |
| 15:30.00 | *** join/#oe tnb (n=tnb@sdgsystems.net) |
| 15:30.19 | polyonymous | psokolovsky__, Exactly. And you don't need ipkg to notice the package if all you've done is fixed compile issues. |
| 15:31.16 | Laibsch | polyonymous: Makes a lot of sense what you're saying |
| 15:31.25 | Laibsch | I just increase it by default ;-) |
| 15:31.50 | polyonymous | that shouldn't hurt much either. |
| 15:31.52 | Laibsch | Which I think has merit - thinking of it |
| 15:31.54 | psokolovsky__ | polyonymous: well, maybe. but quoting Koen, "PRs are cheap - bump them!" |
| 15:32.27 | Laibsch | polyonymous: Consider the person with an incomplete compilation? Unless they do -c rebuild or -c clean they might run into trouble |
| 15:32.45 | polyonymous | psokolovsky__, That is also valid point. Doesn't invalidate mine, though. I think we can coexist with different opinions. At least as long as I'm not committing directly to tree :) |
| 15:32.49 | Laibsch | so yes, they are cheap. And it does not hurt |
| 15:33.12 | polyonymous | Laibsch, what you're talking about is something that bitbake should take care of, I think. |
| 15:33.21 | psokolovsky__ | polyonymous: well, you asked, that was just a suggestion ;-) |
| 15:33.48 | polyonymous | psokolovsky__, Yes, it's nice to share opinions and broaden our views :) |
| 15:33.53 | Laibsch | polyonymous: It probably does. But better safe than sorry |
| 15:34.20 | polyonymous | There's nothing wrong with being sorry and being always safe is boring :))) |
| 15:34.29 | Laibsch | :-D |
| 15:35.27 | polyonymous | I don't like mantis, in fact. :) |
| 15:35.54 | polyonymous | here we are, failing opie-networksettings with the same wireless problem. |
| 15:37.37 | Laibsch | polyonymous: no more changes to the patch you attached from the rafb.net stuff, right? |
| 15:38.01 | polyonymous | Laibsch, no, that's the complete patch against .dev tree. |
| 15:38.46 | polyonymous | and the patch for opie-networksettings follows shortly :) |
| 15:40.10 | tnb | I have been seeing arm alignment problems on Angstrom builds. Anyone else seen that? I think it may be peculiar to Bluetooth? |
| 15:40.42 | koen | tnb: Marcel Holtmann said bluez really needs those unaligned accesses :( |
| 15:41.15 | koen | he noticed them as well on his neo1973 |
| 15:41.25 | tnb | koen: hmm, I see. so we just ignore the messages? |
| 15:41.48 | koen | tnb: for the time being, yes |
| 15:41.48 | *** join/#oe ozstinger (n=ozstinge@216.143.234.167) |
| 15:42.48 | tnb | koen: ok, thanks. |
| 15:44.40 | koen | v8jlene: where did perl-module-strict go? |
| 15:45.26 | koen | v8jlene: I moved 5.8.4 and 5.8.7 out of the way, and bitbake now complains nothing provides perl-module-strict (needed for automake) |
| 15:48.49 | v8jlene | koen: deploy/ipk/i486/perl-module-strict_5.8.8-r9_i486.ipk, tmp/deploy/ipk/sh4/perl-module-strict_5.8.8-r9_sh4.ipk - so the module exists here |
| 15:48.52 | koen | v8jlene: ah, it looks like a dependency deadlock |
| 15:49.02 | koen | perl-module-strict_5.8.8-r9_armv5teb.ipk |
| 15:55.24 | *** join/#oe TheCan (n=thecan@dslb-084-056-144-220.pools.arcor-ip.net) |
| 16:04.14 | *** join/#oe goxboxlive (n=goxboxli@176.84-48-210.nextgentel.com) |
| 16:04.43 | koen | v8jlene: it seems like bitbake 1.8 needs some more info from the perl recipe |
| 16:05.11 | koen | v8jlene: I added PACKAGES_DYNAMIC="perl-module*", but I suspect that's the wrong way to fix it |
| 16:05.30 | xuumbi | is BOOTSTRAP_IMAGE_RDEPENDS depreciated? |
| 16:05.43 | koen | xuumbi: yes |
| 16:06.13 | xuumbi | koen: ok, looks like FirstProject needs to be updated... |
| 16:06.22 | koen | feel free |
| 16:06.23 | xuumbi | how should "specifying package lists" be handled then? |
| 16:06.43 | xuumbi | I'm happy to update it but I don't know the right procedure :) |
| 16:08.44 | v8jlene | koen: "bitbake automake" works fine here with just the DEFAULT_PREFERENCE lines deleted. Bitbake 1.8.2. |
| 16:09.06 | koen | v8jlene: even when you remove the old perl recipes? |
| 16:10.58 | v8jlene | koen: "No providers of runtime build target perl-module-data-dumper". What has the old perl got to do with the new one ;( |
| 16:11.05 | xuumbi | google finds very little on BOOTSTRAP_IMAGE_RDEPENDS, I was hoping to find a mailing list entry or something explaining why it is depreciated, and what to use in its place... |
| 16:11.33 | koen | v8jlene: it probably specifies that it will build perl-module-<foo> |
| 16:11.46 | *** join/#oe Kristoffer|afk (n=Kristoff@81-233-95-80-no75.business.telia.com) |
| 16:12.05 | koen | e.g by having it in PACKAGES |
| 16:12.27 | v8jlene | koen: Oh, old one has: PACKAGES_DYNAMIC = "perl-module-*" - which I don't have in the new one. Seems that applies to all modules called that regardless of what version is selected... |
| 16:14.38 | v8jlene | koen: I presume PACKAGES_DYNAMIC is to tell it that those packages are dynamically generated. Adding that line into perl_5.8.8.bb fixes things. |
| 16:15.03 | koen | yes, that's correct |
| 16:15.14 | koen | although I'm known for abusing PACKAGES_DYNAMIC :) |
| 16:15.29 | v8jlene | there's worse things you could be know for ;) |
| 16:17.05 | *** join/#oe hvontres|poodle (n=hvontres@redhill.orthodyne.com) |
| 16:23.05 | *** join/#oe Crofton__ (n=balister@jhr-476-5192.mprg.ee.vt.edu) |
| 16:23.11 | CIA-11 | 03lenehan 07org.oe.dev * rc18c0af8... 10/ (1 packages/perl/perl_5.8.8.bb): (log message trimmed) |
| 16:23.11 | CIA-11 | perl 5.8.8: Fix to tell bitbake about the perl module packages. I'd left out |
| 16:23.11 | CIA-11 | the PACKAGES_DYNAMIC declaration for the perl modules. This declaration |
| 16:23.11 | CIA-11 | appears to be global though - so if either of the older perl versions exist |
| 16:23.11 | CIA-11 | it actually works - bitbake picks up the definition from the older recipes |
| 16:23.11 | CIA-11 | even though it isn't building them. This shows up as "No providers of |
| 16:23.15 | CIA-11 | runtime build target <x>" errors where x is a perl module. Thanks to Koen |
| 16:26.29 | *** join/#oe kb7sqi (i=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 16:27.45 | koen | v8jlene: I don't think it's global, OE desperately tried to build 5.8.7, which is why I removed those |
| 16:29.08 | v8jlene | koen: With just the DEFAULT_PREFERENCE commented out here it just build 5.8.8... maybe it'd built 5.8.7 before is stopped it and deleted the DEFAULT_PREFERENCE lines.. ah, yes it had.. |
| 16:29.27 | v8jlene | koen: Ok, all makes sense now. |
| 16:37.58 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 16:38.28 | *** join/#oe zap (n=zap@16.170.249.ozerki.net) |
| 16:39.51 | tnb | koen: what is the status of angstrom sdk builds? I tried to build meta-sdk and got QA errors. |
| 16:40.29 | koen | I managed to get an sdk 2 weeks ago, didn't look at it after that |
| 16:42.54 | koen | cbrake: amen to that |
| 16:43.39 | *** join/#oe pgfeller (n=pgfeller@142-213.1-85.cust.bluewin.ch) |
| 16:46.47 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 16:47.42 | polyonymous | I got a feeling that bb 1.8 builds way more packages that 1.6 did... |
| 16:49.12 | cbrake | polyonymous: angstrom-console-image? |
| 16:50.08 | polyonymous | cbrake, that too, I think. Right now building opie-image which pulls in way more stuff than it did a couple of days earlier with 1.6 |
| 16:50.45 | CIA-11 | 03koen 07org.oe.dev * rbc8cfed5... 10/ (3 files in 3 dirs): |
| 16:50.45 | CIA-11 | glibc 2.5: fix the strlen() issues on big endian EABI, thanks to Lennert for tracking down the culprit |
| 16:50.45 | CIA-11 | * This is not a proper fix, we still need to find out wht __ARMEB__ isn't defined |
| 16:51.15 | cbrake | polyonymous: avahi has a gtk dependency, which tends to pull in a lot if it is included. |
| 16:51.50 | koen | had a gtk dependency :) |
| 16:51.59 | *** join/#oe gremlin[it] (n=gremlin@217.201.174.202) |
| 16:52.03 | polyonymous | cbrake, no, that's the other issue. That was consistent across bitbake versions. |
| 16:52.22 | cbrake | polyonymous: ohh, ok. |
| 16:53.00 | polyonymous | I've built opie-image a couple of days ago and now I'm building it again with 1.8. |
| 16:53.16 | polyonymous | And I have to fix a lot of packages that aren't built in my old 'tmp'. |
| 16:53.43 | polyonymous | Right now I'm looking at lirc-modules which I don't need, anyway :) |
| 16:54.07 | Ifaistos | when building with uclibc/gcc 4.1.1 on ppc i get a strange error during the end -> http://rafb.net/p/xwrDJJ10.html |
| 16:54.21 | Ifaistos | and it ipkg-cl is not at staging |
| 16:54.37 | polyonymous | Ifaistos, bitbake ipkg |
| 16:54.38 | polyonymous | oops |
| 16:54.41 | polyonymous | bitbake ipkg-native |
| 16:54.51 | Ifaistos | its all ready build |
| 16:54.56 | polyonymous | bitbake 1.6? |
| 16:55.00 | Ifaistos | yes |
| 16:55.02 | polyonymous | ipkg-native? are you sure? |
| 16:55.13 | polyonymous | I think it's not. |
| 16:55.30 | polyonymous | zecke has a patch already, guess it didn't go upstream yet. |
| 16:56.03 | polyonymous | meanwhile try bitake ipkg-native, should help. |
| 16:56.11 | Ifaistos | hmmm my rep is not synced with OE |
| 16:56.20 | Ifaistos | i'll check |
| 16:56.41 | polyonymous | it is bitbake issue, not tree, I believe. |
| 16:56.46 | Ifaistos | you are right. i was looking at the libc build |
| 16:56.57 | Ifaistos | and there it exists |
| 16:57.06 | polyonymous | base class checks for rootfs_ipk inheritance which isn't cached if class is inherited indirectly. |
| 16:57.13 | zecke_ | polyonymous: could you send me a bitbake -DDD without that patch? |
| 16:57.27 | zecke_ | polyonymous: I'm busy but I still want to understand which cycle we have |
| 16:58.32 | polyonymous | zecke_, angstrom-*-image inherits a class that inherits rootfs_${package type - don't remember the variable}. |
| 16:58.56 | polyonymous | base bbclass checks if package inherits rootfs_ipk before making it depend on some -native stuff. |
| 16:59.25 | polyonymous | and inherit function in parser only collects top-level inheritance. |
| 16:59.56 | polyonymous | because it overwrites whatever happens in nested classes. |
| 17:00.22 | polyonymous | It's not easy to send bitbake -DDD now, because I've --switch-ed to -1.8 :) |
| 17:01.23 | CIA-11 | 03polyonymous 07org.oe.dev * r46287715... 10/ (3 files in 3 dirs): libopie2: add missing include. Patch from polyonymous. Thanks. closes 2193. |
| 17:08.11 | *** join/#oe drw (n=drw@dirus.hrsmart.com) |
| 17:08.24 | *** part/#oe drw (n=drw@dirus.hrsmart.com) |
| 17:12.37 | *** join/#oe drw (n=drw@dirus.hrsmart.com) |
| 17:17.11 | zecke_ | polyonymous: please go back to 1.6 to generate the log |
| 17:18.19 | polyonymous | zecke_, will do, but not in the middle of my builds. |
| 17:19.12 | *** part/#oe ade|desk (n=adavey@194.200.143.249) |
| 17:21.12 | *** join/#oe z72ka (n=hermanj@r5af183.net.upc.cz) |
| 17:33.09 | *** join/#oe HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 17:39.34 | hvontres|poodle | polyonymous: are you going to send your libopie patch upstream as well? |
| 17:39.48 | polyonymous | hvontres|poodle, I did. |
| 17:39.54 | hvontres|poodle | polyonymous: cool :) |
| 17:40.02 | polyonymous | :) |
| 17:41.03 | sirfred | I'm trying to check for iwmmxt support with an AC_TRY_COMPILE statement |
| 17:41.13 | sirfred | It's strange, but the code: |
| 17:41.31 | sirfred | int main() { __asm__ __volatile__ ("wunpckelub wr6, wr4"); return 0; } |
| 17:41.56 | sirfred | Is failing when I try to compile it manually, however, the AC_TRY_COMPILE section passes |
| 17:42.24 | sirfred | The compiler flags are the same -march=armv5te -mtune=xscale |
| 17:43.05 | sirfred | Any hint? |
| 17:44.40 | *** join/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl) |
| 17:44.48 | likewise | hi |
| 17:44.56 | likewise | koen: hi, saw the 'almost' patch |
| 17:47.24 | HopsNBarley | hi likewise, hi koen. |
| 17:47.28 | likewise | HopsNBarley: hi |
| 17:49.42 | hvontres|poodle | Does anybody here know how the kernel build system generates /inclued/linux/autoconf.h ? |
| 17:50.00 | Ifaistos | any idea why the default parameters for squashfs are these ? EXTRA_IMAGECMD_squashfs = "-le -b 16384" |
| 17:51.06 | likewise | Ifaistos: No, and they should be made endianess-aware at least |
| 17:51.35 | Ifaistos | likewise : jffs2 settings are the same |
| 17:51.41 | Ifaistos | le |
| 17:51.47 | likewise | Ifaistos: same issue then :-) |
| 17:53.04 | polyonymous | hvontres|poodle, I don't think kernel really use autotools at all. |
| 17:53.32 | CosmicPenguin | it had better not |
| 17:53.51 | polyonymous | well, I can even reword it as "I'm pretty sure it doesn't" :) |
| 17:56.08 | Laibsch | polyonymous: bug 2196 dupe of 2160? |
| 17:56.10 | sirfred | hvontres|poodle: afaik, the kernel makefile system generates it after 'make prepare' or 'make oldconfig': After configuration. |
| 17:56.22 | polyonymous | !oebug 2196 |
| 17:56.23 | cdbot2 | * * Bug 2196, Status: NEW, Created: 2007-05-01 08:20 |
| 17:56.24 | cdbot2 | * * polyonymous(AT)klever.net: sword (opie) build fails for angstrom fails because of symbols invisibility |
| 17:56.25 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=2196 |
| 17:56.28 | polyonymous | !oebug 2160 |
| 17:56.29 | cdbot2 | * * Bug 2160, Status: NEW, Created: 2007-04-29 06:31 |
| 17:56.30 | cdbot2 | * * bugs.openembedded.org(AT)rolf.leggewie.biz: RPATH issue in sword |
| 17:56.31 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=2160 |
| 17:56.55 | polyonymous | no, I don't think so. Except for both are related to sword |
| 17:57.14 | Laibsch | OK |
| 17:57.22 | polyonymous | I didn't have this rpath issue, btw. |
| 17:58.04 | koen | zecke_: did django send you love note as well? |
| 17:58.44 | hvontres|poodle | sirfred: yes, I just stumbled across that... now I need to figure out why make oldconfig pulls in the uname -r output from my build host for CONFIG_UNAME_RELAEASE... |
| 17:59.29 | sirfred | hvontres|poodle: Good luck. |
| 17:59.55 | hvontres|poodle | sirfred: thanks... at least now I know where to start looking... |
| 18:01.46 | polyonymous | lirc-modules is a hell and I think it's not supposed to cross-build the way it is.... |
| 18:04.32 | koen | likewise: http://rafb.net/p/z2enSS69.html |
| 18:04.36 | Laibsch | polyonymous: Are you reading oe-devel? |
| 18:04.48 | polyonymous | Laibsch, reading yes, I'm not subscribed though |
| 18:05.36 | koen | hey HopsNBarley |
| 18:05.44 | polyonymous | (that is I'm reading via gmane nttp) |
| 18:06.27 | Laibsch | polyonymous: I am not subscribed either (which is exactly why I asked if you read it ;-)) I use gmane for MLs whenever possible |
| 18:07.11 | polyonymous | heh ;-) |
| 18:07.20 | likewise | koen: your patch seems to break glibc 2.4 builds: NOTE: Task failed: Error: /home/leon/sandbox/openembedded/org.openembedded.dev/packages/glibc/glibc-2.4/armeb-strlen.patch not found. |
| 18:08.31 | *** join/#oe carbonfreeze (n=somepc@227-151-237-24.gci.net) |
| 18:09.04 | likewise | koen: which is strange, since you didn't touch glibc 2.4... ??! |
| 18:09.27 | koen | FILES_PATH |
| 18:09.33 | zecke_ | later |
| 18:11.12 | CIA-11 | 03koen 07org.oe.dev * r61e6e424... 10/ (1 packages/glibc/glibc-2.4/armeb-strlen.patch): glibc: also add strlen patch to glibc-2.4 dir |
| 18:12.49 | Laibsch | polyonymous: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/15303 |
| 18:13.11 | Laibsch | RFC for RW access for polyonymous |
| 18:13.18 | polyonymous | yup. I see. |
| 18:13.38 | polyonymous | wow. I didn't know I had so many bugs. |
| 18:14.07 | Laibsch | I sort of did ;-) |
| 18:14.20 | polyonymous | I wouldn't call the whole list "my bugs", though :) |
| 18:14.21 | likewise | koen: ok, wow, this is intertangled. No wonder I am too dumb too follow all this stuff :-) |
| 18:14.33 | Laibsch | polyonymous: You don't own them |
| 18:14.42 | Laibsch | But they are a part of what you contributed |
| 18:14.44 | polyonymous | yeah, I'm somehow involved. |
| 18:14.45 | likewise | s/replace second occurence of too to to/ |
| 18:15.10 | *** join/#oe tomimo (n=kurre@a80-186-77-174.elisa-laajakaista.fi) |
| 18:15.22 | polyonymous | likewise, s/oo f/o f/ ;-) |
| 18:15.26 | *** join/#oe kurre2 (n=tomimo@a80-186-77-174.elisa-laajakaista.fi) |
| 18:15.43 | koen | likewise: next try is http://rafb.net/p/NFyNvC42.html |
| 18:15.47 | polyonymous | likewise, no, better s/o f/ f/ :) |
| 18:16.14 | likewise | koen: OK, I'm now tracking down why __ARMBE__ isn't set. |
| 18:17.26 | likewise | koen: http://rafb.net/p/OfZQ6R27.html and now working on some builds that have #errors to see what is (not) defined |
| 18:27.17 | *** join/#oe ScytheBlade1 (n=Death@about/pxe/ScytheBlade1) |
| 18:32.49 | *** join/#oe Crofton (n=balister@204.119.253.226) |
| 18:35.14 | *** join/#oe timtimred (n=On3@62-31-181-7.cable.ubr02.chel.blueyonder.co.uk) |
| 18:39.30 | Ifaistos | hi timtimred |
| 18:40.03 | timtimred | oh hello |
| 18:40.15 | timtimred | it wasnt me, whatever it was |
| 18:40.27 | Crofton | JustinP, you having rpath issues? |
| 18:40.27 | Ifaistos | :) |
| 18:41.26 | xuumbi | if I have export PACKAGE_INSTALL = "xinetd", then RDEPENDS = "${PACKAGE_INSTALL}" in my-image.bb, if I then bitbake my-image -c rebuild, and an xinetd ipk doesn't already exist under tmp/deploy/ipk/etc., shouldn't bitbake then realize it needs to run bitbake xinetd? |
| 18:42.25 | *** join/#oe punk-ass (n=user@unaffiliated/punkass) |
| 18:47.27 | xuumbi | I'm looking at this mailing list post which seems to suggest that, but it's not working: http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-February/001507.html |
| 18:50.05 | pgfeller | clear |
| 18:51.00 | pgfeller | hi all, - is there a commandline tool in OE to apply xml stylesheets to xml files (like Xalan)? |
| 18:51.18 | polyonymous | xsltproc? |
| 18:51.36 | pgfeller | polyonymous: thanks |
| 18:51.42 | polyonymous | you're welcome. |
| 18:52.03 | pgfeller | polyonymous: I'll try this (I've made a xsl to transfor iTunes podcas/rss to m3u playlists) |
| 18:52.37 | polyonymous | It worked for me like half a year ago or so. |
| 18:53.27 | *** join/#oe Bitmaster (n=Bitmaste@c-9b61e253.325-1-64736c12.cust.bredbandsbolaget.se) |
| 18:59.12 | *** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 19:05.46 | *** join/#oe kb7sqi (n=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 19:06.28 | *** join/#oe tomimo (n=kurre@a80-186-77-174.elisa-laajakaista.fi) |
| 19:13.54 | likewise | koen: for lennert: http://rafb.net/p/4Wf6vD42.html (Not sure if it helps, I'm noob here) |
| 19:26.41 | *** join/#oe kurre2 (n=tomimo@a80-186-77-174.elisa-laajakaista.fi) |
| 19:31.52 | polyonymous | unbelievable. bitbake opie-image completed :) |
| 19:32.33 | hvontres|poodle | polyonymous: wohoooo :) |
| 19:32.48 | polyonymous | I'm going for opie-kdepim-image now :)) |
| 19:33.05 | koen | like|movies: http://rafb.net/p/hgPgSo97.html |
| 19:33.31 | hvontres|poodle | polyonymous: what device are you building for ? |
| 19:33.38 | polyonymous | hvontres|poodle, spitz |
| 19:35.21 | hvontres|poodle | polyonymous: ahh.. :) I guess I'll give poodle another shot as soon as I can figure out my kernel build problems.... |
| 19:36.43 | polyonymous | hvontres|poodle, luckily I haven't had any kernel build problems... ;-) |
| 19:36.44 | polyonymous | btw, someone asked me for my kdepimpi patch here and I just noticed it's in bugzilla for ages now. |
| 19:36.44 | polyonymous | (in case "someone" is around:)) |
| 19:36.55 | hvontres|poodle | polyonymous: I think I might have a clue where to look now... I am suspecting CONFIG_LOCALVERSION_AUTO is somehow goofing things up |
| 19:37.11 | hvontres|poodle | polyonymous: well, maybe soon you can fix that :) |
| 19:37.29 | polyonymous | hvontres|poodle, ;-))) I didn't mean complaining, actually. |
| 19:38.18 | *** join/#oe jott (n=j@unaffiliated/jott) |
| 19:39.02 | polyonymous | and as for your kernel issue, I don't think I can comment on that. Luckily I haven't had a chance to fight kernels in oe, yet :) |
| 19:41.00 | hvontres|poodle | polyonymous: hehe...lucky you :) I just want to be able to re-compile to change the cmdline to use /dev/mmcblk0p1 as / (makes testing images a LOT easier :) ) |
| 19:41.18 | cbrake | xuumbi: I'm guessing bitbake looks at stamps to determine if packages need built, not tmp/deploy/ipk/... |
| 19:41.34 | hvontres|poodle | polyonymous: well, I should probably get back to work...:) |
| 19:41.37 | polyonymous | hvontres|poodle, I see. Wish kexec supported passing cmdline. |
| 19:41.41 | polyonymous | have fun :) |
| 19:41.51 | xuumbi | cbrake: what do you mean by "stamps"? |
| 19:41.57 | cbrake | xuumbi: I've run into this issue before -- digging through dusty archives of my mind ... |
| 19:42.19 | cbrake | xuumbi: tmp/stamps/ |
| 19:42.35 | hvontres|poodle | polyonymous: yeah...but I grok that even less than the kernel build system... but it looks doable. |
| 19:42.43 | xuumbi | cbrake: oh right |
| 19:43.01 | cbrake | xuumbi: technicality, but the problem remains. |
| 19:43.30 | *** join/#oe mreimer_ (n=mreimer_@luthien.vpop.net) |
| 19:43.33 | polyonymous | I'm not bold enough to look at it unless I have to. I'm testing images by kexecing kernel and then altbooting into chroot. Works fine for me. |
| 19:43.54 | mreimer_ | hello all |
| 19:43.55 | xuumbi | cbrake: basically my goal is to not use DISTRO/MACHINE_EXTRA_RDEPENDS to specify packages to be built and therefor included, because that makes those packages dependencies of the distro and require ipkg remove -force-depends to remove them |
| 19:44.02 | mreimer_ | who's the best person to ask about tslib? kergoth? |
| 19:46.22 | xuumbi | cbrake: my current solution, which probably isn't the best, is to create a "dummy" task file with all the packages that I need compiled, so I build that first, then when I build my custom image file that includes the same packages in PACKAGE_INSTALL |
| 19:48.31 | polyonymous | there must be something wrong. bitbake opie-kdepimpi-image complete :)) |
| 19:55.17 | *** join/#oe lrg_ (n=liam@lrg2.demon.co.uk) |
| 19:56.04 | *** join/#oe Crofton (n=balister@hc65215a7.dhcp.vt.edu) |
| 19:56.44 | *** join/#oe B_Lizzard (n=havoc@ppp54-114.adsl.forthnet.gr) |
| 19:56.55 | B_Lizzard | Is bitbake 1.8 slightly crazy? |
| 19:57.18 | B_Lizzard | Why does it leave jobs half-unfinished? |
| 19:57.26 | B_Lizzard | Only to continue them later? |
| 19:57.48 | koen | B_Lizzard: multithreading + intertask dependencies |
| 19:58.10 | polyonymous | huh? Maybe they're half-finished? :) |
| 19:58.22 | B_Lizzard | I'll consider it sane, then |
| 19:58.26 | B_Lizzard | :) |
| 20:02.20 | *** join/#oe dion (n=dion@inhex.net) |
| 20:03.51 | *** join/#oe dkey (i=somebody@193.170.48.236) |
| 20:10.41 | JustinP | Crofton: well, like the recent e-mail by someone else, my build failed and I retried and it continued. The problem is that the bas gcc libs are now not packaged and not installed in my image. I've switched that fatal to warn in my local tree as it sucks that it's allowing broken builds to continue. I want to be able to test things.... |
| 20:11.34 | polyonymous | JustinP, I think everyone comments out #return False in insane :) |
| 20:12.48 | JustinP | polyonymous: ok, commenting that out too |
| 20:12.48 | polyonymous | heh |
| 20:13.13 | JustinP | it really should have been tested that this doesn't break things....if a build which fails with RPATH issues fails on a subsequent build then I'd be fine with it....but allowing bad builds means that we have to restart building from scratch as who knows which packages may have failed... |
| 20:13.35 | polyonymous | Very true. |
| 20:14.06 | *** join/#oe kb7sqi (i=kb7sqi@cpe-071-071-104-054.triad.res.rr.com) |
| 20:16.57 | Crofton | you can also mkdir classes in BBPATH |
| 20:17.01 | Crofton | like in build |
| 20:17.03 | Crofton | and touch classes insane.bbclass |
| 20:17.07 | *** join/#oe darkschneider (n=gab@81-208-36-80.ip.fastwebnet.it) |
| 20:17.11 | Crofton | that is how I think I did it, need to go see if the build finished |
| 20:22.53 | *** join/#oe crink (n=crink@218.147.228.156) |
| 20:23.20 | crink | <PROTECTED> |
| 20:23.25 | crink | Hi, |
| 20:26.16 | *** join/#oe tuxperger (n=mv@a88-112-60-192.elisa-laajakaista.fi) |
| 20:26.32 | Crofton | JustinP, I am going to try to figure out how to start fixing some of the RPATH stuff |
| 20:36.09 | Laibsch | Is tslib still being maintained? |
| 20:36.19 | Laibsch | I see a lot of patches which are apparently not being applied |
| 20:43.47 | psokolovsky__ | it's even hosted on LTG |
| 20:44.30 | koen | psokolovsky__: you mean berlios, right? |
| 20:44.43 | psokolovsky__ | ah, yep, apparently... |
| 20:45.50 | *** join/#oe dijenerate (n=dijenera@69.73.252.86) |
| 20:46.55 | mreimer_ | who's the best person to ask about tslib patches? I found what might be a minor bug |
| 20:47.05 | CIA-11 | 03polyonymous 07org.oe.dev * r1f0046e3... 10/ (4 files in 3 dirs): |
| 20:47.05 | CIA-11 | opie-networksettings cvs: Fix compilation with latest linux-headers. |
| 20:47.06 | CIA-11 | * Closes #2197. |
| 20:47.45 | polyonymous | See, why would I need a mtn access? I'm already committing :) |
| 20:51.02 | vervain | Is there a list of bb variable definitions somewhere? |
| 20:52.02 | NAiL | vervain: bitbake.conf |
| 20:53.56 | koen | or documentation.conf |
| 20:54.15 | vervain | not the OE bitbake configuration but generic bb variables. |
| 20:54.56 | vervain | in teh bb docs there are some examples in the 4. Commands->bitbake->Metadata section but it's thin. |
| 20:55.18 | polyonymous | "read the source"? |
| 20:56.37 | crink | Hi, how to solve "../protocol/jar/src/libnkjar_s.a', needed by `libnecko.a'"? |
| 20:56.47 | crink | minimo on mipsel |
| 20:58.43 | polyonymous | time to boot into angstrom's opie image :) |
| 21:01.04 | polyonymous | I wonder is it a problem to make OE splash screen landscape or is it that just nobody took care of it? |
| 21:05.27 | *** part/#oe crink (n=crink@218.147.228.156) |
| 21:08.42 | hvontres|poodle | polyonymous: Any luck booting? |
| 21:08.51 | polyonymous | hvontres|poodle, Yup, I'm in it now. |
| 21:08.56 | polyonymous | setting up stuff. |
| 21:09.09 | CIA-11 | 03koen 07org.oe.dev * rbc5aec33... 10/ (14 files in 3 dirs): linux-ezx 2.6.21: update patches to r1995, gives you working ts, keys and some powermanagement |
| 21:09.14 | polyonymous | 'booting' is kexecing and chrooting, though. |
| 21:09.31 | hvontres|poodle | polyonymous: works for me :) |
| 21:09.42 | polyonymous | :) |
| 21:10.36 | florian | koen: sounds like i should build new images :-) |
| 21:10.38 | polyonymous | Quite natural methos. |
| 21:11.05 | koen | florian: or just ipkg upgrade if you're using angstrom |
| 21:11.38 | hvontres|poodle | polyonymous: yup. right now I have one "daily driver" SD with OZ 3.5.4.2 and one "experimental" with the image du jour |
| 21:12.17 | polyonymous | hvontres|poodle, you don't have microdrive, I take it? :) |
| 21:12.32 | florian | koen: Angstrom-gpephone images? |
| 21:13.29 | *** join/#oe amaldo (n=amaldo@pdpc/supporter/student/amaldo) |
| 21:14.12 | koen | florian: afaik gpephone is still broken |
| 21:14.14 | hvontres|poodle | polyonymous: actually, i used too. I had a 5GB ST1 that I used for mp3's. but sadly it died. |
| 21:14.23 | florian | koen: ? |
| 21:14.45 | koen | florian: it doesn't compile against a recent gtk |
| 21:14.59 | polyonymous | RIP. |
| 21:15.01 | florian | koen: i guess the world is just bigger than you would like to have it for Angstrom |
| 21:15.27 | koen | so it compiles now? |
| 21:18.11 | florian | koen: here it compiles most of the time, but i never used anything else than the recommended gtk and glib |
| 21:19.07 | polyonymous | I think I'm about ready to switch to angstrom's opie-kdepim-image ;-) |
| 21:19.22 | JustinP | Crofton: I thought that people had already proposed patches for it on the list... |
| 21:20.18 | Crofton | I think there are two problems, fixing insasen.bbclass and fixing the bb files so we do not end up with with bad rpaths |
| 21:24.12 | koen | Crofton: the problem is not in insane.bbclass, but in PACKAGE_FUNCS |
| 21:24.26 | RP | 'morning' all |
| 21:24.41 | Crofton | koen, remind me to keep my mouth shut when I do not really know what I am talking about :) |
| 21:24.48 | koen | if you fiddle with PACKAGE_FUNCS errors don't get propagated |
| 21:25.27 | koen | or rather, it doesn't invalidate the previous task (do_install) |
| 21:25.39 | RP | koen: This is why do_install was part of do_package |
| 21:26.04 | koen | RP: indeed |
| 21:26.56 | RP | koen: Why don't we make it a PACKAGE_FUNCS too? |
| 21:27.14 | koen | RP: I have no idea |
| 21:27.29 | koen | I'll have to wait for zecke to whisper some wise reply into my ear ;) |
| 21:29.31 | RP | Let me make a patch someone can test... |
| 21:29.50 | vervain | exit |
| 21:33.15 | RP | koen: http://www.rpsys.net/openzaurus/temp/oe-install-change.patch |
| 21:33.24 | RP | untested but might just work |
| 21:34.58 | CIA-11 | 03koen 07org.oe.dev * rf342c01c... 10/ (1 conf/machine/ixp4xxbe.conf): ixp4xxbe: add -D__ARMEB__ to target cc arch |
| 22:06.10 | sirfred|zzz | Good night |
| 22:06.18 | mreimer_ | night sirfred|zzz |
| 22:09.22 | *** part/#oe mreimer_ (n=mreimer_@luthien.vpop.net) |
| 22:15.50 | CIA-11 | 03ifaistos 07org.oe.dev * raa47c0e9... 10/ (3 files in 3 dirs): packages/linux/linux-magicbox_2.6.18.6.bb : Add squashfs-lzma support to the kernel |
| 22:15.54 | CIA-11 | 03ifaistos 07org.oe.dev * rda7866de... 10/ (1 conf/machine/magicbox.conf): |
| 22:15.54 | CIA-11 | conf/machine/magicbox.conf : make sure jffs2 and squashfs images generated are for big endian machines |
| 22:15.54 | CIA-11 | Set minimun kernel to 2.6.18. |
| 22:16.26 | like|movies | Ifaistos: squashfs-lzma. cool. |
| 22:17.30 | Ifaistos | 4MB flash don't leave you with much choice... :) |
| 22:18.44 | polyonymous | now that I'm all built and running it's about time to see what in my mtn diff isn't in bugzilla yet :) |
| 22:19.30 | Ifaistos | polyonymous : was the bitbake 1.6 fix for ipkg-native pushed upstream ? |
| 22:19.50 | polyonymous | Ifaistos, what do you mean pushed? I passed the patch to zecke. |
| 22:20.01 | polyonymous | Ifaistos, want a patch? |
| 22:20.14 | Ifaistos | did he put it to the svn ? |
| 22:20.20 | Ifaistos | yeah sure |
| 22:20.24 | polyonymous | I think not yet. hang on. |
| 22:21.03 | polyonymous | http://rafb.net/p/qrOvDZ14.html |
| 22:21.20 | polyonymous | zecke wanted bitbake -DDD output from me which I didn't have to provide him with, yet. |
| 22:21.47 | Laibsch | Ifaistos: Do you happen to know about how to compress for squashfs-lzma on ubuntu? |
| 22:22.37 | likewise | Ifaistos: mksquashfs? |
| 22:23.13 | Ifaistos | Laibsch : yes |
| 22:23.24 | Laibsch | likewise: I think that is going to be normal squashfs, no? |
| 22:23.42 | Ifaistos | you need to patch it |
| 22:23.51 | likewise | Laibsch, Ifaistos: squashfs-tools-native_3.1r2.bb holds mksquash-lzma too (I wrote this .bb) |
| 22:24.11 | likewise | this one --> squashfs-lzma-tools-native_3.1r2.bb |
| 22:24.20 | *** join/#oe dijenerate (n=dijenera@69.73.252.86) |
| 22:24.35 | *** join/#oe mreimer_ (n=mreimer_@luthien.vpop.net) |
| 22:24.46 | Laibsch | OK, so I bitbake it and execute it from within the staging dir? Got the idea right? |
| 22:24.51 | Ifaistos | likewise : this is the one i use. i though Laibsch wanted to compress something outside OE |
| 22:24.55 | *** join/#oe chouimat2 (n=dieu@r2351064.cidc.net) |
| 22:25.09 | likewise | Laibsch: yes |
| 22:25.10 | Ifaistos | yep. works fine |
| 22:25.14 | mreimer_ | anyone know which ASoC git tree is the best to pull from? |
| 22:25.16 | Laibsch | yes, 800 tar.bz2 recompressed on the collie is going to take like ... |
| 22:25.26 | likewise | Ifaistos: OK, I don't know if Ubuntu has it a package, guess not. |
| 22:25.31 | Laibsch | 800MB |
| 22:25.39 | *** join/#oe geekoid_ (n=geekoid@adsl-75-4-101-31.dsl.emhril.sbcglobal.net) |
| 22:25.45 | Laibsch | likewise: google thinks not, too |
| 22:26.59 | Laibsch | plus I don't have the space on the collie to recompress 800 MB already compressed data |
| 22:28.21 | hvontres|poodle | Laibsch: 800MB on collie???????? |
| 22:28.57 | Laibsch | yes |
| 22:29.02 | Laibsch | Japanese wikipedai |
| 22:29.05 | Laibsch | wikipedia |
| 22:30.32 | Laibsch | English would be bigger ;-) |
| 22:31.55 | Ifaistos | night everyone |
| 22:36.56 | polyonymous | I'm totally lost. I'm afraid I'll have to read mtn docs :( |
| 22:39.57 | Laibsch | polyonymous: That is not so bad |
| 22:40.12 | Laibsch | But you could ask in #monotone on irc.oftc.org |
| 22:40.20 | polyonymous | Laibsch, I used to read docs when everything else fails, therefore I have to admit everything else failed :) |
| 22:40.34 | polyonymous | I think I should start off with docs. I'm missing some concept. |
| 22:40.43 | *** join/#oe __blue119__ (i=blue119@twaren2226.niu.edu.tw) |
| 22:40.55 | Laibsch | The guys in #monotone are VERY helpful |
| 22:41.04 | Laibsch | very nice people |
| 22:41.17 | polyonymous | Laibsch, but I shouldn't be pestering. I should first try myself. |
| 22:41.20 | hvontres|poodle | Laibsch: so koen dosn't hang out over there ? :) |
| 22:41.24 | likewise | polyonymous: and the monotone documentation is very well written. |
| 22:42.00 | polyonymous | likewise, good to know. I hope I'm able to figure out things. After all I don't have troubles with git. |
| 22:42.18 | likewise | polyonymous: anything specific you would like to know? |
| 22:42.49 | *** join/#oe pierrelux (n=pierre-l@144-125.sh.cgocable.ca) |
| 22:43.01 | polyonymous | likewise, well, I just don't fully understand what is selected as an update target and why I seem not to have the most recent commits after pulling and updating. |
| 22:43.14 | polyonymous | And I do get updates. |
| 22:43.31 | polyonymous | And how many heads the .dev branch has, etc. |
| 22:43.39 | *** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 22:43.45 | likewise | polyonymous: last question first: how do you know that you do not have the lastest commits? |
| 22:43.56 | Laibsch | hvontres|poodle: You are NOT being nice now, are you ;-) |
| 22:44.32 | likewise | polyonymous: mtn automate get_base_revision_id tells the id's of the head(s), multiple if not merged yet. There must be a simpler way, I always use this though. |
| 22:44.41 | Laibsch | polyonymous: That happens when you have made local changes |
| 22:44.45 | polyonymous | likewise, well, I've seen commit by koen to this xtscal problem and I don't see it in my tree, although koen said that if I've seen commit then I should be having it.. |
| 22:44.50 | Laibsch | I think mtn will not overwrite them. |
| 22:44.53 | polyonymous | Laibsch, thought that's related. |
| 22:45.04 | polyonymous | Yes, but it should've reported conflict, I'd think. |
| 22:45.17 | likewise | Laibsch: yes, it merges and/or reports a conflict |
| 22:45.44 | polyonymous | mtn get_base_revision_id is 9709188a53609e84bb72b7a7f9ee79ee1c0419f2 |
| 22:45.50 | likewise | polyonymous: but take some time to read the docs, I have to catch up on GIT myself so I cannot help you on the differences. |
| 22:46.11 | polyonymous | yes, I think I should. |
| 22:46.37 | likewise | polyonymous: you'll be an expert soon. |
| 22:46.40 | Laibsch | !oebug 2200 |
| 22:46.41 | cdbot2 | * * Bug 2200, Status: NEW, Created: 2007-05-01 15:43 |
| 22:46.42 | cdbot2 | * * bugs.openembedded.org(AT)rolf.leggewie.biz: QA issues in squashfs-lzma-tools-native |
| 22:46.43 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=2200 |
| 22:46.59 | polyonymous | likewise, quite possible :) |
| 22:48.28 | polyonymous | what is base revision id? and what is heads... Well, I'm off to docs, I'm afraid :) |
| 22:48.47 | *** join/#oe emte (n=emte@d64-180-45-14.bchsia.telus.net) |
| 22:51.08 | polyonymous | Laibsch, regarding your answer to koen about mixed-case - `tr` is exactly that makes everything uppercase and therefore you don't need mixed-case. But this is the commit I don't see in my tree yet :) |
| 22:52.24 | Laibsch | polyonymous: Well, maybe you can post a reply. Would be nice |
| 22:52.37 | polyonymous | Laibsch, is List open for non-subscribers? |
| 22:53.09 | polyonymous | hmm.. |
| 22:53.20 | polyonymous | mtn: selected update target da7866de083247553abfdcab2457e49e772484f7 |
| 22:53.21 | polyonymous | mtn: warning: rename target conflict: nodes 2147483655, 21478, both want parent 959, name wireless.patch |
| 22:53.21 | polyonymous | mtn: warning: resolve non-content conflicts and then try again. |
| 22:53.26 | polyonymous | I need to find out what it means ;0 |
| 22:56.56 | Laibsch | polyonymous: you can post via gmane.org. Or maybe I am subscribed and have to receive no mails |
| 22:57.39 | Laibsch | Ifaistos: mksqashfs-lzma is doing a nice job here. Thank you. |
| 22:57.39 | polyonymous | Laibsch, I'll see... |
| 23:04.24 | polyonymous | Laibsch, I'm not registered at gmane either :) |
| 23:05.21 | polyonymous | well, I'd rather sort out my mtn... |
| 23:05.26 | likewise | good nite |
| 23:05.30 | likewise | polyonymous: good luck |
| 23:05.33 | *** join/#oe idealm_ (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au) |
| 23:05.38 | polyonymous | night, likewise |
| 23:05.50 | likewise | polyonymous: there is also "mtn revert", but be sure to copy your local changes first! |
| 23:05.55 | *** part/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl) |
| 23:06.16 | polyonymous | I was thinking about reverting it... |
| 23:09.31 | polyonymous | it's very nice of mtn to ay the problem is with 'wireless.patch' without even mentioning the directory :) |
| 23:09.57 | Laibsch | polyonymous: I meant registering for the ML but set it to sent out no mail since you (and I) read from gmane |
| 23:10.23 | polyonymous | Laibsch, Ah... That may make sense, indeed. |
| 23:12.45 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 23:21.24 | polyonymous | Laibsch, I sorted out monotone, finally, by reverting packages in question (and those are basically the ones that went upstream) |
| 23:21.42 | polyonymous | and by what I read in xtscal-cxk.patch - the problem is solved. |
| 23:46.30 | *** join/#oe Gerrath_ (n=Shane_@c-71-206-208-128.hsd1.pa.comcast.net) |
| 23:49.45 | hvontres|poodle | Laibsch: Well, ok... but koen does seem to lack some of the skills needed for customer support :) |
| 23:54.23 | CoreDump|home | muwhaha |
| 23:58.18 | hvontres|poodle | CoreDump|home: ok, so I was TRYING to be nice this time.....:) |
| 23:58.30 | CoreDump|home | you were |