=== Snova_ is now known as Snova === Snova_ is now known as Snova [02:54] how do i build nvidia driver for my specific kernel [02:54] m-a is broken [02:54] and i dont know to give dkms for version etc [02:54] module=nvidia version=180 doesnt work [02:55] scientes: What kernel are you running? [02:55] 2.6.27.11-g [02:56] scientes: you need linux-headers-generic installed [02:56] have that [02:56] the only way to get it to work is to restart but thats stupid [02:56] you shouldnt break m-a [02:57] scientes: the nvidia kernel driver in intrepid afaicr uses dkms. [02:57] dkms build -m nvidia -v 180 [02:57] Error! DKMS tree does not contain: nvidia-180 [02:57] Build cannot continue without the proper tree. [02:57] give me the command that occurs on startup for dkms [02:58] scientes: I don't know enough about dkms to help any further sorry. [02:58] bingo [02:58] /etc/init.d/dkms_autoinstaller start [03:02] robert_ancell: have you managed to get anywhere with bug 353090? [03:02] Launchpad bug 353090 in guadalinex "(jaunty) Text hidden on "Who are you?" step" [High,Confirmed] https://launchpad.net/bugs/353090 [03:02] robert_ancell: (I'm off to bed now, but will read messages) [03:23] does anyone here suffer from bug 44194 (or, failing that, even just using WPA wireless networking would be somewhat interesting)? If so, could you please make sure you're up to date with jaunty and then upgrade to the wpasupplicant package in my PPA (https://launchpad.net/~cjwatson/+archive/ppa)? [03:23] Launchpad bug 44194 in openssl "wpasupplicant doesn't start when the network start" [High,Fix released] https://launchpad.net/bugs/44194 [03:24] I don't actually have a WPA network here so it's a bit tricky ... [03:25] and I'd like a bit of testing from people who know what they're doing and how to recover from problems before unleashing it on the large number of subscribers to that bug [03:26] * cjwatson goes to fall over for a bit [03:33] cjwatson: I run a WPA wireless network here with a couple of Ubuntu WPA clients. I'll get latest updates and check that bug to see whether I suffer from it, and if so, will test your fix. [03:37] cjwatson: I do have separate /usr, so I could do some testing; would probably be another day or two before I get a chance though, with the rebooting & fiddling involved [04:09] Oh, separate /usr, and static wpa config. I have neither configuration here. :) === Snova_ is now known as Snova [04:27] May someone give me some clue, I'm looking for the source code that define the behaviour of Apple Keyboard [04:52] * calc wonders if there is anything stopping us from flipping a bit to compressing all debs by default with lzma [04:52] aiui opensuse already does that for rpm's [04:58] calc: isn't the reason we don't more to do with lzma's massively increased speed and memory requirements? [04:58] well it takes more on the compression side but takes less cpu time to decompress than even bz2 [04:58] memory requirement was ~ 30MB iirc to decompress [04:58] calc: but bz2 uses more cpu time to decompress than there are seconds left in the universe's life [04:59] so that bar is so low, you practically trip over it on the way in [04:59] iirc it would save us ~ 200MB on the alternate cd when i tested it before [04:59] the alternate CD is not the only problem space-wise [04:59] and, pointedly, the alternate is the fallback in the low memory situations [04:59] yea, getting lzma onto the desktop cd would be more problematic :\ [04:59] I'd be interested to see benchmarks, but I'd be surprised if lzma performed anywhere near gzip [04:59] obviously it can be enabled on a package-by-package basis like we do with bz2 [05:00] hmm true [05:00] we already use bz2 for mostly-text debs where we remember [05:00] how much ram does the alternate disk take by itself i would think we would still be well below the minimum install requirements even with lzma [05:00] no idea [05:01] roughly 3x slower than gzip to decompress [05:01] with bzip being 8x slower than gzip [05:02] what's the difference in compression like? [05:02] as of 7.10 gzip for a whole cd would be 708MB vs 500MB for lzma [05:02] really? [05:02] you tried it? [05:02] also reduces bandwidth requirements obviously for network updates, etc [05:02] https://wiki.ubuntu.com/dpkg-lzma [05:03] yea when i patched dpkg to support lzma [05:03] original was a mixture of bzip2 and gzip already on the cd, i recompressed it all with gzip, bzip2, and lzma to get numbers to see if everything was in one format [05:04] I just picked on a random package [05:04] -rw-r--r-- 1 scott scott 170K 2008-09-29 18:04 upstart_0.3.9-8_i386.deb [05:04] -rw-r--r-- 1 scott scott 170K 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma [05:04] zero difference [05:04] well [05:04] -rw-r--r-- 1 scott scott 173672 2008-09-29 18:04 upstart_0.3.9-8_i386.deb [05:04] -rw-r--r-- 1 scott scott 173754 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma [05:04] the lzma is, in fact, larger [05:05] the ods file on the wiki shows the all the packages on the cd as of 7.10 [05:05] I instantly disbelieve the wiki page [05:05] there were a small numbers of packages like that which grew very slightly [05:05] [05:05] original [05:05] [05:05] none [05:05] [05:05] gzip [05:05] [05:05] bzip2 [05:05] [05:05] lzma [05:05] cjwatson: will update you when I can... [05:05] [05:05] lzma saves [05:05] openoffice.org-core [05:05] [05:05] 37215228 [05:05] [05:06] 112219498 [05:06] [05:06] 38941278 [05:06] [05:06] 37319546 [05:06] [05:06] 27002374 [05:06] [05:06] 10212854 [05:06] err [05:06] BAD PASTE [05:06] what I was trying to point out is that the original number doesn't match ANY of the other numbers! [05:06] so, according to that wiki page, all of the packages are apparently compressed with fairyzip [05:06] for upstart as of 7.10 it was gzip 159454, bzip2 157482, lzma 138966, but of course has changed now [05:07] Keybuk: eh? [05:07] upstart has not changed since 7.10 [05:07] fairyzip? [05:07] not majorly anyway [05:07] calc: as in, the numbers do not match [05:07] compiler has [05:07] calc: openoffice.org-core original should match bzip identically [05:07] otherwise the test is not valid [05:08] well i was using the regular utils to compress not whatever dpkg does internally [05:08] dpkg just uses them too [05:08] maybe it uses some different args to tar for older compatibility? [05:08] not that I know of [05:09] easiest way is just to extract and recompress the control.tar.gz [05:09] gunzip && bzip2 [05:09] the difference is on the order of 0.28% [05:09] thats what i did and it ended up with different sizes than dpkg [05:09] you recompressed the entire cd? [05:10] i'm not sure if i still have the scripts but i used dpkg to pop out the control and the data and then recompressed the data and stuffed it back in [05:10] yes, and the ods shows all the packages [05:11] cool [05:11] I'm surprised it's honestly that much [05:11] a lot of the differences were in the range of .01% difference between original and the same compression type as original [05:12] but they look like they consistently ended up different sizes than the original packages compressed in at least supposed to be the same way [05:13] we're already using lzma for things like openoffice now, right? [05:13] yea === thunderstruck is now known as gnomefreak [05:18] it bought 14% over bzip2 on OOo source in a test i just did [05:18] not bad considering how big OOo is, heh [05:19] the unlzma times seem quite reasonable here [05:19] unlzma data.tar.lzma 7.85s user 0.53s system 96% cpu 8.670 total [05:19] gunzip data.tar 2.86s user 0.46s system 99% cpu 3.331 total [05:20] yea [05:20] it's the lzma times that really bite though [05:20] yea [05:20] but that is a one time cost... depends on if it is too high a one time cost i guess [05:20] Keybuk: lzma fails even worse once your gzip implementation uses threads [05:21] calc: that was the inflate time, not the deflate time [05:21] once per upload/build cost [05:21] Amaranth: i was talking about deflate, yes [05:21] Amaranth: deflate takes much longer [05:22] Keybuk: we already have a huge cost by dpkg-shlibdeps, yuck [05:22] not that huge [05:22] lzma has been running for what seems like minutes so far... [05:22] Keybuk: for OOo it is like 50% of the build time for a cached build i think [05:22] on the order of 20min+ [05:22] eep [05:22] i need to dig into that later this week since i have my bugs under control [05:23] calc: every time you talk about OOo building you make me less and less likely to ever even apt-get source it :P [05:23] i had talked to cjwatson about having a way to disable that option, heh [05:23] both the lzma and dpkg-shlibdeps could have flags to disable them for developer building and only enable them on buildds or something if needed [05:24] or so developers can disable them if they need to build quickly in any case :) [05:24] lzma data.tar 206.26s user 0.53s system 99% cpu 3:27.41 total [05:24] gzip data.tar 19.77s user 0.32s system 99% cpu 20.099 total [05:24] yea compression is yucky [05:25] hmm it was only 4x slower in my test back in 7.10 though, that is interesting [05:26] another place where lzma could help is in archive files like Contents, (amd64) gzip is 15759388, bzip2 is 12875965, and lzma is 10991062 [05:27] currently we appear to only have gzip versions available [05:28] contents isn't grabbed all the time but packages file see similar percentage improvements [05:30] yes [05:30] because the publisher run needs to take longer ;) [05:30] lol :-) [06:10] c [06:39] Congratulations on Ubuntu Jaunty Beta for x86_64! [06:39] You should add to your milestones, "Almost as stable as WindowsME!" === bluefox_ is now known as bluefoxicy [06:41] Keybuk: lzma fails even worse once your gzip implementation uses threads [06:41] lzma2 should be much better with multiple cores... [06:41] don't know if there is a linux port of that already? [06:43] it divides the file in "blocks" that it can compress in parallel [06:44] bluefoxicy: trolling is inappropriate and unwelcome. [06:45] slangasek: wrong bluefox :) [06:45] friendly fire!!!!111 [06:46] wait... [06:46] what the... [06:46] you know what, I'm gonna go to bed now. Night :) [06:46] jdong: night :) [06:46] it's been entirely stable from me, apart from sometimes failing to power off properly. [06:47] the OS itself has been great, but audio problems with proprietary crap has regressed [06:47] high CPU usage, latency, and cutouts from Skype especially, also Flash. [06:48] other than that, by far one of the cleanest upgrades I've done [06:52] about lzma2: http://sourceforge.net/forum/forum.php?thread_id=2965956&forum_id=45797 [06:53] (appears it's still alpha or beta though) [07:06] jdong: Sorry not much we can do re skype, other than you kill pulseaudio to use skype. [07:06] jdong: Oh try also using direct hardware input for the microphone via skype, and only use pulse for output. [07:45] TheMuso: pulseaudio-module-x11 Recommends: gnome-audio | ubuntu-sounds, which confuses germinate; is there any reason not to reverse the order of these? [07:46] slangasek: persia actually asked to have them turned around at one point, I can't remember his reasoning however. I think its in the changelog, let me look. [07:46] should it be supported to change /usr/bin/python symlink to other supported versions than python2.6 in jaunty? [07:46] TheMuso: arguably the Recommends should be dropped entirely... [07:47] hile: no [07:47] ok [07:47] I asked to switch it around precisely because it confused germinate. Dropping it would also meet my goals. [07:47] persia: you asked to have gnome-audio listed first because of germinate? [07:47] (or perhaps not "confuse" but rather "generated a behaviour I didn't want") [07:47] ah [07:47] fair enough, that would complicate things very much :) [07:47] Yeah I think pitti dropped them, but somehow they were re-added. I'll remove them. [07:48] TheMuso: ok, cheers :) [07:48] slangasek, Yes. I don't remember the specifics, but it was something about gnome-audio being installed when there was an ubuntu-sounds alternative available: perhaps related to universe flavours. [07:48] RIght. That was it: for universe flavours, ubuntu-sounds wasn't getting installed because gnome-audio was available. [07:48] persia: ok. the current formulation is going to prefer pulling in gnome-audio for universe flavors; it also causes germinate to want to pull gnome-audio into main. All told, it results in rather a bit of inconsistency. [07:49] I just had some personal code using default python which did not work in 2.6 and I changed 'temporarily' the link, noticing upgrade failed horribly - if it were supposed to be supported to change default python, there would have been a couple of bug reports to be done [07:49] slangasek, I'd agree, especially because I think we'd generally prefer ubuntu-sounds anyway. [07:49] * slangasek nods [07:49] anyway, just fixed my own code, that's the better solution anyway :) [07:50] hile: right - generally, packages are allowed to depend on a specific version of the 'python' package, and expect /usr/bin/python to be that version. [07:50] packages that need a version of python *other* than the current default can still invoke it as /usr/bin/python2.x [07:51] Note that packages that *do* use /usr/bin/python2.x need to be very careful about the libraries that may be available to that version of python. [07:56] yeah this was not packaged code anyway, just some local projects [07:57] * StevenK sighs at libdvdread reporting itself as 0.9.4 in Jaunty [07:58] * slangasek sighs at ogmrip having unreasonable requirements for libdvdread's version reporting [07:58] :) [07:59] slangasek: Ah, so you do know what is going on. [07:59] slangasek: I can patch libdvdread with a one-line patch and then ogmrip requires no changes. [07:59] StevenK: I got as far as the FTBFS and punted on it [07:59] I have no preference on how you fix it [08:00] well; if you change libdvdread, I prefer that it not make other packages FTBFS :) [08:01] * StevenK sobs at the rdepends list. [08:12] slangasek: In other news, do you know about openoffice.org-qa-{api-test,tools} in NBS? [08:13] slangasek: They look to have circular Depends, too [08:25] StevenK: yeah - I actually removed those two just now === reed is now known as Guest85285 [09:04] cjwatson: have workaround for bug 353090 [09:04] Launchpad bug 353090 in ubiquity "(jaunty) Text hidden on "Who are you?" step" [High,In progress] https://launchpad.net/bugs/353090 [09:06] hey robert_ancell [09:08] seb128: morning seb [09:08] Guys I got an issue with samba. I've got a share on my hardy server that works with vista, xp and intrepid but doesn't with jaunty. I'm just looking through the bug report now to see if it's known but thought I'd better add it here too === Guest85285 is now known as reed_ [09:50] robert_ancell: cool, thanks! will look into that. presumably if the parent widgets aren't realized then .realize() just harmlessly does nothing? === seb128_ is now known as seb128 [10:20] asac, do you have an idea about bug 356517 [10:20] Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517 [10:22] could someone please eyeball http://launchpadlibrarian.net/24926831/debdiff ? [10:23] mvo: looks ok to me [10:24] thanks [10:24] tests work fine too, I will upload === mdz_ is now known as mdz [10:27] ogra: driver issue i would think [10:28] ogra: do you have a lshal from such a board for me? [10:28] i can produce one [10:28] ogra: please do and attach to bug (i asked now) === azeem_ is now known as azeem [10:37] hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs? [10:38] good question [10:38] it's insane that somebody can login to a non-root shell and disrupt the whole system [10:53] I read that debian is not affected [10:54] by what? [10:54] hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs? [10:54] oh, dunno about that one [11:02] Debian does not set a maximum number of processes in /etc/security/limits.conf either, so I don't know where you read that. You can check the differences yourself: http://patches.ubuntu.com/p/pam/pam_1.0.1-9ubuntu1.patch [11:03] I imagine the problem is that there is no sensible default. Any limit that will be high enough to avoid impeding legitimate work would also be high enough that a forkbomb would cause problems well before it ever reached the limit [11:04] weren't there kernel scheduler changes to try to level out timeslices among users, so that even if one user had a zillion processes running, another user could still get their processes scheduled effectively? [11:04] that's a much better approach to this kind of problem [11:05] asac, attached [11:06] "I'll quickly mention here that Debian did not suffer the same fate as the others; congrats to the Debian development team." ( http://www.securityfocus.com/columnists/308 ) but in the comments someone said debian is affected [11:13] so the kernel scheduler has to be fixed instead of setting a maximum number of processes? [11:13] has to be hard because the problem still exists [11:14] all approaches to this problem are hard; there is no easy answer (assuming you don't just ignore some of the constraints, as journalists are apt to do) [11:15] im a customer at a small shared web hosting where they give ssh access [11:15] they not big and professional but I really like the ssh access [11:15] I tried a fork bomb in that shell and their server got hosed [11:15] they run debian, but a really old version [11:16] i bet there is lots of ubuntu server installs like that, where a fairly large set of semi-untrusted people are given non-root accounts [11:16] i dont pretend to have a solution though.. [11:18] ogra: that unfortunate. why does that driver need that parent? [11:19] the general term for scheduler fixes that address this problem is "group scheduling" [11:19] ogra: udi = '/org/freedesktop/Hal/devices/net_00_00_45_67_89_ab' [11:20] info.parent = '/org/freedesktop/Hal/devices/computer' (string) [11:20] you can google for it with site:lwn.net for a number of good explanations === Mez is now known as CrazyShoe === CrazyShoe is now known as Mez [11:22] ogra: is that kind of a special device? [11:22] e.g. not pci et al? [11:22] ogra: we opted out managing virtual devices [11:22] ogra: linux.sysfs_path = '/sys/devices/virtual/net/eth0' (string) [11:24] "if a user is running a fork bomb then other users are not affected at all [CPU scheduling wise], and the admin can log in and disable the user as well.)" [11:24] I suspect that the problem is that we have cgroup scheduling enabled, but aren't properly setting up cgroups for tasks [11:26] as this seems to be a bigger problem I might open a question in launchpad for the ubuntu kernel [11:26] cjwatson: did your broadcom driver finally get a proper name or do you still see 'NULL(info.linux.driver)' in the syslog? [11:27] /var/log/syslog.6.gz:Mar 31 21:00:08 sarantium NetworkManager: (wlan0): new 802.11 WiFi device (driver: 'NULL(info.linux.driver)') [11:27] asac: ^- [11:27] sigh [11:28] ogra: ^^ [11:28] asac: that said it works fine ... [11:29] cjwatson: yes. we still carry a patch for that [11:29] i hoped we could drop it [11:31] cjwatson: yes, afaik realize() is not an issue for already realized widgets [11:33] ogra: can you drop the lp199140_dont_manage_virtual_devices.patch; that whould work; then i need the syslog while it works [11:35] cjwatson: re-read your question, yes it will realize any unrealized parents [11:37] I asked a question in launchpad about it: https://answers.launchpad.net/ubuntu/+question/66716 [11:37] thanks for your answers (in this channel) [11:38] asac: how does firefox do its mimetype detection currently? [11:38] asac, its ARM ... [11:38] asac, there is no publically expo9sed PCI bus on any ARM devices [11:49] * ogra twiddles thumbs installing the build deps ... === siretart_ is now known as siretart [12:15] siretart, plans for xine-lib 1.1.16.3? It's a security update === thunderstruck is now known as gnomefreak [12:23] KaiL: dtchen: I see that darren already has prepared an 1.1.16.3 upload. I'll check with him and merge that in the ubuntu hg branch [12:23] ah, ok [12:28] seb128: hi, the fix for bug #352657 has a nasty side-effect. it's better to remove it or to code another variant of the same fix. I've posted the problem in the bugreport [12:28] Launchpad bug 352657 in evolution-indicator "All the strings from evolution-indicator shows untranslated" [Low,Confirmed] https://launchpad.net/bugs/352657 [12:29] RicardoPerez: hi, I've read your comment on the bug and I don't get the issue there, waiting on ted to be online [12:31] seb128: OK. are you followed the steps to reproduce the new issue? [12:32] no [12:32] I've been too busy for that, I'm waiting for ted as said before [12:33] seb128: ok, thanks for all [12:33] you should relax a bit, the way you pressure one bugs nominating everything for jaunty etc is not helping there [12:33] everybody is busy [12:34] I have a quick question. Rhythmbox has support for using brasero for CD writing. Considering that we have removed nautilus-cd-burner from default install and also totem is using brasero, shouldn't rhythmbox packaging be updated accordingly? [12:34] slytherin: no, it's too late in the cycle for a such technology change [12:35] seb128: yes, sorry about that. I'm not nominating anything since you told me about [12:35] seb128: thought so. Just wanted confirmation. [12:36] seb128: Oh, and I have another specific question related to gst-plugins-base package. How do I stop from i686 getting added to arch list in debian/control file everytime I do debuild -S (lintian gives error about i686)? [12:37] slytherin: though it's easy to test and fedora is doing it already so we might want to consider it [12:37] slytherin: I don't know, I've not been looking to that, we are on sync with debian for this one, does that create any issue? [12:39] seb128: the libasound2-dev build dependency has specific architectures. the list of arch is generated by using output of some command and I always get this problem. I believe the pbuilder will also fail building the package but I didn't try it yesterday. I will try today and let you know. [12:41] slytherin: I doubt it's a stopping error [12:41] seb128: I will check again tonight. [12:42] Although why it should use any architecture list is beyond me. [12:42] it's probably because some things are not available on bsd or hurd for example [12:43] so they need to make a list not including those [12:43] asac, ok, works with dropping the patch there are additional deriver issues though [12:43] seb128: but then doing [!bsd !hurd] is easier right? [12:44] anyway, i will check if it fails to build. [12:47] slytherin: not sure why they don't exclude archs only, they use type-handling which does that listing [12:47] ogra: can you give me a syslog anyway? [12:48] will do [12:50] asac, attached [13:36] Error org.freedesktop.DBus.Error.Failed: Element not allowed inside in configuration file [13:36] ^^ do we care that the jaunty upgrade from intrepid says that during hal install? === Sikon is now known as LucidFox [13:36] I'm betting it's transient and because we're mid-upgrade [14:07] mvo: doc-base aging period waived; copied to -updates [14:07] slangasek: ^- [14:07] cjwatson: thanks! [14:27] asac, mind if i assign bug 356517 to NM and milestone it ? [14:27] Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517 [14:31] ogra: not sure if its a NM issue. [14:31] asac, its works fine if i drop your patch [14:31] that will need special casing on arm [14:31] ogra: well. upstream wouldnt work [14:31] ogra: drop the NULL patch we also have [14:32] as i said above, arm has no PCI bus [14:32] (which is actually causing the bug that makes the virtual patch fail) [14:32] you mean drop both ? [14:32] or only the NULL one ? [14:32] ogra: yes. try to drop both. if it still works that would be good to know [14:33] ok, but i urgently need to milestone it else we wont get it past release managers [14:33] ogra: from what i see now what we need is a way to differentiate between the case we fixed by the virtual device bug and the armel valid virtual ethernet === sabdfl1 is now known as sabdfl [14:34] well, you know what arch youre on [14:35] is there a nice little inotify app (or something) somewhere that will tell me who is modifying _that_ file? [14:36] because having both domain and search directives in resolv.conf offends me [14:39] mostly because it scares me to have such cluelessness displayed in such a critical file [14:41] lamont, oh, that's a clever idea: a generic inotify app to catch access to a specific file, I like that [14:42] you don't know who did it, though [14:42] ps ax in incron for /etc/resolv.conf, maybe [14:42] Mithrandir: ew [14:43] make it chattr -i resolv.conf and see who screams? [14:44] well, +i [14:44] mv: cannot move `/etc/resolv.conf.dhclient-new' to `/etc/resolv.conf': Operation not permitted [14:44] ^^WINNAR === nturner_ is now known as nturner === ubott2 is now known as ubottu [15:18] asac, without NULL i dont see eth0 in the nm-applet anymore [15:19] yeah [15:20] so not supported upstream either [15:20] well, all i can say is that it used to work until some days ago [15:20] i will talk to dan [15:20] ogra: right. because of the NULL patch which we have in ubuntu to support the broadcom thing [15:21] so mostly out of luck ;) [15:21] can i assign it to NM and milestone ? [15:21] ogra: well. given that we want to support it, please do [15:21] ok :) [15:21] ogra: please assign to me and set in progress [15:22] I am looking for some openweek volunteers: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep [15:22] holler at me if you have questions [15:23] evil Keybuk just left me with a homeless bug :P [15:23] jcastro: when is it? [15:23] seb128: the week after release [15:23] oh ok [15:24] what about getting sleep etc ... ;-) [15:24] ogra: ? [15:24] seb128: that's what the weekend is for! [15:24] Keybuk, just joking, bug 356517 [15:24] Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/356517/+text) [15:25] jcastro: DOH, I though those were to catch up on bug emails while IRC is not running ;-) [15:25] seb128: you can do that during the times when you are not doing a session, heh [15:26] heh ;-) [15:26] ogra: ah, iz HAL bug [15:26] honestly, I suspect you're not going to get a HAL fix in time for jaunty [15:26] Keybuk, hal ? [15:26] I think so, HAL tends to get grumpy about devices hanging off /computer [15:26] Keybuk, its a bunch of bugs ... one is that the driver doesnt detect plug events [15:27] ICBW though [15:27] one other is that NM ignores non PCI NICs [15:27] is NM ignoring them or is HAL? [15:27] lshal has it [15:27] and it worked until last week [15:27] ok [15:28] I'll shut up then [15:28] but indeed lshal has it under computer [15:28] sure, it's a platform device [15:28] since ARM has no publically exposed PCI bus [15:28] in general, udev has little to do with network interfaces other than renaming them [15:28] I didn't think ARM *had* a PCI bus [15:28] yeah [15:28] it does [15:28] I thought the individual bits of the board were just hardwired into certain bits [15:28] why don't they expose it then? [15:28] but its not accessible from anywhere [15:28] seems kinda silly [15:29] tedg, once told me, i didnt really understand his explanation :) [15:29] but apparently there is a PCI bus in the backend thats not exposed anywhere [15:29] so you can add the cheap PCI components but hardwire them [15:30] (he probably can elaborate on that :) ) [15:30] ogra: I was just saying that it could have an on-chip PCI bus. That's relatively common for SoCs. Not sure about those chips specifically. [15:31] right [15:31]