[12:19] <seb128> doko: around?
[12:20] <mdke> seb128: time for a quick question?
[12:20] <seb128> doko: do you remember what https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/33352 was about?
[12:20] <Ubugtu> Malone bug 33352 in gtk+2.0 "gtk+2.0 should Build-Depends on a newer glib" [Normal,Confirmed]  
[12:20] <seb128> mdke: sure
[12:20] <doko> seb128: trying to stay awake ...
[12:21] <mdke> 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] <seb128> mdke: looks like a gnome-power-manager bug :p
[12:22] <mdke> 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] <doko> seb128: don't know anymore, the build log is 5 days newer ...
[12:23] <doko> than the bug report
[12:23] <mdke> seb128: could it be that the hotkey isn't assigned to do gnome-screensaver-command --lock, whereas the menu entry is?
[12:24] <seb128> mdke: does "gnome-screensaver-command --lock" work?
[12:24] <seb128> no
[12:24] <mdke> seb128: yes, it works.
[12:24] <seb128> did you configure your key to the keyboard shortcut dialog correctly?
[12:24] <mdke> seb128: it gets done automatically
[12:24] <seb128> are you sure?
[12:24] <seb128> to gnome-keybinding-properties
[12:25] <mdke> seb128: I haven't touched it, it all works (or worked) out of the box
[12:25] <seb128> I've just assigned "Lock Screen" to something it was not assigned on my box
[12:25] <seb128> could you look if it's assigned to something and confirm that's the key you use?
[12:26] <mdke> seb128: it's assigned to a key combination which is *not* the key I'm using
[12:26] <seb128> k, so that's the issue
[12:26] <mdke> specifically, ctrl + alt + |
[12:26] <seb128> assign it to the correct key :p
[12:27] <mdke> 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] <seb128> sure it doesn't work out of the box, we don't assign anything to that action
[12:27] <sfllaw> mdke: :P
[12:27] <seb128> :)
[12:28] <mdke> seb128: it worked out of the box on breezy
[12:28] <mdke> mjg59: any ideas?
[12:28] <mdke> maybe this is hotkey related?
[12:29] <mjg59> All hotkey-setup does is send KEY_COFFEE
[12:30] <mjg59> It's up to the gnome stack to actually /do/ something with that
[12:30] <seb128> mdke: in fact upstream schemas has that:
[12:30] <seb128>             <key>/schemas/apps/gnome_settings_daemon/keybindings/screensaver</key>
[12:30] <seb128>             <applyto>/apps/gnome_settings_daemon/keybindings/screensaver</applyto>
[12:30] <seb128>             <type>string</type>
[12:30] <seb128>             <default>&lt;Control&gt;&lt;Alt&gt;l</default>
[12:30] <mjg59> I've no idea what catches it
[12:30] <seb128> so it's probably an upstream change
[12:30] <seb128> and should be ctrl-alt-L
[12:30] <mdke> seb128: so, I'll try setting it to nothing, and see if it works
[12:31] <seb128> not ctrl-alt-|
[12:31] <seb128> maybe if you set it to nothing pbuttond or something takes over
[12:31] <seb128> or used to
[12:31] <mdke> I set it to nothing, and it still just blanks rather than locks
[12:31] <Surak> 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] <Ubugtu> Malone bug 40364 in ubiquity "language selection broken" [Major,Needs info]  http://launchpad.net/bugs/40364
[12:31] <mdke> >_<
[12:31] <seb128> mdke: so something out of GNOME is acting if GNOME doesn't handle it
[12:32] <seb128> might pbuttond?
[12:32] <mdke> who is likely to know about this?
[12:32] <seb128> mjg59 or pitti
[12:33] <seb128> mdke: http://bugzilla.gnome.org/show_bug.cgi?id=171833
[12:33] <Ubugtu> Gnome bug 171833 in Keybinding "Default lock screen keyboard shortcut" [Enhancement,Resolved: fixed]  
[12:35] <seb128> mdke: it had no default action before so whatever does the blank screen for you know was working before
[12:35] <mdke> right, if I set that key action to something, it locks the screen properly
[12:36] <mdke> but the function key doesn't
[12:36] <mdke> so, looks like Gnome is working
[12:36] <seb128> which means that GNOME is doing is part correctly ;)
[12:37] <seb128> s/is part/its part
[12:37] <mdke> 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] <mdke> s/the file/to file
[12:40] <mdke> note: i can't assign the function hotkey in gnome-keyboard-malarky because it blanks the screen and doesn't register in the dialogue
[12:42] <seb128> seems like whatever is running it takes over the event before GNOME
[12:42] <seb128> do you have pbuttond running?
[12:42] <mdke> not that I can see
[12:44] <mdke> I've got two instances of hald-addon-keyboard and one of thinkpad-keys
[12:44] <seb128> maybe stop thinkpad-keys to try?
[12:45] <Surak> 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] <Surak> s/mean/said
[12:45] <mdke> seb128: no change.
[12:45] <seb128> and if you stop gnome-screensaver?
[12:45] <seb128> maybe it's a gnome-screensaver feature...
[12:46] <mdke> seb128: no change.
[12:46] <seb128> grumpf
[12:47] <seb128> and without gnome-power-manager?
[12:47] <mdke> except, lock screen in the menu stops wor
[12:47] <mdke> gah
[12:47] <mdke> seb128: no change.
[12:48] <mdke> ignore the two lines above that
[12:50] <seb128> yeah, so I don't know
[12:50] <seb128> you must have something
[12:50] <seb128> copy a "ps aux" somewhere on pastebin.com if you want
[12:50] <mdke> alrighty
[12:50] <seb128> I might spot a processus looking like it does it :)
[12:50] <mdke> seb128: http://pastebin.com/697130
[12:54] <seb128> mdke: I don't spot anything special .. maybe powernowd?
[12:55] <seb128> mdke: what laptop is that?
[12:56] <mdke> seb128: thinkpad T43-1871
[12:56] <seb128> mdke: cat /etc/acpi/thinkpad-lockorbattery.sh
[12:56] <seb128> mdke: does running /etc/acpi/screenblank.sh do that?
[12:57] <mdke> seb128: http://pastebin.com/697139
[12:57] <seb128> mdke: looks like acpid is what you are looking for
[12:57] <mdke> http://pastebin.com/697141
[12:57] <seb128> mdke: I bet than running /etc/acpi/thinkpad-lockorbattery.sh is what pressing the key do
[12:58] <seb128> mdke: sh /etc/acpi/thinkpad-lockorbattery.sh
[12:58] <mdke> it blanks the screen
[12:58] <mdke> matt@kalliope:~$ sudo sh /etc/acpi/thinkpad-lockorbattery.sh
[12:58] <mdke> bash: xscreensaver-command: command not found
[12:58] <mdke> bash: xscreensaver-command: command not found
[12:58] <mdke> and says that.
[12:58] <seb128> right
[12:58] <seb128> here you go
[12:58] <seb128> bug acpid ;)
[12:58] <mdke> will do, thanks.
[12:59] <seb128> np
[12:59] <mdke> I appreciate you spending so much time to help on such a small problem at this time of night
[12:59] <seb128> np, I'm pondering going to bed or not
[12:59] <seb128> we have the weekly meeting at 4am
[01:00] <seb128> which is not a so nice time for a meeting :p
[01:01] <mdke> oh, right.
[01:01] <mdke> ouch
[01:02] <Riddell> mdz: MainInclusionReportWlassistant and MainInclusionReportKNetworkManager are under approved in UbuntuMainInclusionQueue, pitti approved both
[01:09] <sfllaw> Say.  Where do documentation bugs get filed?
[01:10] <mdke> sfllaw: if on a package, on that package. if on the ubuntu specific docs, the ubuntu-docs product or package
[01:10] <mdke> sfllaw: what's the bug, out of interest?
[01:11] <sfllaw> bug 39411
[01:11] <Ubugtu> Malone bug 39411 in base-installer "386 kernel installed on 686-capable machines" [Wishlist,Confirmed]  http://launchpad.net/bugs/39411
[01:12] <mdke> 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] <sfllaw> Yes, I think so.
[01:14] <sfllaw> mdke: That's the package-name I needed.
[01:14] <mdke> cool
[01:16] <mdz> Riddell: they are *now* ;-)
[01:17] <sfllaw> mdz: Here's a question you can answer...
[01:17] <sfllaw> All of these "can't resume from S?" bugs.
[01:17] <sfllaw> Do they belong in acpi-support?
[01:17] <sfllaw> Or linux-source-2.6...
[01:17] <sfllaw> ?
[01:17] <mdz> sfllaw: to a certain extent, it depends, but most often linux-source-2.6.15
[01:18] <sfllaw> So bug 35174 would be moved to linux-source-2.6.15?
[01:18] <Ubugtu> Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from suspend to RAM" [Normal,Needs info]  http://launchpad.net/bugs/35174
[01:18] <mdke> 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] <mdz> 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
[01:19] <mdke> then again, "my experience" constitutes my own laptop.
[01:19] <mdz> sfllaw: that bug is a good example of the distinction
[01:19] <sfllaw> 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] <mdz> sfllaw: the trouble is that the laptop doesn't suspend properly when the USB modules are loaded
[01:19] <mdz> that could be worked around in acpi-support, but it's a bug in the kernel
[01:20] <mdz> and should be moved there
[01:20] <sfllaw> Excellent.
[01:21] <sfllaw> I like it when sanity checking says I'm right.  :)
[01:21] <mdz> acpi-support used to unload and reload USB modules before and after suspend to work around these bugs
[01:21] <mdz> but nowadays it generally works right without it, and any remaining bugs in the kernel should be fixed
[01:22] <mdz> that one is already subscribed, but be sure to subscribe the laptop team for laptop-specific issues in the kernel
[01:22] <sfllaw> OK.  I'll remember that.
[01:24] <mdz> 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
[01:30] <Surak> 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] <Ubugtu> Malone bug 41472 in ubiquity "Espresso installer logo not descriptive" [Normal,Needs info]  http://launchpad.net/bugs/41472
[01:30] <Ubugtu> Malone bug 39064 in ubiquity "espresso's .desktop only in english." [Normal,Confirmed]  http://launchpad.net/bugs/39064
[01:37] <Surak>  /join #ubuntu-meeting
[01:47] <Surak> night all.
[02:00] <Riddell> fabbione, mvo: do you have the exact error from 41717?
[02:47] <bddebian> Howdy peoples
[02:48] <Mithrandir> iz tired.
[02:49] <bddebian> Mithrandir: Then go to bed :-)
[02:49] <Mithrandir> meeting in about an hour
[02:49] <Mithrandir> it's the 0400 meeting.
[02:50] <bddebian> Doh
[02:51] <HiddenWolf> poor Mithrandir
[02:51] <sfllaw> I'm going to miss the gym, I think.
[02:51] <Mithrandir> HiddenWolf: well, somebody always has the bloody middle-of-night timespot.  This week, it's the europeans.
[02:52] <HiddenWolf> I'm up reading newspapers
[02:52] <HiddenWolf> :P
[02:53] <sfllaw> I'm going to make some food.
[02:53] <bddebian> sfllaw: Great, what are we having? :-)
[02:57] <sfllaw> bddebian: Pierogies.
[03:02] <infinity> mdz: Around?
[03:06] <bddebian> sfllaw: Cool
[03:06] <bddebian> sfllaw: Potato, cheese, what? :-)
[03:07] <sfllaw> Whatever I pull out of the freezer.
[03:07] <sfllaw> Sadly, I have yet to learn how to make homemade pierogies.
[03:08] <zul> perogies are awesome especially with baccon
[03:08] <sfllaw> zul: They are.  But don't let Eastern European grandmothers hear you say that.
[03:08] <zul> hehe
[03:09] <bddebian> heh
[03:14] <robertj> I had to go look perogies up in wikipedia but now I'm hungry
[03:14] <robertj> 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] <robertj> %s/grandmoths/grandmothers/g
[03:16] <bddebian> One of my brother-in-laws is Polish so we get Perogies every year :-)
[03:23] <ogra> Kamion, cc1: warning: command line option "-nostdinc++" is valid for C++/ObjC++ but not for C
[03:24] <ogra> Kamion, whats that in my CD build logs ?
[03:26] <Mithrandir> ogra: it's been there forever, you can just ignore it
[03:26] <ogra> ok
[03:26] <ogra> i've never noticed it
[03:33] <mdz> infinity: yes
[03:35] <bddebian> mdz: Did you make a change to the varconf bug?
[03:35] <mdz> bddebian: I've changed a few hundred bugs this week
[03:35] <mdz> which bug do you mean?
[03:36] <infinity> 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] <Ubugtu> Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed]  http://launchpad.net/bugs/29858
[03:36] <bddebian> mdz: Bug #41369  No big deal, I just didn't understand what changed
[03:36] <Ubugtu> Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed]  http://launchpad.net/bugs/41369
[03:37] <zul> night folks
[03:37] <mdz> infinity: replied
[03:37] <bddebian> Gnight zul
[03:38] <mdz> bddebian: I subscribed ubuntu-archive and cleared the assignee
[03:38] <infinity> mdz: LP disagrees with you. :)
[03:38] <mdz> bddebian: see the instructions for requesting a sync
[03:38] <mdz> infinity: I replied by mail
[03:38] <infinity> Oh. :)
[03:38] <bddebian> mdz: I didn't assign that one.  I already got chastised by Kamion for doing that early on
[03:39] <mdz> bddebian: you asked what I changed; that's what I changed
[03:39] <mdz> bddebian: https://launchpad.net/distros/ubuntu/+source/varconf/+bug/41369/+activity
[03:39] <Ubugtu> Malone bug 41369 in varconf "UVF Exception Request: varconf" [Normal,Unconfirmed]  
[03:39] <bddebian> mdz: No biggie, I was just asking, sorry
[03:39] <ogra> grmbl, what the hell added 8Mb to my CDs
[03:39] <Mithrandir> BenC: around?
[03:50] <sladen> infinity: what about taking the installed kernel versions, reverse-sorting them and only updating the first one
[03:51] <ogra> why do we have pcmcia-cs in ship ? i thought that was superseded by pcmciautils 
[03:52] <Keybuk> Colin was going to own the purging of that, I guess he's not got around to it yet
[03:52] <Keybuk> it's only in ship though, not installed by default
[03:52] <infinity> sladen: We do only update one.  That doesn't help when you call update-initramfs BEFORE the new kernel is installed.
[03:52] <ogra> wont save my ass anyway 
[03:52] <Keybuk> it may be useful to people with older kernels, I guess
[03:53] <ogra> Keybuk, "only in ship" is somewhat pointless with an 8MB oversized CD 
[03:53] <infinity> 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] <ogra> and nothing left i could drop apart from fonts
[03:53] <Keybuk> ogra: I didn't think pcmcia-cs is 8MB
[03:54] <infinity> mdz: I think asking the udev hook to just bail if it discovers it's incompatible is more sane.
[03:54] <ogra> Keybuk, indeed not, but it adds up :)
[03:54] <ogra> (i cant find the reason why its suddenly oversized)
[03:54] <mdz> infinity: except I don't think there's a mechanism for that which won't make update-initramfs fail too
[03:54] <Keybuk> infinity: what about udev?
[03:55] <mdz> Keybuk: bug #29858
[03:55] <Ubugtu> Malone bug 29858 in initramfs-tools "root on lvm fails to boot." [Major,Confirmed]  http://launchpad.net/bugs/29858
[03:55] <Keybuk> I thought the kernels that are "not compatible with udev" also happen to be those not compatible with initramfs :)
[03:55] <mdz> Keybuk: we need to ensure that the right version of udev ends up in initramfs
[03:55] <infinity> 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] <infinity> 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] <Keybuk> right, but then the kernel gets updated anyway, so what's the problem?
[03:56] <infinity> Keybuk: So, if a dist-upgrade leads to "udev upgraded, then kernel upgraded", the OLD kernel will have a broken initramfs.
[03:56] <Keybuk> doesn't update-initramfs get called twice for that?
[03:57] <Keybuk> oh, I see, this is the fact update-initramfs updates them all?
[03:57] <infinity> 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] <Keybuk> (I bitched a lot about this back at UBZ to jbailey :p)
[03:57] <infinity> Keybuk: No, update-initramfs doesn't update them all, it updates the newest.
[03:57] <infinity> Keybuk: Or, the "best".
[03:57] <infinity> Keybuk: If udev is installed BEFORE the new kernel, the current running kernel IS the newest/best.
[03:58] <infinity> Keybuk: We have no way of knowing that a BETTER one will be installed 30 seconds later.
[03:58] <Keybuk> the trouble is, the "does udev work" check can only be performed on a running kernel
[03:58] <Keybuk> (it's actually "does udevplug work")
[03:58] <sladen> 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] <infinity> Keybuk: Can you not just fudge it based on version numbers?
[03:58] <infinity> Keybuk: If we're configuring for << 2.6.15, piss off?
[03:59] <Keybuk> infinity: version number of what?
[03:59] <Keybuk> installed kernels?
[03:59] <infinity> 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] <sladen> 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] <Keybuk> you can't dpkg -l reliably within a dpkg run :)
[03:59] <infinity> Keybuk: No, the version of the kernel we're currently generating an initramfs for.
[04:00] <Keybuk> we could do that -- maybe a switch to update-initramfs
[04:00] <infinity> ...?
[04:00] <Keybuk> update-initramfs -u -V 2.6.15
[04:00] <Keybuk> "only update kernels newer than 2.6.15"
[04:01] <infinity> Oh, I see what you mean.
[04:01] <infinity> 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] <infinity> And probably involves less code.
[04:02] <infinity> 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.
[04:02] <infinity> (Bailing in the hook would prevent all foot-shooting, in theory)
[04:03] <infinity> Oh, wait, no.  Doing it as a switch to update-initramfs solves nothing.
[04:03] <infinity> It needs to be in the hook.
[04:04] <infinity> (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] <Keybuk> doing it in the hook would fuck over existing initramfs users, no?
[04:04] <Keybuk> as mkinitramfs would be merrily generating them an initramfs anyway
[04:04] <Keybuk> it'd also result in update-initramfs failing
[04:05] <Keybuk> which would result in udev failing to configure
[04:05] <infinity> 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] <infinity> That's not tough for me to hack in today.
[04:06] <Keybuk> I'm *really* against that
[04:06] <infinity> Not sure how it would "fuck over existing users", though.
[04:06] <Keybuk> there's no easy way to write shell in the udev hook that'll actually work reliably
[04:06] <Keybuk> and not fuck up on custom kernels, etc. which udev has to still work for
[04:06] <infinity> Custom kernels have versions too...
[04:06] <Mithrandir> maybe feelings as well
[04:07] <Keybuk> infinity: right, but we can't predict the version string, no?
[04:08] <Keybuk> you realise they're lucky if their system boots with the breezy kernel and the new udev userspace, anyway, right? :P
[04:08] <Keybuk> 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] <Keybuk> the udev database format changed
[04:08] <infinity> It should boot far enough to mount root and get a new kernel installed, generally.
[04:09] <infinity> Since all the storage and such will be loaded in the old initrd with the old udev.
[04:09] <Keybuk> why are they rebooting before installing the new kernel?
[04:09] <infinity> Why do hundreds of users not have the linux-image-$(arch) metapackage installed?
[04:10] <Keybuk> well, in theeeeeory the new udev init script would just unmount /dev and leave the old static dev behind
[04:10] <Keybuk> but that's never been tested with the breezy initramfs
[04:10] <Keybuk> might not work if usplash is hanging on to /dev, for example
[04:11] <infinity> So, you're saying you think this whole conversation is pointless because breezy kernels might not boot anyway?
[04:11] <infinity> (I'm pretty sure some do, FWIW)
[04:11] <infinity> Keybuk: Anyhow, the kernel version is in $version, exported by mkinitramfs.  So you have that to test against.
[04:11] <Keybuk> they boot enough to perform system recovery
[04:11] <Keybuk> infinity: which version though?
[04:12] <infinity> Keybuk: I just need to provide you with the "bail and do nothing" error class.
[04:12] <Keybuk> the version of the kernel package?  the upstream version of the kernel inside?  the ubuntu version?  what patch abi, etc.?
[04:12] <infinity> Keybuk: The full version as you'd see in `uname -r` or /lib/modules/$version/
[04:12] <infinity> Keybuk: Simple shell to discover if that's 2.6.15ish enough for you.
[04:13] <Keybuk> it's not simple! :p
[04:13] <infinity> (Yeah, that's what mkinitramfs uses too)
[04:13] <infinity> Why reinvent that wheel, I suppose? :)
[04:14] <Keybuk> random question
[04:14] <Keybuk> why not just change that version? :p
[04:14] <Keybuk> seeing as it'll bail badly there *anyway*
[04:15] <Keybuk> there's bound to be some idiot who tries a warty->dapper upgrade and wonders why udev, usplash, etc. fail to configure
[04:15] <infinity> And just claim (incorrectly) that the dapper initramfs-tools won't work with older kernels?
[04:16] <Keybuk> if you wanted elegance, you could call each hook with a "minimum-version" argument and let them return one :p
[04:16] <infinity> That's doable.
[04:16] <Keybuk> anyway, I'm happy with whatever you decide; and I'll make whatever change you tell me to, like a good little bitch <g>
[04:17] <infinity> Alright, I'll hack something up today.  This is "initramfs-tools bugfixing day"
[04:17] <infinity> Also, am I on crack, or did the meeting start 17 minutes ago without us?
[04:18] <Keybuk> I put them into different windows, so I can watch both <g>
[04:18] <Keybuk> the meeting did start 17 minutes ago
[04:18] <infinity> And I completely lost track of time.
[04:18] <Keybuk> that i2o/hda bug is annoying me
[04:19] <Keybuk> did you see mdz's post on it?
[04:19] <Keybuk> which pretty much proves what Tollef said
[04:19] <Keybuk> the kernel's exposing i2o drives as /dev/sd* not /dev/i2o/hd* now
[04:19] <Keybuk> at least via one set of drivers
[04:19] <infinity> No, it's doing both (well, either), depending on which driver you load.
[04:20] <infinity> Which is crack.
[04:20] <infinity> But also not MY crack.
[04:20] <infinity> So i wash my hands of this one.
[04:20] <Mithrandir> Keybuk: i2o_block exposes it as /dev/i2o/hd* as it used to.
[04:20] <Keybuk> aye, it's a "someone who understands i2o PICK ONE DRIVER"
[04:20] <Keybuk> we can blacklist the other
[04:20] <Mithrandir> dpt_i2o exposes it through sd_mod.
[04:20] <Mithrandir> no, we can't.
[04:20] <Keybuk> dpt_i2o sounds right to me
[04:20] <Keybuk> kill i2o_block! :p
[04:21] <infinity> I suspect they both work on different sets of devices, but have some overlap, or something equally irritating.
[04:21] <Mithrandir> dpt_i2o only works on i386 with those controllers it claims to work with.
[04:21] <Mithrandir> i2o_block will always work.
[04:21] <Keybuk> Mithrandir: so what's the fix?
[04:21] <Mithrandir> if dpt_i2o will work, you want that, since it gives you more twiddly bits to twiddle.
[04:22] <Mithrandir> Keybuk: can you say "load dpt_i2o, but if it fails, load i2o_block"?
[04:22] <Keybuk> Mithrandir: yes, write a kernel driver that does that
[04:22] <infinity> I suppose the "fix" is to make i2o_block use sd_mod too, but that's way too much effort this late.
[04:22] <Keybuk> this is the same "problem" we have with the two prism54 drivers
[04:23] <infinity> One station, one AP?
[04:23] <Mithrandir> Keybuk: if we have to choose one, go with i2o_block
[04:23] <Keybuk> infinity: softmac vs. fullmac
[04:23] <infinity> Ahh.
[04:23] <Keybuk> 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] <Keybuk> 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] <Mithrandir> 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] <Keybuk> modinfo: could not find module dpt_i2o
[04:24] <Keybuk> oh, heh
[04:24] <Keybuk> i386
[04:25] <Mithrandir> or somebody else with an i386
[04:25] <Keybuk> filename:       /lib/modules/2.6.15-21-686/kernel/drivers/scsi/dpt_i2o.ko
[04:25] <Keybuk> author:         Deanna Bonds, with _lots_ of help from Mark Salyzyn
[04:25] <Keybuk> description:    Adaptec I2O RAID Driver
[04:25] <Keybuk> license:        GPL
[04:25] <Keybuk> vermagic:       2.6.15-21-686 SMP preempt 686 gcc-4.0
[04:25] <Keybuk> depends:        scsi_mod
[04:25] <Keybuk> alias:          pci:v00001044d0000A501sv*sd*bc*sc*i*
[04:25] <Keybuk> alias:          pci:v00001044d0000A511sv*sd*bc*sc*i*
[04:25] <Keybuk> srcversion:     813219280BD2DFF356A9C25
[04:26] <Mithrandir> the modalias pci:v00001044d0000A511sv*sd*bc*sc*i* is shared with i2o_core
[04:26] <Keybuk> indeed
[04:26] <Keybuk> so what I'd do there is take the alias away from both of them
[04:26] <Mithrandir> but as you can see, i2o_core has a catch-all too.
[04:27] <Keybuk> and write an icklewickle driver that picks the right one
[04:27] <Keybuk> ie. kmod it in and force-bind it to the device that it knows will work
[04:28] <Keybuk> this is always preferable to a modprobe install hack
[04:28] <Keybuk> (the other alternative)
[04:29] <Mithrandir> can you do modinfo-based blacklists?  So you can say "don't load this driver for this pci id"?
[04:29] <Keybuk> 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] <Keybuk> Mithrandir: no, modprobe doesn't know what pci id it's actually looking for, etc.
[04:29] <Mithrandir> ok
[04:30] <Keybuk> 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] <Keybuk> I'm not convinced though, it may just augment them
[04:30] <bddebian> Riddell: If/when you get a sec.  You did the last upload for ekg and this doesn't seem unreasonable? Bug #38311
[04:30] <Ubugtu> Malone bug 38311 in ekg "Please build libgadu without openssl support" [Normal,Unconfirmed]  http://launchpad.net/bugs/38311
[04:30] <Keybuk> also bear in mind that this isn't doing what you think
[04:31] <Keybuk> udev DOES NOT match devices to drivers
[04:31] <Keybuk> neither does modprobe
[04:31] <Keybuk> all they're doing is loading drivers they think devices might need
[04:31] <Keybuk> the kernel matches devices to drivers
[04:31] <Keybuk> we can influence that a bit by making sure only one of the two possible drivers is loaded automatically
[04:31] <Keybuk> but that has to be across the board, ie. "NEVER LOAD THIS DRIVER"
[04:32] <Keybuk> 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] <Keybuk> and then you're back to the kernel picking one of the drivers
[04:32] <Keybuk> so "pick one of two drivers, where we need both" is always best solved in the kernel
[04:34] <Riddell> 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] <Keybuk> (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] <bddebian> Riddell: True enough.  Wishlist and low priority it or reject it?
[04:35] <Mithrandir> 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] <infinity> Mithrandir: Will i2o_core bind to and drive EVERY piece of hardware that dpt_i2o will?
[04:35] <Keybuk> what happens if you load both?
[04:35] <Mithrandir> infinity: yes.
[04:35] <Keybuk> I guess one of them "wins" the device
[04:36] <Keybuk> rather than you getting the device as both /dev/sd* and /dev/i2o/hd*
[04:36] <Mithrandir> Keybuk: you don't get both.
[04:36] <Keybuk> bah :p
[04:36] <Keybuk> which does the installer favour, btw?
[04:36] <Mithrandir> I can't remember what happens though.  It takes me a day to find out.
[04:36] <Keybuk> I remember something early on where the installer always picked one over the other
[04:36] <Mithrandir> dpt_i2o on the controller I tested.
[04:36] <Keybuk> oh, I can guess what happens
[04:36] <infinity> Not sure if that's deterministic.
[04:36] <Riddell> bddebian: Wishlist, priority doesn't need to be low
[04:36] <Keybuk> whichever driver gets initialised first reserves and binds to the device
[04:36] <pitti> mvo: it's basically " grep '0 pot' http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt"
[04:37] <bddebian> Riddell: OK, thx
[04:37] <Keybuk> so randomly you get either /dev/sd* or /dev/i2o/hd*
[04:37] <infinity> Some people seem to be getting i2o_core in the installer, then dpt_i2o in initramfs (hence the "doesn't reboot after install" issues)
[04:37] <pitti> mvo: that file is updated automatically daily around noon
[04:37] <Keybuk> depending on random fluctuations in the space/time/kernel continuum
[04:38] <Keybuk> (it's actually predictable, just changeable)
[04:39] <Mithrandir> infinity: that'd be bad, agreed.  Then it'd be better to just blacklist dpt_i2o and have those who want it unblacklist it and deal.
[04:40] <infinity> Well, the blacklist file could have a comment that says "if you intend to unblacklist this module, you may want to blacklist i2o_core instead, so they don't race with each other"
[04:40] <infinity> That should cover the 10% of users who can read.  The other 90% can go jump.
[04:40] <mvo> pitti: thanks
[04:41] <Mithrandir> infinity: i2o hardware is server class gear which means you'll generally have more clued users.  I think.
[04:41] <pitti> mvo: mailed you the current list
[04:41] <infinity> Mithrandir: Fine, 30/70 instead of 10/90, then. :)
[04:41] <mvo> pitti: thanks again :)
[04:41] <Mithrandir> infinity: heh. :-)
[04:42] <pitti> mvo: let's coordinate and do the fixing in the next days (I'll do some, too), so that we can forget about this finally and get Rosetta going
[04:44] <mvo> pitti: agreed
[04:44] <Keybuk> infinity: as long as the installer obeys the same blacklist, that'd work
[04:45] <Keybuk> I still don't know where the installer gets its list-o-modules
[04:45] <Keybuk> it's not been important until now, because we've never blacklisted a storage controller -- which are the only class of driver that actually carry over to the configuration of the real install in some way
[04:47] <Keybuk> infinity: was just looking at bug 40522 given our previous conversation
[04:47] <Ubugtu> Malone bug 40522 in initramfs-tools "Check for kernels < 2.6.12 may not always do the right thing" [Normal,Needs info]  http://launchpad.net/bugs/40522
[04:49] <infinity> Keybuk: I suspect the version it's trying to run against isn't the one he thinks it is.
[04:50] <infinity> Keybuk: Also, makes a good argument for that not dying with an "exit 1", I think.
[04:50] <infinity> "WARNING: Kernel version too old, not generating initrd ; exit 0" would work just fine, I suspect.
[04:51] <Keybuk> aye
[04:52] <Mithrandir> sfllaw: is there any particular method you use for attacking the bug list or do you just start at the top of the 10k list and go through it?
[04:52] <sfllaw> Mithrandir: I look at the 10k list and see which ones look tractable.
[04:52] <Mithrandir> 10k is a scary number.
[04:52] <sfllaw> http://tinyurl.com/rc4bs
[04:53] <sfllaw> It's not so bad.
[04:53] <sfllaw> Anyway, pick a bug, any bug.
[04:53] <Keybuk> Mithrandir: I prefer to think of it as a mere 10 light bugs
[04:53] <sfllaw> Then look at its package.
[04:53] <sfllaw> And try to cross-correlate things.
[04:53] <sfllaw> After weeding out the dups, I go on to simple confirmations.
[04:53] <sfllaw> All throughout, I look for bugs that could have been reported upstream or in other distros.
[04:54] <tritium> Mithrandir: will the new kernel be 2.6.15 or .16?  I ask because of patches that would help fan control on iMac G5.
[04:54] <Mithrandir> tritium: .15
[04:54] <tritium> (in .16)
[04:54] <seb128> sfllaw: would you mark bug forwarded upstream you didn't notice on your box as confirmed?
[04:54] <pitti> mvo: wget fixed and uploaded
[04:54] <tritium> Okay, that's what I thought.  Thanks
[04:54] <Mithrandir> tritium: but BenC is pulling stuff from .16 too, so you could talk to him about it.
[04:55] <tritium> Mithrandir: thanks.  I think I'll do that.
[04:55] <sfllaw> seb128: If the bug shows up from several other people, and there's repo steps upstream, then yes.
[04:55] <bddebian> Heya tritium
[04:55] <tritium> hi there bddebian 
[04:56] <bddebian> What is RFE wrt to a bug report?
[04:56] <bddebian> Request For ???
[04:56] <pitti> bddebian: Enhancement? -> Wishlist
[04:56] <ogra> bddebian, think about all the spam you get everyday :)
[04:56] <sfllaw> seb128: Especially if there's a patch in another BTS or distro.
[04:57] <Kamion> ogra: debian-cd uses cpp to munge its package lists, and doesn't bother to suppress all the warning
[04:57] <Kamion> s
[04:57] <ogra> (enhancement ;) )
[04:57] <bddebian> ogra: hehe
[04:57] <seb128> sfllaw: right, I do that too. I was just wondering if a crasher with a debug bt reported by one people should be marked as confirmed so it's out of the way
[04:57] <ogra> Kamion, ah, right, i just never noticed it before
[04:57] <sfllaw> seb128: To me, Confirmed means, "A developer probably has enough debug information to fix the bug."
[04:58] <sfllaw> I'll keep it as Needs Info until I pull enough teeth to get to that stage.
[04:58] <seb128> sfllaw: hum, I should probably mark all the bug I forward as confirmed so ;)
[04:58] <sfllaw> :)
[04:58] <seb128> I usually forward bugs only when they are useful for upstream to do something
[04:59] <sfllaw> seb128: That's forwarding reports upstream?
[04:59] <Keybuk> I tend to use "Confirmed" as "multiple people have actually agreed the bug exists"
[04:59] <Keybuk> and "In Progress" as "developer has enough information to fix the bug"
[04:59] <sfllaw> Keybuk: Well, I'm not a developer.
[04:59] <sfllaw> And there's Needs Info.
[04:59] <sfllaw> Needs Info is the state where a bug is unreproducable.
[04:59] <Keybuk> yeah, I use Needs Info whenever I ask questions
[05:00] <sfllaw> So if there isn't enough info for a developer, why bother a developer?
[05:00] <Keybuk> if I ask a question, I set the bug to Needs Info, and then toggle back to Unconfirmed or Confirmed after
[05:00] <Keybuk> true
[05:00] <tritium> Mithrandir: do I talk to you or BenC about bug #40009 getting resolved in the next kernel?
[05:00] <Ubugtu> Malone bug 40009 in linux-source-2.6.15 "No reboot or shutdown with ipw2200 module loaded" [Normal,Unconfirmed]  http://launchpad.net/bugs/40009
[05:00] <Keybuk> as a developer, I'd love to only get Confirmed (your definition) bugs ;)
[05:00] <sfllaw> Keybuk: That's why I'm here.  :)
[05:00] <Keybuk> sfllaw: oh, while we're on the subject
[05:00] <seb128> sfllaw: I try to not forward things that will be maked as NEEDINFO by upstream directly (ie: I try not forwarding crashers before getting a debug backtrace)
[05:01] <Mithrandir> tritium: BenC.
[05:01] <Keybuk> a good Ubuntu trick for any bug involving hardware is to ask for /var/log/udev
[05:01] <sfllaw> seb128: That's my policy, yes.
[05:01] <Keybuk> almost always better than lspci output, because it actually lists every damned thing
[05:01] <sfllaw> seb128: We want to be helpful to upstream.
[05:01] <tritium> Mithrandir: okay
[05:01] <Mithrandir> tritium: I'm not a kernel hacker. :-)
[05:01] <pitti> mvo: whois fixed, too
[05:02] <tritium> Mithrandir: I'm not much of any kind of hacker ;)
[05:02] <Mithrandir> did launchpad just fall off the face of the planet?
[05:02] <Keybuk> Mithrandir: the entire data centre keeps vanishing
[05:02] <Keybuk> gets lost somewhere in Level 3 / mnet
[05:03] <sfllaw> There's an instability in the time-space continum.
[05:03] <sfllaw> Continuum?
[05:03] <sfllaw> Yes.
[05:05] <pitti> tseng: can you please fix beagle to produce a POT file?
[05:05] <Keybuk> insanity in the spice-team frenulum!
[05:06] <pitti> Riddell: can I bother you with POT file generation in kio-apt?
[05:07] <Riddell> pitti: now on my todo list for tomorrow
[05:07] <Riddell> pitti: was there something else that needed pot generation?
[05:07] <pitti> Riddell: indeed, konversation is the only other KDE package on the list
[05:08] <Riddell> will do
[05:08] <pitti> thank you
[05:08] <ogra> pitti, kino != KDE
[05:08] <Riddell> anyone assigning kino issue to me will be thrown to the dens of the gnome packagers
[05:08] <ogra> :)
[05:10] <ogra> bddebian, could you make the RFE bugs whishlist please ? 
[05:10] <bddebian> ogra: I did
[05:10] <bddebian> Well 2 of them anyway
[05:11] <Mithrandir> iwj do you want ff bugs to actually be assigned to you or will you pick them up by yourself?
[05:11] <ogra>   Priority: None => Low
[05:11] <ogra>        Status: Unconfirmed => Confirmed
[05:11] <ogra> thats not telling about whishlist
[05:11] <bddebian> ogra: It was already wishlist
[05:11] <ogra> ah
[05:11] <ogra> k
[05:11] <bddebian> :-)
[05:11] <ogra> (i didnt actually look at the bug, sorry, just saw the change)
[05:12] <bddebian> Why is there no libldap-2.2-dev package? (Debian doesn't have one either)
[05:12] <Mithrandir> because it's called libldap2-dev?
[05:12] <tritium> I don't suppose I should confirm a bug that I reported, right?
[05:13] <infinity> bddebian: Because there shouldn't be.
[05:14] <infinity> bddebian: There won't be until libldap2.2 is mangled to use gnutls.
[05:15] <infinity> (at which point, libldap2 from 2.1.x will go away)
[05:15] <Kamion> Riddell: qtparted is hanging on exit here trying to write "stdin" to stdout
[05:16] <Kamion> Riddell: shouldn't those debug messages in QP_MainWindow::slotReadStdin be going to stderr, not stdout?
[05:16] <Kamion> er cerr
[05:16] <bddebian> infinity: So should I reject a bug asking for it?
[05:16] <infinity> bddebian: Yes.
[05:17] <bddebian> Thx
[05:17] <Riddell> Kamion: I'm working on qtparted just now, that's sorted on my local machine
[05:27] <sladen> infinity: for ipw2200 led=1  where's the best place to add that (all lots of Acer's want it), or would be better just to have userspace try to flick the LED on startup (like I do for Asus)
[05:27] <Keybuk> /etc/modprobe.d/options
[05:27] <infinity> sladen: You want Keybuk for that sort of thing. :)
[05:28] <infinity> sladen: I avoid loading modules if I can.
[05:28] <Keybuk> that's our collection of module options that should really be set in the bloody driver by default, but BenC hasn't yet been persuaded to do so (or it was "hard")
[05:28] <Keybuk> generally if it's a good default, just patch the damned driver
[05:29] <Keybuk> -static int led = 0;
[05:29] <Keybuk> +static int led = 1;
[05:29] <Keybuk> easy patch, that one <g>
[05:29] <Keybuk> infinity: you don't still compile your own? *gasp*
[05:29] <infinity> Keybuk: No, I run stock kernels on my laptop, but I try to avoid caring about how module loading works. :)
[05:30] <infinity> Keybuk: I do compile my own monolithic kernels on all my server kit, though.
[05:30] <Keybuk> heh, you take the "is broken ... ask Keybuk" approach?
[05:31] <sladen> Keybuk: led=1 isn't needed for everything (and might even break some stuff ...who knows).  Your call.  modprobe.d/options, le kernel or something else?
[05:33] <infinity> Keybuk: With your munging of udev and modprobe in the last cycle, I expect you know more than you ever wanted to know about module loading.  I prefer not to duplicate knowlege, when I can be out learning other stuff. :)
[05:34] <sladen> Keybuk: regarding that thinkpad docking issue, what about having grub grab the UID of the disk *it* thinks is the master and pass that as a second option to the initramfs to try if it can't find the first root=
[05:34] <Keybuk> sladen: modprobe.d/options is applied for everything so early that if it breaks stuff, then you're fucked
[05:35] <Keybuk> so I consider adding anything to modprobe.d/options equivalent to modifying the default in the driver
[05:35] <Keybuk> given both are resolved the same way (adding a modprobe option to change the parameter)
[05:35] <Keybuk> changing the driver is more elegant, as it can't be mistakenly forgotten
[05:35] <Keybuk> sladen: if it's possible, sure
[05:35] <bddebian> Damn, I'm not even making a dent.. :'-(
[05:36] <sladen> it's not lunchtime in Hungary...
[05:36] <Keybuk> sladen: of course, if we wrote root=UUID=* for everything anyway and put UUID=* in fstab instead of /dev/*, the problem goes away too
[05:37] <sladen> Keybuk: /etc/fstab full of UIDS just becomes minging ugly for a human to look at and debug, but yes, it's a finalish solution
[05:37] <Keybuk> I think it's almost certain that we'll do that for edgy now
[05:37] <Keybuk> given we'll probably have the hda->sda switch in that cycle anyway
[05:39] <mdz> BenC: ping?
[05:41] <Kamion> I share the maintainability concern, I must say
[05:41] <Kamion> for admins
[05:42] <bddebian> Hmm, should Samba home shares be writeable by default?
[05:43] <Keybuk> Kamion: admins are free to change it back to /dev/hope-its-the-same-as-last-time
[05:43] <HrdwrBoB> they aren't
[05:43] <Keybuk> but I think writing UUIDs by default is much better
[05:43] <bddebian> HrdwrBoB: ?
[05:44] <Kamion> Riddell: it also seems to be calling slotReadStdin() when stdin is closed, rather than using the exception handler; do you also have that fixed locally?
[05:44] <Kamion> Riddell: if so, could I have your changes? I need to test stuff after that or else chances are I'm going to end up breaking the KDE frontend
[05:44] <Keybuk> (the most reliable way I can come up with to do the hda->sda migration is actually just to go down the list and grab the UUIDs, and replace them with those -- it means we don't rely on the SCSI order being the same as the IDE one)
[05:45] <HrdwrBoB> bddebian: well they are not at the moment
[05:45] <HrdwrBoB> but IMHO they should be
[05:45] <bddebian> HrdwrBoB: That's my question.  There is an LP bug requesting that :-)
[05:46] <Kamion> and I think we need this qtparted bug fixed for Flight CD 7; at the moment I don't see how to get past qtparted ...
[05:46] <HrdwrBoB> ah :)
[06:02] <Kamion> sladen: why are you assigning general live CD bugs to ubiquity?
[06:04] <sladen> Kamion: urmm.  Because it's 5am.
[06:04] <Kamion> I chucked one of them back to usplash, but maybe it's supposed to be casper
[06:05] <Kamion> I chucked the other off to casper
[06:05] <fabbione> morning
[06:05] <bddebian> Morning fabbione
[06:06] <ajmitch> hi fabbione 
[06:07] <sladen> Kamion: I'll bump the other one off to casper and let tollef have it
[06:07] <Kamion> ok
[06:18] <bddebian> Did Riddell go do bed after the meeting?
[06:19] <fabbione> Kamion,mdz: I need UVF exception for #40153
[06:19] <fabbione> otherwise our -evdev driver doesn't work at all
[06:19] <sladen> bddebian: 46 minutes 15 seconds idle on muse, very likely
[06:20] <bddebian> sladen: OK, thx
[06:39] <fabbione> mvo: ping?
[06:41] <mvo> fabbione: pong
[06:41] <fabbione> mvo: are you merging libdevmapper and lvm?
[06:42] <fabbione> be very careful when you do it.. specially the clvm bits where the delta with debian is big
[06:42] <fabbione> bug #38007 <-
[06:42] <Ubugtu> Malone bug 38007 in lvm2 "pvmove coredumps" [Major,Confirmed]  http://launchpad.net/bugs/38007
[06:44] <mvo> fabbione: it was assigned to me yesterday, I haven't looked at it yet at all
[06:44] <mvo> fabbione: could you please add whatever helps me to the bugreport? I'm not sure I will be able to deal with it before the weekend (linuxtag talk is coming as well)
[06:45] <fabbione> mvo: don't want to sound silly but i suggest to do it as soon as you can. Specially because i have a lot of machines on LVM and can test naturally without having you to spend dedicated time
[06:45] <fabbione> mvo: ok.
[06:45] <Kamion> mdz: followed up to bug 41109
[06:45] <Ubugtu> Malone bug 41109 in ubiquity "espresso hangs after setting time" [Major,Confirmed]  http://launchpad.net/bugs/41109
[06:46] <dholbach> fabbione: mvo and I are going to prepare LinuxTag and stuff today
[06:47] <dholbach> fabbione: so better not count on it
[06:47] <Kamion> mdz: I'm not sure that the EINTR bug reported in some comments on that bug is the same as the one described by the original reporter; I've followed up asking the reporter to re-test, though
[06:47] <fabbione> dholbach: whatever.. i am concerned because lvm is delicate part of server/base install.. and there are stuff relaying on it's behaviour like the installer
[06:48] <dholbach> I understand that - maybe somebody else, more familiar with the code should do it then, no?
[06:49] <bddebian> Gnight peoples
[06:49] <dholbach> night bddebian
[06:49] <fabbione> dholbach: i am trying to give mvo a few hints on what to test....
[06:50] <mdz> Kamion: if you'd rather I file it separately, I can do so
[06:50] <dholbach> I merely indicated that "as soon as you can" might take a bit and I never heard of mvo as an LVM speciaslist :)
[06:50] <mdz> Kamion: I saw there was already another bug open about a hang at that point
[06:51] <mdz> I didn't even notice that the original description didn't match the comments
[06:51] <ajmitch> hm
[06:51] <Kamion> mdz: the traceback you reported is bug 41921, and should be fixed now
[06:51] <Ubugtu> Malone bug 41921 in debconf "strange EINTR in keyboard chooser" [Major,Fix released]  http://launchpad.net/bugs/41921
[06:52] <Kamion> (check out that list of dups)
[06:53] <mdz> Kamion: is there anything newer than 20060503?
[06:53] <mdz> Ubuntu 6.06 "Dapper Drake" - Beta 2 amd64 (20060503)
[06:54] <mdz> that's what I get as daily-live/current
[06:54] <Kamion> mdz: 20060503 is current
[06:54] <Kamion> dapper-live-amd64.manifest:debconf 1.4.72ubuntu4
[06:59] <mdz> Kamion: it probably shouldn't say 'beta 2'
[07:01] <Kamion> switch it back to Alpha?
[07:01] <Kamion> which is the normal designation
[07:03] <Kamion> committing
[07:04] <fabbione> hmmm
[07:11] <pygi> mornin'
[07:12] <ajmitch> hi
[07:12] <pygi> hi ajmitch
[07:14] <jdub> is there a way to get apt-cache madison output for all packages?
[07:14] <jdub> oh, never mind
[07:14] <mdz> apt-cache madison `apt-cache pkgnames`
[07:15] <mdz> but surely you don't want that 
[07:15] <jdub> yeah, i'm on crack
[07:15] <jdub> i want to determine on a broken system which packages have been installed from dapper
[07:15] <jdub> will i have to apt-cache policy <pkg> for everything?
[07:15] <mdz> if you've run apt-get update since the last upgrade, you're fucked
[07:15] <infinity> Do an agressive pin to dapper, then see what apt-get dist-upgrade says.
[07:16] <infinity> (or an agressive pin to whatever dist you think you want)
[07:16] <jdub> was hoping to pull everything back to breezy
[07:16] <infinity> Package: *
[07:16] <infinity> Pin: release a=breezy
[07:16] <infinity> Pin-Priority: 1001
[07:17] <infinity> (In /etc/apt/preferences)
[07:17] <jdub> then an upgrade will upgrade dapper packages to breezy?
[07:17] <infinity> Then see how bad the damage is with "apt-get update && apt-get -s dist-upgrade"
[07:17] <infinity> Yeah, any pin > 1000 will force downgrades.
[07:17] <mdz> Kamion: sorry, I added my additional comments to #41109 which were meant for #41921
[07:17] <infinity> Sick, scary, wrong, don't ever do it, but for this case, it will show you what you want.
[07:17] <jdub> mmm
[07:17] <jdub> thanks
[07:18] <infinity> (I use this to sidegrade from sarge to breezy, since they're "close, but not quite identical")
[07:18] <mdz> jdub: infinity's recipe will give you "what's newer than breezy", though you asked for "what's been installed from dapper"
[07:18] <dholbach> I used it to sidegrade from pre-sarge sid to pre-warty :)
[07:19] <mdz> jdub: presumably he understood what you meant and I took you literally, but just to be sure
[07:19] <jdub> mdz: yeah :)
[07:20] <infinity> mdz: I've been here 2.5 years now, so I speak fluent Australian.
[07:21] <infinity> (My, how time flies)
[07:21] <mdz> Kamion: ok, now I've gotten ubiquity into a state where ubiquity is wait4(debconf-communicate) and debconf-communicate is blocked in read(0,...)
[07:22] <mdz> I got here by clicking "next" on the first 3 screens
[07:23] <Kamion> mdz: boggle; if you can reproduce that with UBIQUITY_DEBUG=1 set, that'd be great
[07:23] <Kamion> I've not seen that
[07:23] <mdz> Kamion: I don't run it without debug anymore
[07:23] <mdz> Kamion: log by mail or malone?
[07:23] <Kamion> mdz: malone
[07:23] <mdz> I can get you a shell on the machine where it's in this state if you like as well
[07:24] <jdub> infinity: fie. "someone wanted mysql 5, and it was in dapper, so..."
[07:24] <Kamion> hmm, yeah, I'm up for another 15 minutes or so I guess
[07:24] <infinity> jdub: Should have poked me for a backport.
[07:25] <infinity> jdub: I have one or two lying around at any given time.
[07:25] <jdub> infinity: yeah? that might be an option
[07:25] <Kamion> mdz: this is 42865?
[07:26] <infinity> jdub: If you're too far gone into dapper-land to downgrade successfully, you may as well just do a full upgrade, and I'll welcome you to the server testing team. :)
[07:26] <jdub> oh dude
[07:26] <jdub> i'm running dapper everywhere
[07:26] <jdub> i'm just saving a potential client from doom
[07:26] <infinity> Heh.
[07:26] <infinity> If current dapper has much doom left, we're going to have a pretty bumpy release.
[07:27] <infinity> I'd hope it's mostly doom-free.
[07:27] <jdub> yeah, they're figuring out whether to go back (backports might help) or start testing dapper 'for real'
[07:27] <infinity> With that, I'm going to ignore IRC for a while again and get back to my doom-removal practices.
[07:28] <jdub> 'oops' ~= 'for real'
[07:28] <jdub> infinity: got a link to backports?
[07:28] <jdub> before you fly away to mars
[07:28] <infinity> jdub: Not a current mysql5 right now, but I can do one for you.  What arch?
[07:29] <jdub> no, don't let this interrupt your attack on doom
[07:29] <infinity> I can do it later when I'm pretending to have "spare time".
[07:29] <infinity> I wasn't going to do it right now. :)
[07:30] <jdub> it'd be a waste of your time whenever you did it ;)
[07:30] <jdub> though talking benc into sucking down a new sata_promise driver would be a good use of your time
[07:31] <mdz> Kamion: I was trying to reproduce that (and failing) when this happened
[07:31] <infinity> jdub: Feel free to talk him into it.
[07:31] <infinity> :)
[07:31] <Kamion> mdz: is it with a current live CD now?
[07:32] <mdz> Kamion: 20060503
[07:32] <jdub> #40478
[07:32] <Kamion> ok
[07:32] <jdub> bug #40478
[07:32] <Ubugtu> Malone bug 40478 in linux-source-2.6.15 "Promise TX4300/4310 driver update" [Normal,Unconfirmed]  http://launchpad.net/bugs/40478
[07:32] <infinity> Phone if anyone needs me, I'm off to the land of initramfs and constant reboots.
[07:32] <mdz> Kamion: fd 0 is a pipe; I tried to match it up via /proc, but either I'm a muppet, or the other end of it is...er...esd
[07:33] <Kamion> the other end should be ubiquity; I don't see how it could end up being anything else
[07:33] <Kamion> unless the id has been reused
[07:35] <mdz> Kamion: could something have caused esd to be spawned, and inherit the fd?
[07:35] <mdz> it looks awfully like that's what happened
[07:36] <Kamion> oh, could be
[07:36] <Kamion> what spawns esd?
[07:36] <mdz> Kamion: http://librarian.launchpad.net/2461106/proc
[07:36] <mdz> Kamion: GNOMEy bits can spawn esd
[07:36] <mdz> that fd should be set close-on-exec
[07:36] <Kamion> hate esd
[07:36] <Kamion> right, yeah
[07:37] <Kamion> at least after debconf-communicate has been spawned
[07:37] <mdz> note that it's a second instance of esd running as root
[07:37] <mdz> which smells like ubiquity spawned it
[07:37] <Kamion> must have been a GNOME library
[07:38] <Kamion> sounds like we should attempt to suppress that
[07:38] <mdz> I wonder if other hangs could be explained by this
[07:38] <mdz> e.g., clicking on an inactive button triggering a sound event
[07:39] <mdz> Kamion: can I kill this instance and play with it some more, or do you thin kyou'll want to see it inaction?
[07:39] <Kamion> after dapper, I'd like to attempt to get ubiquity to run as non-root except when spawning other processes
[07:41] <Kamion> mdz: go ahead and kill it; thanks for the analysis
[07:41] <kagou> morning
[07:45] <Coyctecm> https://launchpad.net/distros/ubuntu/dapper/+bug/1
[07:45] <Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  
[07:45] <Coyctecm> :DD
[07:46] <mdz> Kamion: clicking the window close button while it's creating the filesystem closes the window but leaves everything running in the background
[07:46] <Coyctecm> horrible bug!
[07:46] <Coyctecm> ;D
[07:46] <mdz> I imagine it should ignore me instead
[07:47] <Kamion> mdz: bug 41732
[07:47] <Ubugtu> Malone bug 41732 in ubiquity "Cancelling install via X button on progress bar does not halt installation" [Normal,Confirmed]  http://launchpad.net/bugs/41732
[07:47] <mdz> thanks
[07:47] <Kamion> fairly easy to fix
[07:48] <mdz> Kamion: have you ever seen that "partition #2 of /dev/hda as" bug?
[07:48] <Kamion> mdz: yes, frequently, it's filed somewhere
[07:48] <mdz> I mentioned it in the context of one of my other bugs
[07:48] <Kamion> it's a bug in partman_commit somewhere, haven't figured out exactly what; it's on my high-priority list
[07:48] <mdz> but I'm completely unable to reproduce it anymore
[07:48] <mdz> anything I can try?
[07:48] <Kamion> rm -rf /var/lib/partman might let you reproduce it
[07:49] <Kamion> bug 40587
[07:49] <Ubugtu> Malone bug 40587 in ubiquity "file system type labels blank in summary at end" [Normal,Confirmed]  http://launchpad.net/bugs/40587
[07:49] <mdz> Kamion: do you expect it's distinct from bug 37872?
[07:49] <Ubugtu> Malone bug 37872 in ubiquity ""No root file system" error" [Normal,Confirmed]  http://launchpad.net/bugs/37872
[07:50] <Kamion> mdz: looks like the same bug, yes; I'll duplicate
[07:51] <mdz> Kamion: is the unknown/multi-line error significant?
[07:51] <Kamion> mdz: I've fixed debconf to allow using the debconf protocol properly, but not partman (mostly because I haven't added escape to cdebconf yet); however the one you point to isn't important
[07:51] <Kamion> we work around that already, albeit in a nasty untranslatable way
[07:52] <Kamion> the problem will be more of the form that we're writing slightly the wrong stuff into /var/lib/partman/devices/, I expect
[07:54] <mdz> I just got it to happen again
[07:54] <mdz> but only without debug
[07:55] <Kamion> I've got debug logs of the problem on various occasions; don't worry too much about it
[07:55] <Kamion> I'll work on it tomorrow
[07:58] <Kamion> fix for the cloexec thing in my tree, but I need to go to bed now rather than spending more time testing that, I think
[07:59] <Kamion> though it would be nice to be able to reproduce it; will have to poke about
[07:59] <fabbione> mdz, Kamion: could you please review my UVF request before you disappear? so i can take something out of my todo list? thanks
[08:00] <Kamion> Mithrandir: I think I missed the livefs builds, but once ubiquity 0.99.72 binaries are in the archive, as far as I'm concerned you can start livefs builds for flight-7
[08:01] <mdz> Kamion: good night
[08:01] <mdz> Kamion: I'll take care of fabio's request
[08:01] <Kamion> fabbione: there's little point in me trying to make judgement calls in this state; if mdz doesn't do it before then, I'll look when I get up
[08:01] <Kamion> ah, ok, thanks
[08:01] <Kamion> night
[08:01] <fabbione> Kamion: ok thanks.. good night
[08:02] <dholbach> hey janimo
[08:02] <janimo> dholbach: hey
[08:02] <janimo> are the candidate images ready?
[08:12] <Tonio_> hi everyone
[08:21] <infinity> Kamion: You didn't miss livefs builds, the cronjob is disabled anyway, since we were in Flight prep.
[08:22] <pygi> GOSUB: around?
[08:26] <janimo> infinity: there are not candidate images yet right?
[08:26] <janimo> s/not/no/
[08:31] <fabbione> dholbach: #41301 is gtk bug...
[08:31] <fabbione> dholbach: it's a problem with desktop stack going crazy.. i have seen it here too and it's definetely not X
[08:31] <fabbione> it's a focus issue
[08:31] <fabbione> and X does not handle the focus.... kthxbye
[08:33] <janimo> bug #41301
[08:33] <Ubugtu> Malone bug 41301 in xorg "Mouse clicks stop working sporadically" [Normal,Confirmed]  http://launchpad.net/bugs/41301
[09:02] <bluetoad> Hi fabbione
[09:03] <fabbione> hi bluetoad 
[09:03] <bluetoad> You went like a steam train at the bugs last night
[09:03] <fabbione> bluetoad: welcome dude :)
[09:03] <fabbione> eheh
[09:03] <fabbione> bluetoad: i plan to get down to 50 by the end of tomorrow
[09:04] <bluetoad> wow.  I'm watching a few but not much info coming from reporters
[09:05] <bluetoad> I was going to ask about those Radeon ones you fixed with sync.
[09:06] <schweeb> fabbione: is sparc CD installer working yet? or still have to tftp (sorry to bug you directly, but mail list, google, and wiki fail me here)
[09:06] <fabbione> schweeb: on what kind of hw?
[09:06] <fabbione> i am aware of a silo bug on v240
[09:06] <fabbione> otherwise it should work
[09:08] <fabbione> bluetoad: i noticed that we are facing a new kind of issue...
[09:08] <bluetoad> what's that?
[09:08] <fabbione> bluetoad: basically X has problems using Sync when monitor is on DVI
[09:09] <fabbione> the logs are tricky to read
[09:09] <fabbione> you notice that there is a ddc probe on port1 (port0 being the analog output)
[09:09] <fabbione> or also called ddc2
[09:09] <fabbione> you sometimes see that ddc2 doesn't return any value
[09:10] <fabbione> and even if they return, sometimes they are just not used or taken into account
[09:10] <fabbione> i did speak with upstream this morning and they did confirm that this is the case
[09:10] <schweeb> fabbione: blade 1500
[09:10] <fabbione> also when the monitor is CRT
[09:10] <fabbione> schweeb: should work
[09:10] <schweeb> excellent, thx
[09:11] <schweeb> the mini.iso from current/ under Dapper?
[09:11] <bluetoad> fabbione: I wondered  about crt for power pc
[09:11] <fabbione> schweeb: i didn't test that one specifically.. i used the normal -server/desktop iso, but please test it and let me know...
[09:11] <fabbione> bluetoad: you mean for when they use external monitors?
[09:12] <pitti> Hello again
[09:12] <bluetoad> fabbione: I meant lcd for power pc.
[09:13] <fabbione> bluetoad: what about them?
[09:13] <fabbione> they are usually on DVI port, but we always write sync ranges on ppc+ati unconditionally of the output port
[09:13] <fabbione> so that's covered pretty well
[09:14] <fabbione> oh btw
[09:14] <bluetoad> #29540 still has a problem on g3 notebook 
[09:14] <fabbione> guys. bluetoad is the first guy with enough balls to work on X with me...
[09:14] <bluetoad> no brains
[09:14] <fabbione> you desktop ladies :P
[09:14] <fabbione> bluetoad: they know why they are guilty :P
[09:14] <fabbione> bug #29540
[09:14] <Ubugtu> Malone bug 29540 in xorg "Fails to write out sync ranges on G3 iBook video (ati rage 128)" [Major,Fix released]  http://launchpad.net/bugs/29540
[09:14] <bluetoad> yep
[09:15] <fabbione> hmmm
[09:15] <schweeb> fabbione: hrm, no regular build for flight 6? (it's 0bytes) http://cdimage.ubuntu.com/ports/releases/6.06/flight-6/
[09:15] <fabbione> schweeb: there is beta out or daily
[09:15] <schweeb> oh, nm
[09:16] <schweeb> it's way to late for me to be trying to do any type of thinking
[09:16] <fabbione> bluetoad: I tested the daily install for 20060408 and it did not work. It still had the same
[09:16] <fabbione> bluetoad: he needs to try a more recent CD
[09:16] <schweeb> thx for the info
[09:16] <fabbione> from an upload to livecd propagation can take up to 24 hours or more
[09:17] <fabbione> bluetoad: he did expect to get the fix on the CD the exact same day.. that's just not possible
[09:17] <bluetoad> fabbione: I don't think we have logic for lcd in powerpc
[09:17] <bluetoad> That's why I'm trying to get the detailed log
[09:18] <fabbione> AHHHHH
[09:18] <fabbione> GRRR HMMM MEEHHHH
[09:18] <bluetoad> Don't even have a Device Id in the report, either.
[09:18] <fabbione> one sec..
[09:18] <fabbione> let me boot up my ppc
[09:23] <fabbione> bluetoad: ok i see the issue here..
[09:24] <fabbione> the panel on that laptop is broken and doesn't return indo
[09:24] <fabbione> info
[09:24] <fabbione> pitti: ping?
[09:25] <bluetoad> fabbione: so what do you do about that?
[09:25] <fabbione> bluetoad: thinking right now...
[09:26] <fabbione> who has an iBook G3 here?
[09:26] <fabbione> jdub: ^^???
[09:27] <fabbione> jdub: is your toilet seat the ibook g3, isn't it?
[09:27] <Kamion> schweeb: huh, wonder why that's 0 bytes
[09:27] <jdub> fabbione: yeah
[09:27] <fabbione> jdub: do you have it handy?
[09:27] <jdub> fabbione: sort of - what do you need?
[09:27] <jdub> i'd need to download dapper/ppc bits
[09:27] <jdub> which might take a while
[09:27] <Kamion> schweeb: hard to tell now, use the beta instead of flight-6
[09:27] <Kamion> I suspect that ISO is lost
[09:27] <Kamion> (if it ever existed)
[09:28] <pitti> fabbione: pong
[09:28] <fabbione> jdub: ok, i can wait for that.. i need you to do a clean dapper install on it and see if X is autoconfigured properly or you can suffer of #29540
[09:28] <fabbione> pitti: same question as jdub...
[09:28] <jdub> fabbione: with the beta live iso?
[09:29] <fabbione> jdub: whatever.. live or install are fine
[09:29] <Kamion> mm, on investigation I'm going for the "never existed" option
[09:29] <fabbione> jdub: but please if you have the issue allow me to grab some info so i can fix it
[09:29] <Kamion> use beta2 rather than beta if you're using the live CD
[09:29] <jdub> Kamion: ok
[09:30] <pitti> fabbione: I don't have a G3, my iBook is a G4
[09:30] <fabbione> pitti: ok thanks anyway
[09:32] <fabbione> bluetoad: the issue seems to be isolated to the ibook g3, so we can special case that one, once we have a unique keyword to use
[09:32] <fabbione> brb
[09:33] <jdub> fabbione: sucking an image down now
[09:33] <bluetoad> fabbione: OK
[09:35] <Kamion> mvo: libpango1.0-common fails to install, is breaking builds; e.g. http://librarian.launchpad.net/2461122/buildlog_ubuntu-dapper-i386.ubiquity_0.99.72_FAILEDTOBUILD.txt.gz
[09:36] <Kamion> seems ok on upgrade
[09:37] <Kamion> hmm, idle 2.5 hours, maybe I'll look myself
[09:37] <bluetoad> fabbione:  I need fly.  I'll have a look at some more tomorrow.  Got commitments tonight (now).
[09:37] <jdub> fabbione: 1hr to go, even from au ;)
[09:43] <fabbione> jdub: it's ok.. even with 2 hours
[09:43] <fabbione> oh he left alreayd
[09:53] <fabbione> Kamion: livecd -> casper reconfigure X with DEBUG stuff turned.. where is that log stored?
[09:54] <fabbione> never mind
[09:54] <fabbione> i am blind
[09:58] <Kamion> Mithrandir: ubiquity build blocked on libpango1.0-common installability; I'm sorting it out
[10:01] <sivang> morning all
[10:01] <pygi> mornin' sivang
[10:02] <sivang> hey pygi 
[10:11] <YokoZar> Is apt-get build-dep supposed to ignore pipes in the package build depends?  I have a package build-depend on "libicu28-dev | libicu34-dev" and apt-get complains that libicu28-dev isn't installable, but that libicu34-dev replaces it...then errors out.
[10:14] <pitti> hi janimo 
[10:14] <janimo> hi pitti
[10:14] <pitti> janimo: if Mithrandir/infinity allow uploading, can you please fix xfce4-verve-plugin to build a POT?
[10:14] <pitti> janimo: it's the only XFCE package left without one
[10:15] <janimo> pitti, ok
[10:15] <janimo> I was postponing that since there's also a bugfix update I needed to bring in but will do now instead
[10:20] <pitti> janimo: oh, some days don't matter
[10:20] <pitti> janimo: I just wanted to make sure that it's on your list
[10:20] <janimo> ah ok, I thought you needed to cross of something for flight 7 :)
[10:20] <janimo> on my list definitely
[10:21] <pitti> thanks
[10:21] <pygi> hi vuntz__
[10:21] <vuntz__> hello pygi
[10:22] <janimo> any idea why pbuilder could barf with: ln: creating symbolic link `/etc/pango/pangox.aliases' to `/var/lib/defoma/pango.d/pangox.aliases': No such file or directory
[10:23] <janimo> just saw this today, wonder if something in this area changed or the chroot is corrupted
[10:23] <Kamion> janimo: libpango1.0-common is broken for fresh installs; I'm working on it right now
[10:24] <janimo> Kamion, ah, thanks
[10:25] <pitti> mvo: please remove console-data from the 'missing POT' list. It does have a POT, but po and pot are in debian/, so my scripts ignore them
[10:25] <carlos> Riddell: hi, around?
[10:25] <pitti> hi carlos 
[10:25] <carlos> pitti: I saw that you are fixing packages that lack the .pot file (wget and whois) 
[10:25] <carlos> pitti: hi
[10:26] <pitti> carlos: yes, I hope we can finish the list RSN
[10:26] <janimo> Mithrandir: 1) upload exception for xfdesktop (bugfixes for removable media on desktop)? 2) are candidates going to build today? (I need to plan since it takes ~4 hours to DL)
[10:26] <carlos> pitti: I'm finishing now my list
[10:26] <pitti> carlos: can you confirm that you could import console-data? the layout is a bit special
[10:26] <carlos> pitti: I can import anything 
[10:26] <carlos> pitti: if it has a .pot file
[10:26] <carlos> we get the files anyway
[10:27] <carlos> and if it's not imported automatically, I approve them manually
[10:27] <pitti> carlos: yes, it has, but since my scripts ignore debian/*, they don't pick them up
[10:27] <carlos> nothing is lost like we did with hoary and breezy
[10:27] <Kamion> janimo: (note that candidate builds are blocked on libpango1.0-common too)
[10:27] <pitti> carlos: can you please check console-data? (just to make sure)
[10:27] <janimo> Mithrandir: also upload exception for xfce4-verve-plugin. Nothing critical (POT file generation)
[10:27] <carlos> pitti: https://launchpad.net/distros/ubuntu/dapper/+source/console-data/+translations
[10:28] <pitti> carlos: ah, sweet. thanks!
[10:33] <Kamion> ok, pango1.0 fix uploaded
[10:34] <pitti> Mithrandir: permission to upload gcompris? only change is building a POT, the debs don't change at all
[10:45] <Kamion> infinity: are you around, or is that an auto-rejoin?
[10:46] <Kamion> ah, /me notices the /away
[10:54] <Kamion> Mithrandir: ok, since ubiquity 0.99.72 is blocked on pango and will need a retry anyway, I'll upload 0.99.73 in the next archive cycle with a fix for a problem mdz noticed last night
[11:12] <StevenK> pitti: I suspect the reason for the empty POT file is no strings to translate.
[11:12] <pitti> StevenK: so there are no *.po files?
[11:14] <StevenK> pitti: For ldaptor-webui there are; for ldaptor (which has the empty POT file), there are none.
[11:15] <pitti> StevenK: ok, if there are no po files and no _("foo") strings (and no .desktop files either) it's safe to assume that there's nothing to be translated
[11:15] <pitti> StevenK: so removing the POT file should be fine
[11:16] <StevenK> ldaptor 0.0.42ubuntu3 is in the archive which does that.
[11:22] <Mithrandir> janimo: since those only touches your files, please do.
[11:23] <Mithrandir> pitti: preferably not.
[11:23] <pitti> Mithrandir: ok, I'll stage the uploads then
[11:23] <Mithrandir> Kamion: ok, so we should be ready to build images in roughly two hours?
[11:26] <fabbione> Mithrandir: can you give me 10 minutes to upload another xorg-7.0.0 please?
[11:27] <fabbione> Mithrandir: it would be also nice if you could give me the 2 keyboard patches i asked for :/
[11:27] <Mithrandir> fabbione: debdiff?
[11:27] <mjg59> Hm. Don't we need the new l-r-m first?
[11:27] <Mithrandir> fabbione: sorry, I won't have time to do that in the next ten minutes.  I also just saw one request?
[11:27] <fabbione> Mithrandir: one.. possibly..
[11:27] <fabbione> Mithrandir: one sec for the debdiff. the code is safe tho
[11:29] <fabbione> Mithrandir: http://people.ubuntu.com/~fabbione/debdiff
[11:30] <Kamion> Mithrandir: unless you want to wait for the new kernel
[11:30] <fabbione> Mithrandir: i remember one/two requests, but i might be wrong.. i parsed something like 120 bugs yesterday..
[11:31] <mjg59> Kamion: We don't currently seem to have an l-r-m for the current kernel ABI
[11:31] <Kamion> mjg59: the seeds still point to 2.6.15-21
[11:31] <mjg59> Kamion: Ah, ok
[11:31] <Kamion> mjg59: so as long as no ftpmaster decides to remove -21, it should work
[11:32] <mjg59> Kamion: It would be immensely helpful if we could get more -22 testing
[11:32] <Kamion> Mithrandir: your call, I guess
[11:32] <Kamion> I need to upload d-i anyway, for localechooser and kbd-chooser fixes
[11:32] <mjg59> Though if that's going to cause a significant holdup, then I wouldn't worry
[11:32] <Kamion> mjg59: well, we were expecting a fixed kernel that built on sparc yesterday ...
[11:33] <Kamion> so unless we want to attempt to make it go without sparc (which is kinda painful), we have to wait for a whole kernel build cycle
[11:34] <fabbione> Mithrandir: i am grabbing a bite.. back in 10
[11:34] <Mithrandir> Kamion: hmm, true.
[11:35] <Kamion> my inclination would be to go ahead without, I think
[11:35] <Mithrandir> Kamion: given that we were promised a new kernel more than twelve hours ago, I'm not too inclined to wait either.  So, let's go ahead once you have the bits you want in the archive.
[11:45] <zakame> hi all
[11:51] <janimo> Mithrandir, was logged out, did you approve the xfdesktop upload?
[11:51] <janimo> I guess it will take a few hours to build so if it holds back flight7 I'll just leave it to later
[11:51] <janimo> it's not critical just nice to have
[11:51] <tseng> pitti: do you have a doc on that?
[11:51] <tseng> pitti: i really know nothing about it
[11:53] <Kamion> infinity: did anything ever try to build debian-installer_20050317ubuntu20 for breezy-security, and if so could I see the build logs? It looks like it didn't build successfully anywhere
[11:54] <Kamion> Mithrandir: install CD builds should be a few minutes faster now than for the last release, BTW; although I expect all that will do is make the disparity between install CD and livefs build times even more obvious ;-)
[11:56] <tseng> janimo: ping
[11:56] <janimo> tseng: hi
[11:57] <tseng> janimo: hi, would you mind taking malone #42350 off my hands?
[11:57] <Ubugtu> Malone bug 42350 in beagle "Beagle's daemon is not autostarted in xfce/xubuntu." [Normal,Unconfirmed]  http://launchpad.net/bugs/42350
[11:57] <tseng> janimo: notourbug
[11:57] <janimo> tseng, you can just assign to xubuntu-team or myself
[11:57] <tseng> xubuntu-team, no problem
[11:57] <janimo> thans
[11:57] <janimo> k
[11:58] <carlos> pitti: Riddell: https://chinstrap.ubuntu.com/~dsilvers/paste/filejtGubv.html
[11:58] <carlos> pitti, Riddell: That's the list of translation domains that miss a .pot file
[11:58] <carlos> pitti: at the end, you have also some translation domains that should not be inside language packs
[11:58] <Mithrandir> janimo: 11:22 < Mithrandir> janimo: since those only touches your files, please do.
[11:59] <carlos> pitti: I think there are some others missing, but that's the current list I got
[11:59] <janimo> Mithrandir: ok
[11:59] <carlos> pitti: also, as I noted there, I don't know where 'childpanelextension' comes from
[11:59] <tseng> janimo: if you need action from me after you find the cause, gimme a poke
[12:00] <janimo> tseng, ok althoug hthis looks like many gnome autostart apps do not start under xfce
[12:00] <janimo> have to see why
[12:00] <tseng> yes.
[12:00] <tseng> doesnt seem that bad, if people didnt see it 'enabled' in an xfce ui
[12:01] <Mithrandir> janimo: please tell me when you have the .debs in the archive and I can build you cds.
[12:01] <janimo> tseng, as they are marked only show in gnome I am not surprised
[12:02] <janimo> tseng, so if you want beagle to run in xfce fix the .desktop file . the ball is back at you :)
[12:02] <tseng> janimo: then it should not show up in their gui
[12:02] <janimo> I think the autostart daemon is marked only show in, but the actual executable is not?
[12:03] <janimo> I think they say they run beaglke-client or whatever it;s called but no daemon is there to back it up
[12:03] <tseng> selected in the "Autostarted applications" panel
[12:03] <janimo> ok, I'll look even closer then
[12:03] <janimo> o, so an xfce4-session bug then.
[12:04] <tseng> if you ignore my .desktop, ignore it consistantly :)
[12:04] <janimo> Mithrandir the CDs you are about to build are candidates or final flights?
[12:05] <Mithrandir> janimo: they're always candidates until we have released them.
[12:05] <janimo> ok
[12:08] <pitti> carlos: ok, some of them are on my list, too
[12:08] <carlos> pitti: ok
[12:09] <pitti> carlos: however, can we walk through the list in /msg? there are some suspicious ones
[12:09] <carlos> sure
[12:50] <carlos> Riddell: ping
[12:52] <Riddell> carlos: pitti just sent me the list of kde packages from your list, I'll look into them
[12:53] <carlos> Riddell: ok, thanks
[12:53] <carlos> Riddell: those are translation domains I got from kde-i18n-* packages
[12:53] <carlos> not sure if those are not valid anymore or that we miss the .pot file, if are not valid, just tell me and I will ignore those .po files
[12:54] <carlos> like I did with kdevelop ones
[12:57] <carlos> mdke: hi, Could I close #42645?
[12:57] <pitti> carlos, Riddell, tseng, mvo, seb128, dholbach: I just created https://wiki.ubuntu.com/MissingPotFiles for coordination of POT file fixes; can you please use this as well and update it accordingly?
[12:57] <seb128> pitti: sure
[12:57] <seb128> good idea ;)
[12:57] <carlos> pitti: thanks
[12:57] <Diziet> Mithrandir: Yes, please assign firefox bugs to me, or at least make sure I'm subscribed.
[12:58] <Mithrandir> Diziet: ok
[12:58] <seb128> pitti: what are those "docs" listed?
[12:58] <seb128> pitti: why do they "must" be fixed?
[12:58] <pitti> seb128: carlos wants to import them into Rosetta
[12:58] <carlos> seb128: it's documentation using .po files to translate it
[12:59] <carlos> same thing like help/* files
[12:59] <seb128> pitti: yeah, but do you have to do to fix them?
[12:59] <seb128> like gdm uses cdbs, it should "just work" no?
[12:59] <seb128> same for gnome-*
[01:00] <carlos> pitti: btw, how is that your Wiki name is MartinPitt2 ? is there another MartinPitt that is not you?
[01:00] <pitti> seb128: hm, I fixed cdbs for help/ , but not for docs/ etc.
[01:00] <pitti> carlos: hm, no idea TBH
[01:00] <fabbione> hey
[01:00] <seb128> pitti: what do I need to run? intltool-update -p is only for po no?
[01:01] <fabbione> xorg bugs almost fit in one LP page!
[01:01] <tseng> there was a large import of debian developers into launchpad users i think
[01:01] <carlos> pitti: https://launchpad.net/people/pitti <- Fix it there ;-)
[01:01] <pitti> seb128: -p will generate a pot file
[01:01] <seb128> fabbione: nice work ;)
[01:01] <fabbione> 1   75  of 85 results
[01:01] <seb128> pitti: yeah, but it complains that help is no a po dir
[01:01] <seb128> intltool-update: Unable to proceed.
[01:01] <seb128> Make sure to run this script inside the po directory.
[01:01] <pitti> seb128: no idea TBH, I don't know how these are handled
[01:01] <seb128> hum
[01:02] <seb128> I don't agree that are a "must" fix for dapper
[01:02] <carlos> seb128: I think they are not using intltool for them
[01:02] <seb128> language packs don't ship them anyway
[01:02] <pitti> seb128: but there must be a pot somehow, how else did the translators get initial po files?
[01:02] <pitti> seb128: right
[01:02] <carlos> seb128: no it's not a must
[01:02] <pitti> seb128: we can defer the docs/ stuff until later
[01:02] <seb128> the wiki pages is "Source packages whose POT files must be fixed"
[01:02] <pitti> seb128: but it's nice to have a todo list anyway
[01:02] <seb128> pitti: right ;)
[01:03] <pitti> seb128: don't take it too seriously - read it as 'eventually', not 'RIGHT NOW!' :)
[01:03] <lucas> hi, are there some guidelines somewhere for reporting bugs like "When I log out, display hangs, Xorg takes 100% CPU, and can't be killed using kill -9" ?
[01:03] <seb128> pitti: I don't like having half of the page being GNOMEish :p
[01:03] <pitti> seb128: hm, with help/ it works with 'cd help; make pot'
[01:03] <pitti> seb128: maybe it works with docs/, too?
[01:03] <seb128> hum
[01:04] <seb128> for sound-juicer it needs to cd help/sound-juicer
[01:04] <seb128> then "make pot"
[01:04] <seb128> and that works fine
[01:04] <pitti> seb128: that merely requires a rebuild then
[01:04] <pitti> seb128: help/ is cdbs'ed
[01:04] <pitti> seb128: same for the help/ part of gnome-applets
[01:04] <seb128> I did upload those package some days ago or this week
[01:04] <seb128> that is weird
[01:04] <seb128> you cdbs change is not that new
[01:05] <seb128> right
[01:05] <seb128> cd $(DEB_BUILDDIR)/help; make pot || true;
[01:05] <seb128> it does that
[01:05] <seb128> for s-j you need to cd help/sound-juicer as said
[01:05] <seb128> running "make pot" from "help" doesn't work
[01:05] <pitti> make[1] : Entering directory `/build/buildd/sound-juicer-2.14.3/help'
[01:05] <pitti> make[1] : *** No rule to make target `pot'.  Stop.
[01:05] <pitti> ?
[01:05] <pitti> WTH?
[01:06] <seb128> $ ls help
[01:06] <seb128> Makefile  Makefile.am  Makefile.in  sound-juicer
[01:06] <seb128> $ grep pot help/Makefile
[01:06] <seb128> $
[01:06] <pitti> aah
[01:06] <seb128> $ grep pot help/sound-juicer/Makefile
[01:06] <seb128> _DOC_POT = $(if $(DOC_MODULE),$(DOC_MODULE).pot)
[01:06] <seb128> .PHONY: pot
[01:06] <seb128> pot: $(_DOC_POT)
[01:06] <seb128> 
[01:06] <seb128> if that's clear that way :p
[01:06] <pitti> seb128: ok, that needs manual fixing then
[01:06] <pitti> seb128: yes, sorry, didn't read thoroughly enough
[01:06] <seb128> will do
[01:08] <pitti> hi sabdfl, good morning
[01:09] <sabdfl> hey pitti
[01:09] <zakame> hello sabdfl 
[01:09] <sabdfl> how are we on the RaceToDapper?
[01:09] <pitti> full spead ahead :)
[01:10] <zakame> indeed
[01:13] <zakame> hi Hobbsee 
[01:13] <Hobbsee> hi zakame 
[01:18] <Tonio_> hi
[01:24] <kasina> hi Tonio_
[01:38] <infinity> Kamion: I've been in "ingore IRC mode" for ages (first work, then dinner), sorry.
[01:40] <Kamion> not a problem, superseded
[01:41] <Mithrandir> ok, building livefs-es for ubuntu and install images for ubuntu, will do the rest of the derivatives once those are done.
[01:41] <infinity> Hrm?  You uploaded another d-i to breezy-sec?
[01:42] <infinity> Oh, no you didn't.  Then no idea what you meant by "superseded".. :)
[01:45] <infinity> Kamion: Anyhow, I'll talk to you about it after your lunch/
[01:49] <Mithrandir> slomo_: please don't upload to main now, we're trying to get flight-7 out.
[01:50] <infinity> I wonder if I should take all the blame, or give half to dholbach. :)
[01:51] <infinity> slomo_: Also, can you please avoid build-depending on exact versions of debhelper required for bugfixes?
[01:51] <infinity> slomo_: Though I suppose in this case, it doesn't hurt, since anything using dh_iconcache will (well, should) have a pretty high versioned build-dep anyway.
[01:54] <infinity> slomo_: Oh, actually.. Hrm.  No.  CDBS calls dh_iconcache in a conditional, so it doesn't need an inflated build-dep, so you just made all those package unbackportable, when previously they were fine.
[01:55] <pitti> carlos: can you please take a look at bug 41130?
[01:55] <Ubugtu> Malone bug 41130 in language-pack-de " instead of a new line when running espresso and entering the wrong password" [Normal,Unconfirmed]  http://launchpad.net/bugs/41130
[01:56] <pitti> carlos: this happens a lot; can this be checked in Rosetta?
[01:56] <seb128> carlos, pitti: rosetta will import a help/sound-juicer/sound-juicer.pot correctly, right? (ie: the location is not an issue)
[01:58] <carlos> seb128: no, it will not be an issue, I approve them manually the first time I see them
[01:59] <seb128> carlos: ok, fine then ;)
[01:59] <carlos> pitti: yes, we could do something to fix those
[02:00] <pitti> carlos: (I believe the translation itself has already been fixed)
[02:00] <carlos> pitti: https://launchpad.net/products/rosetta/+bug/46
[02:00] <Ubugtu> Malone bug 46 in rosetta ""special symbols" when people copy-paste text from original to translation" [Normal,Confirmed]  
[02:00] <carlos> pitti: please, add your comments there, I'm going to change its priority
[02:04] <janimo> is there a way to auto-assign bugs on specific packages to a team besides just making it a bug contact?
[02:06] <Riddell> pitti: know anything about this cups error?  Request Entity Too Large"
[02:06] <pitti> Riddell: uh, no, sorry
[02:07] <pitti> janimo: no; but subscribing the team to the package should be good enough
[02:07] <Riddell> pitti: I can give it to you in 3 different frontends if you want :) http://kubuntu.pastebin.com/697830
[02:07] <pitti> janimo: you'll see it in +packagebugs, get mails, and so on
[02:07] <zul> heylo
[02:07] <pitti> Riddell: is that hplip?
[02:08] <Riddell> pitti: yes
[02:08] <janimo> pitti: yes, but no way I see to get all bugs on all packages of xubuntu-team
[02:08] <janimo> https://launchpad.net/people/xubuntu-team/+packagebugs
[02:08] <janimo> https://launchpad.net/people/xubuntu-team/+assignedbugs
[02:08] <janimo> a combination of these two somehow
[02:09] <pitti> Riddell: bug 42401 probably
[02:09] <Ubugtu> Malone bug 42401 in cupsys "lpadmin: Request Entity Too Large" [Normal,Unconfirmed]  http://launchpad.net/bugs/42401
[02:10] <pitti> Riddell: Can you please set LogLevel to debug2, remove error_log, restart cupsys, try to add the printer, and attach error_log to that bug?
[02:10] <pitti> Riddell: then I can toss it to upstream
[02:11] <Riddell> pitti: how do I set the LogLevel?
[02:11] <Riddell> oh, cupsd.conf
[02:11] <pitti> Riddell: yes
[02:11] <ogra> woah
[02:12] <janimo> carlos, for each xfce package I want in rosetta I need to set up a project first right?
[02:12] <ogra> apparently that thing has a mass storage device inside as well, holding the driver
[02:12] <carlos> janimo: no if it's for Ubuntu
[02:12] <ogra> i just tried it on my ibook and hal freaks out
[02:13] <ogra> pitti, ^^^
[02:13] <carlos> janimo: you don't need to do anything for Ubuntu
[02:13] <pitti> Seveas: do you still have the USN RSS feed somewhere?
[02:13] <carlos> just upload a source package that produces the .pot file
[02:13] <janimo> carlos, hmm it's all automatic? cool
[02:13] <Seveas> pitti, yes
[02:13] <pitti> ogra: oi, backtrace appreciated :)
[02:13] <janimo> yay, less boring work than I tought :)
[02:13] <Seveas> ubuntulinux.nl/files/usn.xml
[02:13] <carlos> janimo: needs something on my side, but you don't need to care, yes
[02:14] <ogra> pitti, its not even seeing the wlan device inside :)
[02:14] <janimo> carlos: thanks. So once you do whatever that is, they can be translated and end up in the language packs?
[02:14] <carlos> janimo: I did that already 
[02:14] <janimo> carlos: are subsequent upstream package uploads which change/add new translations taken into account too?
[02:15] <pitti> ogra: freak out == crash, or behave weird?
[02:15] <carlos> janimo: only if they land into Ubuntu's archive
[02:15] <pitti> ogra: in the latter case, can you generate a hal debug output (wiki.ubuntu.com/DebuggingRemovableDevices, second half of the page) and attach it to a bug?
[02:15] <pitti> Seveas: merci
[02:15] <ogra> pitti, an endless add/remove loop of the storage device
[02:16] <carlos> janimo: https://launchpad.net/distros/ubuntu/dapper/+lang/es look for xfce*
[02:16] <ogra> looks funny in the device manager 
[02:16] <janimo> carlos: ok. indeed the packages seem to be translatable. I did not even check before as I assumed it requires some work onmy part
[02:16] <ogra> pitti, i doubt its a hal thing ... seems to be rooted deeper
[02:16] <ogra> (rather kernel)
[02:16] <janimo> carlos, ok so if I add a new language to a package and translate it, I can just export the .po file and sent it upstream too?
[02:19] <ogra> pitti, its not urgent, i dont need it running here, i just thought i'd test it before installing it on the win2000 pc
[02:19] <infinity> Seveas: Have you talked with anyone about getting those RSS feeds into the DC, by any chance?  I've been using them for ages now, and I'd love it if they lives on ubuntu.com somewhere, just so they'd be a bit easier to advertise.
[02:19] <Riddell> pitti: added
[02:19] <carlos> janimo: yes, but if it would have some Ubuntu specific strings (depending if you changed the source code like we did with GNOME and KDE to include some specific changes)
[02:19] <Seveas> infinity, I've proposed it several times and people tend to like it. No one takes action though
[02:19] <janimo> carlos, only a few packages have minimal changes. looks good thanks
[02:19] <mdke> carlos: sure, no problem about closing it: I only filed it in case you wanted to figure out what happened. For me, the problem is fixed so I don't mind.
[02:19] <infinity> Seveas: Ahh.
[02:19] <carlos> mdke: I'm not able to reproduce it, if you see it again I tell me it and I will try to be faster to debug it...
[02:20] <pitti> Riddell: thanks
[02:21] <carlos> pitti: btw, the language snapshot for today failed, the mirror is still running so I will need that you run your script by hand later...
[02:21] <pitti> carlos: no problem, if it succeeds tomorrow I don't need to do anything
[02:22] <carlos> well I would need an updated report today... so if you could run it today, that would be good (I will ping you when my tarballs are ready)
[02:25] <Mithrandir> Riddell: kubuntu install images up, please test.
[02:25] <Mithrandir> pitti: any chance for you to test the install images for ppc?
[02:26] <Riddell> Mithrandir: thanks
[02:27] <pitti> Mithrandir: of course, I'm just waiting for the 'new images up' anouncement
[02:27] <Mithrandir> pitti: install images are up now.
[02:32] <janimo> Mithrandir: can spin xubuntu as well, the debs are in. thanks
[02:34] <Mithrandir> janimo: will do once edubuntu has built.
[02:34] <ogra> Mithrandir, there is no point in building edubuntu
[02:34] <ogra> its still 3 Meg to big
[02:34] <pitti> Mithrandir: live images will follow?
[02:34] <ogra> err 8
[02:34] <Mithrandir> ogra: ok.
[02:34] <Mithrandir> ogra: does that mean you won't release a flight 7?
[02:34] <mdke> carlos: sure thing.
[02:34] <ogra> yep
[02:35] <Mithrandir> pitti: yes, once the live fs-es are built, I'll do that.
[02:35] <pitti> 'k
[02:35] <ogra> Mithrandir, i have too much on my plate currently, live should be fine though 
[02:35] <Mithrandir> ogra: "yes, you will release flight-7" or "yes, you won't release flight-7"?
[02:35] <ogra> yes i wont
[02:35] <Mithrandir> ok
[02:35] <infinity> Mithrandir: Oh, I suspect we'll want to skip ports-live this time around (though it's too late for me to stop you from kicking off those livefs builds now, sorry)
[02:36] <infinity> Mithrandir: I still have some ports-live bugs to fix, so there's not much point in holding up the other arches based on 3 CD images almost no one will test.
[02:36] <infinity> Mithrandir: I'll make sure they start getting fixed dailies on the weekend or something.
[02:36] <Mithrandir> infinity: ok.  I'm just waiting for weddell to finish now.
[02:37] <infinity> Mithrandir: Which qualifies as "ports" too. :)
[02:37] <infinity> Mithrandir: So you may as well just sping the live ISOs right now. :)
[02:37] <infinity> s/sping/spin/
[02:43] <janimo> Mithrandir:  the image will go to http://cdimage.ubuntu.com/xubuntu/daily/20060504/ right?
[02:43] <janimo> I am writing a call for testing in advance
[02:45] <Mithrandir> janimo: yes.
[02:57] <Mithrandir> seb128: bug 39640; should this be rejected?  We don't have gaim 2 in the repositories?
[02:57] <Ubugtu> Malone bug 39640 in gaim "[2.0beta3]  gaim: status pulldown menu is half empty (drawn offscreen)" [Normal,Unconfirmed]  http://launchpad.net/bugs/39640
[02:57] <seb128> Mithrandir: not really, upstream are nice enough and some of them are subscribed to the package
[02:58] <seb128> Mithrandir: the package comes from my people.ubuntu.com page too and I've asked to send feeback on launchpad making clear from the title they are using 2.0beta3
[02:58] <Mithrandir> seb128: oh, ok.
[02:58] <seb128> Mithrandir: we can ignore them for now so, upstream reply and it'll be useful when we upload gaim2.0
[03:00] <Mithrandir> seb128: ok, I'm just going through unconfirmed and confirming bugs.
[03:00] <Mithrandir> janimo: xubuntu install images up
[03:00] <janimo> Mithrandir: thanks
[03:01] <janimo> Mithrandir: I assume they are uploading now as it's only a 400Mb sparc one
[03:01] <janimo> from apr 19th
[03:02] <Mithrandir> janimo: they're still syncing it seems, yes, but http://cdimage.ubuntu.com/xubuntu/daily/20060504/ already has amd64 images.
[03:02] <janimo> yup, I see they're showing up one by one
[03:05] <janimo> http://cdimage.ubuntu.com/xubuntu/daily/20060504/report.html
[03:05] <janimo> what does uninstallable  mean here?
[03:06] <janimo> not made it to the CD? As xubuntu has OOo in ship but does not install it
[03:06] <Mithrandir> that they can't be installed.  You can ignore those, ooo2 has been renamed to ooo.
[03:09] <pitti> Riddell: if you do 'lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd', do you get this error, too?
[03:11] <pitti> Riddell: ooh, wait: what is 'ls -l /var/cache/cups/ppds.dat' for you?
[03:11] <pitti> Riddell: your error_log has just one error: 'Unable to write "/var/cache/cups/ppds.dat" - Permission denied'
[03:12] <Riddell> ls: /var/cache/cups/ppds.dat: No such file or directory
[03:12] <pitti> $ ls -ld /var/cache/cups/
[03:12] <pitti> drwxrwxr-x 3 cupsys lp 4096 2006-05-02 20:06 /var/cache/cups/
[03:12] <pitti> ^ for me, that's how it should be like
[03:12] <Riddell>  /var/cache/cups/ ls drwxr-xr-x 4 root root 0 2006-04-26 02:59 ppd
[03:13] <Riddell> ls -l /var/cache/cups/
[03:13] <Riddell> total 0
[03:13] <Riddell> drwxr-xr-x 4 root root 0 2006-04-26 02:59 ppd
[03:13] <pitti> Riddell: ls -ld /var/cache/cups?
[03:13] <Riddell> ls -ld /var/cache/cups
[03:13] <Riddell> drwxrwxr-x 4 cupsys lp 40 2006-05-03 03:50 /var/cache/cups
[03:13] <pitti> hm, that looks fine
[03:14] <Riddell> lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd
[03:14] <Riddell> lpadmin: Request Entity Too Large
[03:14] <pitti> Riddell: and lpstat -p doesn't show the printer?
[03:14] <Riddell> lpstat -p
[03:14] <Riddell> printer LaserJet disabled since Thu 04 May 2006 01:13:22 PM UTC -
[03:14] <Riddell>         reason unknown
[03:15] <Riddell> which is strange, I don't have a laserjet
[03:16] <pitti> Riddell: you just added it with that lpadmin command :)
[03:16] <Riddell> ah, right :)
[03:17] <pitti> hm, I can't reproduce it here
[03:17] <bddebian> Morning folks
[03:17] <bddebian> Riddell: Mind if I ask you a dumb question?
[03:17] <Riddell> bddebian: please do
[03:17] <pitti> Riddell: if you purge cupsys, rm -rf /etc/cups and /var/{cache,run}/cups and reinstall, do you still get it?
[03:18] <bddebian> Riddell: There are several bugs about icons not showing in Gnome for KDE apps.  KDE uses .menu files while Gnome uses .desktop correct?  Or am I wrong?
[03:18] <Riddell> bddebian: both gnome and kde use the freedesktop xdg menu spec
[03:18] <Riddell> bddebian: got an example?
[03:18] <bddebian> Ohh, hmm
[03:19] <bddebian> Riddell: I'll find one, I just got on.. :-)
[03:20] <Mithrandir> Riddell: https://launchpad.net/distros/ubuntu/+source/keep/+bug/39380 for instance
[03:20] <Riddell> bddebian: ah, adept will be so because it's run as "kdesu adept"
[03:20] <Ubugtu> Malone bug 39380 in keep "No menu icon in GNOME" [Normal,Confirmed]  
[03:20] <Riddell> do it's probably looking for the kdesu icon not the adept icon
[03:21] <bddebian> Riddell: Ah, hmm
[03:21] <bddebian> Heya dholbach
[03:22] <Riddell> dholbach: any idea how for gksudo apps gnome doesn't look for the gksudo icon?  we're wondering how to get it to do the same for kdesu apps
[03:22] <Riddell> Mithrandir: that's a mystery, the keep icon is in /usr/share/icons/hicolor/*/apps/keep.png
[03:23] <Riddell> hmm, adept has Icon=adept so that should be ok too
[03:26] <dholbach> Riddell: maybe you ping mvo later about it
[03:28] <Riddell> lpadmin -p LaserJet -v usb://HP/LaserJet%201022 -P /usr/share/ppd/hpijs/HP/HP-LaserJet_1022-hpijs.ppd
[03:28] <Riddell> lpadmin: Request Entity Too Large
[03:28] <Riddell> pitti: ^^ after stopping, purging, removing directories, reinstalling and starting again
[03:30] <bddebian> Rat bastards closing my bugs
[03:30] <bddebian> Riddell: .desktop files should get icon from /usr/share/pixmaps/foo.xxx
[03:31] <bddebian> It should'nt grab gksudo/etc icon
[03:32] <Riddell> it should get it from the standard icon locations
[03:32] <bddebian> Damn bug stealers
[03:32] <bddebian> Riddell: Isn't that /usr/share/pixmaps?
[03:32] <Riddell> seems like a gnome bug to me
[03:32] <bddebian> That's where I usually have been installing them when adding .desktop files and they seem to work
[03:32] <Riddell> no, /usr/share/pixmaps is a last resort, it should be /usr/share/icons/theme/size/apps/
[03:33] <Riddell> and for .desktop files theme should be hicolour since that's the fallback theme for everything
[03:33] <bddebian> Hmm
[03:35] <Riddell> and speain of icons, cdimages.ubuntu.com really needs a crystal theme :)
[03:35] <Riddell> speaking
[03:35] <bddebian> Damn, now you have thrown me all off for my bug hunting today.. :-)
[03:36] <seb128> bddebian: what is your issue?
[03:36] <seb128> bddebian: you might be interested by http://live.gnome.org/GnomeGoals/AppIcon
[03:36] <bddebian> seb128: Same as always.  Figuring out what to look at today :-)
[03:37] <pitti> Riddell: alright, thank you
[03:37] <bddebian> I was going to try to hit some kubuntu bugs today I guess
[03:38] <Riddell> bddebian: yes please :)
[03:38] <bddebian> Riddell: You say that now, util I start inundating you with questions ;-P
[03:38] <seb128> bddebian: heh you are not done with GNOME bugs, there is still some not triaged, don't run away like that :p
[03:39] <bddebian> seb128: I move around.  I hit Unmet Deps one day, Unconfirmed the next, MOTUScience bugs, etc, etc
[03:39] <seb128> ah, k ;)
[03:39] <seb128> you like change :)
[03:39] <bddebian> Not that I can actually do anything substantial mind you :'-(
[03:39] <bddebian> Hello Kyral
[03:40] <Kyral> hey
[03:41] <bddebian> seb128: I'd actually like to help main a lot more but most times I think I just get in the way
[03:41] <tritium> bddebian: you can look at the bugs I've reported or subscribed to :)
[03:42] <seb128> bddebian: I'm sure there is things you can do easily, confirming bug, closing duplicates, etc. And asking questions is not "get in the way", you learn and become better at doing what you do by yourself then ;)
[03:46] <bddebian> seb128: Well I seem to annoy the hell out of certain people :-)
[03:46] <bddebian> tritium: You have assigned bugs? :-)
[03:49] <tritium> bddebian: motu-science, but I've also reported a few and subscribed to a few
[03:50] <Mithrandir> mgalvin: around, by any chance?
[03:50] <mgalvin> Mithrandir: yup, hi
[03:50] <bddebian> tritium: I think I've fixed all the MOTUScience ones that I can vix
[03:51] <bddebian> Err fix even
[03:51] <Mithrandir> mgalvin: sorry for the late notice, and I'm not sure if it's needed, but we're going to release flight 7 today or tomorrow.  Any chance you could whip up a nice-looking "what's changed since beta" page for me?
[03:51] <tritium> bddebian: yeah, you've been filling my inbox!  Nice work :)
[03:51] <bddebian> tritium: Bah, thx
[03:51] <jjesse> mgalvin and i talked about this and are there a lot of changes that would neccesistate a flight7 wiki page?
[03:51] <Kamion> infinity: oh, d-i/breezy-security; I thought you were talking about the *other* thing I was trying to get hold of you about :-) (ubiquity rebuild, no longer necessary)
[03:51] <jjesse> as i was going to do a KubuntuFlight7 page
[03:52] <Mithrandir> jjesse: given that we're in deep freeze, no, I hope there aren't too many changes, but I'l been stuck in my little hole for the last few days, so I'm not sure.
[03:53] <mgalvin> Mithrandir: as jjesse was saying, it seems all the changes are mostly bug fixes so i was thinking of just linking to the announcement
[03:54] <Mithrandir> mgalvin: ok, I guess that works.
[03:55] <Riddell> jjesse: knetworkmanager is in ship (on cd but not installed by default) and wlassistant is in desktop
[03:55] <mgalvin> as was done for flight 1 and beta 2... although... i will spend some time looking at everything... if there is enough to cover i will create a page for it
[03:55] <pitti> Mithrandir: ppc/install went fine
[03:55] <Riddell> jjesse: kubuntu espresso is now ready for some serious testing
[03:55] <jjesse> Riddell: would that be a change for releasenotes?
[03:55] <mgalvin> Mithrandir: i will let you know for certain either way if i get a page ready in time
[03:56] <Riddell> jjesse: yeah, I guess so
[03:56] <infinity> Kamion: Ahh, I suspect the ubiquity ping had no payload, so I assumed both prods were for the same thing.
[03:56] <Kamion> infinity: yeah, I'm still interested in whether debian-installer_20050317ubuntu20 built anywhere
[03:56] <Kamion> infinity: yeah, my bad
[03:56] <infinity> Kamion: It didn't build anywhere due to the "jackss doesn't host a d-i component in breezy-security" thing, or whatever it was, but I can certainly work around that.
[03:57] <Kamion> btw, for the install CDs, it's worth checking for breakage in kbd-chooser choices; I didn't, er, actually test that change
[03:57] <Kamion> infinity: where else would the packages come from? I don't think they've been ambered
[03:58] <infinity> Kamion: Oh, if they've not been ambered, then they can't come from anywhere yet.  We don't build-from-accepted.
[03:58] <Kamion> hmm, actually, we might be ok
[03:58] <Kamion>   cdebconf | 0.84ubuntu12 | breezy-security | source
[03:58] <Kamion>   cdebconf | 0.84ubuntu12 | breezy-security/universe | amd64, hppa, i386, ia64, powerpc, sparc
[03:59] <infinity> Yeah, we fail here:
[03:59] <infinity> Get:5 http://jackass.ubuntu.com breezy/main/debian-installer Packages [21.0kB] 
[03:59] <infinity> Failed to fetch http://jackass.ubuntu.com/dists/breezy-security/Release  Unable to find expected entry  main/debian-installer/binary-sparc/Packages in Meta-index file (malformed Release file?)
[03:59] <Kamion> yeah, building from drescher's breezy-security should work fine then
[03:59] <infinity> Fetched 71.9kB in 0s (74.2kB/s)
[03:59] <infinity> And I can obviously work around that.
[03:59] <Kamion> yep, changing the buildds' /etc/apt/sources.lists should be sufficient
[04:01] <infinity> I can do that right nowish, then.
[04:01] <infinity> (Last time I suggested doing that, you said you wanted to fix jackass instead or some such.. I guess you're over that?)
[04:07] <ogra> Kamion, can you (or another CC member) please make the people of the EC administrators of edubuntu-members ? (no hurry though)
[04:07] <ogra> Kamion, http://www.edubuntu.org/news/3 has the list
[04:09] <Kamion> ogra: I don't think the CC has any special privileges with respect to that team; we're just indirect members. you're marked as the administrator, AIUI you should be able to do it yourself
[04:09] <Kamion> infinity: I think we might as well JFDI
[04:09] <ogra> Kamion, nope, CC is the owner
[04:09] <ogra> only the owner can make new admins apparently
[04:09] <Kamion> oh yes, so it is
[04:10] <ogra> as i said, no hurry
[04:10] <ogra> if it happens during the next days/weeks thats fine 
[04:10] <ogra> (we wont have an EC meeting before june)
[04:10] <Mithrandir> Riddell: kubuntu live images up too
[04:11] <Riddell> Mithrandir: tnks
[04:11] <Riddell> thanks
[04:12] <Kamion> ogra: done
[04:13] <ogra> meh, i just wanted to move it from my todo to yours, didnt want to cause work now :)
[04:13] <ogra> thanks :)
[04:13] <Kamion> was easy enough while I was there
[04:13] <ogra> ok :)
[04:17] <bddebian> Wow, KDevelop is kinda cool
[04:21] <Riddell> :)
[04:35] <bddebian> Riddell: Is this correct or should this be filed under konqeror package?  Bug #42485
[04:35] <Ubugtu> Malone bug 42485 in kdebase "Improve Konqueror defaults for Dapper" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/42485
[04:36] <Riddell> bddebian: it should be kubuntu-default-settings
[04:36] <Riddell> bddebian: and you can reject it, that feature is inaccurate and causes lots of disk activity
[04:37] <bddebian> Riddell: Oh, OK, thx
[04:37] <Riddell> thank you
[04:39] <Gloubiboulga> janimo: around?
[04:39] <janimo> yes
[04:52] <janimo> ogra: does ltsp-client-builder in the installer mean it is automatically installed right?
[04:52] <janimo> does it somehow imply install X only and no desktop?
[04:53] <janimo> there's a report of todays xubuntu CD not installing much besides Xorg, and a ltsp config error during install
[04:56] <janimo> ogra: seems it's CD errors so nevermind
[05:07] <bddebian> Should a .pot file be in the -dev package instead of the normal lib package?
[05:08] <seb128> a .pot should not be shipped by a binary package
[05:08] <seb128> what bug is that?
[05:09] <bddebian> Bug #33676
[05:09] <Ubugtu> Malone bug 33676 in kdelibs "produces zero-length kde.pot" [Normal,Unconfirmed]  http://launchpad.net/bugs/33676
[05:10] <seb128> bddebian: why do you speak about lib package?
[05:10] <Riddell> bddebian: which package is it shipped in?
[05:11] <seb128> bddebian: the .pot is the list of strings to translate, part of the source directory and used by rosetta
[05:11] <bddebian> seb128: http://librarian.launchpad.net/2433849/buildlog_ubuntu-dapper-i386.kdelibs_4%3A3.5.2-0ubuntu13_FULLYBUILT.txt.gz
[05:11] <seb128> Riddell: according to the bug it's kdelibs package
[05:12] <Riddell> seb128: kde.pot is specil, it's a list of standard strings to be excluded from other .pot files
[05:12] <bddebian> In -dev package:  -rw-r--r-- root/root     13730 2005-09-10 09:27:50 ./usr/include/kde/kde.pot
[05:12] <Kamion> kdelibs4-dev
[05:12] <Kamion> if it's been fixed now, great
[05:12] <seb128> Riddell: https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/33676
[05:12] <Ubugtu> Malone bug 33676 in kdelibs "produces zero-length kde.pot" [Normal,Unconfirmed]  
[05:13] <infinity> Kamion: I haven't actually tried the build yet, but I'm a bit concerned about cdebconf appearing to be in universe, according to madison-lite...
[05:14] <infinity> Kamion: Does d-i pull from universe, or will that break horribly?
[05:14] <bddebian> Wow, if I try to install kdelibs4-dev on my kubuntu install it brings in a BOATLOAD of packages??
[05:14] <Riddell> bddebian: I did fix that so if you can confm that kde.pot has strings in it that's all good
[05:14] <Riddell> and it does need to be in -dev
[05:15] <Riddell> bddebian: yes, it'll bring in the -dev packages needed by KDE
[05:15] <bddebian> Yikes, OK, I'll check it thx
[05:15] <Kamion> infinity: that's only cdebconf.deb; the necessary udebs are in main
[05:15] <infinity> Kamion: Ahh.  Check.
[05:16] <infinity> Kamion: I'll fire up some builds right now, then.
[05:16] <Kamion> hmm need to fix madison-lite's config to spot udebs in -security
[05:20] <Riddell> bddebian: if I happen not to be around you may get kde answers from #kubuntu-devel
[05:20] <bddebian> Riddell: Ah, OK, thx
[05:20] <bddebian> BTW, kde.pot in -dev is fine
[05:22] <bddebian> Riddell: Are they more responsive than #xubuntu?
[05:23] <Kamion> cdebconf-udeb | 0.84ubuntu12 | breezy-security/main/debian-installer | amd64, hppa, i386, ia64, powerpc, sparc
[05:26] <infinity> Kamion: test-building on i386, if that goes fine, will do the other 5.
[05:40] <Ubugtu> Gnome bug 56070 in gtk "Can't click button after setting it sensitive." [Normal,Reopened]  
[05:46] <bddebian> Gah, I think I'm over my head on these.. :-(
[05:47] <iegary> Diziet: I was wondering if bug #41093 was worth getting in (looks like a simple patch), and was told to ping you. It's not in the 1.5 branch upstream, but is in 1.8.
[05:47] <Ubugtu> Malone bug 41093 in firefox "Firefox leaks memory if the clipboard contains 500001 bytes or more" [Normal,Unconfirmed]  http://launchpad.net/bugs/41093
[05:48] <janimo> tseng: ping
[05:50] <ogra> janimo, there is a seed bug i got reported yesterday, ldm needs to be added to the seeds in ubuntu
[05:51] <janimo> ogra: ubuntu or xubuntu?
[05:51] <ogra> (since ltsp-client doesnt have a hard dependency on it anymore)
[05:51] <janimo> can this make the install fail?
[05:51] <ogra> janimo, i suspect all distros apart from edubuntu, where ldm is explicitly seeded
[05:52] <janimo> ogra: ldm is in the ship seed for xubuntu alreday
[05:52] <janimo> explicitely
[05:52] <janimo> but the tester said it was bad CD as well
[05:52] <janimo> so that may explaiin the issue
[05:52] <ogra> yep, shit happens :)
[05:53] <janimo> any idea what you need to get rid off to fit on the CD?
[05:53] <Gloubiboulga> I'd say a dead cd drive even :)
[05:53] <janimo> Gloubiboulga: you seem to not be affected too much :)
[05:53] <ogra> i'm pondering between a11y or some asian fonts
[05:53] <ogra> :(
[05:54] <janimo> you cannot drop evolution right?
[05:54] <Gloubiboulga> the base system has been installed, I'm happy with that and a working internet connection ;)
[05:54] <ogra> else i'd have to tear down some edu apps, which is the last i would do
[05:54] <ogra> i want the desktop as similar as possible, else we'd have to have extra documentation
[05:55] <ogra> so no, evo is a must
[05:55] <janimo> yeah, but exposing children to that application :(
[05:55] <janimo> besides some Kansas schools may not install edubuntu because of it :)
[05:57] <Keybuk> they could always use the KDE version, Kreationism
[05:57] <ogra> janimo, even if it looks like, edubuntu is not only for children ;)
[05:57] <ogra> Keybuk, lol
[05:57] <janimo> ogra, well grown-up should not be exposed to evo either
[05:59] <pitti> Mithrandir: shall we test new live images/
[05:59] <infinity> Kamion: Okay, they're all built and landed in queue/byhand on jackass.
[05:59] <pitti> ?
[05:59] <jsgotangco_> lol
[06:00] <ogra> janimo, whats the alternative ? surely not sylpheed or mutt :)
[06:00] <giftnudel> pine
[06:00] <giftnudel> maybe thunderbird?
[06:00] <Kamion> infinity: thanks - I'll work out what to do with them in a bit
[06:00] <ogra> (i'd take balsa, its very userfriendly and small)
[06:01] <ogra> giftnudel, tb eats half of the CD, nope, thanks ;)
[06:01] <giftnudel> hehe
[06:01] <ogra> i need to free 8M
[06:01] <giftnudel> balsa is nice, I tested that a year ago and liked it
[06:01] <ogra> (i wouldnt mind to drop some stuff if it wouldnt be the i386 CD)
[06:02] <giftnudel> and you don't have anything to drop?
[06:02] <ogra> nope
[06:02] <ogra> edubuntu is on the very edge
[06:02] <ogra> everything i can drop now is essential ubuntu stuff or some edu app
[06:02] <ogra> neither thrills me
[06:02] <giftnudel> firefox?
[06:03] <giftnudel> and use epiphany instead
[06:03] <ogra> yelp depends on ff
[06:03] <ogra> ephy as well
[06:03] <ogra> no wayy
[06:03] <ogra> -y
[06:04] <giftnudel> I see, but I guess you were thinking about it longer then me, so my suggestions were probably already considered
[06:04] <jsgotangco_> we can go follow the xubuntu route and have abiword instead :)
[06:04] <bddebian> ugh
[06:04] <jsgotangco_> hehe
[06:05] <giftnudel> maybe two editions, one for asian languages and one for the rest, then you can remove a lot of the langpacks ....
[06:06] <ogra> and get fired because i caused so much extra costs at shipit ? 
[06:06] <janimo> ogra: evolution 33M, thunderbird 26M
[06:06] <giftnudel> 7 MB
[06:06] <janimo> there's your 8M :)
[06:06] <ogra> tb is long gone :)
[06:06] <Kamion> giftnudel: double money in shipit, double disk space on cdimage/releases (which is at a premium), double testing time
[06:06] <Kamion> none of these are trivial resources to spend
[06:06] <giftnudel> yeah, I see
[06:07] <giftnudel> ogra: but if you use balsa and drop evo, you should be fine, right?
[06:08] <ogra> apart from balsa being in universe, yes
[06:08] <giftnudel> there is always a catch ... 
[06:08] <jsgotangco_> ogra: bah, punish the students and make them use mutt
[06:08] <janimo> is there really a need for pop3/imap outside corporate world and developers?
[06:09] <janimo> all mail should just be webmail
[06:09] <ogra> heh
[06:09] <giftnudel> yeah, internet is cheap anyway
[06:22] <ssam> is it ok to discuss google summer of code applications here
[06:27] <highvoltage> mako!
[06:27] <Keybuk> mdz: go a moment?
[06:27] <mdz> Keybuk: yes
[06:28] <Keybuk> do you have any beverage in your hand/mount?
[06:28] <Keybuk> uh, mouth
[06:28] <Keybuk> or anything breakable nearby?
[06:28] <bddebian> Uh oh
[06:28] <mako> highvoltage: hey there
[06:29] <Keybuk> I'd like to change the way udev enumerates /sys
[06:30] <Keybuk> right now we walk /sys/devices and touch everything with a uevent
[06:30] <Keybuk> it turns out that's wrong
[06:30] <Keybuk> we should be iterating through /sys/bus/*/devices instead
[06:31] <Keybuk> this fixes the T42 Docking Station problem, and a number of raid controller problems -- all with hda becoming hde under certain circumstances
[06:33] <Keybuk> I've been gathering comparisons of the two methods on people's machines this afternoon via the mailing list, and so far the /sys/bus method finds the same set of devices
[06:35] <Kamion> mdz: btw, the reliable way to reproduce that ubiquity/partman problem with missing filesystem types on the summary screen is to rm -rf /var/lib/partman, start ubiquity, and then make sure at least one partition you're trying to mount has been newly created in gparted
[06:35] <Keybuk> I think I killed mdz :)
[06:37] <mdz> Keybuk: better than not having a beverage, I was looking at other windows
[06:38] <mdz> Keybuk: does /sys/bus/*/devices end us up at the same actual inodes in /sys? or different stuff?
[06:38] <Keybuk> the way /sys works is that /sys/devices is the actual tree of kernel objects
[06:39] <Keybuk> with an infinitely deep topology
[06:39] <Keybuk> /sys/bus are symlinks into this tree of the actual devices, but listed in logical order
[06:39] <Keybuk> so they are the same actual inodes, yes
[06:40] <Keybuk> the difference is that rather than finding an IDE controller at, e.g.
[06:41] <Keybuk> /devices/pci0000:00/0000:00:01.0/0000:01:05.0
[06:41] <mdz> Keybuk: where did the revelation come from that we should be doing it this way?  does upstream concur?
[06:41] <Keybuk> which would be logically "first"
[06:41] <Keybuk> we find it at
[06:41] <Keybuk> /bus/pci/0000:01:05.0 instead
[06:41] <Keybuk> yup
[06:41] <mdz> it presumably fixes the docking station problem by giving us a different ordering
[06:41] <Keybuk> upstream's done it this way since we got our modifications added in
[06:42] <mdz> what about the raid controller problems?
[06:42] <Keybuk> and we discussed it then, I didn't believe at the time our method was "wrong" just different
[06:42] <Kamion> argh, I see, my implementation of update_partition in ubiquity was TOTALLY WRONG
[06:42] <Keybuk> exactly, we get a logical ordering by PCI Bus id rather than actual physical topology
[06:42] <Keybuk> which seems to be what we're after
[06:42] <mdz> Kamion: it did seem somehow related to creating the partitions in gparted
[06:43] <mdz> Kamion: does that mean you found the bug?
[06:43] <Keybuk> two or three people (linked on the same bug) have reported problems where an IDE RAID controller can cause the ordinary IDE to get renumbered if it's connected and powered up
[06:43] <Kamion> mdz: I believe so; I think I just implemented parted_server.py on far too little sleep and misread the shell code in partman
[06:43] <Kamion> will have to test a bit though
[06:43] <Keybuk> it's the same underlying problem, the controller is on a different bus -- and the bridge for that bus has a lower pci id than the ordinary ide controller
[06:45] <mdz> Keybuk: it seems like we have just as much chance of breaking working setups by changing the order
[06:45] <Keybuk> mdz: there is a slight possibility of that, if they're relying on a toplogy-first order
[06:46] <Keybuk> ie. they have two conflicting drivers and they'll now get loaded in the opposite order again
[06:46] <Kamion> apart from the more complicated mistake, apparently I managed to translate:
[06:46] <Kamion>     [ "$part" ]  || return 0
[06:46] <Kamion> into:
[06:46] <Kamion>         if info != '':
[06:46] <Kamion>             return
[06:47] <mdz> Keybuk: is there any way we can implement this change for new installs but leave existing installs alone?
[06:48] <Keybuk> mdz: how do you tell on boot how new or old the install is?
[06:48] <giftnudel> maybe add a config file somewhere?
[06:48] <mdz> Keybuk: when installing udev, leave yourself a note
[06:48] <mdz> when generating the initramfs, read the note
[06:49] <Keybuk> mdz: given we'd be dropping the "current" way in edgy anyway (it is just plain wrong) I'd prefer to either just do it now, or wait until edgy
[06:49] <mdz> Keybuk: we're too close to the release to break the world
[06:49] <Keybuk> well, yes
[06:49] <Keybuk> that's why I'm talking about it, rather than just uploading it :p
[06:49] <Lure> Kamion, Riddell: bug 42967 with today's Live CD ubiquity
[06:49] <Ubugtu> Malone bug 42967 in ubiquity "crash on when starting partitioner" [Normal,Unconfirmed]  http://launchpad.net/bugs/42967
[06:50] <Keybuk> I'm happy to just tell people that dapper doesn't work in these configurations
[06:50] <Keybuk> and that the fix is known, and edgy would be fine
[06:51] <mdz> it seems fairly straightforward to fix in a backward-compatible way, though
[06:51] <Riddell> Mithrandir: kubuntu install CDs all good, still going to take another ~3 hours for live CDs
[06:51] <Riddell> Lure: thanks
[06:51] <mdz> but I, too, am happy to say that the fix is too intrusive
[06:52] <mdz> Keybuk: of course, in edgy, we're going to probe-for-root by default anyway, right? ;-)
[06:52] <Keybuk> one would hope so
[06:53] <Keybuk> I rather hope we'll have libpata in edgy too
[06:53] <Kamion> Lure: funky, thanks. I'd best have a look at that
[06:53] <Kamion> Mithrandir,Riddell: I think Lure's bug may be RC - it probably affects any installations on systems with existing NTFS filesystems
[06:57] <slomo_> infinity: hrm right... sorry :( i'll write it on my todo list of things to fix after flight7
[06:59] <infinity> slomo_: Thanks for fixing my debhelper bug, though (or dholbach's bug, depending on how you look at it, since I assumed he'd use /g in his regex)..
[07:00] <pips1> doko, ping!
[07:01] <carlos> Riddell: hi, around?
[07:04] <pips1> ajmitch, ping
[07:21] <dieman> Keybuk: do you care which kernels are used when using that check-udev script?
[07:21] <dieman> Keybuk: ie: only Dapper?
[07:21] <Keybuk> dapper
[07:21] <dieman> ok
[07:21] <dieman> hrm
[07:21] <dieman> otherwise I could run it on the couple hundred hoary machines here :)
[07:22] <dieman> well, i'll email what my laptop said
[07:22] <infinity> Actually, comparing it to hoary would be pretty useful, as long as you tag the hoary output as such.
[07:22] <dieman> hmm
[07:22] <dieman> ok
[07:22] <Keybuk> true
[07:22] <infinity> Keybuk: Assuming you can determine from said output how hoary would be enumerating those devices..
[07:23] <infinity> Then you can see how badly this change would break (or unbreak) upgrades.
[07:23] <infinity> Oh, wait?  hoary?... Not sure how useful that would be compared to breezy.
[07:23] <infinity> My brain mapped s/hoary/breezy/ instrinctively.
[07:23] <infinity> But it's up to Scott.
[07:24] <Keybuk> the main thing missing from breezy is just confirmation which ones didn't matter anyway
[07:24] <infinity> Keybuk: Do you know if this change would improve (or degrade) the breezy->dapper upgrade scenario?
[07:25] <infinity> Keybuk: Cause if it breaks dapper->dapper a bit, but fixed breezy->dapper, the latter is the more important upgrade path.
[07:25] <infinity> (Of course, as mdz suggested, a way to make dapper->dapper happy would be swell too)
[07:27] <Keybuk> infinity: it's actually compatible with breezy
[07:27] <Keybuk> which did logical enumeration, rather than topological
[07:27] <Keybuk> so it should avoid breezy->dapper upgrade breakage
[07:27] <infinity> Keybuk: Err, which is compatible with breezy?... The current way, or the proposed new way?
[07:28] <Keybuk> "new" way
[07:29] <infinity> Keybuk: Would have been helpful to mention that in your debate with mdz, then.  dist-upgrades leading to a user's root disappearing are pretty much teh suck.
[07:29] <Keybuk> current way breaks things compared to breezy
[07:29] <Keybuk> I didn't think of it :p
[07:29] <Keybuk> too used to dapper
[07:29] <infinity> mdz: ^^^ (last 5 or 10 lines)
[07:29] <Riddell> carlos: hi
[07:30] <carlos> Riddell: I need to leave, but is a fast question....
[07:30] <carlos> Riddell: why kdepim and koffice provide the same kdgantt .pot file?
[07:33] <carlos> Riddell: I had to disable the one from kdepim and leave the one from koffice
[07:33] <Riddell> carlos: I'm not too sure, I'll look into it
[07:33] <carlos> ok, thank you
[07:35] <dieman> heh
[07:35] <dieman> the script didn't output anything on any of my hoary machines anyhow, im guessing it checks stuff hoary didn't do anyhow?
[07:38] <Diziet> iegary: re 41093: How bad is this problem, really ?  The patches are indeed nice and small.
[07:40] <mdz> Keybuk: what have we broken for breezy users?
[07:40] <iegary> Diziet: it seems to be responsible for memory bloat when large amounts of data is copied to the clipboard. Not a must-have though. There are much worse problems than this with C+P in mozilla, but this is just low-hanging fruit.
[07:41] <Kamion> Mithrandir: damnit. 42967 is RC, I think, and I'm being called away for dinner and haven't tested it yet. There's a patch in my bzr repository if you want it urgently ...
[07:41] <Keybuk> mdz: nothing
 current way breaks things compared to breezy
