[12:09] <mdz> Riddell: I can do that
[12:09] <mdz> Riddell: done
[12:10] <Kamion> mjg59: right, you'd need to reboot I'm afraid
[12:10] <Kamion> mjg59: I could fix that, but it would break preseeding
[12:10] <Kamion> mjg59: alternatively:
[12:10] <mjg59> Kamion: Ok
[12:10] <Kamion> mjg59: (echo RESET console-setup/layoutcode; echo RESET console-setup/variantcode) | sudo debconf-communicate
[12:10] <mjg59> Kamion: I've no problem with rescuing it myself, I just want to make sure it doesn't happen to other people :)
[12:10] <mdz> Riddell: for future reference: https://launchpad.net/people/launchpad-buildd-admins
[12:11] <Kamion> ... should kill off console-setup's memory of this
[12:11] <Kamion> mjg59: if you wouldn't mind then trying it once more, just to confirm before I upload the fix
[12:11] <mjg59> Kamion: Still seems broken
[12:12] <mjg59> Want debug log again?
[12:12] <Kamion> yeah, why not
[12:12] <Riddell> thanks mdz 
[12:14] <mjg59> Kamion: Ok, done
[12:14] <mjg59> Kamion: Oh - is there any hope of us getting a font that means I don't have missing glyph boxes in ubiquity? :)
[12:14] <Kamion> mjg59: yeah, I've been wondering about that - it's just Dzongkha
[12:15] <Kamion> advice gratefully appreciated, otherwise I'll probably just exclude the language
[12:15] <mjg59> If we can't find a font with the glyphs, it's probably the right answer
[12:15] <mjg59> Otherwise there's no way to complete the install in any case
[12:16] <Kamion> there's ttf-dzongkha
[12:16] <sabdfl> if i've mounted a remote server using the Places menu ("Connect to Server...") should those files also be accessible through the Open File dialog?
[12:16] <Kamion> at 600KB
[12:16] <mdz> mjg59: does the backtrace in bug 56587 help at all?
[12:16] <Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Confirmed]  http://launchpad.net/bugs/56587
[12:16] <Kamion> mdz: any opinions on adding the above?
[12:16] <mjg59> We should probably find (or write) a tool that can tell us if all the characters in a po file are in the fonts
[12:16] <Kamion> I believe it's what the d-i team is using
[12:17] <mjg59> mdz: Not really
[12:17] <mjg59> sabdfl: If the application understands gnome-vfs and has told the filechooser that, yes
[12:17] <mjg59> mdz: x86emu blows up with some bioses. We only see it on amd64 because we use vm86 on x86
[12:17] <mdz> sabdfl: firefox in particular won't
[12:18] <mjg59> mdz: I've disabled the code that's likely to trigger it, since we don't use it anyway, but I'll want to track it down at some point because it hurts us in vbetool
[12:18] <mdz> sabdfl: oo.o should, at least when running native
[12:18] <mdz> mjg59: that's in your bzr?
[12:18] <mjg59> mdz: Yup
[12:19] <mjg59> mdz: The bzr needs a trivial fix to compile
[12:19] <sabdfl> yeah, it's t-bird that i noticed this in
[12:20] <mdz> gnome-vfs is solving a problem in the desktop which should probably be solved at a lower level
[12:20] <Kamion> mjg59: ok, that will go away with a newer console-setup - it's because it's sucking the keyboard configuration out of xorg.conf, which I've stopped doing
[12:20] <Kamion> I'll bump the dependency a bit
[12:20] <mdz> but the assumptions which would be broken by doing so make my head spin
[12:21] <mjg59> Kamion: Ah, ok
[12:21] <mdz> mjg59: how bad is it for affected users?  they see a black screen all the way until X starts?
[12:21] <mjg59> mdz: The plan is to redevelop gnome-vfs so that it's accessible via FUSE
[12:22] <mjg59> And then have some mechanism for providing those paths to applications that don't understand gnome-vfs natively
[12:22] <mdz> mjg59: it seems likely that there are all sorts of filename-handling routines which won't cope with a URL though
[12:22] <mjg59> mdz: Yeah, that's the likely behaviour
[12:22] <mjg59> mdz: Right, so they'll never see one
[12:23] <mdz> and suddenly we're all running plan 9!
[12:23] <mjg59> The reason not to just do it all in FUSE is because there's no nice way to do async operations via POSIX
[12:23] <mjg59> And you really want async file i/o when the file store is a random webdav server on a bit of string
[12:23] <jdub> mdz: firefox has gnome-vfs support, and some of the other distros have native dialogue patches
[12:24] <mjg59> So gnome-vfs applications get to do things properly, and non-aware ones get to access the files anyway (just with a bit more suck)
[12:25] <mdz> jdub: oh, so it does.  network servers don't show up in its open dialog though
[12:26] <mjg59> mdz: I'll try testing the usplash changes here in a bit - I can force x86emu on a 32 bit system
[12:26] <jdub> mdz: perhaps they don't turn on that smarts in the filechooser because they can't tell if they have gnome-vfs support? not sure.
[12:26] <jdub> i might be unreliably bad, too, mind
[12:27] <lifeless> mjg59: aio
[12:27] <lifeless> mjg59: unpacking that: there is too async file operations via posix. 
[12:27] <mdz> mjg59: can we notice if usplash segfaults and clean up after it somehow, to be robust against this problem in general?
[12:34] <Kamion> mdz,tfheen: could you eyeball http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.1.24.diff for me? fixes mjg59's UK keyboard selection issue above, which I think is beta-RC
[12:34] <mjg59> mdz: We could add a segv handler to it and chvt back to another vt
[12:40] <mjg59> Keybuk: Ouch. Another reason for blacklisting nvidia is because it takes up *4MB* of kernel memory
[12:40] <mjg59> Which is unswappable
[12:43] <Kamion> mdz,tfheen: also, do I want to accept these changes turning Breaks back into Conflicts?
[12:44] <Kamion> that's gnumeric, mozilla-firefox-locale-all, hplip
[12:47] <Kamion> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
[12:47] <Kamion> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
[12:47] <Kamion> dpkg: error processing cupsys-driver-gutenprint (--configure):
[12:47] <Kamion> ^-- breaks amd64 livefs build
[12:47] <Kamion>  subprocess post-installation script returned error exit status 1
[12:47] <Keybuk> mjg59: I'm not blacklisting it until X loads it
[12:47] <Keybuk> which it doesn't
[12:47] <Kamion> somebody else please fix
[12:47] <Kamion> I need to go home
[12:48] <Kamion> I've started live CD builds, which will presumably only be useful for amd64 and powerpc
[12:48] <Kamion> er, for i386 and powerpc, I mean
[12:49] <mjg59> Keybuk: Yes it does
[12:49] <mjg59> I've just tested it
[12:49] <Keybuk> mjg59: it doesn't here
[12:49] <Keybuk> I also just tested it
[12:50] <Keybuk> I get three flickers, and then a "X could not start"
[12:50] <mjg59> Keybuk: Did you blacklist nvidia and nvidia_legacy?
[12:50] <mjg59> Otherwise nvidia_legacy will get loaded and X will fail because of the ABI mismatch
[12:50] <Keybuk> I just rmmod'd the running one and started X
[12:50] <Keybuk> so no module was loaded
[12:51] <mjg59> Keybuk: I've just tested here with -10. It loaded nvidia.
[12:51] <mjg59> Does your system use nvidia or -legacy?
[12:51] <Keybuk> nvidia
[12:51] <mjg59> Ok
[12:51] <Keybuk> by what process does it load the module?
[12:51] <Kamion> I've uploaded that ubiquity change; somebody please accept it if it's ok
[12:52] <mjg59> Keybuk: I just did sudo rmmod nvidia; X
[12:52] <mjg59> And got running X
[12:52] <Keybuk> *tests again*
[12:52] <Keybuk> nope, still not starting
[12:52] <mjg59> I assume it uses the same mechanism that other drivers can use to trigger the loading of the DRM module
[12:52] <mjg59> Keybuk: What's the error?
[12:53] <Keybuk> Fatal server error:
[12:53] <Keybuk> Caught signal 11.  Server aborting
[12:53] <Keybuk> sweeeeeet
[12:53] <mjg59> Ha
[12:53] <mjg59> I think you have other problems
[12:53] <Keybuk> the unusual thing here is that there are two identical graphics cards in the machine
[12:53] <Keybuk> maybe the auto-loaded can't cope with that
[12:54] <mjg59> I can't see why it would make a difference
[12:54] <Keybuk> *shrug*
[12:54] <Keybuk> anyway I'm not going to blacklist nvidia
[12:54] <Keybuk> we can consider it for edgy+1
[12:54] <mjg59> Keybuk: I consider it somewhat less than ideal that we break suspend and resume for people because of a non-free driver that they may not even be using
[12:55] <Keybuk> suspend and resume are happy features that are nice if they work
[12:55] <mjg59> Keybuk: How about we blacklist by default and then document how to disable the blacklist in the same place that we document how to enable the nvidia driver?
[12:55] <Keybuk> X starting is a mandatory feature
[12:55] <mjg59> X starts out of the box
[12:55] <Keybuk> no, I'm not going to blacklist this by default this close to the release
[12:55] <Keybuk> let's consider this for edgy+1
[12:55] <Keybuk> we're about to make a beta release
[12:55] <Keybuk> now is not the time to start fiddling with hardware support
[12:56] <mjg59> Keybuk: This appears to be causing regressions
[12:56] <Keybuk> it's not causing regressions
[12:56] <Keybuk> because we loaded it by default in dapper too
[12:56] <mdz> Kamion: breaks into conflicts -> yes
[12:56] <mjg59> Keybuk: And the code has changed massively since then
[12:56] <mdz> Kamion: I looked at your diff but I'm afraid I would need to look at quite a bit more to understand the issue
[12:56] <mjg59> Code that we can't debug
[12:57] <mdz> mjg59: is it segfaulting after it has forked, or can we just check its exit code?
[12:57] <mjg59> mdz: usplash? After it's forked.
[12:57] <mjg59> Hm. I /think/.
[12:58] <Keybuk> mjg59: at this point suspend and resume are still mythical features that work if you're lucky
[12:58] <mjg59> Keybuk: They work on ~80% of laptop hardware
[12:58] <Keybuk> it seems better to document that blacklisting nvidia may help there, rather than "oh, if you want X to load, you'll need to remove this file"
[12:58] <mjg59> Keybuk: "If you want X to load after you've already rewritten your config file, you also need to edit this other config file"
[12:59] <mjg59> (Except that in my case, you don't even need to do that)
[01:00] <mjg59> mdz: Wait a sec. Usplash doesn't fork.
[01:00] <mjg59> mdz: So yeah, just check the return code and stick a chvt in the startup script?
[01:02] <mdz> mjg59: that will clean up even after svgalib borkage?
[01:03] <mjg59> mdz: Nope
[01:03] <mjg59> mdz: That's actually slightly difficult. We could hack something with vbetool.
[01:05] <mjg59> Keybuk: I've just straced my server startup - the driver checks /proc/modules (eww) and then execves modprobe
[01:06] <Keybuk> ahh
[01:06] <mjg59> Can you do an strace -f X and see what your one does when nvidia isn't loaded?
[01:06] <Keybuk> and modprobe will therefore obey the blacklist
[01:06] <Keybuk> so won't load the nvidia module
[01:06] <Keybuk> which is why X segfaults
[01:06] <Keybuk> ?
[01:07] <mjg59> Keybuk: if modprobe is explicitly called, the blacklist is ignored, no?
[01:07] <mjg59> I've got it blacklisted, but this still succeeds
[01:07] <Keybuk> varies
[01:07] <Keybuk> if an init script leaks MODPROBE_OPTIONS for example
[01:08] <Keybuk> though of course, I don't have it blacklisted here, so it's not that
[01:08] <mjg59> Keybuk: if I modprobe eth1394, I get eth1394 loaded
[01:08] <Keybuk> could be an honest race condition
[01:08] <mjg59> Mind doing the strace and seeing what happens?
[01:09] <Keybuk> whoah, that crashed the entire machine
[01:09] <Keybuk> hard reboot too
[01:09] <lifeless> bada-boom
[01:09] <Keybuk> mjg59: I'm *really* not comfortable about relying on this to be auto-loaded
[01:09] <Keybuk> I'm sorry
[01:10] <mjg59> Keybuk: And I'm *really* not comfortable with us screwing over people who aren't even using the driver
[01:10] <Keybuk> then you should have spoken up at the START of the release process
[01:10] <Keybuk> not this close to the end
[01:10] <mjg59> I only got the first bug about this last week
[01:10] <Keybuk> this will break people who upgrade
[01:10] <mjg59> I hadn't realised it was the default
[01:10] <Keybuk> it's always been the default
[01:10] <mjg59> Keybuk: It certainly hasn't. People used to need to add nvidia to /etc/modules
[01:11] <Keybuk> that was probably simply because we didn't have as reliable hardware detection as we do now
[01:11] <mjg59> nvidia only added modaliases to their drivers fairly recently
[01:11] <Keybuk> could be that too
[01:11] <Keybuk> fairly recently is still before dapper though
[01:11] <Keybuk> so dapper released like this
[01:11] <Keybuk> which means if we suddenly blacklist the module, it appears that many people's machines will begin crashing on upgrade
[01:11] <Keybuk> I'm totally not happy about that
[01:12] <Keybuk> maybe I'm jaded, but suspend is a "would be nice"
[01:12] <Keybuk> X is a "must have"
[01:12] <lifeless> you're jaded
[01:12] <LaserJock> totally
[01:12] <Keybuk> ok, just tested again
[01:13] <Keybuk> first time it actually did load the module
[01:13] <Keybuk> I rmmod'd, and restarted X
[01:13] <mjg59> Keybuk: But X works fine unless the user has enabled code we have no practical way to support
[01:13] <Keybuk> and that time X crashed
[01:13] <Keybuk> I'm going to try booting with the blacklist to see whether it's an rmmod problem
[01:13] <mjg59> Keybuk: So in your case, it could actually be that the module doesn't clean up after itself?
[01:13] <Keybuk> mjg59: so?  a lot of users are enabling this code
[01:13] <Keybuk> and we're planning on enabling it by default in edgy+1, apparently
[01:13] <mjg59> Keybuk: We *are*?
[01:14] <Keybuk> Mark *really* wants bling for edgy+1
[01:14] <mjg59> Mark can ask nvidia for the source, then
[01:14] <Keybuk> I believe Mark is
[01:14] <mjg59> Excellent
[01:14] <mjg59> When he gets it, I'll remove my objection to turning it on
[01:14] <Keybuk> no, crashed immediately on that reboot
[01:15] <Keybuk> checked, and it definitly was blacklisted and not in lsmod
[01:15] <mjg59> Keybuk: Can you power cycle?
[01:15] <Keybuk> mjg59: sure
[01:15] <mjg59> Rather than just warmbooting?
[01:15] <Keybuk> I'll leave it off for > 3 s :p
[01:17] <Keybuk> hard-lock up :-/
[01:17] <mjg59> Are these drivers made out of string, or something?
[01:17] <mjg59> Jesus
[01:17] <Keybuk> I'll try something
[01:17] <Keybuk> I'll lift one of the graphics cards out
[01:17] <mjg59> Keybuk: Ok
[01:18] <mjg59> Keybuk: Of course, an alternative would be to add an init script to nvidia-glx
[01:18] <Keybuk> this feels like a race condition between the module and the X server; which is scary enough in itsself
[01:18] <mjg59> Keybuk: That checks for the driver in use and then loads the module before X starts
[01:18] <mjg59> Basically, we just want the module load to be conditional on information that udev doesn't have
[01:18] <Keybuk> why not use a modprobe install rule?
[01:19] <mjg59> Sure, that would work
[01:19] <mjg59> We could do with a small tool that told us which driver was in use
[01:19] <mjg59> That would actually be useful for suspend/resume in any case
[01:19] <Keybuk> install nvidia grep 'Driver \"nvidia\"' /etc/X11/xorg.conf && module -Qb nvidia
[01:19] <Keybuk> or something
[01:19] <Keybuk> hmm
[01:19] <Keybuk> worked just fine with just the one in
[01:19] <Keybuk> let me try another restart
[01:20] <Keybuk> fine again
[01:20] <Keybuk> so an SLI-triggered bug
[01:20] <mjg59> nvidia = gash
[01:20] <mjg59> Can you give the modprobe rule a go?
[01:20] <Fade> better than ati. ;/
[01:21] <Fade> I have hopes that amd will cause ati to open their drivers, though.
[01:21] <Keybuk> I don't have any particular objection to the modprove rule
[01:21] <Keybuk> prove?  probe! :p
[01:21] <mjg59> Keybuk: Ok, that leaves me without any objections
[01:21] <mjg59> Keybuk: Needs to be done for nvidia_legacy as well
[01:21] <mjg59> And possibly fglrx
[01:22] <Keybuk> can you file a bug on module-init-tools to remind me?
[01:23] <mjg59> Will do
[01:24] <lifeless> with sli, are you not meant to load the driver just once ?
[01:24] <Keybuk> right
[01:25] <Keybuk> it has one Device section
[01:25] <lifeless> because its one card, honest.
[01:25] <Keybuk> and the PCIe id of the first card
[01:25] <Keybuk> it finds the second card because it's joined to the first one
[01:26] <Keybuk> I actually don't have it enabled on Linux
[01:27] <Keybuk> so in theory, the second graphics card sits there doing nothing
[01:41] <ogra> hmm, doesnt look like we'll see final isos tonight ...
[01:44] <ogra> mdz, do you plan to kick off alternate builds after ubiquity is done ? if so, could you also trigger edubuntu builds, so i can see if anything size wise changed right after i get up ?
[01:46] <keebler> Which one of you is Colin watson?
[01:47] <Fujitsu> Kamion.
[01:47] <keebler> Crap
[01:47] <keebler> Damn dentists.
[01:47] <ogra> he's gone for the day
[01:47] <keebler> Oh.
[01:51] <Keybuk> gone for the *night* would be better
[01:52] <Keybuk> even Colin has to sleep sometimes, to rest that planet-sized brain of his
[01:56] <ogra> right, and moving while releasing a beta is hard stuff
[02:13] <Seveas> keebler, you can backport it yourself. There will not be an official 256-color usplash for dapper
[02:15] <keebler> Seveas: Ok.
[02:15] <keebler> Heh, I don't suppose there is an FAQ to help me is there? 
[02:16] <keebler> I've only been using Ubuntu for 5 months. Was a BSD junkie for the last 8 years.
[02:22] <keebler> Seveas: Or a good start would be where can I aquire the usplash used in edgy?
[02:22] <Seveas> keebler, add a deb-src line for edgy to your sources.list and apt-get source usplash
[02:23] <ogra> keebler, there is the ubuntu packaging guide shipped in your docs and use the source Seveas just pointed out to build a backport
[02:23] <Seveas> or live on the bleeding edge and use the main bzr branch
[02:25] <mdz> ogra: yes, I do plan to do that
[02:26] <ogra> mdz, thanks then i'll get some hours of sleep now and check the isos tomorrow :)
[02:38] <bddebian> Heya
[03:25] <jdong_> what does nautilus-cd-burner use to burn data DVD projects?
[03:26] <jdong_> just straight growisofs -Z device <dir>?
[03:26] <desrt> E: Couldn't configure pre-depend belocs-locales-bin for locales, probably a dependency cycle.
[03:26] <desrt> nice!
[03:30] <Keybuk> jdong_: probably not
[03:30] <Keybuk> DVDs are quite complex
[03:30] <Keybuk> the isofs has some odd properties, iirc
[03:30] <jdong_> hmm
[03:30] <Keybuk> DVD players actually ignore the filesystem
[03:31] <Keybuk> instead they begin playing at particular blocks, and need padding for timing, etc.
[03:31] <jdong_> :-/
[03:31] <Keybuk> ffmpeg -i $INPUT -target pal-dvd -bf 2 $FILE.mpg
[03:31] <Keybuk> mplex -f 8 -o /dev/stdout background.m2v background.m2a | spumux -v 2 spumux.xml > background.mpg
[03:31] <Keybuk> dvdauthor -o $DVD -x dvdauthor.xml
[03:31] <Keybuk> mkisofs -dvd-video -o $DVD.iso $DVD
[03:31] <Keybuk> growisofs -Z /dev/hda=$DVD.iso
[03:31] <Keybuk> -- 
[03:31] <jdong_> hmm
[03:32] <Keybuk> is my "make a video DVD" recipie
[03:32] <jdong_> I've seen it just done with growisofs before
[03:32] <Keybuk> the -dvd-video switch to mkisofs is *very* important, it doesn't work on non-computers without it
[03:32] <jdong_> without mkisofs first...
[03:32] <jdong_> hmm
[03:32] <jdong_> well, better not to risk it
[03:32] <Keybuk> growisofs will call mkisofs if you give it a directory instead of a file
[03:32] <Keybuk> so you could do growisofs -Z /dev/hda -dvd-video $DVD
[03:33] <Keybuk> but I prefer having the iso to check as an intermediate step
[03:33] <jdong_> mmkay
[03:37] <moco> are there any reasons behind the entry 'evolution-2.2.desktop' still in /usr/share/applications whilst it does nothing but duplicate evolution.desktop? Is that some chance the team forgot to remove it when moving up to higher version of Evo?
[03:47] <LaserJock> moco: check out the last comment of bug 57628
[03:47] <Ubugtu> Malone bug 57628 in evolution "there are multiple menu entries for evolution in a new edgy install" [Wishlist,Confirmed]  http://launchpad.net/bugs/57628
[03:49] <moco> thx
[04:36] <mdz> Keybuk: oddly enough, growisofs -dvd-compat doesn't imply mkisofs -dvd-video
[04:39] <zul> wheee...xen from ubuntu-2.6 git works http://70.29.61.171/ubuntu/Screenshot-1.png
[05:10] <jdong_> mdz / Keybuk: right, -dvd-compat doesn't do the trick... In fact my dvd players don't care much about it, but mkisofs's -dvd-video switch is indeed essential.
[05:10] <jdong_> and indeed dragging some VIDEO_TS/AUDIO_TS into nautilus-cd-burner does not make a working dvd video disc
[05:11] <jdong_> zul: do you know if anyone's working on xen wrappers for fglrx or if that'll ever happen?
[05:11] <zul> jdong_: not sure for fglrx but nvidia yes..
[05:13] <jdong_> zul: right; I saw the work going into nvidia
[05:13] <jdong_> oh well....
[05:17] <fabbione> elmo: i am on it
[05:22] <fabbione> ok i see it has been done already
[05:24] <zul> night
[05:26] <fabbione> zul: night
[05:40] <fabbione> mdz: can i declassify #61861 as non beta blocker?
[05:41] <mdz> bug 61861
[05:41] <fabbione> mdz: it's basically a bug on dapper kernel that's triggered by ruby on ppc
[05:41] <Ubugtu> Malone bug 61861 in ruby1.8 "ruby1.8: fails to build on ppc under 2.6.15 kernel" [Medium,Confirmed]  http://launchpad.net/bugs/61861
[05:41] <mdz> fabbione: if it's able to build after elmo's changes, then yes
[05:41] <mdz> it was only a blocker because of the build failure
[05:41] <fabbione> it has been fixed upgrading to .17 davis and buildd
[05:41] <fabbione> yeah exactly
[05:41] <fabbione> it's not an issue anymore
[05:42] <fabbione> see RT #16838 too
[05:43] <fabbione> mdz: demoted
[05:43] <mdz> thanks
[05:43] <fabbione> no problem
[05:43] <fabbione> i guess the 2 sparc kernel bugs will wait after beta..
[05:45] <fabbione> mdz: bug #62485 is worth a ReleaseNote
[05:45] <Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  http://launchpad.net/bugs/62485
[05:45] <fabbione> (beta)
[05:45] <fabbione> basically they need a new OBP
[05:45] <fabbione> (BIOS)
[05:48] <mdz> fabbione: ->Mithrandir
[05:49] <fabbione> oky
[06:02] <bluefoxicy> has anyone noticed there's a voice print recognizer for pam (but it's defunct?)
[06:02] <bluefoxicy> I was thinking, cheap biometric authenticator
[06:04] <jldugger> "my voice is my passport" ;)
[06:06] <HrdwrBoB> verify me
[06:06] <bluefoxicy> it was speaker, password, and password length sensitive
[06:06] <bluefoxicy> I don't get the last two
[06:07] <bluefoxicy> you're speaking your password, those aren't secure variables.
[06:07] <bluefoxicy> The first is, until someone records you.
[06:08] <jldugger> id just be happy if my fingerprint reader worked
[06:09] <jldugger> there's a pam module for that too, and its not defunct, but its been sitting in debian's wnpp for over a year i believe
[06:09] <bluefoxicy> I'd honestly love a secure client-server signature verification mechanism.
[06:09] <bluefoxicy> handshake would be like
[06:10] <bluefoxicy> you have a GPG key, the authenticator has your UID, username, GPG key ID and fingerprint
[06:11] <bluefoxicy> (your username may or may not be an identifier on your gpg key; in general I fancy e-mail address but for most systems where you have to be a user of the system a particular user name is more secure)
[06:11] <bluefoxicy> authenticator says, "Who are you?  Jakub?  OK here's 1024 bytes of shit, sign it for me."
[06:11] <bluefoxicy> if it doesn't know who the hell Jakub is it just discards the signature and says "Nope don't think you fit in"
[06:11] <bluefoxicy> if jakub's signature is wrong it does same
[06:12] <bluefoxicy> if Jakub is a user; it can locate his key; the finger print matches; and Jakub's signature response is good; it allows Jakub to log in.
[06:13] <bluefoxicy> the 1024 bytes of junk is RANDOM and the GPG key is established through PKI or PSK depending on need so replay attacks, MiMs, and all kind of other stupid crap don't work
[06:14] <bluefoxicy> jldugger:  there's a GPG key PAM module but I think it works like "Verify my password really unlocks my private key," which to me looks like "open a goatse-wide security hole in the trust model of this system"
[06:14] <jldugger> i really dont know a lot about pam or gpg
[06:16] <bluefoxicy> I really need to learn to write pam modules that don't suck
[06:17] <bluefoxicy> it was my intent to write a pam module that enforced hold timing of log-ins
[06:17] <bluefoxicy> that is, you log in on TTY1, fail, "wait 3 seconds" no screw that log in on TTY 2 and you're on by the time you time out
[06:17] <bluefoxicy> same with ssh, 300 concurrent connections and only 1 has to hit, 3 seconds.
[06:18] <bluefoxicy> what I want is that 3 seconds is applied across the board except for at the console
[06:18] <bluefoxicy> if you try again, we don't even check your password; we just delay and go "Nope don't know who you are"
[06:19] <HrdwrBoB> bluefoxicy: that would piss me off no end
[06:19] <bluefoxicy> (when 3 months YOU spend brute forcing a 3 character long alphanumeric password, look as l33t, you will not)
[06:20] <bluefoxicy> HrdwrBoB:  in the worst case you could DoS external connections over ssh
[06:20] <HrdwrBoB> you're erring too far on the security vs ease of use
[06:20] <bluefoxicy> but you would have to know the username you're attacking
[06:20] <bluefoxicy> trying to log in as bauoseu is going to lock out... well nothing, that user doesn't exist on any sane system
[06:20] <bluefoxicy> HrdwrBoB:  I said on the console it would allow it
[06:21] <HrdwrBoB> yeah, but people often get their passwords wrong
[06:21] <HrdwrBoB> even via ssh
[06:21] <bluefoxicy> sit your ass in front of the machine and log into gnome and you're good to go even if you're under attack and the attacker is failing at your user account
[06:21] <bluefoxicy> yes but on ssh the single ssh connection you make waits 3 seconds now
[06:21] <bluefoxicy> and then says "failed to authenticate"
[06:22] <bluefoxicy> if you can type really, really fast you can start another ssh session and get logged in within that 3 seconds
[06:22] <bluefoxicy> more usefully, an attacker can make 30 ssh connections at once and launch attacks in parallel; and if he can do 30 at once x 10 times a second, that's 300 attacks a second
[06:22] <HrdwrBoB> 300/s is SFA
[06:23] <infinity> So, you basically just want PAM locking. That sounds trivial to implement.
[06:23] <bluefoxicy> it's highly unlikely you're actually going to be dumb and spend hours trying to ssh in
[06:23] <bluefoxicy> when the solution is "hold on for 3 seconds"
[06:23] <jdong_> bluefoxicy: I doubt you can do parallel SSH brute forcing with decent efficiency
[06:23] <bluefoxicy> especially since you have to willfully kill/restart the ssh client or use another terminal to ssh in real fast to make the window (as I said, ssh does make you wait when you get it wrong)
[06:24] <infinity> jdong_: It gets attempted on my machines several times weekly.
[06:24] <bluefoxicy> jdong_:  as do I; but I prefer "I can guarantee" to "I doubt"
[06:24] <infinity> jdong_: To the point of saturating my DSL sometimes.
[06:24] <jdong_> infinity: wow... that's phenomenal indeed... my ssh has remained relatively unattacked
[06:24] <bluefoxicy> infinity:  yeah, I tried based on pam-audit and failed hard
[06:26] <infinity> bluefoxicy: Check for lockfile, spin until lock released.  Stack pam_foreground appropriately to bypass your pam_locking for foreground console users.
[06:26] <jdong_> umm, why doesn't the linux-server metapackage pull in the latest  kernel?
[06:27] <bluefoxicy> yeah
[06:27] <infinity> jdong_: Does for me.
[06:28] <jdong_> oh hah
[06:28] <jdong_> silly me
[06:34] <bluefoxicy> ugh. Malone 17297 is annoying.
[06:34] <Ubugtu> Malone bug 17297 in synaptic "Orphan Search" [Wishlist,Needs info]  http://launchpad.net/bugs/17297
[06:36] <bluefoxicy> I'm beginning to think I'm actually the only person in the universe that ever actually cleans old packages off his disk
[06:37] <bluefoxicy> (no, the auto-removable packages stuff is NOT doing it for me, I've cleaned out all its suggestions already)
[06:37] <LaserJock> bluefoxicy: I just reinstall ;-)
[06:37] <bluefoxicy> LaserJock:  I try to avoid rebooting
[06:38] <LaserJock> haha
[06:38] <bluefoxicy> LaserJock:  speaking of reinstall did I ever file a bug or spec out "Wipe everything on target / except /home during reboot"?
[06:38] <bluefoxicy> since everyone absolutely refuses to isolate /home from /
[06:38] <bluefoxicy> and some people have 350 gigabytes of /home
[06:38] <LaserJock> seems like you did
[06:38] <LaserJock> can't remember exactly though
[06:39] <bluefoxicy> "oh just burn it to {CD,DVD}" I HAVE A HUNDRED GIGS.  TWENTY FIVE DVDS.  The stock answers I get are totally annoying.
[06:39] <LaserJock> hmm, I just back it up since I want to wipe the drive anyway
[06:40] <lifeless> this machine has been upgraded all the way from debian 3.0
[06:40] <bluefoxicy> (by the way I filled up / on a system; it stops booting, rescue mode barely works, I had to use a livecd)
[06:40] <bluefoxicy> I suppose it doesn't help that I have corrupt packages installed
[06:40] <bluefoxicy> since it filled up WHILE upgrading to edgy
[06:40] <bluefoxicy> /var/cache/apt/packages was HUGE
[06:41] <LaserJock> lifeless: my installs usually last a couple months max
[06:41] <fabbione> tfheen: i assigned bug #62485 to you because it's a BIOS/OBP bug that's triggered by edgy kernel and people must upgrade their OBP. It's worth a release note in that regard.
[06:41] <Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  http://launchpad.net/bugs/62485
[06:41] <LaserJock> too much testing to do
[06:41] <lifeless> LaserJock: just means we're testing things
[06:41] <bluefoxicy> IIRC the OSDL 1.2 docs for what an enterprise data center requires for package management include rollbacks (RPM has these, debs seem to be "uninstall and reinstall the old version if necessary") and some sort of efficient parallel install?
[06:42] <bluefoxicy> I'm not sure on the parallel install
[06:42] <bluefoxicy> but I still want to say
[06:42] <lifeless> like, how many hours uptime before dapper shits itself again and hangs on resume from sleep ?
[06:42] <bluefoxicy> download X packages, get started installing while the other packages are downloading, as you finish installing DELETE the downloaded packages
[06:42] <bluefoxicy> minimal disk usage the whole way
[06:43] <bluefoxicy> lifeless:  during the breezy development era, I was running breezy-dev
[06:43] <bluefoxicy> I had started 20 days prior on Hoary
[06:43] <LaserJock> bluefoxicy: I like keeping them around personally
[06:43] <bluefoxicy> upgraded to breezy and tracked it every day
[06:43] <bluefoxicy> gnome broke
[06:43] <fabbione> bluefoxicy: that doesn't work if one of the X packages Depends on a new version of something you are downloading in parallel
[06:43] <bluefoxicy> I moved to twm, installed icewm, moved to that
[06:43] <fabbione> like a postinst script or something along that line
[06:44] <bluefoxicy> on the 100th day, with a barely functional system, I claimed victory, updated, rebooted, and everything started working again
[06:44] <bluefoxicy> (gnome had been refusing to work, a reboot fixed it, wtf this isn't windows)
[06:45] <fabbione> brb
[06:45] <bluefoxicy> lifeless:  point is, if you have to measure dapper stable uptime before it hirakaris in HOURS, something's wrong
[06:45] <bluefoxicy> this isn't Windows ME
[06:45] <lifeless> bluefoxicy: its measurable in number of suspend-resumes rather than hours of runtime
[06:46] <bluefoxicy> (other point, I'm insane, bored, and abuse my system regularly.  Also I'm playing through Zelda on my modded NES without a sword)
[06:47] <bluefoxicy> um um um.  I'm out of stuff to talk about help.
[06:47] <jdong_> now, time to replicate teardown and backport readahead-list to my dapper boxes....
[06:47] <bluefoxicy> ok so the other day, somebody asked me how to license his software under LGPL.  He wanted to know if he had to register it somewhere or something
[06:47] <jdong_> and then downgrade my primary laptop to dapper again :-/
[06:48] <bluefoxicy> teardown and readahead-list?
[06:48] <infinity> bluefoxicy: You know, when you run out of things to say, it's customary to stop speaking.
[06:48] <bluefoxicy> they're not getting backported to dapper are they?
[06:48] <jdong_> bluefoxicy: not in official backports, of course not
[06:48] <jdong_> but it's handy for my laptop
[06:49] <bluefoxicy> ah o.o
[06:49] <jdong_> I've found that edgy's startup/shutdown times are so good I have no reason to use suspend/hibernate anymore
[06:49] <LaserJock> infinity: heh
[06:49] <jdong_> it takes around 15 seconds for my modified edgy to get to a login screen
[06:49] <jdong_> and around the same amount of time to go down
[06:49] <bluefoxicy> jdong_:  my laptop is being weird
[06:49] <jdong_> if I can optimize my dapper to that point, then I win :)
[06:49] <bluefoxicy> edgy is having a hard time booting except for on 2.6.17-9-386 (generic hangs)
[06:50] <bluefoxicy> when it does boot, it goes from usplash to gdm in under 5 seconds
[06:50] <bluefoxicy> I don't even see the progress bar start to fill up, it's just like "Loading--oshit nm I guess it's time to log in"
[06:50] <jdong_> wow, you must have really nice hardware then
[06:50] <bluefoxicy> it normally takes kind of long, I have an HP zv5405us laptop
[06:51] <jdong_> the bulk of my 15 seconds is readahead, the rest is waiting for modprobe or switching resolution
[06:51] <bluefoxicy> nothing spectacular
[06:51] <bluefoxicy> it just goes
[06:51] <jdong_> and I can't seem to optimize it much more than that :)
[06:51] <jdong_> short of doing something silly, of course
[06:51] <bluefoxicy> Maybe it's all the times I've hard-poweroff'd it, it may have gotten damaged.  Damage causes mutation, favorable mutations cause evolution.  My laptop is evolving?
[06:52] <jdong_> lol
[06:52] <bluefoxicy> jdong_:  I want to know if hotplug ever got fixed
[06:52] <bluefoxicy> daveyj kind of slapped them, cups, X, etc etc etc around with a large trout.
[06:52] <jdong_> what's wrong with hotplug now?
[06:53] <bluefoxicy> um.  Doing about 5000 opens, most of them on the same files, on files about hardware that's not in the machine nor will ever be IIRC
[06:53] <bluefoxicy> opening, reading, and closing the same XML files over and over and over again...
[06:53] <lifeless> bluefoxicy: sounds like it has evolved
[06:54] <jdong_> heh
[06:54] <bluefoxicy> CUPS apparently loads every driver for every printer in existence
[06:54] <bluefoxicy> as in it actually opens every file and reads them all
[06:54] <bluefoxicy> and X likes to probe for hardware that "clearly doesn't exist" on ISA ports that "clearly aren't on the system" or something
[06:55] <bluefoxicy> the devs were in the room when he was giving his presentation, it was lol
[06:55] <bluefoxicy> why am i still talking
[06:55] <lifeless> because
[06:55] <bluefoxicy> is this like OCD or something
[06:56] <tfheen> fabbione: sure.  Can you write me a blurb?
[06:56] <jdong_> bluefoxicy: have you taken your medication today?
[07:00] <fabbione> tfheen: sure... 
[07:00] <tfheen> bluefoxicy: hotplug was removed from the archive ages ago.
[07:01] <bluefoxicy> tfheen: ?  how in the...
[07:02] <bluefoxicy> isn't that kind of required for a functional system?
[07:02] <tfheen> bluefoxicy: no, it's not.
[07:02] <bluefoxicy> I thought it governed firmware loading and automagical pmount of USB drives
[07:03] <tfheen> udev for the former, gnome-volume-manager for the latter.
[07:03] <tfheen> but this is offtopic here.
[07:04] <bluefoxicy> I know; even when I'm actually contributing something useful I'm offtopic
[07:07] <jdong_> something useful being additional scrollback for devs to read through?
[07:07] <jdong_> :)
[07:07] <fabbione> tfheen: added to the bug.. you might want to check for itaglish/english.. but otherwise that's what i think we should slam there
[07:08] <tfheen> fabbione: ok, thanks.
[07:14] <tfheen> sfllaw: around?
[07:17] <tfheen> mgalvin: hi, does the docteam have any particular place they want release notes in?
[07:18] <mgalvin> tfheen: hey, not that I know of ATM, i haven't really been active for a little while, it may be best to ask in -doc, someone may know
[07:18] <tfheen> mgalvin: 'k, thanks.
[07:18] <mgalvin> np
[07:20] <tfheen> Burgundavia: yo, do you know the answer to ^^ ?
[07:40] <bluefoxicy> ugh I'm still banned from #-offtopic
[07:55] <Burgundavia> tfheen: the release docs are being done on the wiki, but I am currently travelling and thus have not been able to complete them
[07:56] <Burgundavia> tfheen: if they are done, they can be moved to teh ubuntu website
[07:57] <Burgundavia> tfheen: somebody else started https://wiki.ubuntu.com/EdgyEft/Beta
[07:57] <tfheen> Burgundavia: release docs != release notes.  Release notes are typically "this bit is broken", "to work around this issue, upgrade $foo", etc.
[07:57] <tfheen> Burgundavia: also, whom should I talk to given that you're travelling?
[07:58] <Burgundavia> tfheen: for the notes, we have been letting the devel team deal with it. I believe the dapper ones were kept on the wiki, but mdz is the better person to ask
[07:58] <Burgundavia> as for the docs, I have asked but nobody has taken it up
[07:59] <tfheen> ok..
[08:01] <mdz> generally they go in the wiki, with contributions from the development team, the doc team and random folk from Canonical and elsewhere
[08:01] <tfheen> mdz: /Beta/ReleaseNotes would work as an URL, or do we have a scheme already?
[08:02] <mdz> tfheen: the existing scheme is AdjectiveReleaseNotes
[08:02] <tfheen> ok
[08:02] <mdz> tfheen: the current set of ubuntu/kubuntu/edubuntu alternate/desktop should all have the ubiquity update which was the outstanding bit
[08:02] <tfheen> mdz: should have as in "have already" or "needs rebuild"?
[08:03] <mdz> tfheen: as in, I triggered them at a time when they ought to have the right bits, but I haven't verified it
[08:03] <tfheen> ok, thanks.
[08:03] <tfheen> I'll poke it.  I'm a tad slow today due to headache and such, but I'll cope.
[08:03] <infinity> Except all the amd64 livefs builds failed.
[08:04] <infinity> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
[08:04] <infinity> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
[08:04] <infinity> dpkg: error processing cupsys-driver-gutenprint (--configure):
[08:04] <infinity>  subprocess post-installation script returned error exit status 1
[08:05] <infinity> tfheen: Can you reproduce that on a local amd64 box?
[08:05] <infinity> tfheen: All the amd64 livefs builds failed with that.
[08:05] <tfheen> infinity: I'll poke it
[08:05] <infinity> I need to buy a new one.
[08:06] <tfheen> deboostrap takes a tad of time here
[08:06] <infinity> Yeah, that's why I always keep clean chroots on my laptop.
[08:06] <tfheen> you're clearly cleverer than I.
[08:31] <pitti> Good morning
[08:32] <pygi> morning pitti 
[08:37] <Hobbsee> hey pitti 
[08:47] <sivang> morning
[08:48] <pygi> hey ho sivang :)
[08:50] <sivang> yo pygi 
[08:58] <dholbach> good morning - HAPPY HUG DAY!
[09:00] <Burgundavia> morning sivang, dholbach
[09:03] <dholbach> hi Burgundavia
[09:21] <mvo> infinity: can you please give-back synaptic?
[09:22] <sivang> hi Burgundavia , dholbach , mvo , pitti 
[09:24] <sivang> I'm getting Ign on all the translated package info when apt-get update'ing, known or recently dropped ?
[09:24] <pitti> hi sivang 
[09:27] <mvo> sivang: maybe your language is not translated yet :)
[09:29] <sivang> mvo: Ign http://archive.ubuntu.com edgy/main Translation-en_GB <== using en_GB ;-)
[09:31] <tfheen> mvo: given back
[09:31] <mvo> tfheen: thanks!
[09:40] <fabbione> hey sharms 
[09:40] <fabbione> feh
[09:40] <fabbione> hey shawarma 
[09:41] <shawarma> fabbione: Hi, there.
[09:43] <shawarma> fabbione: Is the wife going to let you go to UDS this time?
[09:45] <fabbione> shawarma: yeah.. she will try to let me go
[09:46] <pitti> mvo: can g-a-i or synaptic display a list of all installed packages which are unsupported?
[09:47] <mvo> pitti: synaptic can, the easiest way is to click on "status", "Installed" and then sort by the Status column of the tree (the little "S")
[09:47] <mvo> eh
[09:47] <mvo> pitti: make that the second column
[09:47] <mvo> the one with the ubuntu logo
[09:49] <shawarma> fabbione: Coolness. I'm hoping to go this time as well, although it's a quite a bit more expensive trip.
[09:49] <fabbione> shawarma: yeah i know
[09:51] <slytherin> Can anyone please tell me how can I apply for a mailing list for a l10n team?
[09:54] <carlos> slytherin: try mailing to mailman-owner@lists.ubuntu.com
[09:55] <carlos> LaserJock: ping
[09:55] <LaserJock> carlos: yeah?
[09:55] <carlos> LaserJock: hi, I saw the upload of .pot files for Ubuntu documentation
[09:56] <carlos> LaserJock: but I need to know whether I should just approve the .pot files or if you need any adjustment on what we have already imported since Dapper
[09:56] <carlos> (template renames/splits/removals)
[09:56] <LaserJock> ah yes
[09:57] <carlos> so we don't create new unneeded templates 
[09:57] <LaserJock> how can I find out what you have now?
[09:58] <carlos> LaserJock: this is what we have right now:
[09:58] <carlos> https://launchpad.net/distros/ubuntu/edgy/+source/xubuntu-docs/+translations
[09:58] <carlos> https://launchpad.net/distros/ubuntu/edgy/+source/ubuntu-docs/+translations
[09:58] <carlos> https://launchpad.net/distros/ubuntu/edgy/+source/kubuntu-docs/+translations
[09:58] <carlos> https://launchpad.net/distros/ubuntu/edgy/+source/edubuntu-docs/+translations
[09:59] <carlos> it comes from Dapper
[09:59] <LaserJock> k
[09:59] <carlos> and I think mdke told me that we would need to remove/rename some of them
[10:02] <mdz> tfheen: any luck with the livefs bulid failures?
[10:03] <carlos> slytherin: sorry, I gave you the wrong address, send an email with your request to mailman@lists.ubuntu.com
[10:05] <slytherin> carlos: Is it automated response kind of thing? Or the replies are sent by any person?
[10:05] <carlos> slytherin: by our admins
[10:05] <slytherin> carlos: Ok. Thanks.
[10:05] <carlos> not sure if they have it redirected to a ticket system
[10:05] <carlos> but anyway, they should answer you
[10:07] <tfheen> mdz: no, my test failed with a different error, but I suspect that was because I forgot to mount /proc
[10:20] <mdz> tfheen: it seems likely to be a broken pipe issue
[10:20] <mdz>         close GENPPD or die "can't close cups-genppd pipe: $!";
[10:20] <mdz> GENPPD is the read end of a pipe
[10:21] <mdz> that script hasn't changed in ages of course, and there's no reason it should fail consistently on amd64
[10:21] <mdz> infinity: only adm64 failed, but all derivatives?
[10:25] <mdz> tfheen: meanwhile, please get folks started on testing the architectures which are up to date.  sfllaw,
[10:25] <tfheen> mdz: willdo
[10:25] <mdz> tfheen: when he wakes, should have testing facilities ready to go
[10:26] <mdz> in montreal
[10:26] <tfheen> goodie
[10:26] <tfheen> mdz: did you build DVD images too?
[10:26] <mdz> tfheen: no, I didn't
[10:26] <tfheen> I'll do that, then
[10:27] <mdz> I didn't build xubuntu either
[10:27] <mdz> or server
[10:27] <tfheen> ok, doing those too, then
[10:28] <mdz> I built alternate and desktop for ubuntu, kubuntu, edubuntu
[10:31] <Hobbsee> hey sabdfl 
[10:33] <LaserJock> heh
[10:33] <LaserJock> self-appointed benevolent dictator for life
[10:33] <LaserJock> perhaps the spelling is right
[10:34] <`anthony> self-appointed or south african?
[10:35] <Hobbsee> self appointed
[10:35] <realist> Speaking of which, I'm going to Cape Town in Janurary, can't wait!
[10:49] <ogra> was the cupsys breakage fixed ? i see no upload on -changes 
[10:49] <ogra> pitti, tkamppeter ^^^ ?
[10:49] <pitti> ogra: cupsys breakage?
[10:49] <pitti> ogra: I only fixed the dapper update breakage recently
[10:49] <ogra> pitti, the postinst error we discussed yesterday
[10:50] <ogra> it breaks the installer
[10:50] <pitti> ogra: I don't remember a discussion about cupsys postinst 
[10:50] <ogra> meh
[10:50] <pitti> well, I do remember a gutenprint discussion vaguely
[10:50] <ogra> we discussed it for 30 min or so
[10:50] <ogra> right
[10:50] <tfheen> pitti: take a look at http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/20060927/livecd-20060927-amd64.out
[10:50] <ogra> cupsys-driver-gimpprint tris to gnerate ppds
[10:50] <ogra> *tries
[10:50] <ogra> and fails
[10:51] <tfheen> Setting up cupsys-driver-gutenprint (5.0.0-2ubuntu1) ...
[10:51] <tfheen> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
[10:51] <tfheen> dpkg: error processing cupsys-driver-gutenprint (--configure): subprocess post-installation script returned error exit status 1
[10:51] <tfheen> is the error
[10:51] <ogra> tfheen, yes, that one
[10:51] <ogra> thanks :)
[10:51] <pitti> tkamppeter: hm, what was the result of that discussion?
[10:51] <mvo> Kamion: could you please approve my dist-upgrader upload?
[10:52] <ogra> pitti, iirc he said we could make it a no-op i the case there are no queues set up (i.e. in a fresh install)
[10:56] <mdz> mvo: what's in it?
[10:56] <mdz> (we are in beta freeze)
[11:00] <mvo> mdz: the dist-upgrader tarball that revert the "Breaks" changes (ie it does not download any backports). it also has a special case handling for the packages with the Breaks field (just ensuring that if they were installed, they will be kept installed)
[11:00] <mdz> mvo: I just finished building CDs :-/
[11:00] <mvo> mdz: *argh* :( sorry
[11:01] <mdz> mvo: we hadn't talked about the latter part
[11:01] <mvo> mdz: about the special case for the packages that used to use Breaks? I though we did
[11:01] <mdz> mvo: surely there wouldn't be any packages with Breaks, since we didn't use it in dapper
[11:02] <ogra> mdz, pkgsel fails anyway unless the cupsys-driver-gutenprint postinst is fixed
[11:02] <mdz> mvo: oh, the packages that once used breaks, but no longer do
[11:02] <mvo> mdz: yes. 
[11:02] <mdz> ogra: not everywhere
[11:02] <mdz> apparently the livefs build succeeded except on amd64
[11:02] <ogra> well, alternate (thus edubuntu) fails completely
[11:03] <Riddell> mdz: could you give back koffice on ppc
[11:03] <mdz> mvo: please mail me a diff
[11:03] <tfheen> ogra: for i386 and ppc too?
[11:04] <mdz> Riddell: done
[11:04] <ogra> tfheen, pkgsel exits  ... i didnt test ppc yet, but i assume its the same there
[11:06] <ogra> (which leaves you with an unconfigured grub)
[11:09] <Bazzi> hi :)
[11:09] <Bazzi> doko_: ping
[11:13] <mvo> mdz: send
[11:15] <ogra> tfheen, mdz, http://people.ubuntu.com/~ogra/cupsys-driver-gutenprint.postinst vs http://people.ubuntu.com/~ogra/cupsys-driver-gutenprint.postinst.quickfix ... would that be ok with you ?
[11:15] <tfheen> ogra: diff, please?
[11:15] <mdz> ogra: I don't see the difference
[11:15] <ogra> (i just added two || true to make it fail less evil)
[11:16] <tfheen> root@vawad:/# /usr/sbin/cups-genppdconfig.5.0 -u
[11:16] <tfheen> cups-genppd: Unable to create file "/usr/share/ppd/gutenprint/5.0/en/stp-bjc-30.5.0.ppd.gz" - No such file or directory.
[11:16] <mdz> ogra: the script is bailing out; it's not at all clear that it has finished doing its work
[11:16] <tfheen> can't close cups-genppd pipe:  at /usr/sbin/cups-genppdconfig.5.0 line 418.
[11:16] <Kamion> mdz: a dist-upgrader update won't require livefs rebuilds, at least, and those are the slow bits
[11:17] <ogra> mdz, it cant finish ... it needs a set up printer queue to finish at all according to tkamppeter 
[11:17] <mdz> ogra: that seems unlikely
[11:17] <ogra> thats what he said yesterday
[11:17] <mdz> otherwise it would have failed on upgrade for every user without a printer queue set up
[11:18] <tfheen> mkdir /usr/share/ppd/gutenprint/5.0/en/ fixes it for me.
[11:18] <tfheen> can somebody verify that?
[11:18] <ogra> tfheen, even in a norwegian locale ? 
[11:18] <tfheen> ogra: in a clean chroot without any locale params set.
[11:18] <ogra> ah, k
[11:19] <ogra> seems it only generates them in /en here as well
[11:20] <fabbione> tfheen: sparc-server CD has kernel module mistmatch...
[11:20] <fabbione> tfheen: did somebody updated the seeds?
[11:20] <tfheen> fabbione: gnr.
[11:20] <fabbione> (for -10- that's it)
[11:20] <tfheen> fabbione: I don't touch your seeds.
[11:20] <mdz> mvo: this diff is 22k
[11:20] <fabbione> tfheen: server is in the normal seed.. i don't touch them either
[11:21] <mvo> mdz: a lot of it is mo-file change (because the translations were rebuild and the update to the demotions.cfg file). the actual source changes are much much smaller
[11:22] <fabbione> tfheen: probably Kamion did always fix them in background because i never had to put my hands there
[11:22] <tfheen> fabbione: if you could just Get It Fixed, I'd appreciate.  I'm trying to fix the gutenprint b0rkage.
[11:22] <ogra> tfheen, hmm, the /usr/sbin/cups-genppdconfig.5.0 seems to create it at the very top ...
[11:23] <ogra> hah, no its doesnt :)
[11:23] <ogra> it needs to be called with -d -u
[11:23] <ogra> tfheen, could you try that in your chroot ?
[11:23] <Kamion> I didn't fix them last night ...
[11:23] <Kamion> let me check
[11:23] <Kamion> if they aren't done, I'll do them and respin
[11:23] <mdz> mvo: I can't possibly look at this and say that it's correct
[11:24] <tfheen> ogra: it won't help.  It doesn't create the subdirs.
[11:24] <mdz> mvo: which is the level of certainty that we need to have the day before a major release
[11:24] <fabbione> Kamion: thanks, i would love if you could that
[11:24] <Kamion> yep, nobody fixed the seeds
[11:24] <tfheen> Kamion: thanks.
[11:24] <ogra> ah, crap ...
[11:25] <Kamion> won't take long to sort out
[11:26] <fabbione> Kamion: thanks dude
[11:26] <tfheen> I wonder why the cupsys problem doesn't bit us on i386 though
[11:26] <ogra> it does here
[11:27] <ogra> i cant install amd64 or i386 alternate
[11:27] <mdz> mvo: and there are changes in here not even described in the changelog
[11:30] <Riddell> Kamion: looks like a couple of errors creating the alternate ppc kubuntu cds, "cat: /srv/cdimage.no-name-yet.com/debian-cd/data/edgy/yaboot/yaboot.conf.server: No such file or directory" and "cp: cannot create directory `powerpc/cdrom': Permission denied"
[11:30] <Kamion> ok, thanks, I'll check that out
[11:30] <Kamion> first is definitely my fault
[11:31] <tfheen> the latter is probably that ppc gets unhappy when you run it as your own user.  The group for the kernels and such is then wrong and the cron scripts become unhappy
[11:31] <mvo> mdz: let me create a new diff that removes the special handling of the breaks, translations and the fixes in aptsources.py. those are not critical. 
[11:31] <tfheen> s/ppc/ppc build/
[11:32] <Kamion> yeah, let me do the alternate builds and I'll clean them up
[11:32] <mdz> mvo: why is the demoted.cfg update so large?
[11:32] <Kamion> I must fix that group bug at some point
[11:32] <mdz> mvo: had it not been updated since dapper?
[11:33] <Kamion> isn't the Breaks handling the critical bit? or did I misread?
[11:33] <mvo> mdz: effectively yes, my bad
[11:34] <mdz> Kamion: the breaks issue is multifaceted
[11:34] <mvo> Kamion: I did add some code to special case the packages that used to use breaks but now use conflicts. that one can be taken out and we just hope that apt gets it right
[11:35] <mdz> Kamion: in the last update a bunch of new code was added to use backported packages to handle the breaks
[11:35] <mdz> Kamion: that's being reverted, which is the important bit
[11:35] <Kamion> right
[11:36] <ogra> grmbl ... tfheen it sets the default language several times in /usr/sbin/cups-genppdconfig.5.0, so i wonder why it doesnt work :/
[11:38] <tkamppeter> ogra, I did not say that the script needs a print queue to work, I said that the script updates existing print queues. So it is only needed to be run when print queues can be there. In situations which can never have print queues, like install on virgin partition, one coukld simply omit running it.
[11:39] <ogra> tkamppeter, so a check if the directory exists in the packages postinst would suffice ? 
[11:39] <tfheen> tkamppeter: is there a reason why /usr/share/ppd/gutenprint/5.0/en/ isn't shipped in the .deb?
[11:39] <ogra> its created dynamically ... you can specify different language dirs ...
[11:39] <ogra> /usr/sbin/cups-genppd.5.0 does that it seems
[11:40] <mvo> mdz: does this http://people.ubuntu.com/~mvo/tmp/20060927.1137.diff look more appropriate?
[11:40] <ogra> (or doesnt in our case, wich i would see as the real bug here)
[11:40] <tkamppeter> tfheen: This is strange, as the PPDs shipping with gutenprint are exactly in this directory.
[11:42] <tfheen> tkamppeter: which package?
[11:42] <ogra> the perl script (cups-genppdconfig.5.0) does everything right and sets the defaults, but cups-genppd.5.0 seems not to pick up these settings 
[11:42] <mdz> mvo: perfect
[11:43] <tfheen> tkamppeter: it seems to me there are no included ppds from the build of the gutenprint package
[11:43] <tkamppeter> tfhenn: cupsys-driver-gutenprint
[11:43] <ogra> tkamppeter, if i add a test for that dir to avoid running cups-genppdconfig.5.0, would the ppds ever be created after install ? 
[11:44] <ogra> (is it run if i add a printer or something like that ?)
[11:44] <tkamppeter> tfhenn: Perhaps they are generated by the postinst script (and this must be done also when there is no print queue)
[11:45] <tkamppeter> In Mandriva I get the PPDs when the package is built (by make), but in Ubuntu it seems that the PPD building by 'make' is suppressed and postponed to the postinst script.
[11:46] <tkamppeter> So Mandriva's postinst script only updates queues.
[11:46] <ogra> hmm, what is gutenprint-locales ??
[11:46] <tfheen> tkamppeter: (you're consistently spelling my nick incorrectly, so I don't get any highlights.)  Would there be any downside to just shipping /usr/share/ppd/gutenprint/5.0/en/ in the package?  If not, I'll just add that.
[11:46] <tkamppeter> This means that in Ubuntu we must assure that the postinst script is always executed correctly.
[11:47] <Kamion> that's true anyway :)
[11:47] <Kamion> postinst script failures always cause the package to fail to install
[11:47] <Kamion> rebuilding alternate CDs now, with the right kernel this time
[11:47] <Fade> has anybody else here noticed serious breakage in xemacs and gnuemacs?
[11:47] <Fade> I'm on a powerpc box, but it seems like it's probably sort of endemic.
[11:48] <tkamppeter> tfheen, go ahead and add it (or mkdir ... in the postinst script), there is no problem caused by having that dir.
[11:48] <Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/58856
[11:48] <Ubugtu> Malone bug 58856 in xemacs21 "xemacs segfaults on edgy powerpc system" [Undecided,Unconfirmed]  
[11:49] <fabbione> Kamion: mind to let me know when server CD's will be ready?
[11:49] <tfheen> Kamion: supposedly, we need new alternate CDs too for the gutenprint thing.
[11:49] <tfheen> Kamion: can you stop the publisher, please?
[11:50] <tfheen> I want to test build this before uploading
[11:52] <mdz> Ubugtu: bug 62590 please
[11:52] <Ubugtu> Malone bug 62590 in Ubuntu "openoffice.org FTBFS, when built on edgy's kernel" [High,Confirmed]  http://launchpad.net/bugs/62590
[11:52] <tfheen> tkamppeter: we seem to build all the PPDs in the package build too, but they're never shipped.  Anyway, we can revisit that after beta.
[11:52] <Fade> I can't believe I'm the only one who values xemacs. lol
[11:52] <mvo> mdz: dist-upgrader 20060927.1137 is uploaded and wating for approval.
[11:55] <Kamion> fabbione: maybe about an hour?
[11:55] <doko_> Bazzi: pong
[11:55] <fabbione> Kamion: sure that's fine
[11:55] <Kamion> fabbione: actually I can do them earlier, due to the gutenprint thing
[11:55] <Kamion> so within the hour
[11:55] <fabbione> Kamion: that's fine. i just need to know when they are done. doesn't matter when
[11:55] <fabbione> Kamion: i am testing netinstalls in the meantime
[11:56] <mdz> mvo: accepted, thanks
[11:56] <Kamion> oh I see, your grammar confused me then
[11:57] <Kamion> "when server CDs are ready"
[11:57] <Bazzi> doko_: I talked with dholbach a bit on Java things in ubuntu. you are the responsible person for java?
[11:57] <Kamion> quirk of English tenses
[11:57] <doko_> Bazzi: as long as it's in main, maybe yes
[11:58] <Bazzi> doko_: I particularly have two interests, (1) fixing eclipse so that it works flawlessly, (2) giving ubuntu some more free java love ;-)
[11:58] <Bazzi> hm, those things are mostly in universe, though
[11:59] <tkamppeter> tfheen: Lets leave it this way, it consumes less CD space for the package. Only fix the directory creation in the postinst script and the package is perfect.
[11:59] <tfheen> Kamion,infinity: please let gutenprint in once you see it.
[11:59] <doko_> Bazzi: you're welcome. (2) is not a problem, just start. what problems do you have with eclipse?
[12:00] <tfheen> with that, I'm off for a little bit of rest to avoid my head falling off.
[12:00] <dholbach> doko_: I said to Bazzi that a java maintenance team might be a good idea - so more than one can chip in fixes for java packages :)
[12:00] <Bazzi> doko_: it doesn't work for me at all, I get wrong/missing build-deps (I'm all new to hacking packages so I don't know where to fix them) and they're quite complex
[12:01] <ogra> tfheen, thanks a lot :)
[12:01] <Kamion> tfheen: done
[12:01] <Kamion> infinity: want to drive the publisher? or you could just turn the cron jobs back on ...
[12:01] <Kamion> we're just about in time
[12:02] <Kamion> actually, maybe not, I think cron needs the jobs to be in place one minute before they run
[12:02] <Kamion> or at least vixie cron used to be that way
[12:02] <fabbione> oh grat
[12:03] <fabbione> i found a glibc6 regression
[12:04] <doko_> Bazzi: so you did use an upstream version, or the packaged one?
[12:04] <infinity> Kamion: I'll just drive by hand.
[12:05] <Bazzi> doko_: since the packaged one didn't work I thought it might be useful to recompile it myself against the current gcj version. but apt-get build-dep eclipse failed
[12:07] <TheMuso> c
[12:09] <doko_> Bazzi: just download, start the build with debian/rules build and try to figure out, what goes wrong. it works for me.
[12:10] <Bazzi> you mean starting or compiling works?
[12:10] <Riddell> new kubuntu-meta upload if someone could let it through
[12:11] <infinity> Kamion: Any particular reason why ubuntu-minimal isn't a task?
[12:11] <doko_> Bazzi: compiling
[12:12] <infinity> Kamion: See bug #61684 ... This can be fixed for -standard or -desktop by installing tasks instead of metapackages, but not for -minimal
[12:12] <Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  http://launchpad.net/bugs/61684
[12:12] <Kamion> infinity: historically, because we didn't have aptitude at the point when we were installing -minimal
[12:12] <Kamion> and also because debootstrap installs -minimal
[12:12] <infinity> Oh, debootstrap installs it.  Right.
[12:13] <Kamion> I think we lose here, TBH. We can cope with occasionally having to fix up stuff in minimal, right?
[12:13] <infinity> Then it won't matter anyway, cause it won't end up in apt's autoremove DB.
[12:13] <Bazzi> doko_: that's btw the error I get when trying to start it: http://phpfi.com/157675
[12:13] <infinity> So, we win.
[12:13] <Kamion> we should probably mark ubuntu-minimal as manually installed?
[12:13] <infinity> (In this case)
[12:13] <Kamion> oh, no, that's the default
[12:14] <infinity> Yeah, no need to mark it at all.
[12:14] <Kamion> mark everything else at the end of the debootstrap run as automatically installed?
[12:14] <infinity> Since it's done by dpkg and black magic, not apt.
[12:14] <doko_> Bazzi: so that for running eclipse, not building it ...
[12:14] <infinity> Marked as auto-installed would give us the above bug, which I was trying to avoid. :)
[12:14] <Kamion> oh, right
[12:14] <Kamion> ok
[12:14] <infinity> In other words, the bug isn't there for -minimal, I just didn't think it through.
[12:14] <mvo> Kamion: if it is not installed by apt, then its all good :)
[12:14] <Kamion> righto
[12:15] <Bazzi> doko_: yep that error is for running it
[12:15] <Kamion> fabbione: server CDs should be up now
[12:15] <fabbione> Kamion: it appears that finish-install fix for ttySX didn't kick.. just tested on a netinstall
[12:15] <Kamion> what version of finish-install was on your image?
[12:15] <Kamion> oh, netinstall
[12:15] <Kamion> hmm
[12:16] <fabbione> syslog:Sep 27 10:03:04 finish-install: Configuring /etc/inittab for serial console
[12:16] <fabbione> hmm
[12:16] <fabbione> i have 2.3ubuntu1 in my local mirror
[12:16] <Kamion> yeah, I didn't update the message, that doesn't matter
[12:16] <fabbione> rsynced no more than one hours ago
[12:16] <Kamion> oh, I suck
[12:16] <Kamion>         if [ -f /target/etc/inittab ] ; then
[12:16] <Kamion>         if [ -f /etc/event.d/tty1 ] ; then
[12:16] <Kamion> spot the bug
[12:17] <Bazzi> doko_: do I need anything special to du a debian/rules build? it complains about lack of /usr/share/dpatch/dpatch.make
[12:17] <pitti> missing /target?
[12:17] <fabbione> Kamion: yeah.. if we have inittab..
[12:17] <Kamion> pitti: bingo
[12:17] <fabbione> ah no
[12:17] <fabbione>  /target
[12:17] <fabbione> yeah
[12:17] <fabbione> ok i guess beta for sparc is going to be doomed.. slightly :)
[12:18] <doko_> Bazzi: sudo apt-get build-dep eclipse
[12:18] <Kamion> I can fix this, it's a one-liner
[12:18] <Kamion> ... sugar?
[12:18] <ogra> haha
[12:18] <Bazzi> doko_: that fails. libjsch-java is in wrong version
[12:18] <fabbione> Kamion: ahah
[12:18] <Kamion> I have no kettle at my workplace right now :(
[12:19] <fabbione> Kamion: btw.. bug #62596
[12:19] <Ubugtu> Malone bug 62596 in glibc "ld.so.conf disappeared?" [High,Confirmed]  http://launchpad.net/bugs/62596
[12:19] <fabbione> that will stop some interesting thing to work
[12:20] <Kamion> score
[12:20] <Kamion> I guess that's due to /usr/X11R6/lib going away
[12:20] <fabbione> i dunno..
[12:20] <fabbione> i still need to dig into it
[12:20] <ogra> i still have it in my i386 install from yesterday
[12:21] <fabbione> ogra: it's not on my i386 server installed 20 minutes ago
[12:21] <ogra> (but indeed that has /usr/X11R6/lib)
[12:21] <Kamion> fabbione: weird, the code looks correct
[12:22] <Kamion> in libc6.postinst
[12:22] <fabbione>     if dpkg --compare-versions $preversion lt 2.3.999.2-4; then
[12:22] <fabbione>         if [ -e /etc/ld.so.conf ] ; then
[12:22] <fabbione>             [ -z "$(tail -n 1 /etc/ld.so.conf)" ]  || echo >> /etc/ld.so.conf
[12:22] <fabbione>         else
[12:22] <fabbione>             touch /etc/ld.so.conf
[12:22] <fabbione>         fi
[12:22] <fabbione>         if ! grep -q '^include /etc/ld.so.conf.d/.*\.conf$' /etc/ld.so.conf ; then
[12:22] <fabbione>             echo 'include /etc/ld.so.conf.d/*.conf' >> /etc/ld.so.conf
[12:22] <fabbione>         fi
[12:22] <fabbione>     fi
[12:22] <fabbione> no it's not
[12:22] <fabbione> $preversion doesn't exist on install?
[12:22] <infinity> preversoin needs ot be quoted.
[12:22] <Kamion> ah yes, I just came to the same conclusion as infinity
[12:22] <infinity> Then --compare-versions will be happy.
[12:22] <fabbione> feh
[12:23] <infinity> Do I want to upload for that, or not?
[12:23] <Kamion> finish-install fix is in accepted
[12:23] <Kamion> how long does glibc take to build everywhere?
[12:23] <infinity> Too long.
[12:24] <Kamion> jbailey said the other day that he was concerned about uploading glibc at the moment in case compiler updates broke it
[12:24] <infinity> 6 hours on sparc.
[12:24] <infinity> That's a no-go.
[12:24] <Kamion> we could simply bump that version check later, and fix it post-beta
[12:24] <fabbione> no no
[12:24] <fabbione> no glibc uploads
[12:24] <fabbione> Jeff has other fixes pending
[12:25] <infinity> Yeah, bumping the version check sounds alright to me.
[12:25] <fabbione> it's not catastrophic
[12:25] <doko_> Bazzi: right, that was in preparation for eclipse-3.2. if you want to rebuild the current eclipse, please install the libjsch-java from dapper
[12:26] <Bazzi> doko_: will eclipse-3.2 still come for edgy?
[12:27] <doko_> Bazzi: probably yes, probably no
[12:27] <Bazzi> mmmh :( hopefully yes
[12:30] <Bazzi> doko_: I'll use upstream for now, then and hope eclipse 3.2 slips into edgy in time
[12:31] <thom> sabdfl: http://www.flickr.com/photos/x180/253623622/in/set-72157594289138343/ <-- practising the ballroom dancing again?
[12:43] <pygi> sivang: poke? :)
[12:45] <sivang> pygi: hi
[12:45] <pygi> sivang: you have time or are you busy once again? :)
[12:46] <sivang> pygi: doing something but can talk and multitask :-)
[12:46] <pygi> sivang: ah, won't bug you then, just ping me if you're done in next 10 years :)
[12:47] <sivang> pygi: heh
[12:47] <sivang> pygi: no, please, go ahead
[12:53] <lloydinho> hi pitti. I have problems with query stuff.
[12:53] <pitti> lloydinho: oh, not registered?
[12:53] <lloydinho> I'll just try and get it working, just a moment'
[12:53] <pitti> lloydinho: how are your travels and interviews coming along?
[12:53] <lloydinho> (I'm using KDE...)
[12:54] <lloydinho> weird business.
[12:54] <lloydinho> I'm at the aKademy.
[12:54] <lloydinho> in Dublin.
[12:54] <lloydinho> So things are going quite well.
[01:08] <lloydinho> hey mvo!
[01:09] <lloydinho> mvo: busy with the beta release?
[01:09] <tfheen> infinity: you're running the publisher back-to-back?  Is it done yet?
[01:09] <mvo> lloydinho: yeah :( otherwise I would have answered your last mail already :)
[01:10] <lloydinho> mvo: No worries, I've been too busy with the fieldwork stuff anyway. :-)
[01:18] <infinity> tfheen: No, it's still going (second run)
[01:19] <sivang> tfheen: you've asked that exact same question some point in time during this release cycle right? 
[01:20] <Fujitsu> My wireshark builds failed with `Chroot problem' 4 days ago, they haven't been rebuilt yet...
[01:20] <Fujitsu> Do I have to do something special?
[01:22] <tfheen> sivang: as in "sometime during edgy", yes, as in "sometime during beta preparations", no.
[01:22] <tfheen> infinity: ok, please tell me when it's done.
[01:22] <infinity> tfheen: Hah, it just finished.
[01:23] <sivang> tfheen: right, the former. good I'm sane still.
[01:26] <tfheen> infinity: thanks, I'll build amd64 livefs-es now to test.
[01:26] <infinity> tfheen: Kay, cool.  You'll be testing a quick livefs.sh tweak at the same time, so I'll be watching.
[01:26] <tfheen> infinity: ok.
[01:29] <infinity> tfheen: The sooner, the better, mind you. :)
[01:31] <ogra> id gutenprint already done ? 
[01:31] <ogra> *is
[01:31] <infinity> Yes.
[01:31] <ogra> wow, that was fast
[01:31] <infinity> You must have fallen asleep, it wasn't that fast. :)
[01:32] <ogra> i sat here twiddling thumbs :)
[01:33] <fabbione> ogra: slaker!
[01:33] <ogra> heh
[01:33] <bddebian> Howdy folks
[01:40] <Kamion> lp_archive@drescher:~$ change-override.py -c universe -S tcsh
[01:40] <Kamion> woo
[01:44] <infinity> !
[01:44] <infinity> I thought tcsh was a build-dep of large chunks of weird crap (and OOo)?
[01:45] <Fujitsu> infinity, doesn't OOo come under weird crap anyway?
[01:45] <infinity> Well, yes.
[01:46] <infinity> Would appear that it's not a build-dep, though.  Maybe I'm on crack, or maybe it bootstraps its own csh to use in the build process.
[01:46] <infinity> The latter wouldn't surprise me.
[01:46] <infinity> I suspect they'll ship the GCC source bundled with OOo eventually.
[01:47] <fabbione> sooner or later they will have obiquity as b-d
[01:47] <fabbione> ubiquity even
[01:47] <mantiena-baltix> Hi all
[01:51] <mantiena-baltix> Kamion, Hi, could you give me some time ? I wanna work on ubiquity bugs (I noticed lots of bugs in dapper's ubiquity), so, maybe it would be better to use ubiquity from edgy on our distro (Baltix, based on Dapper) ?
[01:52] <Riddell> Kamion: could you let kubuntu-meta 1.14 into the archive?
[01:53] <infinity> mantiena-baltix: You might want to try bugging him after we've released the Edgy Beta (in the next 24-48 hours)
[01:53] <infinity> Riddell: Will this require livefs rebuilds for kubuntu?
[01:53] <Riddell> infinity: yes
[01:54] <fabbione> Riddell: that's not the right answer
[01:54] <fabbione> ;)
[01:54] <infinity> Riddell: Unavoidable? :)
[01:54] <Riddell> well amd64 live CD is oversized so seems unavoidable to me
[01:55] <mantiena-baltix> infinity, I just wanna ask if ubiquity from edgy is stable enough and if there are any important reasons do not use ubiquity from Edgy on Dapper-based system
[01:55] <slomo_> infinity: ping? did you already do something about apache1/2 at the same time? :)
[01:55] <infinity> Fair enough.
[01:55] <infinity> slomo_: Not for beta, no.
[01:55] <infinity> Riddell: Accepting.
[01:55] <Riddell> thanks infinity 
[01:56] <doko_> infinity: OOo dropped tcsh in edgy
[01:57] <infinity> doko_: Nice.
[01:57] <ogra> to switch to zsh ? 
[01:57] <ogra> or csh ?
[01:57] <doko_> infinity, Fujitsu: OOo isn't as evil as Keybuk says ...
[01:57] <infinity> Switching from tcsh to zsh would be a neat trick...
[01:58] <Fujitsu> doko_, sure...
[01:58] <ogra> :)
[02:11] <ogra> ARGH 
[02:11] <ogra> what did you do to my isos ?
[02:11] <ogra> where do these 7M come from ?
[02:12] <pitti> ogra: straight from hell
[02:12] <ogra> seems like :((
[02:15] <ogra> sh*t 
[02:16] <ogra> how could our kernel and modules grow by 7M ?
[02:16] <ogra> its the only differenc i see apart from gutenprint and synaptic
[02:17] <infinity> They don't seem to have grown at all here, from -9 to -10
[02:17] <ogra> i have no clue where to take that space from ... damn, the iso was perfect 
[02:18] <ogra> well, i dont think synaptic grew by 7M
[02:18] <mvo> ogra: I hope not :P
[02:18] <ogra> and the gutenprint fix was a one liner
[02:19] <ogra> infinity, l-r-m probably ?
[02:19] <infinity> Nope.
[02:19] <infinity> No change there.
[02:19] <ogra> hmm
[02:19] <Lathiat> some missing debug stripping or something?
[02:19] <ogra> ubuntu has the same issue it seems
[02:20] <sabdfl> thom: it's just a jump to the left...
[02:20] <ogra> heh
[02:20] <sivang> hehe
[02:21] <thom> sabdfl: *g*
[02:22] <infinity> ogra: Indeed, though only on i386.. The others didn't grow.
[02:22] <ogra> yep
[02:22] <ogra> thats why i suspect some part of the linux package ...
[02:23] <ogra> oh
[02:23] <ogra> heh
[02:24] <infinity> Found it?
[02:24] <ogra> where is the difference between -generic and -i386 ?
[02:24] <ogra> i have all d-i modules twice in the .list file 
[02:24] <infinity> Ahh, that wouldbe it.
[02:24] <ogra> one -generic and one -i386
[02:24] <ogra> d-i rebuild ? 
[02:25] <ogra> or onyl a metapackage glitch ?
[02:25] <infinity> germinate bug, I'd guess.
[02:25] <infinity> -generic is listed for amd64, and I think it's pulling it in for i386 too.
[02:25] <ogra> ah
[02:36] <Kamion> mantiena-baltix: use the dapper-updates version of ubiquity; I don't support edgy's ubiquity on a dapper-based distribution
[02:36] <Kamion> mantiena-baltix: for one thing, edgy's ubiquity uses console-setup, which isn't in dapper; and it needs other bits of infrastructure you don't have
[02:38] <Kamion> tfheen: just heard about an oem-config bug
[02:38] <Kamion> +  * Add /usr/lib/oem-config to sys.path in oem-config-dm so that it can
[02:38] <Kamion> +    import frontend modules.
[02:39] <Kamion> +sys.path.insert(0, '/usr/lib/oem-config')
[02:39] <mantiena-baltix> Kamion, I understand, that you don't support edgy's ubiquity on dapper, but if edgy's ubiquity just need some packages to be backported then it
[02:40] <mantiena-baltix> it's not a problem for me, I can do this ;)
[02:40] <Kamion> mantiena-baltix: then on your head be it; I don't want to be asked about it
[02:40] <Kamion> honestly, it's too much work for me to attempt to help
[02:41] <tfheen> Kamion: without it, it doesn't work, or?
[02:41] <Kamion> tfheen: I've uploaded the fixed oem-config; if you want to get somebody to push it through, please do
[02:41] <Kamion> tfheen: yeah, it'll raise an AttributeError on oem-config-dm startup unfortunately
[02:41] <Kamion> which is kind of fatal
[02:41] <tfheen> Kamion: ok, thanks
[02:41] <Kamion> abattoir's tested the fix and it works
[02:41] <tfheen> infinity: if you'd be so kind as to approve that. ^^ 
[02:41] <mantiena-baltix> Kamion, thank you very much, you told me exactly what I need - ubiquity from edgy will not work on default dapper system :)
[02:41] <infinity> tfheen: Will do.
[02:42] <zul> heylo
[02:42] <ogra> infinity, any results in proving that theory ? 
[02:42] <Kamion> mantiena-baltix: I'm willing to backport more individual fixes to dapper-updates if you want to identify them, although I can't fix everything that way
[02:43] <Kamion> anyway, I really have to run, I need to be five minutes' drive away two minutes ago
[02:44] <infinity> ogra: Looks like we're committing a hackish fix right now.
[02:44] <ogra> ok
[02:44] <mantiena-baltix> Kamion, good luck, I try to help you with version from dapper-updates at first
[02:44] <infinity> Kamion: germinate tests look good, committing.
[03:15] <tfheen> Riddell: that seed adjustment you did -- does it affect live cds?
[03:16] <tfheen> ogra: you probably want new livefs-es too?
[03:16] <tfheen> ogra: or are those you have too big already?
[03:16] <ogra> nope, they are fine ... 
[03:16] <ogra> my liveCD is usually a bit smaller anyway
[03:17] <ogra> as soon as the germinate fix is in i need new i386 builds though
[03:17] <tfheen> ogra: you want new livefs-es for  https://launchpad.net/distros/ubuntu/+bug/61684 don't you?
[03:17] <Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  
[03:17] <ogra> if thats fixed then yes
[03:18] <Riddell> tfheen: yes
[03:19] <Riddell> tfheen: so wait for kubuntu-meta 1.14 is in the archive before rebuilding
[03:20] <tfheen> Riddell: will do
[03:27] <seb128> bah, edgy on amd64 is no fun
[03:27] <Treenaks> seb128: it's fun here!
[03:27] <seb128> depending of the fun then ;)
[03:27] <seb128> valgrind is not working
[03:28] <ogra> seb128, wahts not funny about it ? 
[03:28] <ogra> ah
[03:28] <seb128> lot of "DWARF2 CFI reader: unhandled CFI instruction 0:24" to start
[03:29] <Treenaks> what's a DWARF2 CFI reader?
[03:29] <seb128> no idea
[03:29] <seb128> and it exits on "valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed."
[03:29] <ogra> a little person with glasses and a book ?
[03:30] <tfheen> dwarf2 is a debugging format.
[03:30] <tfheen> or debugging symbol format or whatever
[03:30] <ogra> how boring ... i lkie my idea better :)
[03:30] <ogra> *like
[03:31] <ogra> if you use a DVD the current isos should work ...
[03:31] <ogra> they are just to big for 700MB 
[03:32] <Kamion> infinity: thanks for testing that
[03:32] <tfheen> Kamion: new alternate builds running now.  I forgot and ended up doing full builds rather than i386 only.
[03:33] <Kamion> we'd need everything for oem-config anyway
[03:34] <mvo> will we see another -live build as well?
[03:34] <ogra> yep
[03:35] <pitti> bandwidth even
[03:35] <ogra> heh, i get 36k (on a 2M line)
[03:36] <sivang> lines dropping again?
[03:36] <pitti> ogra: that's not the point, de.archive.u.c. serves me 150 kb
[03:36] <sivang> pitti: .de never seem to be servig less 
[03:36] <pitti> but it's always a day out of date
[03:36] <sivang> it's quite good
[03:36] <mvo> archive.u.c is pretty slow these days :/
[03:36] <ogra> yep
[03:36] <elmo> I can get 8Mbit from the office
[03:36] <elmo> the machines are fine - if  it's slow for you a) let us know (esp. where you're coming from IP wise),and b) use a mirror - that's why they exist :-P
[03:37] <Znarl> pitti : What's your IP address?
[03:37] <sivang> hmm, seems fine. I am now dist-upgrading in 194Kb/s
[03:37] <sivang> from a.u.c
[03:37] <pitti> Znarl: 195.227.105.180 is my ISP's public address
[03:37] <Znarl> pitti : Ta.
[03:38] <tfheen> mvo: live iso, not live fs, no
[03:38] <pitti> sometimes, when I ^C apt-get and start again, I get a better one, though; seems to be pure luck
[03:38] <mvo> tfheen: no new livefs? oh well, so no fix for #61684 :/
[03:39] <tfheen> mvo: yes, that's what I'm rebuilding for now.  Not yet another is what I meant.
[03:39] <mvo> aha, right
[03:40] <ogra> ergh, why did my rsync just stop ?
[03:40] <Znarl> pitti : Ah, you're now using easynet transit to get to a.u.c, which seems to be why it's slow for you.
[03:40] <pitti> Znarl: ah; this is most likely the reason for mvo's slow link, too?
[03:41] <Znarl> pitti : You use telia.net otherwise, which is faster, to get to the DC.
[03:41] <pitti> Znarl: thanks for investigating; good that it's not a DC issue then
[03:41] <ogra> evil german telecom i guess
[03:42] <mvo> Znarl: oh! anything I can do on my end? I guess not :/ crap provider
[03:42] <mvo> Znarl: it seems I go over atlas.cogentco.com
[03:42] <ogra> my rsync just had an evil hiccup via telecom ... now i cant get more than 4k either
[03:43] <tfheen> i386 is better now, but it's still a tad oversized..
[03:44] <Kamion> tfheen: you need to rm your .ssh/known_hosts on lithium or something
[03:44] <Kamion> or just sudo su - cdimage first
[03:44] <Spads> hello
[03:44] <Kamion> I do wonder if I should force LANG=C in build-image-set ...
[03:44] <Spads> I just updated lithium's global known_hosts.  
[03:44] <Kamion> ah, thanks
[03:45] <tfheen> Kamion: to fix up builds you mean or something else?
[03:45] <Kamion> tfheen: look at the end of the last log file
[03:45] <tfheen> Kamion: done
[03:45] <ogra> tfheen, it shrunk by 8M ... thats fine for edubuntu you can start builds for it if you like 
[03:46] <Kamion> tfheen: I think that group warthogs thing for powerpc only happens when the build is interrupted; my attempts at debugging it haven't been useful so far
[03:46] <tfheen> Kamion: any excellent ideas what we should do to get i386 down?
[03:46] <Znarl> mvo : What's your source IP?
[03:46] <tfheen> Spads: is the ssh key for calcium.u.c globally wrong on lithium?
[03:46] <Spads> let me check
[03:47] <ogra> Znarl, http://pastebin.ca/184024
[03:47] <ogra> i have similar issues
[03:47] <Spads> tfheen: yes it is.  Let me just go and update our known_hosts databases
[03:48] <tfheen> Spads: I also get some weird errors when pushing to scandium: buffer_get_ret: trying to get more bytes 257 than in buffer 103 (and more)
[03:49] <Spads> tfheen: I'll look into that once I get calcium sorted out
[03:49] <mvo> Znarl: 84.166.114.83 (changes daily)
[03:50] <Kamion> removing kbd-chooser would help a little bit, but probably not much
[03:50] <Spads> tfheen: try the calcium thing again
[03:51] <Spads> scandium was just re-IP'd I think.  Znarl would know more
[03:51] <tfheen> Spads: seems happy now.
[03:51] <tfheen> lithium tries to contact chlorine, but get no route to host.
[03:51] <Spads> yes
[03:51] <Spads> that's known
[03:51] <Znarl> mvo : You seem to be getting to a.u.c using an busy peering connection.
[03:52] <Spads> tfheen: is that fatal?
[03:52] <mvo> Znarl: aha, ok. thanks
[03:52] <tfheen> Spads: it's fatal for the mirror on chlorine; I have no idea what's running on chlorine and whether whoever uses it or not cares.
[03:52] <Spads> chlorine and palmer are going to be in motion for a while
[03:53] <Spads> we'll be sure to kick off a manual trigger for chlorine when we bring it back into the fray
[03:53] <tfheen> ok
[03:53] <Spads> likewise palmer once we bring it down and back again
[03:54] <Spads> but so long as the script keeps trudging on if a trigger doesn't happen, it can be safely ignored
[03:54] <tfheen> it does, so we're fine
[03:54] <tfheen> ogra: your installation ISOs are ready.
[03:55] <ogra> well, even reloading the webpage on cdimage takes a minute here atm :/
[03:55] <Kamion> tfheen: there are like loads of language packs in there
[03:55] <Kamion> I'll cut them down a bit
[03:55] <ogra> yay 698M :)
[03:59] <Kamion> tfheen: right, give it 20 minutes for seed propagation
[04:00] <tfheen> Kamion: ok, thanks.
[04:07] <elmo> mvo/pitti: how long has archive been like this for you?
[04:07] <Hobbsee> ogra: then it migth go quicker :P
[04:08] <ogra> hahaha
[04:08] <pitti> elmo: hm, a few weeks maybe
[04:08] <pitti> thom: HAH! apache2 builds fine with just downgrading autoconf to 2.59 without any other modifications
[04:09] <thom> pitti: ugh, that sucks
[04:10] <tfheen> pitti: oh, that interesting bug.  Same as autoconf 372179 ?
[04:10] <tfheen> s/autoconf/debian/
[04:11] <pitti> tfheen: most probably
[04:12] <tfheen> pitti: if so, just patching the layout file is a reasonable workaround.
[04:12] <tfheen> (instead of passing --foodir=$bar , etc)
[04:13] <pitti> tfheen: I thought about patching the layout file, but it seems like an ugly hack
[04:13] <tfheen> pitti: it's what we did in the Debian packages. *shrug*.
[04:13] <pitti> tfheen: my plan was to review the diff -ur between a successful and a failed build and spot the important difference
[04:13] <tfheen> pitti: we're already using the layout called "debian", so it makes sense to modify it to be correct, imo.
[04:14] <pitti> tfheen: you mean you are patching the 'apr' layout for the apr lib to be like 'Debian'?
[04:14] <pitti> (since apr is built with the 'apr' layout)
[04:14] <pitti> but with lots of --foo-dir=$debian_specific_dir
[04:15] <tfheen> pitti: ah, I fixed it for apr, not apache2, iirc, but yeah, just patching the right layout (or patching the debian layout and using --with-layout=debian) seems sensible.
[04:15] <pitti> tfheen: ok, I'll do that then
[04:17] <Riddell> tfheen: you can build new kubuntu livefs's now
[04:18] <tfheen> Riddell: two out of three of them are already done.  And your alternate CDs are done too.
[04:27] <tfheen> all livefs-es shold be golden now.  kubuntu and edubuntu alternate cds should be golden, ubuntu, edubuntu desktop cds should be golden.  That leaves ubuntu-server, all DVDs, ubuntu alternate and nothing else, I think
[04:28] <pitti> tfheen: I'm currently test-building the apache2 fix
[04:28] <pitti> tfheen: do you want to stall -server until I uploaded this, so that we don't ship apache2 with a known security hole?
[04:29] <tfheen> pitti: hmm, I guess that makes sense.  That is, -server just built, but I can build again
[04:30] <thom> heh
[04:30] <Hobbsee> hehe
[04:31] <Hobbsee> good luck with that, pitti 
[04:31] <tfheen> apache2 builds in the time ooo runs debian/clean, so it's not that long.
[04:31] <pitti> 'a watched build never boils'
[04:33] <Treenaks> pitti: boils => finishes
[04:33] <pitti> yes, yes
[04:34] <tfheen> pitti: please do tell me when you have something
[04:34] <pitti> it's just that a watched build never FTBFSes
[04:34] <pitti> tfheen: of course
[04:37] <tfheen> jay, ubuntu i386 not oversized any more.
[04:38] <tfheen> and ubuntu alternate done.
[04:38] <tfheen> everybody: please test the ISOs, those are hopefully the ones which will be the beta images.
[04:39] <fabbione> tfheen: are -server images ready?
[04:39] <pitti> rsync is running at a ridiculous 4kB
[04:39] <tfheen> fabbione: they need a small update for a new apache2 (see above), but should work otherwise, so testing is good.
[04:39] <fabbione> tfheen: ok thanks
[04:39] <pitti> but jigdo grinds through with 200kB/s, so I'll test the ppc/alternates first
[04:40] <tfheen> and with that, I'm off for a bit of food and such
[04:41] <pitti> tfheen: if apache2 works, shall I upload immediately?
[04:41] <tfheen> pitti: yes.  And poke Colin to approve it
[04:41] <pitti> yup, willdo
[04:48] <pitti> SCORE!
[04:48] <pitti> tfheen: ok, uploading with a nice autoconf macro fix, no evil hacks
[04:52] <thom> pitti: what was the fix?
[04:53] <pitti> thom: fix the affected apache2's autoconf macros to not rely on $@, but restore it from $ac_configure_args instead
[04:54] <pitti> thom: http://bugs.debian.org/cgi-bin/bugreport.cgi/052_restore_prefix_fix?bug=374160;msg=20;att=1
[04:54] <pitti> thom: (taken from recent Debian NMU)
[04:57] <thom> ah, d'oh. 
[04:58] <doko_> pitti: python2.4 for dapper updated on chinstrap:~doko/python2.4, please wait until the version is in edgy
[04:58] <pitti> doko_: oh, cool, thanks
[05:17] <pitti> keescook: https://wiki.ubuntu.com/Testing/Current
[05:17] <keescook> pitti: sure.  I had "reinstall laptop" on my todo list
[05:17] <pitti> I'll do the ppc/alternate tests today
[05:17] <pitti> and tomorrow morning ppc/desktop
[05:18] <pitti> keescook: https://wiki.ubuntu.com/Testing/Short should be fine as a test plan
[05:18] <keescook> step 2 in the testing/current says "... listed at the top", which isn't listed.  :)
[05:20] <pitti> keescook: it's in the derivative-specific section
[05:20] <Kamion> I do finally have a fix for the HFS bootstrap partition mess in ubiquity in the works, BTW
[05:20] <pitti> keescook: choose ubuntu/kubuntu/edubuntu (whichever you feel most attached to), there are the matrices
[05:20] <Kamion> won't make the beta though
[05:20] <keescook> pitti: cool, sounds good.
[05:20] <pitti> Kamion: can you please approve the apache2 upload?
[05:21] <pitti> Kamion: (tfheen was fine with it)
[05:21] <Kamion> pitti: done
[05:27] <ogra> tfheen, reboot doesnt work (hardlocks the machine)... but apart from that edubuntu i386 install is golden ...
[05:29] <tfheen> ogra: note it in Testing/Current, please.
[05:29] <ogra> willdo
[05:30] <ogra> i have no plain i386 system around, the hardlock might be caused by my turion (even i doubt it)
[05:30] <tfheen> get some edubuntu users to test it?
[05:30] <Kamion> tfheen: bit worried about bug 61732 - investigating
[05:30] <Ubugtu> Malone bug 61732 in ubiquity "edgy knot 3, installer formated a partition I didn't asked for (windows ntfs)" [High,Confirmed]  http://launchpad.net/bugs/61732
[05:31] <ogra> ugh ... Testing/current links to dapper isos all over the place 
[05:31] <tfheen> ogra: please fix that. :-)
[05:31] <ogra> doing ;)
[05:32] <tfheen> Kamion: ugh. :-(
[05:34] <pitti> keescook: btw, if you plan to test a range of stuff, please add your nick without a test value to the particular matrix elements, so that we can coordinate testing better
[05:35] <pitti> ogra: oh, oops, sorry for breaking your lock, I saw it too late
[05:35] <ogra> argh...
[05:35] <ogra> i made a lot of changes (dapper/edgy)
[05:35] <pitti> ogra: feel free to clobber my changes if you changed anything in Ubuntu (I suspect you only touched edubuntu?)
[05:35] <Kamion> tfheen: I've marked it for beta
[05:35] <ogra> pitti, i fixed the links at the top
[05:36] <pitti> ok, there shouldn't be conflicts then
[05:36] <Kamion> I think it's been there forever actually, but we should really fix it for beta
[05:36] <ogra> pitti, you added only "pitti:" ?
[05:36] <keescook> pitti: okay
[05:36] <pitti> ogra: yes
[05:36] <ogra> ok
[05:40] <doko_> tfheen, ogra: do we have a testing wiki page?
[05:40] <tfheen> doko_: yes, Testing/Current
[05:40] <ogra> doko_, https://wiki.ubuntu.com/Testing/Current
[05:41] <doko_> thanks
[05:41] <ogra> even though the tests i want for edubuntu go a bit further :)
[05:44] <ogra> grmbl ... powerpc rsync ETA ... 2:40h ...
[05:44] <Kamion> rsync ETAs are not to be grumbled about until the rsync has finished
[05:45] <Kamion> they are calculated based on the current average transfer rate, which might change radically
[05:45] <ogra> right, 2:40 is the shortest i saw in the last 3 hours
[05:45] <ogra> the average is rather at 16-20h
[05:45] <ogra> german telekom has routing probs it seems
[05:46] <pitti> ogra: (here, too)
[05:46] <ogra> yep ...
[05:47] <ogra> and i dont have a single live iso thats up to date :(
[05:47] <ogra> will be a long night ...
[05:47] <pitti> ogra: well, mine are two days old and the first already syncs for half an hour; annoying...
[05:47] <ogra> lucky you mine are knot3 
[05:48] <Kamion> tfheen: please review http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.1.25.diff
[05:48] <pitti> however, cdimage.ubuntu.com -> chinstrap wget is only 3 K/s, too
[05:49] <pitti> ah, better now at second attempt
[05:49] <Kamion> basically just moves the "did partman detect a filesystem" test inside 'if format' and make sure that an undetected filesystem doesn't trigger formatting
[05:49] <tfheen> Kamion: I don't know the code well enough to review it well, but it looks good to me.
[05:51] <Kamion> I've always been a little uncomfortable with that code, but that bug convinced me that it has to go
[05:51] <Kamion> unfortunately, as usual right now, I'm not in a position to be able to test
[05:51] <Kamion> I may be able to *try* to boot the powerpc image from my hard disk later
[05:55] <\sh> When do we have oracle certificaton for dapper? ,-)
[05:57] <Kamion> mvo: do you know whether mdz approved either of these dist-upgrader uploads in unapproved?
[05:59] <mvo> Kamion: Accepted:
[05:59] <mvo> dist-upgrader_20060927.1137_all.tar.gz
[05:59] <mvo> +(http://librarian.launchpad.net/4519037/dist-upgrader_20060927.1137_all.tar.gz)
[05:59] <mvo> +was ACCEPTED
[05:59] <mvo> Kamion: that should be fine, that was the latest version
[06:03] <Kamion> mvo: oh right - can I reject 20060927.1046 and 20060927.1108 then?
[06:04] <Kamion> tfheen: ubiquity 1.1.25 accepted
[06:04] <Kamion> I have to go in a moment; can somebody shepherd that through? sorry for the last-minute discovery
[06:04] <tfheen> Kamion: I'll rebuild livefs-es.
[06:04] <Kamion> please (please!) call me on my mobile if ubiquity appears to have regressed due to that upload
[06:04] <mvo> Kamion: yes, all the others can be rejected
[06:06] <Kamion> mvo: ok, thanks
[06:09] <Ng> cool, much love for the new gnome-power-manager graphs stuff :D
[06:17] <mvo> Kamion: a quick question. I have some apparently randoms hangs here on a amd64 test-install in ubiquity. it looks like the communication with the child somehow stoped. was that reported before? 
[06:17] <tfheen> Kamion: he's not around more.  If you need an answer, you must call him
[06:22] <seb128> pitti: bug day today, somebody on #ubuntu-bugs is asking about bug #61834 if you have a min to have a look to it and comment
[06:22] <Ubugtu> Malone bug 61834 in hal "SD slot on 7-in-1 USB card reader not recognised as SD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61834
[06:23] <doko_> Kamion: should I be offered a "Resize partition" option, when I install a second time onto the same disk?
[06:26] <mjg59> seb128: Looks like the right fix
[06:27] <seb128> mjg59: ok, thank you
[06:27] <keescook> pitti: Desktop i386 fails "check" similarly to your PPC bug 60395
[06:27] <Ubugtu> Malone bug 60395 in cdrom-checker "desktop CD-ROM checker hangs forever" [Undecided,Confirmed]  http://launchpad.net/bugs/60395
[06:27] <mvo> tfheen: thanks, its not that urgent, I will keep testing
[06:27] <tfheen> mvo: thanks.
[06:31] <keescook> are boot-time warnings sufficient to open a bug for beta testing?
[06:31] <keescook> (udev warnings, /var/run over-mount warnings, etc?)
[06:32] <tfheen> keescook: please do file bugs, if you think they're _urgent_ mark them with the ubuntu-6.10-beta milestone.
[06:32] <tfheen> they don't sound like blockers, though
[06:35] <keescook> tfheen: okay, thanks
[06:42] <jdong_> whose archive day is friday?
[06:47] <pitti> argh, oem-config has regressed even further
[06:47] <tfheen> pitti: is that possible?
[06:47] <tfheen> as in, it used to not start.
[06:47] <pitti> tfheen: last time it started and got stuck on the third question
[06:47] <pitti> (in knot-3)
[06:48] <pitti> now it immediately crashes
[06:48] <janimo> tfheen: permission to upload a new xfce4-mixer package? not critical for beta, but would be goot to have it tested
[06:49] <tfheen> janimo: no, please not.
[06:49] <janimo> tfheen: ok
[06:49] <tfheen> pitti: hmm, can you check that your version has:
[06:49] <tfheen> 14:38 < Kamion> tfheen: just heard about an oem-config bug
[06:49] <tfheen> 14:38 < Kamion> +  * Add /usr/lib/oem-config to sys.path in oem-config-dm so that it can
[06:49] <tfheen> 14:38 < Kamion> +    import frontend modules.
[06:49] <tfheen> 14:39 < Kamion> +sys.path.insert(0, '/usr/lib/oem-config')
[06:50] <pitti> tfheen: it's probably that (see bug 62684)
[06:50] <pitti> bug 62648 even
[06:50] <Ubugtu> Malone bug 62648 in oem-config "immediately crashes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62648
[06:52] <pitti> tfheen: will take me a minute, console is completely broken and there's no user; 
[06:53] <pitti> keescook: please only note the real bad ones on Testing/Current; the less important ones should just be filed
[06:53] <keescook> pitti: yup, following tfheen's suggestion.
[06:54] <keescook> if a dialog confirmation (manual partitioning) pops under ubiquity... that's going to confuse a lot of people, but shouldn't really be considered a blocker, correct?
[06:54] <pitti> tfheen: hm, it already has that path
[06:56] <pitti> keescook: that one is filed for ages
[06:56] <pitti> keescook: right
[06:57] <mdz> Kamion: yes, I accepted the newest one and ignored the other two dist-upgraders
[06:59] <mdz> tfheen: how goes?
[07:03] <pitti> tfheen: ah, right, that was it
[07:09] <fabbione> Kamion: your finish-install fix works like a charm! GOOD WORK!
[07:10] <fabbione> tfheen: sparc -server CD is go, i386 server + DNS + LAMP netinstall is good, sparc netinstall + raid + lvm in different combos including Niagara is go
[07:11] <fabbione> tfheen: also tested resize of windows partition on x86 and that was good too
[07:13] <tfheen> mdz: what I believe are golden alternate images are up now.  Waiting for the fix for http://launchpad.net/bugs/61732 to propagate through soyuz.
[07:13] <Ubugtu> Malone bug 61732 in ubiquity "edgy knot 3, installer formated a partition I didn't asked for (windows ntfs)" [High,Fix released]  
[07:13] <tfheen> (and then I can build final livefs-es).
[07:13] <tfheen> pitti: hmm, that should have been on the CDs then.  Are you sure you have the latest ones?
[07:15] <pitti> tfheen: yes, pretty sure
[07:15] <pitti> tfheen: there are more issues, please see the bug trail
[07:15] <pitti> tfheen: I checked the CD again, I have 20060927.7
[07:16] <pitti> it has oem-config 1.5 from Sept 25
[07:16] <pitti> tfheen: so it's indeed missing 1.6
[07:16] <mdz> sfllaw: ping
[07:16] <pitti> tfheen: however, it's not the only bug (see bug trail), so it'll require another upload
[07:17] <tfheen> pitti: yeah..
[07:17] <tfheen> pitti: wondering if we should drop oem-config for beta
[07:17] <tfheen> mdz: ^^
[07:18] <mdz> tfheen: oem-config is busted?
[07:18] <tfheen> mdz: yes, see https://launchpad.net/distros/ubuntu/+source/oem-config/+bug/62648
[07:18] <Ubugtu> Malone bug 62648 in oem-config "immediately crashes" [Undecided,Unconfirmed]  
[07:18] <mdz> tfheen: we can document that
[07:18] <tfheen> the first is something we had an upload for, but it didn't make it in, for some reason.
[07:19] <tfheen> mdz: my thought exactly.
[07:19] <tfheen> pitti: did you upload the fixed a2?
[07:19] <pitti> tfheen: yes, hours ago, Kamion approved it
[07:19] <mdz> tfheen: once a fixed daily is available, add a link from the wiki version of the beta announcement so that folks can find it
[07:19] <tfheen> mdz: s/beta announcement/release notes/?
[07:20] <mdz> tfheen: yes, same
[07:21] <pitti> tfheen: yep, a2 is built everywhere and in the archive
[07:21] <tfheen> pitti: excellent
[07:21] <pitti> tfheen: I'll ditch my laptop then and continue testing
[07:21] <pitti> I guess we need the other stuff tested more urgently then
[07:22] <tfheen> pitti: yes, please do
[07:23] <mdz> Riddell,ogra: do you have any outstanding issues?
[07:24] <Riddell> mdz: looking good so far
[07:25] <tfheen> fabbione: new -server ISOs building.  Those should contain a security-fixed apache.
[07:25] <keescook> software-prefs doesn't have 6.10 listed as a channel.  ;)
[07:26] <fabbione> tfheen: ok.. i am not sure how much energy i have left for another round of tests. i am at 14 hours in the day
[07:26] <fabbione> and i have fixes ready for other release bugs
[07:28] <mdz> tfheen: is that the only change?
[07:28] <tfheen> mdz: in the -server ISOs?  Yes, TTBOMK.
[07:28] <mdz> if so, we don't need the security-fixed version for the beta. better to have the tested version
[07:29] <tfheen> it's tested in dapper, though.
[07:29] <mdz> beta users will need to install updates anyway, as will users of the final release
[07:29] <tfheen> so you'd like me to cancel the -server build?
[07:30] <mdz> up to you whether you cancel it or just ignore it
[07:30] <mdz> but we can use the version fabio tested for beta if it passed tests
[07:30] <tfheen> ok
[07:30] <mdz> better to spend time testing other isos
[07:31] <sladen> jono is never online when you want him...
[07:32] <dholbach> sladen: he'S in holidays
[07:32] <sladen> dholbach: already!  he's barely started
[07:33] <dholbach> afaik he even said so in his blog
[07:33] <nixternal> he is on holiday right now sladen
[07:33] <nixternal> hehe
[07:33] <nixternal> ya
[07:33] <nixternal> LOL
[07:33] <nixternal> dholbach: and don't forget about the email he sent to the mailing lists ;)
[07:34] <nixternal> ok..im done beating this one..im gonna hide for a minutes
[07:34] <keescook> where can I find a list of package versions installed via the beta CD?
[07:34] <sladen> keescook: dpkg -l
[07:35] <keescook> sladen: well... this is why I'm confused.  after install, it claims it wants to do 358 updates, so I don't trust my system's view of the versions.
[07:35] <mdz> keescook: there is no beta CD yet, but in general, look in the .manifest files adjacent to the .isos
[07:36] <keescook> mdz: ok, thanks (sorry, meant: "daily")
[07:36] <mdz> keescook: 358 updates relative to what?
[07:37] <keescook> mdz: that's what I'm trying to figure out.  only dapper channels were selectable in synaptic, so I'm trying to figure out where the confusion is.
[07:37] <mdz> keescook: you're running Dapper then
[07:38] <mdz> in which case, 358 updates isn't entirely unbelievable
[07:38] <keescook> mdz: considering I installed from the edge-desktop-i386.iso, this is why I'm confused.  :)
[07:39] <ogra> mdz, edubuntu i386 install is golden already, i have some network probs over here that delays my rsyncs 
[07:39] <ogra> so ppc and amd64 are still oustanding, and i fear my liveCDs wont be up to date before early morning ...
[07:39] <sladen> keescook: 'edgy' or 'edubuntu'?
[07:40] <ogra> but i dont expaect any evil stuff
[07:40] <sfllaw> mdz: Pong.
[07:40] <keescook> sladen: edgy.
[07:41] <mdz> sfllaw: are you set up for testing according to plan?
[07:42] <pitti> keescook: where did you download this from?
[07:42] <keescook> pitti: http://cdimage.ubuntu.com/daily-live/current/
[07:42] <pitti> now, that looks ok
[07:42] <mdz> keescook: there's surely been a mixup somewhere and you don't have the CD you thought you had
[07:42] <sfllaw> mdz: I talked to cr3 about it and we're ready to do installations.
[07:42] <keescook> usplash was the test-screen too.  I'm going to start over...
[07:43] <mdz> sfllaw: tfheen can fill you in on which candidates are ready
[07:43] <pitti> wow, ppc's usplash loks just terrible after some seconds
[07:43] <tfheen> sfllaw: all alternates are ready, -desktop needs an update for a possible data loss issue.
[07:44] <tfheen> sfllaw: please see Testing/Current for the versions we want tested
[07:44] <pitti> keescook: what does 'lsb_release -a' say?
[07:44] <ogra> mdz, the links on Testing/Current were wrongly pointing to dapper before, if keescook used one of them he might have gotten a dapper iso
[07:45] <keescook> pitti: md5sum doesn't match... I'm redownloading
[07:45] <fabbione> mdz: i did install LAMP and apache2 was working after the reboot. i don't mind to do another test... doesn't take terribly long
[07:45] <fabbione> tfheen: ^^^
[07:45] <sfllaw> tfheen: Er...  The daily*/current is Edgy right?
[07:45] <sfllaw> I should remove the stuff on this page about Dapper?
[07:45] <mdz> fabbione: if you have time for more testing, I'd prefer that you test things which haven't been tested yet.  it really isn't important to try to roll security updates in at the last minute
[07:45] <tfheen> sfllaw: yes, please.  It's all edgy.
[07:46] <keescook> ogra: I think it was an ancient edgy ISO, actually.
[07:46] <ogra> ah
[07:46] <keescook> probably happened while URL were out of date... :(
[07:46] <fabbione> mdz: i did test what i could test already.. but i am pretty much brain dead atm.. if it's just a reinstall i can do it with no problem...
[07:46] <ogra> well, they were dapper urls until i did the first edit of the page ... i suspect i was the first who touched it after dapper testing :)
[07:47] <tfheen> ogra: uh, no.  It's been used for all the knots as well, I just haven't noticed.
[07:47] <ogra> (apart from someone flushing the results from the tables)
[07:47] <ogra> heno, k
[07:47] <ogra> err ...
[07:58] <keescook> ogra: no clue.  The ISO claimed to be 6.10, but the md5sum didn't match the 2006-09-27 build md5sum.  So... redownloading.  :)  I have lots of great notes on the earlier edgy build.  ;)
[07:58] <mdz> tfheen: jbailey mentioned you'd requested a hardware test from marc; was that completed?
[07:59] <ogra> keescook, ah :)
[08:01] <tfheen> mdz: I haven't gotten any feedback from him, nor seen anything in Testing/Current, so I assume not.
[08:04] <Xnix> is there a doc that explains how to build my own linux-restricted-modules based on a self-compiled kernel
[08:04] <Xnix> to work with my compiled version
[08:09] <lfittl> where can I find the blacklist that lists reasons why we kicked out packages? (want to know that for nvidia-cg-toolkit, we removed it, Debian still has it)
[08:15] <mdz> tfheen: that was for an earlier daily build?
[08:16] <tfheen> mdz: as I understood it, it wasn't a single-shot thing but more like "we're getting close to release now, please help testing the images".  I haven't given him an exact image to test.
[08:21] <cr3> any ideas why ubuntu 6.06.1 server boot stalls with the following message on Dual Opteron: io scheduler cfg registered
[08:24] <keescook> cr3: I've seen that on dapper too.  If I reboot, it usually goes away.  :(
[08:25] <_ion> 6.06 *is* dapper.
[08:25] <keescook> _ion: I meant, "I too, have seen it"
[08:30] <zul> later
[08:30] <keescook> c'ya zul
[08:37] <fabbione> Kamion: ping?
[08:37] <fabbione> how is the check CD supposed to be selected?
[08:38] <fabbione> (i think we forgot to update the silo text on cd)
[08:40] <mdz> tfheen: ok, so this test might be the first one on the hardware in the lab
[08:40] <tfheen> mdz: quite conceivably, yes.
[08:44] <cr3> keescook: thanks for the suggestion. however, the problem arises after selecting any of the installation options from the server CD. So, I can't really reboot otherwise I'm simply back to square one.
[08:52] <mvo> tfheen: should #61684 be fixed with the latest livefs build?
[08:53] <tfheen> mvo: yes
[08:53] <tfheen> mvo: do you observe otherwise?
[08:53] <mvo> tfheen: unfortunately yes :/ 
[08:53] <tfheen> mvo: *sigh*, ok
[08:53] <pitti> I checked it on latest powerpc livefs
[08:54] <mvo> tfheen: are there logs somewhere that I can look at ?
[08:54] <mvo> I checked it with the latest i386 too
[08:55] <tfheen> mvo: logs of the livefs build?  Yes, http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/
[08:55] <tfheen> for some reason, there is just an AMD64 build there, not an i386 and ppc build.
[08:55] <tfheen> I need to rebuild those for ubiquity anyway, so I'll do that now
[08:56] <mvo> thanks
[08:57] <pitti> bye fa
[08:57] <pitti> bye fabbione 
[08:57] <fabbione> tfheen, mdz: i have my mobile phone turned on for disaster recovery or anything slightly blocker/urgent
[09:10] <pitti> BenC: do you know how to reproduce the kernel oops when killing apport?
[09:11] <pitti> BenC: I tried it several times now on the old kernel (-8) without success
[09:14] <BenC> pitti: kill apport before it's done
[09:14] <BenC> or kill the gdb process
[09:15] <pitti> BenC: I did the former
[09:15] <pitti> BenC: I used kill -SEGV firefox-bin to have a reasonably long operation
[09:15] <pitti> but it's just killed without any oops or other negative impact
[09:15] <pitti> BenC: has this already been fixed in -8?
[09:16] <BenC> it was supposed to be
[09:16] <BenC> glad to see it worked :)
[09:17] <pitti> BenC: I'm not sure whether I ever killed apport with a pre -8 kernel
[09:29] <mdz> sfllaw: just heard from Kamion; he'll be doing some testing offline and will report any findings to you by phone
[09:35] <sfllaw> mdz: Cool.
[09:35] <mdz> sfllaw: I gave him the 8900 number from the wiki since I didn't know if you had a phone nearby
[09:38] <mvo> pitti: did you got offered a non-german keylayout by default too (when booting  with german)?
[09:38] <pitti> mvo: I think I saw that in my last amd64 install
[09:38] <pitti> mvo: but since ppc has no gfxboot, I can't test it there
[09:38] <pitti> mvo: btw, an alternate installation has the same ubuntu-desktop removal problem
[09:39] <mvo> pitti: *sigh*
[09:39] <sfllaw> mdz: Uhm.  Best number is +1-514-839-4887.
[09:39] <mdz> sfllaw:  the one I gave him is the office landline.  your mobile says EMERGENCY USE ONLY in big scary letters
[09:39] <sfllaw> Fair enough.
[09:40] <sfllaw> It was, until now.
[09:40] <sfllaw> I'll change it.
[09:41] <sfllaw> LaserJock: Please don't be #1.
[09:41] <mdz> pitti,mvo: did someone confirm with infinity that the livefs changes for that were complete?
[09:42] <mdz> he emailed me saying he would do it
[09:42] <pitti> mdz: I confirmed that it does not work on /current desktop and alternate
[09:42] <mdz> about 10 hours ago
[09:42] <mdz> (this is bug 61684)
[09:42] <mvo> mdz: I talked to him earlier and he said it should be fixed. but I haven't seen the changes myself
[09:42] <Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  http://launchpad.net/bugs/61684
[09:43] <mdz> mvo: how can we work around it?
[09:44] <mvo> mdz: there is no really good workaround short of removing /var/lib/apt/extended_states (which is wrong too, but better than the current thing)
[09:44] <mdz> mvo: removing it under what circumstances?
[09:45] <mdz> mvo: during the live build?
[09:45] <mvo> mdz: yeah, after the live build
[09:45] <mdz> tfheen: do you have access to hack that yet?
[09:45] <tfheen> mdz: no.
[09:46] <tfheen> we could sneak it in via the sysadmins.
[09:46] <mdz> tfheen: please open an RT ticket
[09:46] <tfheen> for the access or for hacking it once?
[09:46] <mdz> tfheen: access
[09:46] <mdz> might as well solve it permanently
[09:47] <tfheen> mdz: 16833 is about it.  Do you have access to look at it?
[09:47] <mdz> tfheen: I should, but I don't know the URL
[09:47] <mdz> ok, found it
[09:48] <tfheen> yeah, you can see the discussion there.  I didn't want to force anything, but if you want to make it happen, feel free to chime in.
[10:45] <tfheen> mdz: so, what do we do?
[10:47] <tfheen> I need to catch a bit of sleep to make my headache go away.
[10:47] <mjg59> mdz: I agree that we ought to update the bluez package - what we have seems a touch unstable. But that can wait until after beta.
[10:54] <mvo> mdz: I found the reason why the https://launchpad.net/distros/ubuntu/+bug/61684 is not gone away :(
[10:54] <Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [High,Confirmed]  
[10:55] <seb128> Kamion: could you promote industrial-cursor-theme when you have some time (pitti said it's fine)? no hurry, that's just to make gtk2-engines-industrial installable again
[11:07] <pygi> sivang: you still here by any chance?
[11:10] <sivang> pygi: I am
[11:10] <pygi> sivang: may I grab you for just a sec?
[11:10] <sivang> pygi: sure
[11:26] <ogra> muhahahaha 
[11:27] <pygi> ogra: and jwz would be who? :P
[11:28] <ogra> mr. xscreensaver ... he's since 100 years the screensaver maintainer 
[11:28] <LaserJock> haha
[11:29] <Ng> I thought he defected to os x because alsa was annoying? ;)
[11:30] <ogra> well, he has "kiosks in his nightclub" (his words) and wants to switch them to ltsp ...
[11:31] <ogra> haha
[11:32] <ogra> funny usecase :)
[11:33] <mjg59> No, they're web browsing things
[11:34] <mjg59> http://www.dnalounge.com/backstage/src/kiosk/
[11:38] <Keybuk> mjg59: oh, and URGENT wasn't documented last time I looked <g>
[11:38] <bioeng> Hello everyone
[11:38] <bioeng> I am trying to get some experience in electrical and software engineering
[11:38] <bioeng> now that I've dropped out of college
[11:39] <mjg59> Keybuk: Tollef added it a couple of weeks ago
[11:39] <mjg59> It was needed for the CD MD5 checking
[11:39] <mjg59> But it ought to do what you want, right?
[11:39] <bioeng> I'm trying to find out how to get that expericne
[11:39] <bioeng> Any suggestions?
[11:40] <Keybuk> mjg59: the only problem there is that the theme appears to be designed by somebody who assumed there would never be any text
[11:41] <Keybuk> if we did an URGENT to say "Will now check the root filesystem", etc.  there would always be text
[11:41] <mjg59> Keybuk: Mm?
[11:42] <mjg59> Oh, yes, it has to be done only in the case of us actually checking the filesystem
[11:42] <Keybuk> which we don't know
[11:42] <mjg59> Which is an interesting problem to solve
[11:42] <Keybuk> not without modifying, or at least driving, fsck
[11:42] <mjg59> Indeed
[11:42] <Keybuk> wouldn't usplash just timeout anyway?
[11:42] <mjg59> It ought to, yeah
[11:42] <Keybuk> and show them the console messages and fsck output underneath?
[11:42] <mjg59> Unless something is bumping the timeout and never resetting it
[11:43] <mjg59> You can flag an fs to require fsck on next boot and test this fairly easily :)
[11:43] <mjg59> Maybe we should restart usplash after fsck if it exits
[11:44] <Keybuk> that's a not unresonable short-term solution
[11:44] <Keybuk> longer term, it'd be sweet if we could detect an fsck needed, and even drive a progress bar on the usplash to show it
[11:44] <ogra> mjg59, bah, so no tabledance then :)
[11:44] <Keybuk> I'd vaguely planned to do that for edgy, but never got nearly enough tuits
[11:44] <mjg59> Keybuk: Spec!
[11:45] <mjg59> Anyway, I think usplash is pretty much feature complete now
[11:45] <mjg59> All the known bugs ought to be fixed
[11:45] <mjg59> (In bzr, not in the archive)
[11:45] <mjg59> The themes need a bit of love, though
[11:46] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/usplash-fsck-progress
[11:48] <jdong> <insert general wish for faster bzr http performance here>
[11:52] <pygi> ogra: :-/
[11:52] <ogra> i have a depends line like: syslinux [i386 amd64] , mknbi[i386]  | yaboot[powerpc]  | aboot[alpha]  | sparc-utils[sparc]  ... why does it complain about mknbi ?
[11:52] <_ion> Is usplash going to get resolution fallback support?
[11:52] <ogra> it shouldnt care about it on powerpc
[11:53] <mjg59> _ion: What do you mean by resolution fallback support?
[11:53] <Keybuk> ogra: you missed a " " there, no?
[11:53] <ogra> i dont think so ...
[11:53] <_ion> mjg59: usplash.conf on my machine contains xres=1024 yres=768 (from X config), but usplash just says "screen init failed" (AFAIR) and exits.
[11:54] <ogra> argh !
[11:54] <ogra>  EARLY_PACKAGES="xorg ltsp-client discover1 laptop-detect xresprobe esoun
[11:54] <ogra> d inputattach usplash ldm ltspfsd mknbi"
[11:54] <mjg59> _ion: It would be nice to know why it's failing :)
[11:54] <_ion> mjg59: When i manually change it to 800x600, it works.
[11:54] <ogra> indeed if the script tries to install it after debootstrapping that cant work 
[11:54] <_ion> mjg59: Yes, it would. :-) I tried to debug it, but didn't have success.
[11:54] <ogra> tfheen, still around ? 
[11:54] <mjg59> _ion: Though I admit that that's not terribly practical given the current code. God I hate you, svgalib.
[11:54] <mjg59> _ion: I'll see what I can do to make that saner.
[11:57] <jdong> mjg59: I compiled usplash from bzr, and it just segfaults when I try  to run it
[11:57] <jdong> do I have to do something special to make usplash happy?
[12:01] <mjg59> jdong: Did you install it, or just run it from the build directory?
[12:01] <jdong> mjg59: I built it in a pbuilder and installed it
[12:01] <jdong> then ran update-initramfs -u
[12:01] <mjg59> jdong: Ok. Any chance you can give me a backtrace?
[12:02] <mjg59> Running it from the console should be fine
[12:03] <jdong> gdb doesn't know any symbols.... would an strace be of any use?
[12:03] <ajmitch> mdz: what's your policy on new packages going into universe after universe freeze? up to the MOTU team to decide?
[12:03] <mjg59> jdong: Copy the files out of the build directory before they're stripped
[12:03] <jdong> mjg59: k, will do
[12:04] <fschoep> I've got a simple question - is there a devteam meeting tomorrow? It isn't listed on the Fridge it seems
[12:04] <Burgundavia> fschoep: yes
[12:05] <fschoep> Burgundavia: at 23:00 UTC?
[12:05] <ajmitch> it was said that it's cancelled due to beta release
[12:05] <mvo> there will be no dev-team meeting this week
[12:05] <Burgundavia> oh
[12:05] <Burgundavia> hmm
[12:06] <ajmitch> on u-d-a
[12:06] <mvo> mdz: would a package descriptions translation upload be ok for beta? it will update only the translated descriptions for universe + remove a incorrect Translations-ko 
[12:07] <Keybuk> he's at the dentists
[12:07] <ajmitch> poor guy
[12:07] <fschoep> OK thanks for the quick answer
[12:07] <Keybuk> still too many jelly beans
[12:08] <mvo> oh
[12:08] <mvo> poor guy