| 00:16.13 | *** join/#oe dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 00:19.27 | *** join/#oe idealm (n=ideal@58.33.48.72) |
| 00:26.18 | *** join/#oe dyoung-a1ay (n=dyoung@cpe-24-94-88-62.hawaii.res.rr.com) |
| 00:46.39 | *** join/#oe dan2003 (n=dan2003@cpc3-ware3-3-0-cust39.lutn.cable.ntl.com) |
| 00:56.47 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
| 01:17.19 | *** join/#oe noclouds (n=mhfan@60.166.37.131) |
| 01:27.31 | *** join/#oe xtmdster (n=default@adsl-69-234-22-118.dsl.irvnca.pacbell.net) |
| 01:28.14 | *** join/#oe idealm (n=ideal@222.66.46.90) |
| 01:30.44 | *** join/#oe katossi (n=guillerm@dslb-084-062-130-083.pools.arcor-ip.net) |
| 01:58.35 | *** join/#oe gerwinin (n=gerwinin@ip5457b30e.direct-adsl.nl) |
| 01:58.57 | gerwinin | lo |
| 01:59.14 | gerwinin | I am getting an unmet depencies when I do a pull |
| 01:59.24 | gerwinin | Where can I see what went wrong ? |
| 02:02.42 | *** join/#oe |dkey| (n=dkey@L0002P07.dipool.highway.telekom.at) |
| 02:15.54 | hue | gerwinin: I upgrade my monotone to 0.24 and do it again to solve this problem |
| 02:16.09 | gerwinin | Okay will do that now |
| 02:47.29 | *** join/#oe CSMan (n=csman@toronto-HSE-ppp3949669.sympatico.ca) |
| 02:52.34 | *** join/#oe minipanda (n=zhanght@221.122.51.131) |
| 02:53.02 | *** part/#oe minipanda (n=zhanght@221.122.51.131) |
| 03:10.11 | *** join/#oe MP0_ (n=paulinge@63.161.128.32) |
| 03:32.10 | *** join/#oe aquadran_ (i=pablo@scummvm/undead/aquadran) |
| 06:06.59 | *** join/#oe [lala_] (n=lala@p54B3AF79.dip0.t-ipconnect.de) |
| 06:16.42 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 06:21.46 | *** join/#oe _law_ (n=law@mail.stiftadmont.at) |
| 06:38.39 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 06:40.21 | *** join/#oe minipanda (n=zhanght@221.122.51.131) |
| 06:40.56 | *** part/#oe minipanda (n=zhanght@221.122.51.131) |
| 06:45.24 | *** join/#oe theturtle_ (n=theturtl@theturtle.net) |
| 06:55.19 | *** join/#oe Minase (n=minase@reverie.encapsulated.net) [NETSPLIT VICTIM] |
| 07:00.08 | *** join/#oe gints (n=gints@195.244.141.102) |
| 07:22.53 | *** join/#oe molivier (n=omougin@d05m-213-44-29-3.d4.club-internet.fr) |
| 07:24.26 | *** join/#oe Minase (n=minase@reverie.encapsulated.net) [NETSPLIT VICTIM] |
| 08:19.30 | *** join/#oe pTweety (i=www@thor.66h.42h.de) |
| 08:32.13 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 08:36.31 | RP | morning all |
| 08:36.52 | _law_ | hi RP |
| 08:52.28 | *** join/#oe ade|desk (n=adavey@194.200.143.249) |
| 08:52.40 | ade|desk | morning all |
| 08:52.47 | RP | morning ade|desk |
| 08:54.34 | *** join/#oe freyther (i=fakeuser@p54BD10E4.dip0.t-ipconnect.de) |
| 09:04.45 | *** join/#oe uv1 (n=kvirc@p508902E2.dip0.t-ipconnect.de) |
| 09:15.40 | zecke | hi uv1 |
| 09:16.54 | RP | hi zecke |
| 09:18.34 | zecke | RP: we did not get any complains about broken fetchers? |
| 09:18.38 | ade|desk | anything happened lately? |
| 09:23.40 | RP | zecke: Not that I know of. I do have a fetcher bug to report and fix but that was in the original code... |
| 09:23.56 | RP | svn filenamed in DL_DIR need to have $path in their filename |
| 09:25.31 | *** join/#oe mhfan (n=mhfan@60.166.56.177) |
| 09:27.48 | do13 | morning all |
| 09:28.44 | RP | hi Dirk |
| 09:29.07 | do13 | hi Richard |
| 09:30.34 | do13 | RP: your LED class is cool |
| 09:31.01 | RP | do13: Pleased you like it :) |
| 09:31.10 | RP | do13: Say that loudly on LKML :) |
| 09:31.36 | RP | I really need to post some code updated after the comments it got (no major changes) |
| 09:32.19 | do13 | RP: with blinking leds the device looks better:) |
| 09:32.55 | RP | do13: Agreed. It was long overdue :) |
| 09:33.05 | RP | do13: You've written support for tosa? |
| 09:33.47 | do13 | RP: Yep. This was an easy task. It took only a few minutes. |
| 09:34.18 | RP | do13: It means I can claim more devices are using it though :) |
| 09:36.50 | do13 | RP: If it helps, you can integrate http://www.do13.de/oz/patches/tosa-leds-r0.patch into your patchset. |
| 09:39.18 | *** join/#oe zap (n=zap@217.170.93.196) |
| 09:39.26 | RP | do13: thanks - Do you want to add a LKML patch style header to that and sign it off, then I can add a signed-off line from me and everyone is happy :) |
| 09:44.21 | *** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it) |
| 09:44.54 | XorA | morning |
| 09:46.22 | RP | hi XorA |
| 09:46.56 | do13 | RP: Yep. You can integrate drivers/leds/ into your patchset. |
| 09:48.01 | RP | I've just mailed the NSLU2 people asking for a driver from them as well :) |
| 09:48.22 | XorA | RP: noticed last night, sound code still doesnt shutdown amplifier on c7x0 in suspend (though I accept this may be impossible) |
| 09:49.24 | RP | XorA: you mean the speaker? |
| 09:49.33 | RP | Did the Sharp kernel do this? |
| 09:49.35 | XorA | RP: I noticed it on the headphones |
| 09:49.53 | XorA | RP: Im actually not sure, its been years since I ran sharp |
| 09:49.54 | RP | XorA: It might be an idea to ask lrg about this |
| 09:50.23 | RP | It its not shutting down, that could be a nasty source of power drain :-/ |
| 09:50.50 | XorA | RP: my battery does drain quite badly when in suspend |
| 09:51.01 | XorA | RP: more so than I remeber from sharp rom |
| 09:51.27 | RP | XorA: The tests I did on suspend power draw looked ok for the basic system |
| 09:51.34 | XorA | but not as badly as a wince Ipaq :-) |
| 09:51.42 | RP | Adding CF cards, audio and things like that haven't been tested yet |
| 09:52.10 | XorA | RP: of course my battery is now 2.5 years old, it could just be wearing out |
| 09:52.18 | RP | the hx2750 is a monster power eater... |
| 09:52.36 | XorA | RP: or h5550 at work are next to useless as PDA's |
| 09:52.41 | RP | XorA: I'll do some power measurements with the audio and cf wifi cards |
| 09:53.06 | RP | Audio didn't work when I last did the tests :) |
| 09:53.19 | XorA | RP: audio is awesome now |
| 09:53.48 | RP | XorA: We're slowly getting there with the kernel :) |
| 09:54.01 | RP | audio beats 2.4 now :) |
| 09:54.05 | XorA | RP: the 2.6 kernel is so far beyond the 2.4 its unreal |
| 09:57.59 | RP | XorA: it is quite a bit different now :) |
| 09:58.43 | *** join/#oe freyther (i=fakeuser@p54BD30BD.dip0.t-ipconnect.de) |
| 10:17.22 | *** join/#oe gints (n=gints@195.244.141.102) |
| 10:23.17 | *** join/#oe Jenna (n=cherryRe@209.8.233.249) |
| 10:23.51 | *** part/#oe Jenna (n=cherryRe@209.8.233.249) |
| 10:24.31 | *** join/#oe _alwin_ (n=ral@cable-195-14-254-45.netcologne.de) |
| 10:25.26 | *** join/#oe |dkey| (n=dkey@L0001P01.dipool.highway.telekom.at) |
| 10:32.32 | *** join/#oe matthias_ (n=matthias@ppp-82-135-6-198.mnet-online.de) |
| 10:37.16 | *** join/#oe dan2003 (n=dan@host81-129-39-158.range81-129.btcentralplus.com) |
| 10:47.45 | dan2003 | i ran a bad block count test on my z falsh yesturday, and found 3. Does anythign take these into account and avoid using them, or will i hve problems with corupted data from now on? |
| 11:03.39 | CIA-12 | 03koen 07org.oe.oz354fam083 * r0091680b... 10/conf/machine/h2200.conf: h2200: RRECOMMEND kernel modules |
| 11:03.44 | CIA-12 | 03koen 07org.oe.dev * r4580f887... 10/conf/machine/h2200.conf: h2200: RRECOMMEND kernel modules |
| 11:03.48 | CIA-12 | 03koen 07org.oe.dev * r8a71e516... 10/conf/distro/preferred-gpe-versions-2.7.inc: gpe 2.7: prefer gpe-conf 0.1.27 |
| 11:03.54 | koen | good morning all |
| 11:07.45 | lrg | morning koen |
| 11:11.34 | *** join/#oe freyther (i=fakeuser@p54BD37F6.dip0.t-ipconnect.de) |
| 11:16.12 | mickeyl | morning folks |
| 11:16.34 | lrg | morning mickeyl |
| 11:17.13 | koen | hey mickeyl |
| 11:28.52 | RP | dan2003: The nand driver should take care of it |
| 11:29.09 | RP | hi koen, lrg and mickeyl |
| 11:30.03 | RP | lrg: Did you see XorA's comment about the amp suspending on corgi? If all the codec is powered down, will the machine controls get powered down? |
| 11:30.16 | RP | If not, we can probably ask scoop to handle this |
| 11:30.36 | RP | it already does for cxx00 but not c7x0 iirc |
| 11:34.05 | *** join/#oe molivier (n=omougin@d05v-213-44-3-143.d4.club-internet.fr) |
| 11:34.10 | lrg | RP: it's designed to power up/down external components. i've probably left it out by ommision. |
| 11:34.25 | lrg | RP: should it be in corgi ? |
| 11:35.10 | RP | lrg: Yes, the APM scoop control needs to be powered down when not in use |
| 11:35.22 | lrg | ok, I'll have a look |
| 11:38.30 | *** join/#oe malfimalfi (n=malte@dslb-084-059-005-206.pools.arcor-ip.net) |
| 11:47.51 | RP | zecke: svn fetcher bug is #554 - patch attached to fix it |
| 11:51.01 | *** join/#oe reenoo_ (n=r@p5489E888.dip.t-dialin.net) |
| 11:51.09 | reenoo_ | morning |
| 11:51.14 | RP | hi reenoo_ |
| 11:51.42 | reenoo_ | hey RP |
| 12:07.43 | ade|desk | any ideas what bvdd is as my .jp is nonexistent, it seems to be some kernel 2.4 and not 2.6 , any pointers? |
| 12:08.09 | koen | iirc it's an overlay interface for pxafb |
| 12:08.36 | RP | yes, accelerates video slighty by using overlays |
| 12:10.03 | *** join/#oe dkey (n=dkey@L0001P01.dipool.highway.telekom.at) |
| 12:10.31 | koen | do we have source, or is it like aticore? |
| 12:22.25 | RP | koen: We have source. Its very simple though just supporting overlays |
| 12:22.36 | RP | aitcore is a compelte 2D acceleration engine |
| 12:29.43 | *** join/#oe _law_ (n=_law_@213.173.86.202) |
| 12:42.21 | ade|desk | hmm found some stuff on overlays for 2.6 on intels site patches for 2.6.9 for loads of other bits too |
| 12:42.47 | ade|desk | doesn't look like much has hit the mainline kernel though :( |
| 12:44.08 | RP | ade|desk: What kind of bits? |
| 12:44.29 | ade|desk | ftp://ftp.arm.linux.org.uk/pub/armlinux/people/xscale/mainstone/01-27-2005/src/kernel/patch-2.6.9-intc1 |
| 12:44.31 | RP | and waht kind of code quality? |
| 12:45.33 | RP | ah, a cpufreq driver :) |
| 12:46.47 | ade|desk | ftp://ftp.arm.linux.org.uk/pub/armlinux/people/xscale/mainstone/01-27-2005/README.txt |
| 12:47.09 | ade|desk | its the 14th bit that interesting |
| 12:48.15 | *** join/#oe dhr (n=hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 12:52.33 | *** join/#oe Spyro (n=ian@i-195-137-81-187.freedom2surf.net) |
| 12:52.49 | Spyro | hey guys... |
| 12:52.56 | lrg | hey Spyro |
| 12:53.05 | Spyro | I want to select a specific version of konq-embedded |
| 12:53.32 | Spyro | I set PREFERRED_VERSION_konqueror-embedded = "0.0cvs20050322" |
| 12:53.33 | Spyro | in local.conf |
| 12:54.55 | *** join/#oe Mardy (n=mardy@adsl-118-50.38-151.net24.it) |
| 12:55.12 | Mardy | hi |
| 12:55.18 | Spyro | its still building the older 2003 rev though |
| 12:55.22 | Spyro | hi mardy |
| 12:57.30 | RP | Spyro: You might need to set CVSDATE_konqueror-embedded |
| 12:57.56 | RP | Spyro: and check your bitbake it uptodate as there were issues when both of these were set in older bitbakes |
| 13:01.24 | Spyro | older meaning older than 2 days ? |
| 13:01.56 | Spyro | I dont need to specify PREFERRED_VERSION_konqueror-embedded-snapshot = "0.0cvs20050322" |
| 13:01.59 | Spyro | do i? |
| 13:03.04 | RP | Spyro: not newer than 2 days, no |
| 13:03.24 | RP | Spyro: that would depend on the PN of the package... |
| 13:04.20 | Spyro | PN ? |
| 13:04.53 | RP | Package Name - comes from the .bb filename but can be redefined |
| 13:05.14 | RP | bitbake knows it as $PN |
| 13:05.45 | Spyro | ok |
| 13:06.07 | Spyro | what becvame of the C verson of bb that was mooted ? |
| 13:06.55 | RP | nobody has had time to work on it |
| 13:07.00 | Spyro | shame |
| 13:13.26 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
| 13:19.09 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 13:20.48 | *** join/#oe bora (n=bora@85.103.174.58) |
| 13:56.10 | *** join/#oe xtmdster (n=default@adsl-69-234-22-118.dsl.irvnca.pacbell.net) |
| 13:57.23 | *** join/#oe idealm (n=ideal@58.33.48.72) |
| 14:07.26 | *** join/#oe malfimalfi (n=malte@dslb-084-059-044-234.pools.arcor-ip.net) |
| 14:37.50 | *** join/#oe MP0_ (n=paulinge@63.161.128.32) |
| 14:57.29 | *** join/#oe theturtle_ (n=theturtl@lns-bzn-51f-81-56-135-127.adsl.proxad.net) |
| 15:13.17 | *** part/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 15:21.12 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 15:32.18 | ade|desk | RP: what does mmc0: unrecognized SCR structure version 1 mean ? |
| 15:32.24 | *** join/#oe drw (n=drw@c-67-172-219-167.hsd1.tx.comcast.net) |
| 15:34.17 | RP | ade|desk: It means we need 2.6.15-rc6 ;-) |
| 15:34.31 | RP | I also have a fix for the akita backlight resume bug |
| 15:34.33 | mickeyl | heh |
| 15:36.14 | ade|desk | RP: souds good |
| 15:37.35 | ade|desk | RP: whats in rc6 thats so good then ? |
| 15:37.45 | RP | ade|desk: a fix for the SCR problem |
| 15:38.00 | RP | I believe - try looking at the changelog as I think its mentioned |
| 15:39.10 | ade|desk | [MMC] Proper check of SCR error code |
| 15:39.38 | ade|desk | how much of your code does rc6 break ? |
| 15:40.30 | RP | ade|desk: Its not a big diff - very little should break |
| 15:40.36 | RP | I'll do a release soon |
| 15:40.58 | ade|desk | :) sounds damn good to me |
| 15:41.23 | RP | The bigger problem is the mmc driver is dead after a suspend/resume :-/ |
| 15:42.03 | ade|desk | ok that sucks |
| 15:42.57 | RP | Do we have a c7x0 user seeing that problem? |
| 15:43.05 | RP | I wonder if its cxx00 specific... |
| 15:44.43 | ade|desk | sorry can only test c100 |
| 15:44.45 | ade|desk | +0 |
| 15:44.58 | koen | RP: is there a way to download patches from RMKs tracker? |
| 15:45.14 | RP | koen: no, cut and paste I'm afraid :-/ |
| 15:45.19 | koen | crapzilla |
| 15:45.26 | RP | AFAIK anyway |
| 15:45.35 | koen | ok |
| 15:45.41 | koen | time to c/p 13 patches |
| 15:47.12 | RP | Right - suspend/resume mmc lockup is cxx00 only |
| 15:47.29 | RP | which makes it highly likely my code it at fault :) |
| 15:47.45 | ade|desk | bad Rp , naughty RP , slap |
| 15:48.32 | ade|desk | can you tell its 2 hours away from christmas hols yet ? |
| 15:49.12 | RP | yes, same test on spitz locks it up :) |
| 15:49.24 | RP | ah well, that gives s good clue as to what the problem is :) |
| 15:49.54 | ade|desk | you mean you let the elves in |
| 15:50.31 | RP | At least I can reproduce it... |
| 15:51.10 | ade|desk | promising |
| 15:52.21 | ade|desk | 3208/1 Overlay 1 and 2 support for the Intel PXA27x (part 1 of 2) 2.6.15-rc5-git5 15 Dec 2005 18:53:47 |
| 15:52.43 | ade|desk | was just look at that stuff from intels site, lol |
| 15:54.47 | koen | damn |
| 15:54.55 | koen | that wouldn't work on the hx |
| 15:54.59 | koen | stupid ati w3220 |
| 15:55.34 | ade|desk | koen: but the ati i probably a better 2d accel no ? |
| 15:55.40 | ade|desk | s/i/is |
| 15:55.43 | koen | probably |
| 15:56.12 | koen | let's hope the 2.6 aticore stuff will be finished soon |
| 15:56.19 | ade|desk | indeed |
| 15:56.55 | RP | koen: aticore might not run with the w3220 |
| 15:57.05 | RP | we can only guess the differences between the w100 and w3220 |
| 15:57.06 | ade|desk | hmm only patch 1 of 2 , wonder where 2 of 2 i s |
| 15:57.28 | koen | RP: too bad |
| 15:58.13 | koen | ~lart nvidia for removing mediaq docs |
| 16:03.50 | *** join/#oe schurig (n=schurig@p54B296AC.dip0.t-ipconnect.de) |
| 16:04.42 | schurig | mickeyl: Merry & blessed Christmas ! |
| 16:05.29 | *** join/#oe Crofton (n=balister@hc6521d1e.dhcp.vt.edu) |
| 16:07.38 | koen | RP: the eabi patches still apply to rc6 |
| 16:18.45 | RP | koen: Is that a hint? :) |
| 16:19.24 | koen | if you want it to be ;) |
| 16:25.45 | RP | koen: I'm tempted to apply those patches to the oz kernel :) |
| 16:26.21 | koen | that was my plan too *after* &*(&^(#%# glibc has been built |
| 16:26.50 | koen | you'd probably want 3108 - 3112 and 3204 too |
| 16:27.10 | RP | Can anyone else see the really neat simplification of OE's dependencies with what I'm proposing on oe@hh.org or am I just imagining things... |
| 16:27.57 | koen | you're proposing something what resembles how familiar handled it in the past |
| 16:28.45 | RP | I mean removing the DEPENDS >= RDEPENDS constraint and having bitbake's build list = DEPENDS+RDEPENDS+RRECOMENDS |
| 16:30.15 | koen | that won't work |
| 16:30.23 | koen | due to that ugly python mess |
| 16:30.50 | RP | I'm not saying its easy... |
| 16:30.55 | RP | but if we make a plan... |
| 16:30.57 | koen | R* stuff in only known at packaging time |
| 16:31.15 | koen | and with debian shlib renaming it will be even harder |
| 16:31.43 | koen | it actually is a non-problem |
| 16:31.56 | koen | since R* is *always* a subset of DEPENDS |
| 16:32.15 | RP | Its not |
| 16:32.31 | koen | it should be |
| 16:32.52 | RP | It OE as it stands it is but it doesn't have to be |
| 16:33.21 | RP | a hotplug script does not need virtual/hotplug to build but it is a runtime dependency |
| 16:33.55 | [lala_] | if a .bb file produces several packages - how can R* always be a subset? take glibc package as an example |
| 16:34.29 | koen | RP what about http://handhelds.org/hypermail/oe/51/5113.html ? |
| 16:35.24 | RP | koen: The duplicate information for DEPENDS and RDEPENDS just looks and feels wrong and worst still makes things break easily |
| 16:40.02 | RP | kergoth: As someone who was probably involved with this in the depths of time, was the overlap between DEPENDS and REDEPENDS intentional? |
| 16:48.45 | koen | RP: RDEPENDS was invented to cope with stuff shlibs doesn't pick up (among other stuff) |
| 16:49.12 | koen | it is for package managers, not for building |
| 16:49.15 | *** part/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 16:49.20 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 16:49.46 | RP | koen: using it for building as well would make more sense than the current postion though... |
| 16:50.02 | koen | why should it? |
| 16:50.10 | koen | it should always be a subset of DEPENDS |
| 16:50.57 | koen | if OE was a 'build one package at a time' sort of thing you would be right with your hotplug example |
| 16:51.22 | koen | but OE is 'give me everything I need' kind of thing |
| 16:54.50 | RP | It applies even more when building multiple packages rather than the other way around... |
| 16:56.09 | koen | You want a seperate list of 'not needed for building, but needed on runtime'-stuff? |
| 16:56.46 | RP | koen: A mutli threaded bitbake would find that useful |
| 16:57.09 | RP | and I think the duplication of data is plain wrong |
| 16:57.20 | koen | that would be usefull, but that's not what RDEPENDS is about |
| 16:57.33 | RP | but can it be used for that? |
| 16:57.50 | koen | not cleanly |
| 16:57.56 | RP | why not? |
| 16:58.25 | koen | interpreted languages, xml files used for compilation and runtime, etc |
| 16:58.46 | RP | you've lost me... |
| 16:59.34 | RP | if something is used at both build and runtime it can go in both... |
| 16:59.48 | koen | correct |
| 17:00.29 | RP | but some things aren't and we have no way to handle that |
| 17:01.14 | koen | if the result worth the trouble of implementing that? (if it is even possible) |
| 17:02.09 | koen | s/if/is/ |
| 17:04.22 | koen | and will it confuse people even more? |
| 17:10.18 | RP | It means you no longer need to set both DEPENDS and RDEPENDS to match |
| 17:10.43 | RP | I think the simplification would be worth it |
| 17:12.39 | reenoo_ | although DEPENDS and RDEPENDS happen to sometimes contain the same elements, they can be entirely disjoint sets and there's no known correlation between the two |
| 17:14.28 | RP | reenoo_: Despite the fact DEPENDS >= RDEPENDS ? |
| 17:14.48 | RP | I know the names can be different for subpackages and that is a problem we'd need to solve |
| 17:18.20 | reenoo_ | we need to solve a hell lot of problems |
| 17:18.45 | reenoo_ | let's do one thing after another and get the task-bootstrap split done first |
| 17:19.21 | reenoo_ | it's not that difficult to grok how dependencies work in OE after all |
| 17:30.24 | kergoth | RP: eh? Imposing some foolish arbitrary limitation on subpackage naming because you don't want to have duplicate data is just plain wrong. |
| 17:34.59 | RP | kergoth: its not the duplicate data that bothers me in that case - its the inability to work out which packages provide a given subpackage |
| 17:35.30 | kergoth | what are you talking about? |
| 17:35.39 | gb2 | hiya kergoth |
| 17:35.59 | gb2 | it's surprisingly warm here :) |
| 17:36.41 | RP | kergoth: Can bitbake work out which PN's might provide kernel-modules-hostap ? |
| 17:37.02 | kergoth | why? |
| 17:37.39 | RP | You're now going to tell me I don't need to know about that :) |
| 17:37.47 | RP | My point is it can't |
| 17:37.49 | kergoth | i'm just trying to figure out what you're trying to do |
| 17:37.59 | kergoth | you're spouting nonsense about RDEPENDS and DEPENDS as though they dont need to be seperate, when they do |
| 17:38.07 | kergoth | so lets back up a step, what exactly are you trying to do adn why? |
| 17:38.16 | RP | There are several things here that bother me, all interconnected |
| 17:39.04 | RP | One conern is we have no way of specifying runtime dependencies without making them build dependencies as well |
| 17:39.21 | kergoth | uh? |
| 17:39.47 | RP | DEPENDS must contain everything in RDEPENDS |
| 17:39.51 | RP | so I'm told |
| 17:39.55 | kergoth | no, that is not the case. |
| 17:40.28 | RP | Well, all packages/subpackages in RDEPENDS must be listed in RDEPENDS |
| 17:40.33 | kergoth | what? |
| 17:40.46 | RP | <PROTECTED> |
| 17:40.55 | RP | according to what I keep getting told... |
| 17:41.30 | kergoth | RDEPENDS is _only_ used by packaging. DEPENDS is not. |
| 17:41.39 | kergoth | i can use oe and bitbake without packaging anything at all. |
| 17:41.45 | RP | right |
| 17:42.30 | RP | My point is that it might be better to have oe and bitbake using DEPENDS and RDEPENDS to work out the buildlist |
| 17:43.01 | kergoth | you're assuming that the packages you're building are going to be used in an oe built root filesystem. there's no guarantee of that. |
| 17:43.36 | kergoth | but i still dont see what you're proposing |
| 17:43.39 | kergoth | "buildlist"? |
| 17:44.05 | kergoth | it sounds like you're proposing imposing a limitation on the system. making bitbake add the packages that provide the elements in RDEPENDS to DEPENDS |
| 17:44.18 | RP | What I'm proposing doesn't change anything in the built packages so I don't understand you point either... |
| 17:44.46 | RP | bitbake produces a list of packages to build - correct? |
| 17:44.50 | kergoth | you're about to make it impossible for me to emit packages that RDEPEND on things that arent provided in the oe package metadata. |
| 17:45.21 | RP | That is a valid point |
| 17:45.56 | RP | and probably what ASSUME_PROVIDED though? |
| 17:46.12 | kergoth | ASSUME_PROVIDED is _build_ package names, not _runtime_ |
| 17:46.18 | kergoth | DEPENDS, not RDEPENDS |
| 17:46.54 | RP | At the moment, you can't have a package that has a RDEPEND that isn't in its DEPEND |
| 17:46.55 | kergoth | honestly i dont see the point. you're proposing imposing a limitation on the system, or adding variables to get around your imposed limitation, and gaining precisely nothing. |
| 17:47.00 | RP | or so I keep getting told |
| 17:47.24 | RP | I'm just not explaining it well :-( |
| 17:47.25 | kergoth | what makes you think that? of course you can, just the binary packages your emitted binary packages depend on, then wont be built by the time you build an image. |
| 17:47.32 | kergoth | but no one is forcing people to build images anyway |
| 17:47.43 | kergoth | and 99% of the time, RDEPENDS is populated automatically |
| 17:48.04 | RP | I've been asked to revert changes that have RDEPENDS that aren't in DEPENDS |
| 17:48.40 | RP | Having RDEPENDS that aren't in DEPENDS really messed up image generation |
| 17:48.46 | kergoth | because they want to ensure that those rdepends have been built by the time you're creating an image |
| 17:48.47 | kergoth | right |
| 17:48.51 | kergoth | stop assuming people have to build images. |
| 17:49.02 | kergoth | stop making assumptions about people's use of oe and bitbake in general |
| 17:49.20 | RP | I'm not - others are and are telling me to stick to their assumptions |
| 17:49.36 | RP | I don't want DEPENDS >= RDEPENDS |
| 17:49.48 | RP | so we're actually on the same side here :) |
| 17:50.20 | RP | The question becomes can be make bitbake resolve both DEPENDS and RDEPENDS for images? |
| 17:51.00 | kergoth | you mean.. look at the rdepends of all the packages we're about to install, go determine what packages provide them, then build them? |
| 17:51.13 | RP | yes |
| 17:51.18 | kergoth | thats a good idea, and would solve it. DEPENDS would then be what it was originally designed for, proper _BUILD_ dependencies |
| 17:51.24 | kergoth | only that which is needed to build the package |
| 17:51.32 | RP | This is what I want to achieve |
| 17:51.42 | RP | Everyone else is telling me I'm mad |
| 17:51.48 | kergoth | okay, i agree, guess we just had a communications breakdown there, i didnt understand your intent |
| 17:52.01 | Crofton | heh |
| 17:52.24 | Crofton | Every time someone says that I hear Led Zeppelin in my head |
| 17:53.55 | kergoth | DEPENDS should contain _that which your package needs to build_ only. it sounds like people are polluting it |
| 17:54.13 | RP | Its being badly abused |
| 17:54.33 | RP | and people are saying the pollution is the correct behaviour as it fixes image generation |
| 17:54.57 | kergoth | yeah, that's completely bogus. |
| 17:55.30 | RP | Could you post that to oe@hh.org please :) |
| 17:55.37 | emte | that has more to do with some packages having wrong/missing depends isnt it? |
| 17:55.38 | kergoth | they're not only fixing it wrong, they're ruining the integrity of the metadata based on an assumption |
| 17:55.48 | *** join/#oe molivier (n=omougin@d05v-213-44-3-143.d4.club-internet.fr) |
| 17:55.48 | kergoth | can do |
| 17:55.53 | RP | kergoth: Yes, which is why I want to try and fix this |
| 17:56.30 | RP | Its been bugging me a lot but nobody will listen to me :) |
| 17:56.40 | RP | They might listen to your second opinion though.... |
| 17:56.58 | kergoth | is there an existing thread, or should i just start ranting? :) |
| 17:57.15 | RP | start a new one :) |
| 17:57.24 | RP | The existing ones are confused |
| 17:58.45 | *** join/#oe andersee (n=andersen@codepoet.org) |
| 18:00.34 | *** join/#oe lrg|home (n=liam@exize.demon.co.uk) |
| 18:04.48 | *** join/#oe dkey| (n=dkey@L0004P15.dipool.highway.telekom.at) |
| 18:05.04 | RP | I'm being called away now :-( |
| 18:05.09 | kergoth | RP: whats your email addy? gonna cc you on the mail so you can read it sooner |
| 18:05.12 | kergoth | k |
| 18:05.26 | RP | kergoth: rpurdie@rpsys.net |
| 18:05.49 | reenoo_ | heh |
| 18:05.53 | kergoth | sent. |
| 18:06.02 | RP | reenoo_: You might want to read the above |
| 18:06.09 | reenoo_ | nobody ever said it would not be nice if DEPENDS could be just build dependencies. unfortunately that currently breaks image generation. if you have a fix for that people will be happy to use that I would think |
| 18:06.34 | RP | reenoo_: That doesn't make breaking the metadata right |
| 18:06.50 | kergoth | the problem is, you're ruining the integrity of the metadata. if at some point we do fix it correctly, now its going to take a huge amount of effort to recover the lost information. |
| 18:07.40 | reenoo_ | well. DEPENDS has been used this way ever since I joined the project |
| 18:07.56 | reenoo_ | 2.5 years ago |
| 18:08.08 | reenoo_ | (IIRC) |
| 18:08.23 | RP | kergoth: I think you can see the scale of this problem :-( |
| 18:08.52 | RP | anyhow I really must go - the mail gives me something to try and move this forward with. kergoth: thanks |
| 18:09.08 | kergoth | no problem, sorry i misunderstood at first |
| 18:09.11 | reenoo_ | later RP |
| 18:10.08 | kergoth | i should pull down oe, havent played with it in ages |
| 18:14.09 | reenoo_ | so, how are you going to resolve RDEPENDS on automatically named packages? |
| 18:15.41 | reenoo_ | s/resolve/determine DEPENDS from/ |
| 18:16.20 | kergoth | i see a few possibilities. list the original package names in the image's variable, then let it scan PACKAGES for those, then finally run the name mangling on them itself to deteremine the names to actually install with ipkg |
| 18:16.49 | kergoth | or.. well i've been out of it too long to say the other off the top of my head |
| 18:17.12 | kergoth | but better to take the time to do it properly than to let this continue as is |
| 18:19.01 | reenoo_ | hmm. might work |
| 18:19.39 | reenoo_ | i.e. something like RDEPENDS = "gst-plugins:gst-plugin-mad" |
| 18:20.26 | koen | and now make it work with and without debian lib renaming |
| 18:20.33 | kergoth | .. |
| 18:20.37 | kergoth | thats what i was just talking about, actually. |
| 18:20.52 | koen | and python-crap to autogenerate subpackages |
| 18:21.15 | kergoth | koen: all that ends up in PACKAGES eventually, doesnt it? |
| 18:21.32 | kergoth | the image creator just scans the metadata for .bb's whose PACKAGES list the elements we want in the image. |
| 18:21.32 | koen | eventually, yes |
| 18:21.34 | kergoth | right |
| 18:21.47 | reenoo_ | that won't work |
| 18:22.12 | kergoth | how so? |
| 18:22.15 | reenoo_ | PACKAGES is generated *after* do_build() |
| 18:22.25 | kergoth | what? |
| 18:22.44 | kergoth | no, it isnt. do_package is a dependency of do_build |
| 18:22.59 | kergoth | unless you guys completely changed things while i was gone |
| 18:23.45 | reenoo_ | s/do_build/do_compile/ sorry |
| 18:24.32 | reenoo_ | the problem being that you have to compile the package first before you know how PACKAGES will look like |
| 18:24.41 | kergoth | and? |
| 18:24.46 | kergoth | hmm |
| 18:24.48 | kergoth | i see what you mean |
| 18:25.24 | kergoth | wait, give me an example of a package whose PACKAGES isnt determined until after compilation |
| 18:25.39 | koen | gst-plugins or gnumeric iirc |
| 18:25.53 | reenoo_ | and glibc localedata |
| 18:27.48 | kergoth | i'm not even sure where to start in describing the issues with that. sigh. |
| 18:27.48 | koen | kergoth: http://handhelds.org/hypermail/oe/51/5120.html |
| 18:28.36 | kergoth | DEPENDS is not a "lets shovel everything i need to install the packages" variable |
| 18:28.43 | kergoth | DEPENDS doesnt even assume you're emitting packages at all. |
| 18:31.27 | reenoo_ | koen: debian library renaming is taken care of by our shlibdeps code btw |
| 18:31.46 | reenoo_ | apart from -dev packages IIRC |
| 18:32.00 | kergoth | maybe itd be best to just rework our DEPENDS variables somewhat. currently we're destroying the build dependency information. |
| 18:36.20 | reenoo_ | well. the actual problem is that OE currently doesn't evaluate manually setRDEPENDS at all |
| 18:36.33 | kergoth | evaluate? |
| 18:37.00 | reenoo_ | it just copies that stuff into the package control file and has ipkg do the rest |
| 18:37.33 | kergoth | which is as it should be. RDEPENDS is runtime. when you build a package in .oe, you're building that package and what was necessary to build that package. not what was necessary to run that package. |
| 18:37.51 | reenoo_ | until you want to build an image |
| 18:40.04 | reenoo_ | anyways |
| 18:40.15 | kergoth | again, the intent was for DEPENDS to hold build dependency information, not everything you need to run it. and hardcoding the name of one (of possibly many) packages that can emit the runtime ones you need |
| 18:40.17 | kergoth | seems wrong |
| 18:41.22 | reenoo_ | of course the current (ab)use of DEPENDS is wrong |
| 18:42.50 | reenoo_ | but until someone teaches OE to build images with DEPENDS being build depends only you would break image generation |
| 18:43.12 | reenoo_ | which is what I've told RP before |
| 18:44.04 | kergoth | if you're aware of the problem, why do you continue to ruin the integrity of the metadata? this shouldve been dealt with a long time ago. |
| 18:45.14 | kergoth | even a hackish solution wouldve worked just to ensure that you arent losing information. DEPENDS = "foo $(BDEPENDS)" or something. seperate the real, actual build deps from the runtime crap. |
| 18:45.45 | reenoo_ | I rarely get to working on OE these days due to university and work stuff |
| 18:46.51 | reenoo_ | whenever I do spend time on OE I try to keep things in a status quo way working |
| 18:47.05 | reenoo_ | I just can't fix any issues in the core these days |
| 18:47.50 | *** join/#oe zinosat (n=Davide@adsl-194-86.38-151.net24.it) |
| 18:51.31 | reenoo_ | I mean.. in a perfect world I would have fixed out-of-tree kernel module dependency handling, done the task-bootstrap split and rewritten ipkg ages ago >:) |
| 18:51.48 | kergoth | hehe |
| 18:52.31 | kergoth | i mean, i dont expect this to be fixed correctly right now, but at the very least we should fix it so we arent losing information. so that when we do fix it correctly, it isnt going to be impossible to recover the knowledge of what deps arent actual build deps, you know |
| 18:53.54 | reenoo_ | good plan. I like your DEPENDS = "foo $(BDEPENDS)" idea (where BDEPENDS is actual build dependencies I suppose) |
| 18:54.39 | reenoo_ | as an interim solution that is |
| 18:55.02 | reenoo_ | would you mind sending a followup on that to oe@ ? |
| 18:55.16 | kergoth | will do |
| 18:55.24 | reenoo_ | thanks |
| 18:56.05 | kergoth | np, thanks for the info. didnt realize that you cant know what binary packages will be emitted until compile time in some cases. meh. |
| 19:23.19 | *** join/#oe _law_|iBook (n=_law_|iB@213.173.86.202) |
| 19:23.53 | *** join/#oe alwin_ (n=ral@cable-195-14-254-92.netcologne.de) |
| 19:42.42 | *** join/#oe fyliu (n=Fangsta@pool-71-109-15-33.lsanca.dsl-w.verizon.net) |
| 19:54.19 | *** join/#oe pb_ (n=pb@2002:5168:d214:1:a00:1fff:fe06:93c) |
| 19:56.06 | *** join/#oe MP0_ (n=paulinge@63.161.128.32) |
| 20:10.50 | *** join/#oe koen__ (n=koen@dominion.kabel.utwente.nl) |
| 20:50.39 | *** join/#oe rob_w (n=bob@p85.212.140.248.tisdip.tiscali.de) |
| 20:50.42 | rob_w | hi |
| 21:32.26 | chouimat | ok merry xmas to everybody see you all around the 27 or the 28 |
| 21:37.15 | *** join/#oe shiyee (n=Shiyee@0x50c5a714.abnxx4.adsl-dhcp.tele.dk) |
| 21:39.51 | *** join/#oe koen|770 (n=Koen@dominion.kabel.utwente.nl) |
| 21:40.39 | *** join/#oe dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 21:45.57 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 22:02.08 | *** part/#oe _law_ (n=_law_@213.173.86.202) |
| 22:31.00 | *** join/#oe wingel (n=wingel@2-1-3-15a.ens.sth.bostream.se) |
| 22:31.01 | *** part/#oe wingel (n=wingel@2-1-3-15a.ens.sth.bostream.se) |
| 22:31.16 | *** join/#oe wingel (n=wingel@2-1-3-15a.ens.sth.bostream.se) |
| 22:32.13 | *** join/#oe reenoo_afk (n=r@p5489CBE3.dip.t-dialin.net) |
| 22:37.24 | RP | kergoth: Some of my other comments were about trying to solve the knowing what packages will be emitted before compile time problem |
| 22:42.08 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 22:46.30 | *** join/#oe synth (n=cb@pcp839781pcs.venice01.fl.comcast.net) |
| 23:30.11 | *** join/#oe hufnus (n=slonsiki@DSL135-071.LABridge.com) |
| 23:41.56 | *** join/#oe omougin_ (n=omougin@d03v-212-194-222-80.d4.club-internet.fr) |
| 23:43.25 | *** join/#oe koen_ (n=koen@dominion.kabel.utwente.nl) |
| 23:57.27 | *** join/#oe MP0_ (n=paulinge@63.161.128.32) |