=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #ubuntu-devel === infinito [n=infinito@VPNPOOL03-0234.UNI-MUENSTER.DE] has joined #ubuntu-devel === dborg [n=daniel@e182058033.adsl.alicedsl.de] has joined #ubuntu-devel [12:19] doko: around? [12:20] seb128: time for a quick question? === _TomB [n=ownthebo@ACD8A0DC.ipt.aol.com] has joined #ubuntu-devel [12:20] doko: do you remember what https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/33352 was about? [12:20] Malone bug 33352 in gtk+2.0 "gtk+2.0 should Build-Depends on a newer glib" [Normal,Confirmed] [12:20] mdke: sure [12:20] seb128: trying to stay awake ... [12:21] seb128: so, System/Lock Screen locks the screen, but function/lock screen on the laptop keyboard doesn't, it just blanks. Do you know if this is a gnome-control-center bug, or gnome-screensaver? And, should I look upstream for a bug report, or in ubuntu [12:21] mdke: looks like a gnome-power-manager bug :p [12:22] seb128: apparently gnome-power-manager doesn't do that. gnome-screensaver does them both. mjg59 said he thought the bug would be in one of those two packages [12:22] seb128: don't know anymore, the build log is 5 days newer ... [12:23] than the bug report [12:23] seb128: could it be that the hotkey isn't assigned to do gnome-screensaver-command --lock, whereas the menu entry is? [12:24] mdke: does "gnome-screensaver-command --lock" work? [12:24] no [12:24] seb128: yes, it works. [12:24] did you configure your key to the keyboard shortcut dialog correctly? [12:24] seb128: it gets done automatically [12:24] are you sure? [12:24] to gnome-keybinding-properties [12:25] seb128: I haven't touched it, it all works (or worked) out of the box [12:25] I've just assigned "Lock Screen" to something it was not assigned on my box [12:25] could you look if it's assigned to something and confirm that's the key you use? [12:26] seb128: it's assigned to a key combination which is *not* the key I'm using [12:26] k, so that's the issue [12:26] specifically, ctrl + alt + | [12:26] assign it to the correct key :p [12:27] seb128: it would be wrong of me to do that. This laptop was a present, on condition that I file bugs when it doesn't work out of the box :) [12:27] sure it doesn't work out of the box, we don't assign anything to that action [12:27] mdke: :P [12:27] :) === holycow [n=a@mail.wjsgroup.com] has joined #ubuntu-devel [12:28] seb128: it worked out of the box on breezy [12:28] mjg59: any ideas? [12:28] maybe this is hotkey related? === mdke is handicapped by not knowing how the whole hotkey, gnome-keyboard-lark stuff works === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-devel [12:29] All hotkey-setup does is send KEY_COFFEE [12:30] It's up to the gnome stack to actually /do/ something with that [12:30] mdke: in fact upstream schemas has that: [12:30] /schemas/apps/gnome_settings_daemon/keybindings/screensaver [12:30] /apps/gnome_settings_daemon/keybindings/screensaver [12:30] string [12:30] <Control><Alt>l [12:30] I've no idea what catches it [12:30] so it's probably an upstream change [12:30] and should be ctrl-alt-L [12:30] seb128: so, I'll try setting it to nothing, and see if it works [12:31] not ctrl-alt-| [12:31] maybe if you set it to nothing pbuttond or something takes over [12:31] or used to [12:31] I set it to nothing, and it still just blanks rather than locks [12:31] Kamion: again, bug #40364 was fixed just by an "sudo apt-get update ; sudo apt-get install localechooser-data" - I'll boot the machine again to post on the bug the debug output without updating it. [12:31] Malone bug 40364 in ubiquity "language selection broken" [Major,Needs info] http://launchpad.net/bugs/40364 [12:31] >_< [12:31] mdke: so something out of GNOME is acting if GNOME doesn't handle it [12:32] might pbuttond? [12:32] who is likely to know about this? [12:32] mjg59 or pitti === mdke bounces the ball back to mjg59 hopefully [12:33] mdke: http://bugzilla.gnome.org/show_bug.cgi?id=171833 [12:33] Gnome bug 171833 in Keybinding "Default lock screen keyboard shortcut" [Enhancement,Resolved: fixed] === mdke shrugs hopelessly. All he knows is that it's not working. [12:35] mdke: it had no default action before so whatever does the blank screen for you know was working before [12:35] right, if I set that key action to something, it locks the screen properly [12:36] but the function key doesn't [12:36] so, looks like Gnome is working [12:36] which means that GNOME is doing is part correctly ;) [12:37] s/is part/its part [12:37] mjg59: let's do it like this. You tell me where the file the bug, based on that, and I'll do it. [12:37] s/the file/to file [12:40] note: i can't assign the function hotkey in gnome-keyboard-malarky because it blanks the screen and doesn't register in the dialogue === GmanAFK is now known as Gman [12:42] seems like whatever is running it takes over the event before GNOME [12:42] do you have pbuttond running? [12:42] not that I can see === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-devel [12:44] I've got two instances of hald-addon-keyboard and one of thinkpad-keys [12:44] maybe stop thinkpad-keys to try? [12:45] Kamion, forget what I mean about localechooser-data. The bug comes up only with 256mb of ram. With 512, it disappears. (I let it there for 15 minutes to see if languages list would appear - it didn't) - this machine has no swap partition, and needs 32megabytes to be allocated to onboard video. [12:45] s/mean/said [12:45] seb128: no change. [12:45] and if you stop gnome-screensaver? [12:45] maybe it's a gnome-screensaver feature... [12:46] seb128: no change. [12:46] grumpf [12:47] and without gnome-power-manager? [12:47] except, lock screen in the menu stops wor [12:47] gah [12:47] seb128: no change. [12:48] ignore the two lines above that [12:50] yeah, so I don't know [12:50] you must have something === Hwyvar [n=Ferdinan@cp106356-c.tilbu1.nb.home.nl] has joined #ubuntu-devel [12:50] copy a "ps aux" somewhere on pastebin.com if you want [12:50] alrighty [12:50] I might spot a processus looking like it does it :) [12:50] seb128: http://pastebin.com/697130 === Hwyvar [n=Ferdinan@cp106356-c.tilbu1.nb.home.nl] has joined #ubuntu-devel [12:54] mdke: I don't spot anything special .. maybe powernowd? [12:55] mdke: what laptop is that? [12:56] seb128: thinkpad T43-1871 [12:56] mdke: cat /etc/acpi/thinkpad-lockorbattery.sh === Arrogance [n=aks@ottawa-hs-209-217-75-110.d-ip.magma.ca] has joined #ubuntu-devel [12:56] mdke: does running /etc/acpi/screenblank.sh do that? [12:57] seb128: http://pastebin.com/697139 [12:57] mdke: looks like acpid is what you are looking for [12:57] http://pastebin.com/697141 [12:57] mdke: I bet than running /etc/acpi/thinkpad-lockorbattery.sh is what pressing the key do [12:58] mdke: sh /etc/acpi/thinkpad-lockorbattery.sh [12:58] it blanks the screen [12:58] matt@kalliope:~$ sudo sh /etc/acpi/thinkpad-lockorbattery.sh [12:58] bash: xscreensaver-command: command not found [12:58] bash: xscreensaver-command: command not found [12:58] and says that. [12:58] right [12:58] here you go [12:58] bug acpid ;) [12:58] will do, thanks. [12:59] np [12:59] I appreciate you spending so much time to help on such a small problem at this time of night [12:59] np, I'm pondering going to bed or not [12:59] we have the weekly meeting at 4am [01:00] which is not a so nice time for a meeting :p [01:01] oh, right. [01:01] ouch [01:02] mdz: MainInclusionReportWlassistant and MainInclusionReportKNetworkManager are under approved in UbuntuMainInclusionQueue, pitti approved both [01:09] Say. Where do documentation bugs get filed? [01:10] sfllaw: if on a package, on that package. if on the ubuntu specific docs, the ubuntu-docs product or package === freeflying [n=freeflyi@222.33.71.168] has joined #ubuntu-devel [01:10] sfllaw: what's the bug, out of interest? [01:11] bug 39411 [01:11] Malone bug 39411 in base-installer "386 kernel installed on 686-capable machines" [Wishlist,Confirmed] http://launchpad.net/bugs/39411 [01:12] sfllaw: interesting one. he's suggested adding it to the download page, we don't have a bug tracker for the website, but I'm inclined to think that this isn't significant enough to document on that page. It might be something for installation-guide? [01:13] Yes, I think so. [01:14] mdke: That's the package-name I needed. [01:14] cool [01:16] Riddell: they are *now* ;-) [01:17] mdz: Here's a question you can answer... [01:17] All of these "can't resume from S?" bugs. [01:17] Do they belong in acpi-support? [01:17] Or linux-source-2.6... [01:17] ? [01:17] sfllaw: to a certain extent, it depends, but most often linux-source-2.6.15 [01:18] So bug 35174 would be moved to linux-source-2.6.15? [01:18] Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from suspend to RAM" [Normal,Needs info] http://launchpad.net/bugs/35174 [01:18] sfllaw: in my experience filing them in acpi-support is always good, because the maintainer will generally be aware of what is going on with the kernel too. [01:18] sfllaw: acpi-support contains the scripts which control the suspend/resume process, so occasionally they will be acpi-support's fault, but it's rare these days === truz24 [n=truz24@12.203.70.118] has joined #ubuntu-devel [01:19] then again, "my experience" constitutes my own laptop. [01:19] sfllaw: that bug is a good example of the distinction [01:19] Also, many of these fail-to-resume bugs appear to be hardware specific. Collapsing them as duplicates is not the Right Thing, is it? [01:19] sfllaw: the trouble is that the laptop doesn't suspend properly when the USB modules are loaded [01:19] that could be worked around in acpi-support, but it's a bug in the kernel [01:20] and should be moved there [01:20] Excellent. [01:21] I like it when sanity checking says I'm right. :) [01:21] acpi-support used to unload and reload USB modules before and after suspend to work around these bugs [01:21] but nowadays it generally works right without it, and any remaining bugs in the kernel should be fixed [01:22] that one is already subscribed, but be sure to subscribe the laptop team for laptop-specific issues in the kernel [01:22] OK. I'll remember that. [01:24] the right people hear about these bugs when they're filed on acpi-support, because they're bug contacts there, but for the kernel, that obviously doesn't work so well === womble [n=mpalmer@106.135.233.220.exetel.com.au] has joined #ubuntu-devel === j_ack [n=nico@p508D902A.dip0.t-ipconnect.de] has joined #ubuntu-devel [01:30] mdz: about your answer on bug #41472, "The good news is that the string "Install" is likely to be translated for other applications already, so we should be able to get it translated quickly.", the problem is that the icon is not in rosetta. that's bug #39064 [01:30] Malone bug 41472 in ubiquity "Espresso installer logo not descriptive" [Normal,Needs info] http://launchpad.net/bugs/41472 [01:30] Malone bug 39064 in ubiquity "espresso's .desktop only in english." [Normal,Confirmed] http://launchpad.net/bugs/39064 === dborg [n=daniel@e182062075.adsl.alicedsl.de] has joined #ubuntu-devel [01:37] /join #ubuntu-meeting === didymo [n=ashley@CPE-61-9-197-223.nsw.bigpond.net.au] has joined #ubuntu-devel [01:47] night all. [02:00] fabbione, mvo: do you have the exact error from 41717? === Toadstool is now known as ToadZzZztool === stratus [n=stratus@201008164023.user.veloxzone.com.br] has joined #ubuntu-devel === ozamosi- [n=nnnozamo@h80n3c1o1049.bredband.skanova.com] has joined #ubuntu-devel === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #ubuntu-devel === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #ubuntu-devel === FunnyLookinHat [n=FunnyLoo@71.57.11.218] has joined #ubuntu-devel === bddebian [n=bdefrees@71.224.172.103] has joined #ubuntu-devel [02:47] Howdy peoples [02:48] iz tired. [02:49] Mithrandir: Then go to bed :-) [02:49] meeting in about an hour [02:49] it's the 0400 meeting. [02:50] Doh [02:51] poor Mithrandir [02:51] I'm going to miss the gym, I think. === HiddenWolf makes fresh coffee for the team [02:51] HiddenWolf: well, somebody always has the bloody middle-of-night timespot. This week, it's the europeans. [02:52] I'm up reading newspapers [02:52] :P [02:53] I'm going to make some food. [02:53] sfllaw: Great, what are we having? :-) [02:57] bddebian: Pierogies. === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel [03:02] mdz: Around? === JaneW [n=JaneW@dsl-146-141-13.telkomadsl.co.za] has joined #ubuntu-devel [03:06] sfllaw: Cool [03:06] sfllaw: Potato, cheese, what? :-) [03:07] Whatever I pull out of the freezer. === freeflying [n=freeflyi@222.33.71.168] has joined #ubuntu-devel [03:07] Sadly, I have yet to learn how to make homemade pierogies. [03:08] perogies are awesome especially with baccon [03:08] zul: They are. But don't let Eastern European grandmothers hear you say that. [03:08] hehe [03:09] heh [03:14] I had to go look perogies up in wikipedia but now I'm hungry [03:14] if any of you have nice polish grandmoths that want to come on holiday in the US for a month we have a spare bedroom! [03:15] %s/grandmoths/grandmothers/g [03:16] One of my brother-in-laws is Polish so we get Perogies every year :-) === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #ubuntu-devel === dAndy [n=dandy@131.252.208.28] has left #ubuntu-devel [] === slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-devel [03:23] Kamion, cc1: warning: command line option "-nostdinc++" is valid for C++/ObjC++ but not for C [03:24] Kamion, whats that in my CD build logs ? [03:26] ogra: it's been there forever, you can just ignore it [03:26] ok [03:26] i've never noticed it === jlj [n=agp@h460c0ed9.area2.spcsdns.net] has joined #ubuntu-devel [03:33] infinity: yes === ogra curses [03:35] mdz: Did you make a change to the varconf bug? [03:35] bddebian: I've changed a few hundred bugs this week [03:35] which bug do you mean? [03:36] mdz: See my last comment on bug #29858 ... Can you think of any clever way to NOT break old initrds, while also having our "update the initrd every time something that uses it is upgraded" magic? [03:36] Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed] http://launchpad.net/bugs/29858 [03:36] mdz: Bug #41369 No big deal, I just didn't understand what changed [03:36] Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed] http://launchpad.net/bugs/41369 [03:37] night folks [03:37] infinity: replied [03:37] Gnight zul === Kinnison goes to get something savory before the meeting [03:38] bddebian: I subscribed ubuntu-archive and cleared the assignee [03:38] mdz: LP disagrees with you. :) [03:38] bddebian: see the instructions for requesting a sync [03:38] infinity: I replied by mail [03:38] Oh. :) [03:38] mdz: I didn't assign that one. I already got chastised by Kamion for doing that early on [03:39] bddebian: you asked what I changed; that's what I changed [03:39] bddebian: https://launchpad.net/distros/ubuntu/+source/varconf/+bug/41369/+activity [03:39] Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed] [03:39] mdz: No biggie, I was just asking, sorry [03:39] grmbl, what the hell added 8Mb to my CDs [03:39] BenC: around? === dholbach [n=daniel@i577B0969.versanet.de] has joined #ubuntu-devel === Amaranth_ [n=amaranth@ubuntu/member/amaranth] has joined #ubuntu-devel === Amaranth [n=amaranth@ubuntu/member/amaranth] has joined #ubuntu-devel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-devel [03:50] infinity: what about taking the installed kernel versions, reverse-sorting them and only updating the first one [03:51] why do we have pcmcia-cs in ship ? i thought that was superseded by pcmciautils [03:52] Colin was going to own the purging of that, I guess he's not got around to it yet [03:52] it's only in ship though, not installed by default [03:52] sladen: We do only update one. That doesn't help when you call update-initramfs BEFORE the new kernel is installed. [03:52] wont save my ass anyway [03:52] it may be useful to people with older kernels, I guess [03:53] Keybuk, "only in ship" is somewhat pointless with an 8MB oversized CD [03:53] mdz: Hrm, your idea would be to only allow "update-initramfs -u" (without a -k argument) to operate on the running kernel? That's an attractive thought, but it still breaks on upgrades now if we upgrade kernel first, then udev, since udev can't get its hooks into the new kernel's initramfs. [03:53] and nothing left i could drop apart from fonts [03:53] ogra: I didn't think pcmcia-cs is 8MB [03:54] mdz: I think asking the udev hook to just bail if it discovers it's incompatible is more sane. [03:54] Keybuk, indeed not, but it adds up :) [03:54] (i cant find the reason why its suddenly oversized) [03:54] infinity: except I don't think there's a mechanism for that which won't make update-initramfs fail too [03:54] infinity: what about udev? [03:55] Keybuk: bug #29858 [03:55] Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed] http://launchpad.net/bugs/29858 [03:55] I thought the kernels that are "not compatible with udev" also happen to be those not compatible with initramfs :) [03:55] Keybuk: we need to ensure that the right version of udev ends up in initramfs [03:55] mdz: Adding a "Print an error message, do nothing, but exit 0" state to mkinitramfs is simple enough, if udev can make use of it. [03:56] Keybuk: The udev in dapper doesn't work with the kernels in breezy, afaik. At least, that seems to be the case with any number of bug reports we've seen. [03:56] right, but then the kernel gets updated anyway, so what's the problem? [03:56] Keybuk: So, if a dist-upgrade leads to "udev upgraded, then kernel upgraded", the OLD kernel will have a broken initramfs. [03:56] doesn't update-initramfs get called twice for that? [03:57] oh, I see, this is the fact update-initramfs updates them all? === Gman [n=gman@nwkea-socks-1.sun.com] has joined #ubuntu-devel [03:57] Keybuk: Which is pretty devastating if the new kernel doesn't work, or if there is no new kernel (because the user doesn't have linux-$(arch) installed to pull it in) [03:57] (I bitched a lot about this back at UBZ to jbailey :p) [03:57] Keybuk: No, update-initramfs doesn't update them all, it updates the newest. [03:57] Keybuk: Or, the "best". === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-devel [03:57] Keybuk: If udev is installed BEFORE the new kernel, the current running kernel IS the newest/best. [03:58] Keybuk: We have no way of knowing that a BETTER one will be installed 30 seconds later. [03:58] the trouble is, the "does udev work" check can only be performed on a running kernel [03:58] (it's actually "does udevplug work") [03:58] infinity: could it be handled by diverting 'update-initrd' at the start of an upgrade using dpkg-divert and then un-diverting afterwards (this is used for the fonts...) [03:58] Keybuk: Can you not just fudge it based on version numbers? [03:58] Keybuk: If we're configuring for << 2.6.15, piss off? [03:59] infinity: version number of what? [03:59] installed kernels? [03:59] sladen: All sorts of tricks like that will work fine for the upgrade tool, that doesn't fix dist-upgrade on a non-desktop machine. [03:59] infinity: effectively it turns it into a call back and would mean that it only gets run only, even if there are several updates and also only gets run on the latest kernel [03:59] you can't dpkg -l reliably within a dpkg run :) === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-devel [03:59] Keybuk: No, the version of the kernel we're currently generating an initramfs for. [04:00] we could do that -- maybe a switch to update-initramfs [04:00] ...? [04:00] update-initramfs -u -V 2.6.15 [04:00] "only update kernels newer than 2.6.15" [04:01] Oh, I see what you mean. [04:01] That's from the other end from where I was suggesting (which was just to check the version in your hook and bail), but that would work well. [04:01] And probably involves less code. [04:02] Of course, that doesn't stop the user from manually running "mkinitramfs" and breaking their initramfs, but I suppose if they do that, they can keep both pieces. === Huahua [n=hua_@221.172.49.234] has joined #ubuntu-devel [04:02] (Bailing in the hook would prevent all foot-shooting, in theory) [04:03] Oh, wait, no. Doing it as a switch to update-initramfs solves nothing. [04:03] It needs to be in the hook. [04:04] (udev installs, u-i is a no-op, then usplash installs, u-i runs and uses the wrong udev, then the new kernel installs) [04:04] doing it in the hook would fuck over existing initramfs users, no? [04:04] as mkinitramfs would be merrily generating them an initramfs anyway [04:04] it'd also result in update-initramfs failing [04:05] which would result in udev failing to configure === Mithrandir mumbles something about "let's make grub assemble the pieces and we won't have this problem" [04:05] Keybuk: Part of this discussion was that "mkinitramfs needs a 'Print an error, do nothing, and exit 0' failure state for udev to use" [04:05] That's not tough for me to hack in today. [04:06] I'm *really* against that [04:06] Not sure how it would "fuck over existing users", though. [04:06] there's no easy way to write shell in the udev hook that'll actually work reliably [04:06] and not fuck up on custom kernels, etc. which udev has to still work for [04:06] Custom kernels have versions too... [04:06] maybe feelings as well [04:07] infinity: right, but we can't predict the version string, no? [04:08] you realise they're lucky if their system boots with the breezy kernel and the new udev userspace, anyway, right? :P === Keybuk never tested that [04:08] in fact, I wouldn't be at all surprised if the combination of the breezy initramfs and the dapper udev userspace is fucked [04:08] the udev database format changed [04:08] It should boot far enough to mount root and get a new kernel installed, generally. === poningru [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #ubuntu-devel [04:09] Since all the storage and such will be loaded in the old initrd with the old udev. [04:09] why are they rebooting before installing the new kernel? [04:09] Why do hundreds of users not have the linux-image-$(arch) metapackage installed? [04:10] well, in theeeeeory the new udev init script would just unmount /dev and leave the old static dev behind [04:10] but that's never been tested with the breezy initramfs [04:10] might not work if usplash is hanging on to /dev, for example [04:11] So, you're saying you think this whole conversation is pointless because breezy kernels might not boot anyway? [04:11] (I'm pretty sure some do, FWIW) === Kyral [n=kyral@ubuntu/member/kyral] has joined #ubuntu-devel [04:11] Keybuk: Anyhow, the kernel version is in $version, exported by mkinitramfs. So you have that to test against. [04:11] they boot enough to perform system recovery [04:11] infinity: which version though? [04:12] Keybuk: I just need to provide you with the "bail and do nothing" error class. [04:12] the version of the kernel package? the upstream version of the kernel inside? the ubuntu version? what patch abi, etc.? [04:12] Keybuk: The full version as you'd see in `uname -r` or /lib/modules/$version/ [04:12] Keybuk: Simple shell to discover if that's 2.6.15ish enough for you. [04:13] it's not simple! :p === _jason [n=jasonr@dhcp0534.hrn.resnet.group.UPENN.EDU] has joined #ubuntu-devel === Keybuk would just call dpkg --compare-versions [04:13] (Yeah, that's what mkinitramfs uses too) [04:13] Why reinvent that wheel, I suppose? :) [04:14] random question [04:14] why not just change that version? :p [04:14] seeing as it'll bail badly there *anyway* [04:15] there's bound to be some idiot who tries a warty->dapper upgrade and wonders why udev, usplash, etc. fail to configure [04:15] And just claim (incorrectly) that the dapper initramfs-tools won't work with older kernels? === Amaranth [n=amaranth@ubuntu/member/amaranth] has joined #ubuntu-devel [04:16] if you wanted elegance, you could call each hook with a "minimum-version" argument and let them return one :p [04:16] That's doable. [04:16] anyway, I'm happy with whatever you decide; and I'll make whatever change you tell me to, like a good little bitch === Keybuk puts his collar on and offers you the lead === infinity tugs experimentally. [04:17] Alright, I'll hack something up today. This is "initramfs-tools bugfixing day" [04:17] Also, am I on crack, or did the meeting start 17 minutes ago without us? [04:18] I put them into different windows, so I can watch both [04:18] the meeting did start 17 minutes ago === infinity didn't get pinged. [04:18] And I completely lost track of time. [04:18] that i2o/hda bug is annoying me === theCore [n=alex@toronto-HSE-ppp4205553.sympatico.ca] has joined #ubuntu-devel === hendry [n=hendry@222.106.128.78] has joined #ubuntu-devel [04:19] did you see mdz's post on it? [04:19] which pretty much proves what Tollef said [04:19] the kernel's exposing i2o drives as /dev/sd* not /dev/i2o/hd* now [04:19] at least via one set of drivers [04:19] No, it's doing both (well, either), depending on which driver you load. [04:20] Which is crack. [04:20] But also not MY crack. [04:20] So i wash my hands of this one. [04:20] Keybuk: i2o_block exposes it as /dev/i2o/hd* as it used to. [04:20] aye, it's a "someone who understands i2o PICK ONE DRIVER" [04:20] we can blacklist the other [04:20] dpt_i2o exposes it through sd_mod. [04:20] no, we can't. [04:20] dpt_i2o sounds right to me [04:20] kill i2o_block! :p [04:21] I suspect they both work on different sets of devices, but have some overlap, or something equally irritating. [04:21] dpt_i2o only works on i386 with those controllers it claims to work with. [04:21] i2o_block will always work. [04:21] Mithrandir: so what's the fix? === nictuku [n=yves@ubuntu/member/nictuku] has joined #ubuntu-devel [04:21] if dpt_i2o will work, you want that, since it gives you more twiddly bits to twiddle. [04:22] Keybuk: can you say "load dpt_i2o, but if it fails, load i2o_block"? [04:22] Mithrandir: yes, write a kernel driver that does that [04:22] I suppose the "fix" is to make i2o_block use sd_mod too, but that's way too much effort this late. [04:22] this is the same "problem" we have with the two prism54 drivers [04:23] One station, one AP? [04:23] Keybuk: if we have to choose one, go with i2o_block [04:23] infinity: softmac vs. fullmac [04:23] Ahh. [04:23] the choice is "if this bit of code only the kernel can do fails, load this one, if it works, load that one" [04:24] so I've suggested a tiny prism54_magic driver be written that wraps whichever one of the two would actually work for that device [04:24] Keybuk: can you run modinfo dpt_i2o and dump that in a query for me? I don't have any i386 boxes handy. [04:24] modinfo: could not find module dpt_i2o [04:24] oh, heh [04:24] i386 [04:25] or somebody else with an i386 [04:25] filename: /lib/modules/2.6.15-21-686/kernel/drivers/scsi/dpt_i2o.ko [04:25] author: Deanna Bonds, with _lots_ of help from Mark Salyzyn [04:25] description: Adaptec I2O RAID Driver [04:25] license: GPL [04:25] vermagic: 2.6.15-21-686 SMP preempt 686 gcc-4.0 [04:25] depends: scsi_mod [04:25] alias: pci:v00001044d0000A501sv*sd*bc*sc*i* [04:25] alias: pci:v00001044d0000A511sv*sd*bc*sc*i* [04:25] srcversion: 813219280BD2DFF356A9C25 [04:26] the modalias pci:v00001044d0000A511sv*sd*bc*sc*i* is shared with i2o_core [04:26] indeed [04:26] so what I'd do there is take the alias away from both of them [04:26] but as you can see, i2o_core has a catch-all too. [04:27] and write an icklewickle driver that picks the right one [04:27] ie. kmod it in and force-bind it to the device that it knows will work [04:28] this is always preferable to a modprobe install hack [04:28] (the other alternative) [04:29] can you do modinfo-based blacklists? So you can say "don't load this driver for this pci id"? [04:29] because the install hack won't work for people that happen to have two i2o raid controllers, one which needs dpt_i2o and one which needs i2o_block [04:29] Mithrandir: no, modprobe doesn't know what pci id it's actually looking for, etc. [04:29] ok [04:30] you could try putting "alias pci:v00001044d0000A501sv*sd*bc*sc*i* ..." in a modprobe config file, that might override the module-supplied ones [04:30] I'm not convinced though, it may just augment them [04:30] Riddell: If/when you get a sec. You did the last upload for ekg and this doesn't seem unreasonable? Bug #38311 [04:30] Malone bug 38311 in ekg "Please build libgadu without openssl support" [Normal,Unconfirmed] http://launchpad.net/bugs/38311 [04:30] also bear in mind that this isn't doing what you think [04:31] udev DOES NOT match devices to drivers [04:31] neither does modprobe [04:31] all they're doing is loading drivers they think devices might need [04:31] the kernel matches devices to drivers [04:31] we can influence that a bit by making sure only one of the two possible drivers is loaded automatically [04:31] but that has to be across the board, ie. "NEVER LOAD THIS DRIVER" [04:32] as soon as you get "only sometimes load this driver" you'll find someone (hi, fabbione!) who always manages to build a PC that causes both to be loaded [04:32] and then you're back to the kernel picking one of the drivers [04:32] so "pick one of two drivers, where we need both" is always best solved in the kernel [04:34] bddebian: if it's really the case that the servers don't support ssl that doesn't seem like it could cause many problems [04:34] (I always pick on fabbione; after some random bug I can't remember anymore caused by him having eight different IDE controllers in the same box, or something) [04:35] Riddell: True enough. Wishlist and low priority it or reject it? [04:35] Keybuk: well, dpt_i2o is nice to have, but I think we can blacklist it if we have to. I certainly don't have time to do the tiny kernel driver you're talking about. [04:35] Mithrandir: Will i2o_core bind to and drive EVERY piece of hardware that dpt_i2o will? [04:35] what happens if you load both? [04:35] infinity: yes. [04:35] I guess one of them "wins" the device [04:36] rather than you getting the device as both /dev/sd* and /dev/i2o/hd* [04:36] Keybuk: you don't get both. [04:36] bah :p [04:36] which does the installer favour, btw? [04:36] I can't remember what happens though. It takes me a day to find out. [04:36]