[07:41] <Keybuk> mdz: for breezy users, the current cod emay be broken
[07:41] <Keybuk> yes
[07:41] <mdz> that doesn't *sound* like nothing...
[07:41] <Kamion> Mithrandir: (but if you're uploading from bzr be careful to debian/rules update first)
[07:42] <Keybuk> breezy did:  for DEVICE in /sys/bus/pci/devices/*
[07:42] <Kamion> Mithrandir: failing that, I'll nip back in a couple of hours, do the testing, and upload
[07:42] <Keybuk> which is what I'm proposing we make dapper do
[07:42] <Kamion> mdz: translation, he means his new way doesn't break anything but the current code breaks, AIUI
[07:42] <mjg59> Keybuk: If a module for a network device is loaded, will udev automatically bring up the interface if it's flagged auto?
[07:43] <Keybuk> mjg59: ye
[07:43] <mdz> Keybuk: thing is, we won't know if we've screwed them until it's too late to fix
[07:43] <Keybuk> well, we know the dapper stuff didn't break too much
[07:43] <Keybuk> so far this IDE renumbering issue seems to be the primary breakage
[07:44] <mjg59> Keybuk: Is there any way to inhibit that?
[07:44] <Keybuk> mjg59: don't flag it auto
[07:44] <mjg59> Keybuk: Since it means the "only ifup interfaces that were up previously" bit of resume, well, doesn't
[07:44] <Keybuk> mjg59: explain
[07:45] <mjg59> Keybuk: On suspend, we check which interfaces are up. We remember that, and then down them all.
[07:45] <mjg59> Keybuk: On resume, we only up the interfaces that were up
[07:45] <Diziet> iegary: Right.  Well, thanks for pointing it out and I'll think about it.  I expect I'll include it.
[07:45] <mjg59> Keybuk: Except we also unload the network modules, and then reload them. So all the interfaces end up up.
[07:45] <Keybuk> mjg59: right ...
[07:45] <Diziet> (What I really meant was how many people does this affect?)
[07:46] <mjg59> And you made the change to acpi-support for the "Only bring up some interfaces" IIRC (though it may have been mdz)
[07:46] <Keybuk> it was me
[07:46] <Diziet> (I don't have a good feel for how common huge clipboards are.)
[07:46] <mjg59> Keybuk: So, this situation is obviously sub-optimal
[07:46] <Keybuk> mjg59: obviously, but no, there's no way to inhibit that
[07:46] <mjg59> Keybuk: Horrible ideas include the use of a lock file
[07:47] <mdz> mjg59: it has been just as sub-optimal since ~warty, though, no?
[07:47] <Keybuk> mjg59: edgy
[07:47] <mjg59> mdz: It's now differently suboptimal because the code looks like it does one thing, but a completely unexpected side-effect does something else
[07:48] <iegary> Diziet: they're pretty common - large multi-megabyte text file loads in the browser instead of saving to a file. rather than whipping out wget, the average person might copy/paste into an editor.
[07:48] <mdz> mjg59: much like the laptop-mode comment, which said "this is disabled by default" and then enabled it by default
[07:48] <mjg59> mdz: Yeah
[07:49] <mjg59> mdz: If loading the modules brings up the devices, we should just remove that bit of acpi-support
[07:49] <Keybuk> the problem is you're talking about adding locking and crap around a piece of code that really should just work
[07:49] <Keybuk> I mean really *needs* to just work
[07:50] <mjg59> Keybuk: But there's no way of making it just work in the current form
[07:50] <mjg59> Until we fix the entire kernel
[07:50] <Keybuk> fair enough, let's leave it as it is then
[07:50] <mjg59> Well, stub out the current code
[07:50] <mjg59> Because it just runs extra ifups
[07:51] <Keybuk> it's rarely harmful to up interfaces, no?
[07:51] <mjg59> Right, but there's no point in having redundant code
[07:51] <mjg59> Especially when it makes it look like stuff behaves one way, when it doesn't
[07:52] <Keybuk> sure
[07:52] <janimo> ogra: 'building ltsp chroot' at the end of xubuntu install. Can that be made optional?
[07:52] <janimo> given the ltsp builder is in the installer seed
[07:52] <Diziet> iegary: Mmmm.
[07:53] <ogra> not ifr its in the seed i think
[07:54] <janimo> ogra, for edubuntu it does not install for all install menu options?
[07:54] <mjg59> Keybuk: But the interface bringing up is backgrounded, right?
[07:54] <Keybuk> right?
[07:54] <ogra> janimo, right we have a separate seed for workstation installs that doesnt install it
[07:54] <nomed> janimo, i think "xfdesktop" hates you :)
[07:54] <mjg59> If I do "modprobe ipw2100" followed by "modprobe e1000", nothing is going to block?
[07:55] <Keybuk> right
[07:55] <janimo> nomed, why it crashes again?
[07:55] <Keybuk> you only get blocking when you use udevplug
[07:55] <mjg59> What if I do "modprobe ipw2100", it creates eth0, it launches dhclient and I then do "ifup eth0"?
[07:55] <janimo> ogra, so that separate seed does not have that in the installer?
[07:55] <janimo> separate installer seed you mean?
[07:55] <ogra> yep
[07:55] <janimo> oh crap
[07:56] <mjg59> That is, I do ifup eth0 before the first dhclient has returned
[07:56] <Keybuk> mjg59: then ifup eth0 will return immediately because the interface is already up
[07:56] <nomed> janimo, have u seen the comment to the bug ?
[07:56] <mjg59> Ok
[07:56] <Keybuk> or, if the ifup eth0 happened somewhere between eth0 being created and ifup being run to launch dhclient ...
[07:56] <janimo> ogra, I thought it would trigger only if something in the desktop seed or som e other references it
[07:56] <Keybuk> the ifup eth0 would block until finished
[07:57] <Keybuk> except it's backgrounded in that script too
[07:57] <janimo> otherwise all xubuntu installs put a ltsp
[07:57] <ogra> janimo, nope ...
[07:57] <janimo> which is not what I want
[07:57] <janimo> nomed, not yet
[07:57] <mjg59> Keybuk: Yeah. It /ought/ to be ok
[07:57] <janimo> installe r is stuck in building ltsp chroot for a while now
[07:57] <ogra> yep
[07:57] <ogra> its a bit unresponsive
[07:58] <ogra> i have a patch for eft pending to make it throw out more info
[07:58] <janimo> nomed, I did not get mail
[07:58] <Keybuk> mjg59: this gets tested every time dapper boots
[07:58] <janimo> will check url direcly
[07:58] <nomed> realy absurd in general .. but what i do not understand is that he thinks we should have a mount point dir already for removable devices :/
[07:58] <ogra> janimo, console 3 should have the output
[07:58] <janimo> ogra, ok
[07:58] <mjg59> Keybuk: I'm getting occasional hangs on resume for reasons I haven't determined yet
[07:59] <janimo> but this is not what I want for default xubuntu, so should I take it out from the installer seed?
[07:59] <ogra> i would do so
[07:59] <ogra> it will be in the expert menu anyway
[07:59] <ogra> so users doing an expert install can select it
[07:59] <mjg59> Keybuk: So I just wanted to make sure it wasn't a bizarre and nasty network race thing
[08:00] <Keybuk> I'm not aware of any of those
[08:00] <Keybuk> and I tested the locking pretty thoroughly
[08:00] <mjg59> Ok, cool
[08:00] <mjg59> I just need to figure out how to dump stuff usefully
[08:01] <Keybuk> what kind of stuff do you need to dump
[08:02] <Keybuk> why does the first 10 minutes of a Simpsons episode never have anything to do with the rest?
[08:03] <jdub> because that's where the jokes go
[08:03] <ogra> to keep you intreasted
[08:05] <zul> simpsons are getting tired though
[08:05] <zul> family guy is way more funnier
[08:05] <zul> anywyas
[08:07] <_ion> True.
[08:07] <tseng> jdub: hi
[08:08] <janimo> nomed: actually it's a polite answer why you say xfdesktop hates me? :)
[08:09] <janimo> ogra: so I remove ltsp builder frominstaller seed it causes failed installation step
[08:10] <janimo> tseng: upstrream xfce just fixed autostart editor to not show desktop which have onlyshowin gnome set
[08:10] <tseng> janimo: cool
[08:10] <janimo> however it would be nice if beagle set xfce as well
[08:10] <janimo> since it can run there too
[08:10] <tseng> I guess
[08:10] <janimo> I need to ask mvo to do the same for update notifier
[08:10] <tseng> can i say
[08:10] <janimo> they're generic gtk apps which use gnome libs too
[08:10] <tseng> onlyshowin=gnome,xfce?
[08:11] <janimo> tseng, yes
[08:11] <tseng> ok
[08:11] <tseng> thats fine
[08:11] <janimo> I'd say it could even go in kde
[08:11] <tseng> no
[08:11] <janimo> is that a daemon?
[08:11] <tseng> kde uses a different file path
[08:11] <tseng> for autostart files
[08:11] <tseng> yay for standards
[08:11] <janimo> I'd thought only show in is to be used when teh app could cause confusion or misbehaviour in a specific environment
[08:12] <Keybuk> the nice thing about them is that there are so many to choose from
[08:12] <janimo> not when it's written using the other ui toolkit
[08:12] <tseng> eh
[08:12] <tseng> its done so that gnome uses it in one path
[08:12] <tseng> and kde uses it in another
[08:12] <tseng> you can debate the onlyshowin= all day for all I care
[08:12] <tseng> when they use the path I'll happily list anything in there you want
[08:13] <janimo> so far xfce will do thanks :)
[08:13] <tseng> np
[08:14] <janimo> Kinnison: hello, could g-p-m's autostart file have xfce added besides gnome in the autostart .desktop file's onlyshowin entry? I file a LP bug to remind you if you wish
[08:15] <Diziet> doko: You said in your meeting paste that you wanted my feedback on something font-related ?  Can you send me a mail about that ?  I have to go now but I want to answer you ASAP.
[08:15] <nomed> janimo, yes better then usually .. anyway always same mood
[08:16] <doko> Diziet: that was two weeks ago, last meeting I did want feedback from Riddell ;-)
[08:16] <Diziet> Oh!
[08:16] <Diziet> Good.
[08:16] <Diziet> I thought it looked familiar.
[08:16] <janimo> nomed: we had a private mail exchange and the communication seesm to have improved since :)
[08:16] <Diziet> But I thought `surely my IRC scrollback doesn't go back that far'.  Evidently it does.
[08:16] <nomed> that's cool :)
[08:16] <Diziet> You see, it just occurred to me that I didn't search in each client for the nick I use with the other one ...
[08:17] <Diziet> Anyway, I'm off now.  Thanks :-).
[08:21] <janimo> Gloubiboulga: hi I got the LTSP error too
[08:21] <janimo> looks like we need to have new CDs :(
[08:22] <Mithrandir> Kamion: I was out biking so if you'd like to upload, that'd be nice.
[08:23] <Mithrandir> Kamion: I presume this affects all distros?
[08:23] <Gloubiboulga> janimo, ok, it's not an issue with my drive then...
[08:24] <Kamion> Mithrandir: just uploaded; yeah, it affects both the GTK and KDE frontends :(
[08:25] <Kamion> was introduced by the fix to make ubiquity handle partman exceptions
[08:26] <Mithrandir> Kamion: we'll just roll new images once it's in, then.
[08:29] <Treenaks> gar @ dying spamd
[08:31] <ogra> Amaranth, btw, since you want to work on an edubuntu SoC project, being in #edubuntu might be good :)
[08:32] <kagou> is there rules to use for permissions on directory/files under /var/log ?
[08:32] <Amaranth> ogra: good idea :)
[08:32] <ogra> :)
[08:45] <shutdownrunner> Hi. I'm trying to install ubuntu under compaq deskpro 350. all the time I'm getting errors. Under dapper I don't know what the problem is "Attempted to kill init ...", but under breezy I get "Acpi : Unable to load system description database" and something about [_SB_]  not to be found. Have you got any ideas what this is? If you could suggest where I could look for a solution, I'd also be grateful.
[08:56] <janimo> Mithrandir: a new xubuntu install CD will be needed unfortunately. The current one tries to install LTSP and fails. So I took out that package from the installer seed for now
[09:00] <Mithrandir> janimo: ok, tell me when you have new meta packages in the archive.
[09:02] <Kamion> you don't need a -meta upload for an installer seed change, just a CD rebuild
[09:02] <Kamion> assuming rookery has the new seeds
[09:04] <Mithrandir> oh, ok
[09:06] <janimo> Mithrandir:  The seeds are mirrored already in Kamion's bzr branch soI guess it's good to go
[09:07] <Mithrandir> janimo: build running
[09:07] <janimo> Kamion, so if I want a ltspserver install should I not put it in the installer seed as it affects workstation install as well?
[09:07] <janimo> Mithrandir: thanks
[09:08] <janimo> the 4 packages that made up the ltsp menu entry which I added to the LP bug may need to be ammended with the ltsp-client-builder then
[09:30] <janimo> Mithrandir: ok rsynced the new image, started testing
[09:48] <ben-2006> hey, I am planning on entering the google summer of code for an ubuntu project - anyone got any tips?
[09:48] <pygi> ben-2006: I might be of help considering I am a mentor there :)
[09:48] <pygi> ben-2006: what project are you interested in?
[09:49] <ben-2006> i've completed an application for the sync tool (haven't submitted it yet)
[09:49] <pygi> ben-2006: point me to the link on Ubuntu SoC wiki pls?
[09:49] <ben-2006> want to complete another application (just to give me more chance, really excited about the opporunity)
[09:50] <ben-2006> 2secs
[09:50] <ben-2006> https://wiki.ubuntu.com/MultipleComputersSynchronization
[09:50] <pygi> ben-2006: also, please move to #summer-discuss at slashnet, cause this is not appropriate place
[10:24] <pitti> hey seb128, wb
[10:24] <seb128> re pitti
[10:24] <pitti> seb128: thanks for the POT files, great!
[10:24] <seb128> are we still upload frozen? :)
[10:24] <pitti> (- fixes)
[10:24] <seb128> pitti: np
[10:29] <pygi> Kamion: around? :)
[10:34] <Riddell> Mithrandir: still expecting flight 7 tonight?
[10:34] <Mithrandir> Riddell: no, tomorrow.
[10:35] <Mithrandir> Riddell: we need to redo the live images.
[10:35] <Riddell> yeah, just wondering if that was happening today
[10:35] <Riddell> but tomorrow is good
[11:00] <pygi> Kamion: still not here? :-/
[11:17] <Kamion> pygi: it's my evening, dude
[11:17] <Kamion> pygi: I'm going to bed now, but if you say what you want then I'll reply when I'm next around
[11:17] <pygi> Kamion: yes, sorry :-/ Enjoy :)
[11:18] <pygi> will do, thanks
[11:45] <andreasn> JaneW: ping
[11:46] <pygi> andreasn: I don't think she's here now :)
[11:46] <andreasn> ok
[11:46] <andreasn> thanks
[11:47] <andreasn> when can I usually reach her?
[11:48] <janimo> Mithrandir: ok xubuntu install CD looks good on i386 can become flight 7
[12:01] <carlos> pitti: I know is a bit late... but if you are still around and can execute the script to compare the language packs tarballs... that would be really good
[12:01] <pitti> carlos: yes, I can