[12:01] <ogra> CarlFK, we are just ahead of time ;)
[12:02] <CarlFK> heh
[12:02] <lamont> Kamion: i386/ppc uploaded
[12:02] <CarlFK> call it breezy/tomorrow
[12:02] <lamont> actually ppc is accepted
[12:02] <lamont> i386 is ~3 minutes from likewise
[12:02] <lamont> ia64 is... mada.
[12:02] <Kamion> lamont: ~3 minutes from new
[12:02] <lamont> doh.  we had that discussion
[12:11] <Kamion> (i386 newed, btw)
[12:12] <zyga> hmm
[12:12] <zyga> is it just me or did nautilus started crashing regulary today?
[12:12] <sivang> zyga: not for me
[12:13] <zyga> hmm...
[12:13] <zyga> I'm using libnautilus-extension
[12:13] <zyga> maybe it's related
[12:15] <lamont> CarlFK: it's the script cron.daily from debian's archive, we just have _really_ fast days.
[12:15] <lamont> (and hours)
[12:19] <mjg59> mdz: sl-modem-daemon is about a meg
[12:19] <mjg59> Keybuk: Hi
[12:19] <Keybuk> 'sup
[12:20] <crimsun> mjg59: I've reuploaded 2.9.9d-6 from Debian, now just 2.9.10 needs to be dropped from the archive
[12:21] <crimsun> mjg59: thanks for keeping me on my toes
[12:23] <mjg59> Keybuk: You wanted me?
[12:23] <mjg59> crimsun: No problem
[12:23] <Keybuk> mjg59: yeah, cc'd you on the bug
[12:24] <Keybuk> someone with a cute network card/dsdt problem where their network card is pretending to be asleep during boot
[12:26] <mjg59> It's probably some bizarre interrupt issue
[12:27] <Keybuk> the attached redhat bug shows the card is in D3 sleep during boot
[12:35] <mjg59> Oh, right
[12:35] <mjg59> What fun
[12:35] <mjg59> Ok, BIOS weirdness followed by patch that's been posted to LKML
[12:35] <mjg59> Probably Dapper at this point
[12:42] <Keybuk> indeed
[12:42] <Keybuk> bugzilla should have a "fake close" button
[12:43] <Keybuk> to drag out of the woodwork the users who have been hiding and get them to wail "but this bug affects me!"
[12:50] <sivang> g'night all
[12:52] <Keybuk> hotplug is dead
[12:53] <Keybuk> ...I so love a conffile question for /etc/X11/xkb/symbols/*
[01:06] <Kamion> d-i accepted *phew*
[01:07] <Keybuk> \o/
[01:12] <lamont> Kamion: note that the first of the LiveCD fsbuilds starts in about 2 hours, unless you decide to trump it...
[01:12] <lamont> and then there's the question of whether you want the script disabled for a day or 2
[01:14] <Kamion> might as well have it run tonight, but disable after that for a bit, please?
[01:14] <Kamion> just in case
[01:16] <lamont> Kamion: ok.  ping me tomorrow to make sure i do/did it.
[01:17] <lamont> anything else before I sleep?
[01:17] <Kamion> lamont: nope
[01:24] <Keybuk> mdz is going to have a heart-attack when he gets out of bed and casually glances at the mail count in ubuntu-bugs
[01:27] <ajmitch> Keybuk: bugs closed, I hope?
[01:27] <Keybuk> ajmitch: comments from Debian
[01:27] <Keybuk> the script that imports stuff has been broken for about 6 months
[01:28] <Keybuk> I just fixed it ... and it's now catching up
[01:44] <lamont> Keybuk: you are a mean man
[01:44] <lamont> new bugs, or just comments on old ones?
[01:45] <Keybuk> comments on old ones
[01:45] <Keybuk> debzilla was still creating new bugs, just never actually filling in the comments
[01:45] <lamont> Kamion: I wonder if I can combine proxycommand and a control channel,,,
[01:46] <lamont> ah, ok
[01:46] <Keybuk> so basically it's now filling in every comment, on every release-critical and "manually related" debian bug since ~April
[01:46] <Keybuk> and then mailing them individually to ubuntu-bugs, and all the subscribers of that list
[01:46] <Keybuk> and mailing them individually to the reporter, assigned-to and cc list of each bug
[01:46] <lamont> and to think that they called _me_ the spaminator
[01:46] <lamont> (well, different "they"
[01:48] <Kamion> lamont: yes
[01:49] <lamont> Kamion: elmo would love for you to teach me how sometime.  But not this week
[01:49] <Kamion> lamont: seems to break occasionally ... race conditions if two ssh clients try to be master on the same control socket simultaneously
[01:49] <lamont> I can see that... needs to have mutual exclusion and all that, eh?
[01:50] <Kamion> lamont: ssh 4.2, mkdir -p ~/.ssh/control, 'ControlMaster auto' and 'ControlPath ~/.ssh/control/%h.%p.%r' in the relevant Host stanzas in ~/.ssh/config (or in a 'Host *' stanza at the end if you're feeling brave)
[01:50] <lamont> right now, it just sleeps 1.7 seconds after each one, so that the poor machine in the middle doesn't think it's getting DoSed
[01:50] <Kamion> lamont: you might have to put a small sleep in there to make it work reliably
[01:50] <Kamion> or leave it in there :-)
[01:52] <Kamion> if you put it in Host * or in something that covers both chinstrap and the buildds, it'll automatically reuse both ssh connections to chinstrap and tunnelled ssh connections to the buildds
[01:52] <Kamion> if you just put it in Host chinstrap, that would probably cover your immediate requirement
[01:52] <lamont> ok.  but I'm asleep now, so I'll have to stare at that next week while I'm waiting for ia64 builds to happen
[01:53] <lamont> and the goal is to reduce the number of sshd's on chinstrap, not to speed up the setup of same
[01:53] <lamont> but anyway, time for this one to, um, go to sleep
[01:55] <Kamion> lamont: yes, it will do that
[01:55] <Kamion> lamont: the same sshd will handle a number of channels, each with a session
[01:56] <bddebian> elmo: You around?
[01:57] <lamont> Kamion: btw, ia64 needs some lrm love....  I'll look at it tomorrow, but it's just another cluebat to the selection critiera that seems to have gone away when nvidia was dropped 1/2 way
[01:58] <lamont> I'll check with you before uploading same though
[01:58] <Kamion> ok
[01:58] <Kamion> about to drop offline, I imagine - night
[01:58] <lamont> yeah. ditto.  g'night
[02:04] <Keybuk> why does my update-notifier icon keep blinking ? :-/
[02:31] <`anthony> is using #!/usr/bin/env python2.4 rather than #!/usr/bin/python2.4 standard practice for Ubuntu?
[02:32] <`anthony> i'm talking about for system tools (like update-manager, bug 16087).
[02:32] <`anthony> It seems very wrong for system tools to do this.
[02:33] <dholbach> `anthony: i don't think so - i saw #!/usr/bin/env python more often
[02:33] <bddebian> elmo: If you happen to swing by: Is something up with memaid-pyqt?  I'm trying to clean up the MoM list.  If you want I'd be happy to check it out.
[02:33] <`anthony> dholbach: that's _slightly_ less bad (in this case) but it really should be an explicit path.
[02:34] <`anthony> If someone needs to install their own python (in /usr/local/bin) you really don't want the system tools using it.
[03:39] <spstarr> hmm, powernowd we shouldn't force this on for non-AMD laptop/desktops?
[03:39] <spstarr> n/m
[03:39] <spstarr> The name is somewhat misleading, as any processor supported by the kernel cpufreq driver will work, not  just  processors  supporting  AMD
[03:39] <tseng> yes.
[03:39] <bob2> tes
[03:39] <desrt> see bug 7263
[03:40] <tseng> desrt: dude i think you fixed my battery applet
[03:40] <tseng> desrt: or something.
[03:40] <desrt> tseng; i patched hal.  martin merged the patch into ubuntu
[03:40] <tseng> yeah
[03:41] <tseng> awesome stuff
[03:50] <spstarr> weeeee
[03:53] <spstarr> 3.4.91 :)
[03:53] <spstarr> very nice indeed
[04:07] <spstarr> aruh? we have no Linus sparse package? ;)
[04:08] <bob2> someone should package it now the source is actually available
[04:10] <Keybuk> Q. How are you?
[04:10] <Keybuk> A. I'm fine thanks
[04:11] <`anthony> Keybuk: No "Q. Would you like a cheaper mortgage? A. Die, spammer, die!" ?
[04:11] <Keybuk> spstarr: ya know, for a few brief moments there I thought you were trying to aim for "no linux source package"
[04:11] <spstarr> nope
[04:11] <Keybuk> `anthony: I've been replying "YES!" to those for a while now
[04:12] <`anthony> Keybuk: maybe I should see if I can get a cheap mortgage on this rental property I live in.
[04:12] <Keybuk> bah
[04:13] <Keybuk> it used to be 441 (MTV itself is 440), but now it's 442 because VH-1 (which used to be 442) has more viewers
[04:15] <spstarr> actually, where 'is' the source for it, its not on kernel.org ;)
[04:15] <tseng> id start by searching lkml.org
[04:16] <spstarr> that should still be relevant
[04:17] <spstarr> http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
[04:31] <nomed> from what i'm reading ubuntu will and doesn't use xdebconfigurator ... is there any other script that can generate an xorg.conf file for a livecd?
[04:37] <dholbach> good night
[04:38] <bob2> adios
[04:55] <mitsuhiko> hi all
[04:55] <mitsuhiko> short question to the thunderbird security hole
[04:56] <mitsuhiko> why is it not working in the ubuntu version?
[04:56] <infinity> "it"?
[04:56] <infinity> The exploit, or thunderbird?
[04:57] <magnon> Security dept has to do _something_ :)
[04:57] <mitsuhiko> infinity: the exploit (or i'm to stupid=
[04:58] <mitsuhiko> mozilla-thunderbird -compose 'mailto:someone@domain`id`'
[04:58] <magnon> mitsuhiko: isn't that a good thing?
[04:58] <mitsuhiko> magnon: question. why?
[04:59] <magnon> mitsuhiko: Why a non-working exploit is good?
[04:59] <bob2> mitsuhiko: /usr/share/doc/mozilla-thunderbird/changelog.Debian.gz
[05:01] <mitsuhiko> does this meens this thunderbird is fixed?
[05:01] <wasabi> it is fairly annoying that Debian bug mail doesn't have a link to the actual bug in it
[05:02] <bob2> mitsuhiko: why don't you just go check?
[05:02] <mitsuhiko> hm
[05:02] <mitsuhiko> no. it's not fixed
[05:02] <mitsuhiko> [alt] +[f2]  is working
[05:25] <mitsuhiko> hm. can we expect a fix in the this week?
[05:28] <wasabi> update-manager should have some option to hold a package
[05:32] <mitsuhiko> are you planning a workaround?
[05:34] <jsgotangco> there seems to be no linux-restricted-modules-386 for -9 yet?
[05:34] <infinity> mitsuhiko : It's being worked on, bugging people in a -devel channel won't make it happen faster though.
[05:34] <infinity> jsgotangco : On that right now.
[05:34] <jsgotangco> infinity, ahhh...i was testing atm, it borked nvidia heh
[05:34] <infinity> jsgotangco : Just refreshing my mirror before I do heavy testing and upload.
[05:34] <mitsuhiko> infinity: thx. i was only interested if there's something in the make :)
[06:18] <mdz> morning
[06:18] <magnon> morning
[06:18] <mdz> did we get a new d-i with the new kernel done?
[06:19] <mdz> neither did I
[06:19] <mdz> I always say 'morning'
[06:19] <infinity> Does d-i use lrm?  If so, then the answer's probably "no", since I'm doing the lrm ABI bump right now.
[06:19] <elmo> 17's in the archive
[06:22] <crimsun> mdz: is it possible for us to demote vlc to multiverse in time for Breezy?
[06:23] <crimsun> mdz: (one of the build-dependencies is in multiverse)
[06:24] <elmo> crimsun: it's in universe
[06:24] <elmo> (so mdz probably doesn't care much)
[06:24] <elmo> but why does it b-d on multiverse?  it doesn't in Debian
[06:25] <mdz> infinity: the d-i build doesn't, no
[06:25] <crimsun> elmo: right, but that means that vlc will never build using the default b-d from Debian, so to make it build, we'd have to strip the ffmpeg b-d, which makes it fairly useless
[06:25] <infinity> mdz : Ahh, good.
[06:25] <crimsun> elmo: vlc b-ds on libpostproc-dev, which is in multiverse
[06:26] <elmo> crimsun: for values of fairly useless as in "as useful as it is in Debian" ?
[06:26] <infinity> ... because libpostproc-dev is built from ffmpeg, which was recently punted to multiverse?
[06:26] <crimsun> infinity: exactly
[06:26] <elmo> ffmpeg isn't in multiverse
[06:27] <infinity> Filename: pool/multiverse/f/ffmpeg/libpostproc-dev_0.cvs20050626-1ubuntu1_i386.deb
[06:27] <elmo> sigh
[06:27] <infinity> Well, that binary is, which means the source would almost have to be, no?
[06:27] <elmo> the source should be
[06:27] <elmo> well, no
[06:27] <crimsun> the source is in universe
[06:27] <elmo> universe shouldn't build multiverse binaries
[06:27] <elmo> demoting ffmpeg is excessively non-obvious
[06:27] <infinity> Oh, we have universe source building multiverse binaries?... Neat.
[06:28] <elmo> as it pulls whole swathes of stuff into multiverse
[06:28] <infinity> \o/
[06:28] <elmo> and I don't think we should encourage users to add multiverse to their sources.list without good reason
[06:28] <infinity> "It's filled with crack; you love crack" is enough reason for most of them.
[06:28] <lifeless> is there any change in status for teh mac laptotop wifi cards ? the builtin ones
[06:29] <jk-> lifeless: nope
[06:29] <lifeless> I've heard rumours they can be made to work. :[
[06:29] <Amaranth> lifeless: not a chance
[06:29] <lifeless> ah well.
[06:29] <Amaranth> lifeless: with some fun mol hackery you can make it work
[06:29] <jk-> someone's working on building a driver, but it's a long, slow process.
[06:29] <elmo> Amaranth: that's not true
[06:29] <elmo> there are people working on reverse engineering the driver
[06:29] <crimsun> libpostproc-dev is most problematic, because without it, vlc will not build with ffmpeg support without much hacking (e.g., including ffmpeg snapshot in diff.gz, which is much ugliness)
[06:29] <elmo> crimsun: what IS libpostproc-dev?
[06:30] <elmo> and why does it need to be in multiverse?
[06:30] <mdz> infinity: I believe Kamion uploaded d-i before the kernel was built; so perhaps it dep-waited on it and built?
[06:30] <elmo> mdz: as I said, 17's in the archive
[06:31] <infinity> postproc is a postprocessing library, I see no reason why it would need to be in multiverse.
[06:31] <mdz> elmo: ah, missed that
[06:31] <infinity> I could see how one of it's deps (avcodec) could need to be in multiverse, except that it's not.
[06:31] <infinity> Oh, wait, it is now.
[06:31] <mdz> anyone know if Kamion did install CD builds?
[06:32] <infinity> I was looking at the wrong apt-cache stanza.
[06:32] <mdz> I dunno an easy way to check the version of d-i on the CDs
[06:32] <infinity> Or, no it's not.  I just can't read.
[06:32] <infinity> Right, so postproc (multiverse) doesn't appear to need to be in multiverse, as it's only dep (avcodec) is in universe...
[06:32] <infinity> And postproc itself shouldn't contain any terribly iffy code.
[06:32] <crimsun> and libpostproc's license is GPL
[06:33] <infinity> Unless it infringes an Adobe patent for linear editing or something.
[06:33] <elmo> breezy's kernel has degraded horribly in terms of xmms stutter :(
[06:33] <infinity> (Well, I think half the archive probably infringes Adobe patents in some way, I know the GIMP hits several)
[06:33] <crimsun> elmo: are you using the esd output or the ALSA output?
[06:34] <elmo> OSS
[06:34] <mdz> elmo: for me, xmms sucks at playing mp3s.  xmms plays other things fine, and other apps play mp3 fine.
[06:34] <mdz> didn't matter what xmms output I used
[06:34] <elmo> mdz: these are oggs
[06:34] <crimsun> whoa, that shouldn't be messed up
[06:34] <elmo> and hoary on this box was fine - it's definitely since I upgraded to breezy
[06:34] <elmo> and I'm even running a "real" breezy kernel too
[06:34] <elmo> (i wasn't for hoary)
[06:36] <crimsun> elmo: does it occur regardless of switching to the ALSA output?
[06:37] <elmo> dunno, trying that
[06:38] <fabbione> morning
[07:10] <pitti> Good morning
[07:11] <ajmitch> morning pitti
[07:16] <bob2> shouldn't ia32-libs include libz?
[07:16] <fabbione> hey pitti
[07:18] <fabbione> hey pitti
[07:18] <fabbione> pitti: i am going to do that hoary security thing today
[07:18] <fabbione> been pretty busy with other stuff yesterda
[07:18] <fabbione> +y
[07:30] <infinity> bob2 : No, it depends on lib32z1, which includes it.
[07:53] <fabbione> mdz: ping?
[08:04] <pitti> infinity: hi! can you please have a look why mozilla-firefox_1.0.7-0ubuntu0.0.1 did not build?
[08:04] <pitti> infinity: I did not get a failure log
[08:05] <infinity> Ugh, why not -0ubuntu04.10?
[08:05] <infinity> Meh.
[08:07] <fabbione> who is experienced with ubuntu-meta?
[08:08] <infinity> pitti : Did you accept hoary and warty at the same time?
[08:08] <infinity> pitti : Looks like the orig didn't make it in in time for the warty builds, or something.
[08:08] <infinity> fabbione : Define experienced.  I've updated it a few times, and fiddled with the seeds and such.
[08:09] <fabbione> infinity: i need to remove powermanagement-interface from sparc desktop
[08:09] <fabbione> i need to understand if i have to do it via seeds or directly into ubuntu-meta lists
[08:10] <fabbione> + i would love to understand why totem is trying to pull in totem-xine from universe
[08:10] <infinity> It depends on -gstreamer | -xine
[08:10] <infinity> Is -gstreamer uninstallable for you, or otherwise something apt would skip?
[08:10] <fabbione> oh i see
[08:11] <fabbione> right
[08:11] <fabbione> yes they have a very strict version depends
[08:11] <fabbione> ok.. how do i kill the other package instead?
[08:12] <infinity> So, you're saying we want pmi on all arches except sparc?
[08:13] <fabbione> i don't know about the other arches, but pmi depends on acpi-support
[08:13] <infinity> Is it hideously broken on sparc and shouldn't build there at all, or?...
[08:13] <fabbione> and sparc has no acpi
[08:13] <fabbione> and it has been built by mistaker
[08:13] <fabbione> -r
[08:13] <infinity> Does sparc have acpi-support?
[08:13] <fabbione> nope
[08:13] <fabbione> NFU
[08:13] <infinity> I mean the package.
[08:13] <fabbione> nope
[08:14] <infinity> Hrm.  Then it shouldn't be happening at all.
[08:14] <infinity> If pmi depends on acpi-support and there is no acpi-support for sparc, then it shouldn't get included, afaik.
[08:15] <infinity> Or... It's a germinate bug.  Hrm.
[08:15] <infinity> Or a misfeature.
[08:15] <fabbione> this is the last glitch to make sparc-desktop installable
[08:16] <infinity> Yeah, hppa will have the same problem.
[08:16] <fabbione> i am checking how the update algos work
[08:16] <infinity> As will powerpc, which is an actual release arch.
[08:17] <fabbione> perhaps in the first place it is added automatically and you need to remove it manually after
, I can just make pmi arch-dependant in the seeds, that will fix it.
[08:17] <fabbione> desktop/sparc: Skipping package acpi-support (unavailable)
[08:17] <infinity> But this still seems broken.
[08:18] <pitti> infinity: I did not accept either of them yet
[08:18] <fabbione> Added powermanagement-interface to desktop-sparc
[08:18] <fabbione> it gets readded automatically
[08:18] <pitti> infinity: and the orig was uploaded to breezy first
[08:18] <infinity> pitti : The orig in breezy is for a different package.
[08:18] <infinity> pitti : So, if he did hoary with -sa, and warty without -sa (which would be correct), hoary needs to be accepted before warty can build.
[08:19] <infinity> fabbione : yeah, I'll just make it arch-specific in the seeds and refresh.
[08:19] <pitti> infinity: ouch, why a different one? that's stupid...
[08:19] <fabbione> infinity: ok, so are you going to take care of it?
[08:19] <infinity> fabbione : I'll bug Kamion later about how it's SUPPOSED to work. :)
[08:19] <fabbione> infinity: ok thanks
[08:19] <infinity> fabbione : yeah, it affects everything !i386/amd64, so it's not just an "SCC port" problem. :)
[08:19] <fabbione> from a first shot this seems to be the only glitch left
[08:20] <infinity> pitti : Uhm.  Huh?
[08:20] <pitti> infinity: indeed there is an orig.tar.gz in the queue - that means Diziet accidentialyl uploaded with -sa for hoary?
[08:20] <fabbione> infinity: oh well :)
[08:20] <infinity> pitti : breezy ships "firefox", not "mozilla-firefox"
[08:20] <infinity> pitti : Hence -sa is required for hoary.
[08:20] <pitti> infinity: ah, I see - mozilla-firefox vs. firefix
[08:20] <fabbione> lol.. firefix :)
[08:20] <infinity> If only.
[08:20] <pitti> infinity: bah, that's ugly - we need to test both debs, and we want to release them at the same time
[08:21] <pitti> infinity: any workaround?
[08:21] <infinity> pitti : Then do manual builds... Using the upload queue as a testbed is pretty insane.
[08:21] <infinity> pitti : I mean, what if we find out they're buggy?... New uploads with new version numbers to fix them?.. Ugh.
[08:22] <pitti> infinity: they should not be buggy, the question was more like if they built at all, and Ian wanted a clean build
[08:22] <pitti> infinity: anyway, so I can't release them all together, I suppose
[08:22] <infinity> Clean builds are easy enough to accomplish.
[08:22] <infinity> Toss me the warty sources, and I'll do a clean chroot build here.
[08:22] <pitti> infinity: I told him to use local builds, but he was sure that they work
[08:23] <pitti> infinity: chinstrap:~pitti (mozilla-firefox_1.0.7-0ubuntu0.0.1)
[08:23] <infinity> Maybe I need to document "how to make your chroots behave just like buildds, so you don't have to abuse the buildds for test builds"
[08:24] <lifeless> how do you get middle and right mouse clicks on a powermac ?
[08:24] <pitti> lifeless: F11 and F12 by default
[08:24] <infinity> Ew.
[08:24] <lifeless> pitti: thanks
[08:24] <infinity> lifeless : Buy an external mouse iwth more buttons.
[08:24] <pitti> or that :-)
[08:24] <lifeless> infinity: its my partners laptop
[08:25] <infinity> lifeless : Or trade in the powerbook for a thinkpad. :)
[08:25] <lifeless> infinity: I don't see that going down well ;0
[08:25] <lifeless> infinity: she -loves- mac. enough said
[08:25] <lifeless> I had a hoary partition
[08:25] <lifeless> and I'm trying the upgrade on that to breezy
[08:26] <lifeless> hoary couldn't drive the trackpad :[
[08:26] <infinity> So, she owns several iPods, and defends Steve Jobs' every move?
[08:26] <lifeless> nope
[08:26] <lifeless> just attached to the design
[08:26] <lifeless> had one ipod, it got driven over by a truck
[08:26] <infinity> A fitting end.
[08:26] <lifeless> heh
[08:30] <fabbione> infinity: can you be so kind to debootstrap a buildd chroot on ia64?
[08:30] <fabbione> infinity: it seems there is a bug in /usr/lib/debootstrap/scripts/breezy that affects only sparc and ia64
[08:31] <fabbione> but i need to be sure before fixing it
[08:31] <fabbione> you will get the error almost immediatly
[08:32] <infinity> What's this bug?
[08:32] <infinity> (-ENOTIME to play right now)
[08:32] <fabbione>        add () { if [ "$ARCH" = "$1" ] ; then eval "$2=\"\$$2 $3\""; fi; }
[08:33] <fabbione> I: Retrieving Release
[08:33] <fabbione> I: Retrieving Packages
[08:33] <fabbione> I: Validating Packages
[08:33] <fabbione>  /usr/lib/debootstrap/scripts/breezy: line 20: libc6-dev-sparc64=-dev-sparc64 : command not found
[08:33] <fabbione> but that part of the script is called only on sparc/ia64
[08:33] <infinity> Pretty.
[08:34] <infinity> Broken the same way in Debian?
[08:34] <fabbione> dunno..
[08:34] <infinity> Oh, wait, no it's not.
[08:34] <infinity> I think I tripped on sometihng like that when trying to debootstrap breezy (variant=buildd) on the sparc here ages ago, and whined to you about it.
[08:34] <infinity> deboostrapping sid worked fine.
[08:35] <fabbione> yeah it's only on buildd variant
[08:35] <infinity> And unless we've not had to rebuild an ia64 chroot for months (which seems unlikely, given that we built new ones for -autotest not that long ago), it's okay too.
[08:35] <infinity> So, it's sparc/buildd that's broken in special ways.
[08:36] <infinity> Probably the base package set broke in a way that's confusing the rest of the script in oddly undebuggable ways.
[08:36] <infinity> (since variant=buildd still uses a slightly static list, compared to the auto-guessed lists for the regular debootstrap)
[08:37] <infinity> Oh look, it's a Kamion.
[08:37] <fabbione> ODDD
[08:37] <infinity> Kamion : It is intentional behaviour for ubuntu-meta/germinate/whoever to pull in packages whose dependencies aren't satifiable?
[08:38] <fabbione> infinity: you know what.. if i run sh -x deboostrap... it works..
[08:38] <fabbione> now..
[08:39] <fabbione> ah no
[08:39] <fabbione> it still fails
[08:39] <infinity> Kamion : s/It is/Is it/
[08:42] <fabbione> infinity: it looks to me that also ia64 is affected...
[08:42] <fabbione> because it's the shell line that's broken
[08:42] <infinity> Hrm.  I'll have to test later, then.
[08:43] <infinity> Oh, wait.  We don't use the current debootstrap on the buildds.
[08:43] <infinity> We just ship a breezy script for an older backport.
[08:43] <infinity> That's probably why.
[08:43] <infinity> It likely broke in the great reorg of debootstrap 3.x
[08:44] <fabbione> infinity: ihhh
[08:47] <fabbione> ahhh here it is
[08:47] <fabbione> infinity:       add () { if [ "$ARCH" = "$1" ] ; then eval "$2=\"\$$2 $3\""; fi; }
[08:47] <fabbione>  <-
[08:47] <fabbione> it chokes on pkg names with "-"
[08:48] <fabbione> it's reproducible on all arches
[08:48] <fabbione> infinity: if you edit that file and add something like: add $ARCH "dselect" will work
[08:49] <fabbione> if you do instead: add $ARCH "x-common" will choke
[08:50] <infinity> Ahh, so it only breaks on sparc, because only sparc has the crazy package in its list.
[08:50] <infinity> Makes sense.
[08:51] <infinity> Feh.  How/why did libxp6 get pulled back into main (and into -desktop, no less)?
[08:51] <fabbione> infinity: debian doesn't choke because it doesn't have that function
[08:51] <fabbione> infinity: it is required.. mdz told me to seed it
[08:52] <Chipzz> hmmm
[08:53] <sivang> Morning all!
[08:54] <daniels> infinity: groff, I think.
[08:54] <Chipzz> just wondering... why are debootstrap scripts in /usr/lib ? they are arch:all, and perl has perl-modules in /usr/share too...
[08:54] <infinity> daniels : No, nothing depends on it, it was seeded to -desktop for the benefit of people installing 3rd-party proprietary apps.
[08:54] <infinity> Ugh.
[08:54] <infinity> Oh well.
[08:55] <infinity> Chipzz : Holdover from when they used to be arch:any, I suspect.
[08:55] <daniels> fucking christ.
[08:55] <infinity> Chipzz : debootstrap used to build arch-specific packages for each arch, with static package lists.
[08:55] <Chipzz> infinity: that would explain
[08:56] <infinity> fabbione : ubuntu-meta fixed.
[08:57] <Chipzz> are things that can be executed/"run" allowed to go in /usr/share if they are arch:all? I don't think the FHS says anything about that
[08:57] <fabbione> infinity: danke
[08:57] <infinity> Chipzz : If not executed directly, they CAN be, but /usr/lib/package is still the standard place for most "package internal binaries", which includes scripts.
[08:58] <fabbione> brb
[09:09] <sivang> mmm, nvidia module missing after last update..knonw?
[09:13] <infinity> You mean "no matching restricted modules for the new kernel" (That's known, new upload on the way), or "I'm using the old kernel, but something's hideously broken"?
[09:13] <infinity> If it's the latter, I want details. :)
[09:15] <sivang> infinity: Seems it's the first one :)
[09:15] <infinity> Oh, good.  That's an easy fix, then.
[09:15] <infinity> The only holdup on the upload is that I'm fixing other bugs at the same time as doing the ABI bump.
[09:15] <infinity> So, give it a bit of time.
[09:15] <sivang> infinity: it's <IP_ADDRESS> but the corrosponding modules pkg not installabe yet ;-)
[09:16] <sivang> infinity: k, there a way to revert back , or shoudl I just boot with the previous kernle?
[09:21] <infinity> Boot with the -8- kernel, you still have the matching l-r-m package for that installed.
[09:21] <infinity> Nothing to "revert".
[09:21] <sivang> infinity: just did :)
[09:23] <sivang> infinity: I'm curious to know what causes the lrm of a previous kernel to not be availabe anymore, that is I've had times when the new kernel was installed, broken , and I tried to use he previous kernel with it's lrm and it was "removed" ..
[09:26] <infinity> sivang : It shouldn't get removed automatically, ever.
[09:26] <infinity> sivang : Unless you're using aptitude, and it's ditching old linux-image and l-r-m packages when linux-foo is upgraded, but that just sounds evil.
[09:57] <\sh> daniels: #15720 -> dapper
[09:58] <daniels> yeah
[10:14] <Kamion> infinity: which uninstallable packages in particular? ubuntu-meta will certainly just take every top-level thing in the seed; germinate will take them, but will print an error
[10:14] <Kamion> daniels: I stopped groff depending on libxp6 with that vile hack in -10
[10:14] <daniels> oh
[10:14] <daniels> so why's it in main still?
[10:14] <Kamion> 07:54 < infinity> daniels : No, nothing depends on it, it was seeded to -desktop for the benefit of people installing 3rd-party proprietary apps.
[10:15] <daniels> gnrgh
[10:15] <daniels> i was hoping infinity was just talking out of his arse
[10:15] <Kamion> see the seed changelog
[10:16] <Kamion> it has the relevant bug reference
[10:16] <daniels> the baz changelog?
[10:17] <Kamion> yeah
[10:19] <daniels> Modified-files: desktop
[10:19] <daniels> New-patches<EMAIL_ADDRESS>[10:19] <daniels> Summary: libxp in Desktop
[10:22] <fabbione> yes i did that commit.. it's going to stay there
[10:23] <daniels> as long as it never becomes my problem
[10:23] <Burgundavia> jdub, can I blog about the fridge yet?
[10:31] <jsgotangco> Burgundavia, it doesn't look like it's finished yet
[10:35] <infinity> Kamion : See the last seed commit, and the -meta refresh.  Granted, packages that depend on arch-dependant packages should be listed in P-a-s, and never make it to the archive in the first place, but it seems a bit weird/wrong for such uninstallable packages to get included.
[10:37] <Kamion> infinity: er dude - powerpc has powermanagement-interface
[10:39] <Kamion> infinity: mmm, yeah, not sure which layer is properly responsible for that. I think the answer is that we should have britney runs for hppa/ia64/sparc so that we can see their uninstallables, then we'd just have fixed them ages ago
[10:43] <seb128> hi
[10:46] <infinity> Kamion : It has it, but it depends on acpi-support, which powerpc doesn' thave.
[10:47] <infinity> Kamion : Oh, the dependency is arch-specific too.  Feh.  Should just fix pmi, then.  Didn't realise it could work without it.
[10:47] <mvo> hey seb128
[10:48] <seb128> Hi mvo
[10:48] <infinity> Kamion : If you want to revert the seed/-meta changes, I can just fix pmi...
[10:49] <infinity> Or, better, have fabbione fix pmi. :)
[10:49] <infinity> Oh, no, wait.
[10:50] <infinity> It still will only work on i386/amd64/powerpc anyway.
[10:53] <Kamion> and I think ia64 has acpi?
[10:53] <Kamion> it does indeed. please add ia64 back too
[10:54] <seb128> pitti: around?
[10:54] <infinity> Meh. :)
[10:54] <Kamion> infinity: the pmi script is different on powerpc; it uses pbbuttonsd there
[10:54] <Kamion> no fixing needed :)
[10:54] <infinity> Kamion : Yeah, I just noticed that.
[10:54] <Kamion> infinity: also, http://people.ubuntu.com/~cjwatson/testing-ports/, have a nice day ;)
[10:54] <Kamion> (just created)
[10:56] <infinity> I'll attack some of the ia64 stuff later.  The rest is so clearly SEP.
[10:56] <infinity> :)
[10:57] <Kamion> I should do universe at some point too, but that's a start
[10:58] <infinity> Well, until main is in shape for a port, universe is a moot point.
[10:58] <Kamion> lamont-away,fabbione: you two might want to look at http://people.ubuntu.com/~cjwatson/testing-ports/ too
[10:58] <Kamion> infinity: I was thinking more for the big-three arches
[10:58] <\sh> Kamion: will sparc{32/64} become an official arch for ubuntu?
[10:58] <infinity> Alright, seeds fixed.  You want to deal with updating -meta again when your seed mirror thingee runs?
[10:59] <Kamion> \sh: it'll need more interest (both users and developers) first
[10:59] <Kamion> infinity: sure
[10:59] <infinity> Kamion : Oh, yes, britney runs for universe for the release arches would be much appreciated.
[10:59] <Kamion> meh, I guess I'll have to rebuild CDs for that
[10:59] <Kamion> hope it didn't affect the live CDs
[11:00] <infinity> The last -meta refresh would have, cause it added libxp6 to all -desktops.
[11:00] <fabbione> Kamion: cool
[11:00] <Kamion> hm, I have to wait for new l-r-m anyway
[11:01] <infinity> Well, it's uploaded now.
[11:01] <\sh> Kamion: when u know a good (OSS) driver for a wildcat III 3d card for our sun blades 100 then I could test ubuntu on some blades here ,-)
[11:01] <infinity> Shouldn't be too long to build.
[11:01] <Kamion> \sh: I know nothing about sparc
[11:01] <infinity> Sparc is all about the serial console love.
[11:01] <fabbione> Kamion: does that output include universe?
[11:01] <Kamion> fabbione: no, as mentioned above ...
[11:02] <Kamion> I think I know how to do that now though, so I can sort it out later
[11:02] <fabbione> no that's ok!
[11:02] <fabbione> main is more than enough
[11:02] <Kamion> it'll be hyoooooge
[11:02] <\sh> infinity: not at all...we use the stoopid blades only for some hp openview client stuff and some other nasty things..so running 3 tfts here with three wildcat III 3d accel cards on slowlaris 8
[11:03] <dholbach> hello!
[11:03] <mvo> hi dholbach
[11:03] <infinity> Hrm.
[11:03] <dholbach> hey mvo
[11:03] <fabbione> Kamion: that's why .)
[11:03] <infinity> Kamion : What's the deal with "everything from xorg is uninstallable, EEK!" in the release arch breezy testing output?
[11:03] <infinity> Kamion : That seems... Wrong.
[11:04] <Kamion> infinity: build skew with x-common or something?
[11:04] <Kamion> there were three X-related uploads this morning
[11:04] <Kamion> BTW, I need a fairly stable archive starting nowish
[11:04] <infinity> x-common shouldn't affect it.
[11:05] <Kamion> britney output's generally light on detail - you need to have a test system you can do 'apt-get install' on to actually see the causes
[11:05] <infinity> Yeah, and apt-get install works here, hence the confusion..
[11:06] <fabbione> Kamion: that output is weird.. because i get the same using apt-get install ubuntu-desktop (X can't be installed).. but if i do it manaullt.. apt-get install xwindows-core-crack-whatever.. it just works
[11:06] <fabbione> Kamion:  i wonder if that could be an apt problem
[11:06] <Kamion> unlikely
[11:07] <lamont> Kamion: dist-upgrade vs install?
[11:07] <Kamion> every single time I've seen somebody attempt to blame the packaging toolchain for britney output, it has been the packages' fault ;)
[11:07] <infinity> No, it means something ubuntu-desktop depends on is breaking X, in that case.
[11:07] <fabbione> lamont: fresh install
[11:07] <Kamion> infinity: britney doesn't test co-installability, only installability of single packages
[11:07] <fabbione> Kamion: oh i am not blaming.., i want to understand :)
[11:07] <Kamion> if it says xserver-xorg-core is uninstallable, it means on its own
[11:07] <infinity> Kamion : Yes, I was explaining what fabbione saw, not britney.
[11:08] <Kamion> ah, right
[11:08] <Kamion> fabbione: one possibility is that you have packages installed which are no longer in the archive, or which are not in main
[11:08] <infinity> Kamion : britney's output is just very wrong in this case, probably caught the exact half hour where something was broken.
[11:08] <fabbione> Kamion: unlikely.. it's a fresh breezy debootstrap + apt-get install ubuntu-desktop
[11:08] <infinity> Oh, that half hour is NOW. :)
[11:09] <fabbione> Kamion: there 2 failures.. one related to pmi and one to xorg
[11:09] <fabbione> but install xorg alone does work..
[11:09] <fabbione> so i guess i will need to recheck with the new ubuntu-meta
[11:09] <Kamion> I'm just uploading that
[11:10] <infinity> Found it.
[11:10] <Kamion> can I just express general annoyance at an ubuntu-meta upload for unreleased arches at a point when we're trying to do a CD release? :P
[11:10] <infinity> Kamion : It also pulled in the libxp6 thing, which was for all arches.
[11:10] <Kamion> well, that's true
[11:12] <Kamion> yeah, never mind me, I'm just undercoffeed and grumpy
[11:12] <\sh> what the hell...why is xorg being removed?
[11:12] <lamont> \sh: because it loves you
[11:12] <\sh> come on guys, who did that
[11:13] <Kamion> \sh: read the scrollback
[11:14] <\sh> Kamion: yeah..got it...but I have to fight now with 2 people here running breezy on their laptops and they did a dist-upgrade
[11:14] <Kamion> don't do that then
[11:15] <infinity> Kamion : xorg uninstallibility fixed.  Go britney.  (We need more of her)
[11:16] <Kamion> what was the problem?
[11:16] <\sh> Kamion: it's too late..."don't restart/reboot/shutdown your laptop" is my current warning now..but anyways..now I got the blame
[11:16] <infinity> Granted, I would have seen the bug the next time I tried to upgrade, which is normally nore often than I'd look at testing output. :)
[11:16] <infinity> Kamion : x-common grew a conflict against xfree86-common.. Which xorg-common provides.
[11:16] <infinity> TOO MANY COMMON PACKAGES.
[11:16] <lamont> Kamion: disabling the daily livecd runs now.  you want dailyDI disabled as well?
[11:17] <Kamion> \sh: sorry, I've little sympathy for people who dist-upgrade on a development branch without checking the list of packages that are going to be removed and making sure they're sane. They should consider it as an educational exercise for next time. :-)
[11:17] <Kamion> lamont: yeah, although I hope it won't matter
[11:17] <lamont> Kamion: ++
[11:17] <Kamion> infinity: hah
[11:17] <lamont> Kamion: you're in manual mode for the next few days then
[11:17] <Kamion> that's fine
[11:19] <\sh> Kamion: don't worry...u know, I'm sitting here in the NOC and have a screensaver on my windows machine which says: "This is the Place of our Ubuntu Supporter -> Please kick him when something's wrong" ... well, to point this out: I don't like SM ;)
[11:23] <pitti> Mithrandir: here?
[11:25] <Kamion> hmm. I have a nasty suspicion that universe britney runs will take longer than the cron.daily interregnum
[11:25] <Kamion> that's kind of annoying - I might have to run them on a mirror instead
[11:27] <infinity> Kamion : lrm is all uploaded, you can NEW it at will.  You may want the new, not-completely-broken x-common (1.08) before you start building images, though.
[11:28] <\sh> did I say that I hate skype?
[11:32] <sivang> \sh: use linphone :)
[11:32] <sivang> \sh: I use it with sipgate.de ;-)
[11:32] <sivang> works smoothly
[11:32] <\sh> sivang: I'm not using skype anyway...but look at #16107 this annoys me...the distro is being blamed for closed source developers mistakes
[11:34] <sivang> \sh: bah, I see
[11:35] <Mithrandir> pitti: pong
[11:35] <pitti> Mithrandir: do you happen to know about any plans to release a new tbird?
[11:35] <pitti> Mithrandir: and do you feel like updating tbird for our releases?
[11:40] <Kamion> lrwxr-xr-x root/root         0 2005-09-23 10:17:20 ./usr/share/isdn/2.6.12-9-amd64-generic -> 2.6.12-8
[11:40] <Kamion> infinity: what's that about?
[11:40] <Kamion> hmm, avm-fritz-firmware is still at 2.6.12-8
[11:40] <Kamion> is that intentional?
[11:41] <Kamion> I've newed that lot, but it might need further fixing
[11:42] <pitti> Kamion, seb128: do you see any reason to keep libzvt2 in main? it seems to be useful for gnome 1 only...
[11:42] <pitti> seb128, Kamion: (gnome-libs source)
[11:43] <seb128> pitti: why is it a main package?
[11:43] <Kamion> libzvt-dev's in the supported seed
[11:43] <Kamion> I have no problem removing that if nothing else uses that (check germinate rdepends!)
[11:43] <pitti> right, but that seems pretty useless; if it is needed, it should be a dependency IMHO
[11:44] <Kamion> * Reverse Build-Depends:
[11:44] <Kamion>  +- libgtk-perl
[11:44] <pitti> Kamion: I poked in the rdepends, I did not see anything that would hold it - and if there was, we don't need to seed it either, right?
[11:44] <pitti> Kamion: that's universe
[11:44] <Kamion> that's true
[11:44] <Kamion> go ahead and unseed it
[11:44] <pitti> there's libgtk2-perl
[11:45] <pitti> (and similar for the other packages, like gtk2-print-perl, and so on)
[11:45] <Mithrandir> pitti: for the mailto:`command` stuff?
[11:45] <pitti> Mithrandir: yes, and there are some other vulns as well - http://www.mozilla.org/security/announce/mfsa2005-58.html
[11:46] <pitti> Mithrandir: the shell injection patch is easy and will apply cleanly to the current package
[11:46] <pitti> Mithrandir: I have a bulk version of all the other patches (not separated, though)
[11:49] <Mithrandir> pitti: are you thinking "update to newer upstream version" or trying to backport the changes?
[11:49] <pitti> Mithrandir: if there is a new upstream, and the diff is similarly sane as Mozilla and ffox, the new upstream would be fine
[11:50] <pitti> Mithrandir: otherwise, throwing the bulk patch on our current version should work
[11:50] <Mithrandir> pitti: I can take a look.
[11:50] <pitti> Mithrandir: but the shell injection is pretty bad and should be fixed asap
[11:51] <ajmitch> hm, no doko today?
[11:51] <pitti> Mithrandir: please look in chinstrap:~pitti/{mfsa2005-58-ff10.diff,mfsa2005-58-moz17.diff}
[11:51] <lamont> he might still be sleeping, or in a room that has no network
[11:52] <dholbach> ajmitch: he's at DevJam (oldenburg, afaik)
[11:52] <lamont> ajmitch: ^^
[11:52] <ajmitch> dholbach: ah, I see
[11:52] <lamont> dholbach: he arrived yesterday.  haven't seen him yet today
[11:52] <ajmitch> dholbach: I'm just doing some wx fixing :)
[11:52] <dholbach> maybe he went on holiday instead
[11:52] <Mithrandir> pitti: scp: /home/pitti/mfsa2005-58-ff10.diff: Permission denied
[11:52] <infinity> Kamion : Dang, missed that one, new upload coming. :/
[11:52] <dholbach> :-p
[11:53] <lamont> infinity: you're doing a new lrm???
[11:53] <pitti> Mithrandir: sorry, try again
[11:53] <Mithrandir> pitti: thanks
[11:53] <lamont> infinity: if so, please make ia64 stop trying to build/install nvidia, since we dropped it elsewhere in the process....
[11:54] <infinity> lamont : It's not, is it?
[11:54] <lamont> see the log: FTBFS
[11:54] <infinity> lamont : If it was, it would be FTBFS right now, and it isn't.
[11:54] <infinity> lamont : You're one revision behind, dude.
[11:54] <lamont> ah, cool.  last looked at -4.4
[12:02] <pitti> does anybody have a scanner and a powerpc?
[12:08] <lamont> pitti: I will come monday night...
[12:08] <lamont> HP-PSC 2400, and a colored G3
[12:08] <ajmitch> pitti: yes, but running hoary
[12:08] <ajmitch> similar vintage to lamont's G3, I guess
[12:09] <pitti> ajmitch: any chance you could try xsane on a current breezy live CD?
[12:09] <ajmitch> pitti: sure, if I can wget one in time :)
[12:09] <pitti> ajmitch: I'm asking because of https://bugzilla.ubuntu.com/show_bug.cgi?id=10573
[12:10] <Mithrandir> pitti: I'm wondering if we should patch in the experimental genesys backend in sane-backends.  It works fine for me at home.
[12:10] <ajmitch> it's a usb scanner, so I know it works on i386
[12:10] <mvo> pitti: do you plan a upload of xsane? I have a translation for the desktop file I would like to add
[12:10] <ajmitch> pitti: wgetting now
[12:11] <infinity> Kamion : Fixed lrm uploaded; sorry. :/
[12:11] <infinity> Kamion : You'll need to NEW it again when it builds.
[12:11] <pitti> Mithrandir: no idea, I am clueless about scanners (I don't have one)
[12:11] <Kamion> ok, will do
[12:11] <Kamion> thanks
[12:11] <pitti> ajmitch: thanks
[12:11] <pitti> mvo: no, not until I have a patch to apply at least
[12:12] <Kamion> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html looking much healthier now
[12:13] <Mithrandir> pitti: I can try applying the change, I don't know the code base well enough to really have any idea if it works and if it breaks something else in a subtle way..
[12:14] <Mithrandir> pitti: (the chunderbird change)
[12:14] <infinity> Kay, and avm-frtiz* should be fixed with that upload, so that just leaves rrdtool and language-support.
[12:15] <ogra> Kamion, did you get my message yesterday? the netcfg error in the installer is still there, telling me to file a bug if i see it...
[12:15] <pitti> Mithrandir: oh, I did not understand the patches either - I just rely on testing
[12:16] <pitti> Mithrandir: for understanding them, looking at the patches is not enough, one needs to read the complete source
[12:16] <Mithrandir> pitti: I'm not that insane.  Yet, at least.
[12:16] <pitti> seb128: if you print something, do you get an icon in the tray, like in hoary?
[12:16] <infinity> Kamion : The rrdtool thing looks like a universe->main promotion of rrdtool is required...
[12:17] <Diziet> kamion: JOOI, are the installer udebs supposed to be in archive.ubuntu.com ?
[12:17] <seb128> pitti: lemme try
[12:17] <pitti> Mithrandir: me neither :-)
[12:18] <Kamion> Diziet: yes, they most certainly are
[12:19] <pitti> Hi Diziet
[12:19] <Kamion> ogra: oh, ok - please file a bug
[12:19] <seb128> pitti: yep
[12:19] <ogra> Kamion, will do :)
[12:19] <pitti> seb128: ok, thanks
[12:19] <seb128> pitti: just printing from epiphany-browser a page and I get the icon
[12:20] <Kamion> ogra: component cdebconf rather than netcfg, I think
[12:20] <seb128> np
[12:20] <Kamion> Diziet: e.g. http://archive.ubuntu.com/ubuntu/pool/main/c/cdebconf/
[12:20] <ogra> oki
[12:21] <Kamion> ogra: if you could boot with DEBCONF_DEBUG=20 as a kernel parameter and attach /var/log/syslog from the installer, that'd be good too
[12:21] <ogra> o
[12:21] <ogra> k
[12:21] <Kamion> infinity: must be new, it's not showing up in anastacia
[12:22] <Kamion> oh, an rrdtool *demotion* is showing up
[12:22] <Kamion>  o librrdp-perl python-rrd python2.3-rrd python2.4-rrd               {rrdtool}
[12:22] <Kamion> is that ok to do?
[12:23] <Mithrandir> pitti: this is the patch from mofo for mozsuite and firefox?  They haven't released anything for thunderbird?
[12:23] <ogra> not on anastacia it seems ...
[12:23] <pitti> Mithrandir: no, unfortunately not
[12:23] <Mithrandir> pitti: grrr. :-/
[12:24] <pitti> Mithrandir: you can look into the referenced bugs, they might have patches, too
[12:24] <pitti> Mithrandir: but usually the "aviary" patches work for both ffox and tbird
[12:25] <infinity> Kamion : That would fix the problem just as well, I'm sure.
[12:26] <Kamion> infinity: done
[12:30] <pitti> infinity: enjoy
[12:34] <Mithrandir> pitti: the thunderbird thing seems to just be mailto:`command` and similar trickery?
[12:34] <pitti> Mithrandir: right
[12:34] <pitti> Mithrandir: also works from the command line (if called from another program)
[12:35] <Mithrandir> pitti: I just got confused since there are two bugs for it; I can handle it just fine.  Warty + hoary + breezy, I guess?
[12:35] <pitti> Mithrandir: yes, the whole fun
[12:35] <Mithrandir> yay
[12:35] <pitti> Mithrandir: however, mfsa58 had more critical vulns that apply to tbird
[12:36] <pitti> Diziet: how is ffox going? moz works quite well here on warty and hoary (just finished building warty)
[12:37] <Mithrandir> pitti: the bugs seems to be embargoed, so I can't look at them.
[12:38] <seb128> Mithrandir: gnomemeeting update?
[12:38] <pitti> Mithrandir: right, that's the problem... that's why we currently use the whole patch
[12:39] <pitti> Mithrandir: apart from the version number changes (which will fail for tbird), do you get so many rejections?
[12:39] <Mithrandir> pitti: haven't even tried applying the fix yet.
[12:39] <pitti> Mithrandir: alternatively, I'm pretty sure that they will do a new upstream release, too
[12:43] <Mithrandir> seb128: works fine for me
[12:44] <seb128> Mithrandir: have you planned to upload?
[12:46] <Mithrandir> seb128: I thought I'd leave that to you?  I just rebuilt the packages from Debian so a sync might be the easiest?
[12:46] <seb128> Mithrandir: oh, nice
[12:47] <seb128> pwlib and gnomemeeting are to update, right?
[12:47] <Mithrandir> you need a newer h323lib too, iirc
[12:47] <seb128> thanks
[12:48] <seb128> all stock from Debian are ok? I can ask a sync to elmo ? :)
[12:49] <Mithrandir> seb128: yes, those worked for me at least.
[12:50] <seb128> thanks
[12:50] <seb128> elmo: please sync gnomemeeting (GNOME desktop component) pwlib h323lib (required by the new gnomemeeting) from Debian
[12:50] <Diziet> pitti: Just checking some things on warty now.  14390.
[12:51] <pitti> Diziet: btw, we have the problem I talked about yesterday - warty is not built on the buildds since hoary was uploaded with -sa and warty does not see the orig.tar.gz
[12:51] <pitti> Diziet: however, not your fault, there is nothing you could have done about this
[12:52] <pitti> Diziet: but I can't toss you the warty debs; the hoary debs are in chinstrap:~pitti
[12:54] <Diziet> Oh, damn, I've just discovered that the warty debs are missing.
[12:54] <pitti> Diziet: see above
[12:54] <Diziet> Mmm.
[12:54] <pitti> Diziet: please build them yourself
[12:55] <Diziet> Willdo.
[12:57] <seb128> is libxp6 useful for firefox?
[12:57] <seb128> #14882 has a comment saying "people report they solved
[12:57] <seb128> Firefox instability by installing libxp6."
[12:58] <ogra> seb128, its needed by that blackdown plugin at lease and i suspec for other third party plugins too... if its not installed ff crashes if you open a site with plugin (at least java stuff, havent tested others)
[12:59] <pitti> ah, makes sense
[12:59] <ogra> s/that/the
[12:59] <ogra> s/lease/least
[12:59] <pitti> maybe ffox should recommend it then?
[12:59] <seb128> k, thanks
[12:59] <ogra> nope, blackdown should
[12:59] <seb128> pitti: desktop list it now
[12:59] <mvo> seb128: what do you think about having a fixed gtk in hoary-updates for #14998? I'm considering this atm
[12:59] <seb128> pitti: cf -changes from this morning
[12:59] <ogra> and the new java-plugin metapackage depends on it afailk
[01:00] <pitti> seb128: ah, ok, then it should be good
[01:00] <ogra> i'm not sure if its really needed for other plugins...
[01:00] <pitti>      - automatic upgrading from the cd disabled until this is properly
[01:00] <pitti>        speced
[01:00] <pitti> *sniff*
[01:00] <mvo> pitti: :(
[01:00] <ogra> :/
[01:01] <ogra> what was wrong with it ?
[01:01] <seb128> is that the stuff that want to update my box to hoary when I put an hoary CD? :)
[01:01] <ogra> oh
[01:01] <mvo> seb128: yep, but it won't update you to hoary :)
[01:01] <seb128> mvo: oh, I thought it has some strong pinning to achieve it :)
[01:01] <seb128> mvo: for the GTK fix seems to be a good idea
[01:02] <mvo> seb128: no, pinning would be a bit dangerous :)
[01:03] <seb128> mvo: don't be a sissy :p
[01:03] <dholbach> that seb... :)
[01:03] <mvo> seb128: tsss, you never actually _tried_ to "upgrade" you system back to hoary ;)
[01:04] <mjg59> elmo: Can you sync hotkey-setup?
[01:04] <zyga> hey
[01:04] <seb128> no, the nice dialog has a button to reject the proposition :p
[01:04] <zyga> I've just noticed
[01:04] <zyga> the screen saver allows for another person to login
[01:04] <zyga> does that launch another X and gdm
[01:04] <zyga> ?
[01:05] <ogra> zyga, gdmflexiserver
[01:05] <ogra> zyga, the same you get from "new login" in the menu
[01:05] <zyga> ogra: it crashes on radeon 9000
[01:05] <zyga> :/
[01:05] <zyga> ogra: I get another gdm but the screen is corrupted and everything dies
[01:06] <ogra> zyga, with the "new login" from the menu too ?
[01:06] <zyga> ogra: checking (don't mind if I become silent)
[01:06] <ogra> heh
[01:06] <mvo> seb128: you mean a patch that makes it crash ;) ?
[01:07] <zyga> wow :-)
[01:07] <zyga> okay the result was the same
[01:07] <zyga> this time I pressed alt+ctrl+backspace
[01:07] <zyga> and re-logged in
[01:07] <ogra> then its a bug either in gdmflexiserver or in X
[01:07] <seb128> mvo: not that's not funny enough, some little screwage all over the place ... just enough to be annoying :p
[01:07] <zyga> pretty fade in though :)
[01:07] <seb128> anyway time to grab some food :)
[01:08] <zyga> ogra: the new login did work in hoary though....
[01:08] <ogra> zyga, i'd suspect X, but it could also be a gdm prob...
[01:08] <zyga> ogra: I have to go now
[01:08] <ogra> ok
[01:08] <zyga> talk to you later, okay?
[01:09] <ogra> sure
[01:09] <pitti> BenC: do you have any idea about #5049? it affects so many people, and it makes your CDs stuck in the drive without any chance to get it back
[01:25] <Diziet> Bizarre.  My warty test build has failed.   undefined reference to `operator delete(void*)'
[01:25] <Diziet> Let me try the 1.0.6 to see if it's something with my machine.
[01:28] <Kamion> linking with gcc rather than g++ perhaps?
[01:32] <Diziet> Hmm.  1.0.6 does the same.
[01:33] <Diziet> Well, yes, linking with gcc rather than g++, but why ?
[01:34] <Diziet> Aha, no g++ installed, only g++-3.0
[01:34] <sivang> ogra: I see the current screensaver is like mpt's design, so the window design and UI changes are already applied?
[01:35] <ogra> sivang, thats xscreensaver
[01:39] <pitti> Diziet: btw, can you ping me once you are satisfied with hoary's ffox stability? then I will release the hoary packages, which should make the warty packges able to build
[01:40] <Mithrandir> pitti: it applies mostly fine, I'll need to futz it a little (for breezy), but it'd be really nice to have a patch against aviary.
[01:41] <Diziet> pitti: Willdo.
[01:42] <pitti> Mithrandir: the ffox patch is the aviary patch
[01:42] <Lathiat> hrm
[01:42] <Lathiat> new kernel is loading the wrong sata driver on my laptop i think
[01:42] <Mithrandir> pitti: hmm, it is?  The tags says FIREFOX_* not AVIARY_
[01:43] <pitti> Mithrandir: right, there is only FFOX_ and TBIRD_
[01:43] <pitti> Mithrandir: there is no aviary tag in the CVS
[01:43] <pitti> Mithrandir: both are commonly refered to as "aviary branches" in bugzilla, though
[01:45] <Mithrandir> pitti: my client.mk seems to disagree with you: MOZ_CO_TAG = AVIARY_1_0_1_20050124_BRANCH
[01:46] <pitti> Mithrandir: ah, ok, then this is an additional tag; I only saw TBIRD and FFOX_ so far; sorry
[01:51] <sivang> ogra: ah :)
[01:59] <ogra> seb128, whats that with #16128 ? i dont think gnome-screensaver will stay in main and we shouldnt encourage users to use the broken gnome-screensaver in breezy yet
[02:08] <mjg59> Kamion: Do you have a rough timeframe on the Colony release?
[02:08] <Kamion> mjg59: when I've unbroken everything; currently enduring much frustration as to just how much this morning's uploads broke things
[02:09] <Kamion> I'm fixing l-r-m at the moment
[02:09] <Kamion> (please, nobody upload to main without checking with me right now)
[02:10] <mjg59> Kamion: Urgh.
[02:10] <seb128> ogra: 1- why the heck do you want to move it to universe to move it again to main in 2 weeks?
[02:10] <seb128> 2- how is it broken? It works fine for a lot of people
[02:11] <ogra> seb128, it gets demoted automatically if nothing depends on it, doesnt it ?
[02:11] <seb128> if it's no seeded yep
[02:11] <ogra> seb128, apt-cache show gnome-screensaver ;)
[02:11] <Kamion> how many times do we have to say that demotions are not automatic?
[02:11] <seb128> but it's a good candidate for suported imho
[02:11] <ogra> Kamion, then it got demoted maunall, its not in main
[02:12] <ogra> and i dont think we shoudl support it in breezy
[02:12] <seb128> ubuntu-desktop can have an | with an universe package?
[02:13] <ogra> either we decide its immature and demote it, or we decide its ready and support it ... where is the rationale for supporting it if we dont think its mature enough ?
[02:13] <Kamion> seb128: no
[02:13] <seb128> I think it's mature enough to be used
[02:13] <Kamion> it can't have a | at all with the current implementation of update
[02:13] <seb128> it just lacks some polish and feature
[02:13] <ogra> seb128, then we should use it and support it
[02:13] <Kamion> people can deinstall ubuntu-desktop if they want to vary from our recommended desktop set; that's fine
[02:13] <ogra> its lacking a lot of feature
[02:14] <seb128> Kamion: fine but not optimal, anyway
[02:14] <seb128> ogra: yeah, lack of feature is not an issue to support a package
[02:14] <ogra> seb128, there are other issues
[02:15] <seb128> every single package has bugs
[02:15] <ogra> i switched back to xscreensaver today, after i had to wait about 15min for the lock screen to how up after the screen was locked overnight
[02:15] <seb128> there is no huge concern with gnome-screensaver, that's just not the right moment to switch
[02:15] <ogra> seb128, you cant adjust *any* dpms settings...
[02:16] <ogra> you cant adjust *and* screensaver settings
[02:16] <seb128> lack of feature is not an issue to support a package, again
[02:16] <ogra> any even
[02:16] <seb128> what we want to support a package is something stable and with a certain QA level
[02:16] <mjg59> Oh dear. Right, that's going to be another kernel build for Breezy.
[02:16] <Kamion> due respect, but lack of necessary features is an issue, otherwise lots more of universe would be in main
[02:17] <Kamion> there's no point supporting lots of alternatives in main when there's one we've selected as the primary one
[02:17] <fabbione> mjg59: ????
[02:17] <ogra> seb128, exactly, and we decided its not ready to support t, else we would use it in the default install
[02:17] <seb128> grrr
[02:17] <mjg59> fabbione: sk98lin wasn't switched on in the configs
[02:17] <ogra> seb128, and it simply doesnt match the QA level yet
[02:17] <seb128> that's plainly wrong
[02:18] <seb128> stop the FUD
[02:18] <seb128> there is no QA concern about it
[02:18] <seb128> it lacks feature and polish
[02:18] <\sh> mjg59: :(
[02:18] <seb128> but it's stable and has no security issue
[02:18] <ogra> seb128, waiting 15mins for a lock screen to show up matches our QA ?
[02:18] <Lathiat> seb128++
[02:18] <seb128> I agree with Kamion on the duplicate feature though
[02:18] <seb128> ogra: nautilus has crasher too, should we move it to universe?
[02:18] <fabbione> mjg59: you kidding?
[02:18] <seb128> gnome-panel too
[02:18] <ogra> seb128, there are enough bugs to be solved before we can ship it
[02:19] <mjg59> fabbione: Sadly not
[02:19] <ogra> seb128, nope, but these bugs get solved...
[02:19] <seb128> no
[02:19] <mjg59> tyrosine% find -name sk98lin.ko
[02:19] <mjg59> tyrosine%
[02:19] <seb128> want to see the list of bug on nautilus before speaking maybe?
[02:20] <seb128> ogra: things happening to some users and not to other are quite frequent
[02:22] <magnon> hm
[02:22] <ogra> seb128, it locks up certain systems when using GL screensavers, it locks up systems when using unclutter, it doesnt really work with acpi, these are just some errors that are seroius enough to not support it yet
[02:22] <magnon> kernel-package is the way to go for entering kernel bugs into bugz?
[02:23] <ogra> magnon, linux
[02:23] <magnon> ah
[02:25] <seb128> ogra: lack of feature is not an error, again but let's forget about it we will switch to it right after 5.10 anyway and we will support it, you happy or not with that
[02:26] <ogra> seb128, i'm absolutely happy with that
[02:26] <ogra> seb128, just not for breezy... and hadrlocking user systems is quite serious imho
[02:28] <torkel> ogra: looks like they have solved (for any definition of solved) which themes to run when using random in g-s-s now
[02:28] <seb128> ogra: let's stop discussing about it, it bugs for some people like a lot of apps
[02:28] <ogra> torkel, that was solved long ago...our gss already uses it
[02:28] <seb128> ogra: you should move gamin to universe too with your definition
[02:28] <ogra> seb128, yep...
[02:29] <seb128> and enough talk, that start pissing me to discuss on details
[02:29] <seb128> I've some work to do
[02:29] <torkel> ogra: in upstream
[02:29] <ogra> seb128, probably, but gamin bugs will be looked at before release... gss bugs wont
[02:29] <ogra> torkel, as i said, we already used that, upstream just tweaks it... its there since a while
[02:30] <seb128> ogra: we shipped warty with some of those gamin issues, but let's stop discussing about it
[02:30] <torkel> ogra: k
[02:30] <ogra> seb128, yup
[02:30] <ogra> seb128, we'll have a BOF about it anyway :)
[02:51] <pitti> Diziet: can you receive /msgs? did you get mine?
[02:52] <mjg59> pitti: It's probably worth giving up on /msg here
[02:52] <pitti> bah
[02:53] <ogra>  /msg nickserv set unfiltered off
[02:53] <ogra> or something like that
[02:53] <pitti> odd
[02:53] <ogra> may be "on"
[02:53] <pitti> I never have problems with receiving messages
[02:53] <pitti> from registered users, that is
[02:54] <ogra> freenode blocks them since the spambot attacs began
[02:54] <pitti> ogra: you mean it blocks unregistered users?
[02:54] <ogra> them == unregistered users
[02:54] <pitti> right
[02:54] <\sh> pitti: yes
[02:54] <pitti> so what is hard about registering?
[02:54] <\sh> pitti: time, seeing no need
[02:54] <pitti> you can kill ghost nicks, you won't lose your nick, it's easy
[02:55] <ogra> pitti, it gets hairy if you use multiple nicks ;)
[02:55] <pitti> \sh: the lack of private communication is a pretty severe need (for me at least)
[02:55] <ogra> (at the same time)
[02:56] <\sh> pitti: well..that's why I prefer for fast communition between me and person X the jabber way...:) I know that he will receive my message :)
[03:05] <Diziet> pitti: I've just finished testing that ffox, and the hoary binary seems fine.  I'm not really sure what's a good test but it works with a variety of sites.
[03:06] <pitti> Diziet: great, thanks! what about warty?
[03:07] <Diziet> My test build (which I most recently set off about an hour and a half ago!) is still going.
[03:07] <pitti> ouch
[03:07] <Diziet> So I think you should release the hoary one into hoary-security and let the warty one build ASAP.
[03:07] <pitti> ok
[03:07] <Diziet> And I thought it was a fast computer !
[03:07] <pitti> Diziet: on my amd64 3000 it needs about 30 minutes
[03:08] <Diziet> It seems much slower than my main workstation (which has no space left for a warty chroot).
[03:08] <Mithrandir> I'll just do this on a reasonable machine.
[03:08] <Mithrandir> (dual dualcore 275)
[03:08] <sivang> Mithrandir: amd?
[03:08] <Mithrandir> sivang: yeah
[03:08] <sivang> Mithrandir: pheee,  cool
[03:09] <Mithrandir> actually, that one is down for maintenance so it's the dual 265 instead.
[03:09] <sivang> Mithrandir: did you ever built cvs GNOME on it?
[03:09] <Mithrandir> sivang: nah, I could try once.
[03:09] <Nafallo> "dual dualcore" *fniss*
[03:09] <Mithrandir> sivang: or my home box, which is a 4400+
[03:09] <sivang> Mithrandir: nice ;)
[03:10] <Mithrandir> yup
[03:10] <sivang> Mithrandir: how many machines do you have?  ;-)
[03:10] <Mithrandir> sivang: the 275/265s aren't mine; personally I've got two athlon64 and a laptop (and loads of junk)
[03:12] <sivang> Mithrandir: ah, you told me you have a couple of machines from the uni, including an alpha or something?
[03:12] <Mithrandir> Nafallo: "junk". :-P
[03:13] <Nafallo> Mithrandir: still machines ;-)
[03:13] <Mithrandir> sivang: yeah, the computer club has plenty of stuff.
[03:13] <Mithrandir> Nafallo: just stuff like XP1800 with 256MB of ram and similar slowlyness.
[03:13] <sivang> Mithrandir: I need to visit you sometime :)
[03:14] <Nafallo> Mithrandir: baah. that's a lot faster than my server :-P.
[03:17] <Kamion> 9/wg 24
[03:17] <Kamion> (sigh)
[03:18] <zyga> hey :-)
[03:19] <zyga> I'm getting my key signed finally :D
[03:19] <ogra> great
[03:19] <sivang> zyga: cool for you
[03:22] <zyga> which keyserver would you suggest?
[03:22] <zyga> to send my keys to?
[03:22] <bddebian> Morning
[03:22] <ogra> afternoon
[03:23] <bddebian> :-)
[03:23] <pitti> Hi bdd
[03:23] <pitti> Hi bddebian
[03:23] <bddebian> Heya pitti
[03:24] <pitti> Mithrandir: I won't manage to release tbird for stables any more today; can we wait until Monday?
[03:24] <Mithrandir> pitti: sure
[03:24] <pitti> Mithrandir: maybe there will be a new upstream relase by then
[03:25] <Mithrandir> pitti: I've got the hoary and warty builds running, testing the breezy one now.
[03:30] <Nafallo> anyone working on the broken x-common? :-)
[03:31] <Mithrandir> pitti: ok, breezy works for me, now I need to do the mailto-fix
[03:31] <Mithrandir> pitti: would you like me to upload to -updates or should I send you the diffs?
[03:31] <pitti> Mithrandir: if the packages work fine for you, I'd just like to take a look at the new changelog
[03:32] <pitti> Mithrandir: after that you can directly upload to *-security
[03:32] <pitti> Mithrandir: Maybe you can take the breezy moz changelog as example?
[03:32] <Diziet> Come on you worthless piece of junk, built it !
[03:33] <pitti> Diziet: let's see whether the buildds are faster :-)
[03:33] <Mithrandir> pitti: sure, can do that.
[03:33] <Kamion> noooooo, I need the buildds today :P
[03:33] <Mithrandir> pitti: I haven't written the changelog.
[03:33] <Mithrandir> Kamion: it's just *mozilla*
[03:33] <Mithrandir> :-)
[03:33] <pitti> Mithrandir: not even that, mozilla is ready
[03:34] <Kamion> pitti: please don't upload stuff like pbbuttonsd for non-essentials today; see the topic
[03:34] <Kamion> it's built now, but still
[03:34] <pitti> Kamion: oops, sorry, I missed that
[03:52] <Diziet> Wahey!  Finally!
[03:53] <pitti> Diziet: it built?
[03:53] <Diziet> What's the odds it segfaults on startup ?
[03:53] <pitti> Diziet: DON'T tell me! :-)
[03:53] <sivang> Diziet: ffox ?
[03:56] <Diziet> Yes, warty's security update.  Well, it at least seems to work a bit.  I'll play with it and see if I can break it.
[03:56] <pitti> Diziet: so it didn't segfault? *phew*
[03:56] <Keybuk> b.b.b...but sir, the odds of starting firefox are approximately 3,720 to 1!
[03:56] <fabbione> pitti: you got the hoary crack
[03:56] <pitti> fabbione: merci
[03:57] <fabbione> pitti: det er i orden
[03:58] <pitti> fabbione: is that dansk?
[03:58] <pitti> Danish, even?
[03:58] <fabbione> yup
[03:58] <fabbione> "it's all right"
[03:59] <pitti> Nafallo: cheating
[03:59] <sivang> Keybuk: LOL
[03:59] <Nafallo> we should have #ubuntu-nordic or something :-P
[04:00] <Nafallo> Mithrandir: well, we _could_ make that a rename of #norsksvenskar ? ;-=
[04:01] <Nafallo> ;-)
[04:01] <jdahlin> #ubuntu-nordiska-idioter
[04:01] <ogra> there is no #ubuntu-no ?
[04:01] <Mithrandir> ogra: there is
[04:01] <ogra> :)
[04:04] <Diziet> Well, I didn't manage to break it so I'm obviously just too normal.  We should ship it and let anyone still using warty break it, instead :-).
[04:05] <Nafallo> hehe
[04:07] <Diziet> So, pitti, do you want anything else from me ?
[04:08] <pitti> Diziet: sounds like a plan, thanks! Adam was kind enough to kick the m-f build, so it shuold be all fine now
[04:08] <Kamion> like, er, characters being left off the end of multi-paragraph descriptions
[04:09] <fabbione> Riddell: ping?
[04:10] <Diziet> pitti: Excellent.
[04:11] <Riddell> fabbione: hi
[04:11] <fabbione> Riddell: yo...
[04:11] <ogra> pitti, m-f build sounds nasty....
[04:12] <pitti> ogra: why?
[04:13] <ogra> ...
[04:14] <ogra> (not apropriate for this channel :) )
[04:14] <sivang> lol
[04:14] <pitti> poor Kamion - Herbert and Fabio both uploaded kernel security updates, and Ben uploaded a breezy one...
[04:15] <pitti> darn, I need these buildds
[04:17] <infinity> Meh.
[04:17] <infinity> pitti : Still no orig showing up.
[04:18] <infinity> pitti : Can't mix ACCEPTED and INSTALLED source bits, maybe?
[04:18] <pitti> infinity: http://archive.ubuntu.com/ubuntu/pool/main/m/mozilla-firefox/mozilla-firefox_1.0.7.orig.tar.gz
[04:18] <Diziet> kamion: I'd like to upload a new lsb package to tidy up slightly more some of the non-usplash init.d script output.
[04:18] <pitti> infinity: not good enough?
[04:18] <infinity> pitti : Too little, too late?  Not sure.
[04:18] <pitti> infinity: would a no-change upload help?
[04:18] <infinity> pitti : Do you have the power to REJECT the warty upload, and then reupload it, so katie does her magic on it?
[04:19] <pitti> infinity: no :-(
[04:19] <pitti> elmo: ping
[04:19] <jcohen85> jbailey: did you get a chance to  create the new initramfs-tools package?
[04:19] <Kamion> Diziet: fine for after Colony 5 is out, but please leave it until then
[04:19] <infinity> Diziet : Define "tidy"... Your last upload made my boot significantly less tidy.
[04:20] <pitti> infinity: can't I just upload a newer version?
[04:20] <Kamion> I can reject the upload if need be
[04:20] <Kamion> somebody explain to me in small words why
[04:20] <infinity> pitti : Should work too.  Assuming this will work at all.  I'm trying to wrap my head around why it has no source.
[04:20] <Yagisan> jbailey: The vmware error I reported yesterday does not appear on an all ide install. It is the known buslogic issue. Thanks for your help
[04:20] <infinity> Kamion : Has to do with accepted autobuilding hooks.
[04:20] <Kamion> oh, except I'm not sure I can reject out of queue/accepted/
[04:20] <pitti> Kamion: katie can't see the source, so we need a reupload, as it seems
[04:20] <Diziet> kamion: OK.
[04:20] <Diziet> inf: Yes, I think this will fix it.
[04:21] <Kamion> just upload a new version
[04:21] <pitti> Kamion: ok
[04:21] <Diziet> Do you want to try it ?
[04:21] <pitti> Diziet: do you still have the sources on your box?
[04:21] <pitti> Diziet: can you increment it by .1 and reupload?
[04:21] <Diziet> The ffox sources, yes ?
[04:21] <pitti> Diziet: for warty, yes
[04:21] <Diziet> For warty.  OK, willdo.  Will take a few ks to go up my local pipe.
[04:22] <Diziet> Oh, just a mo, again without the .orig.tar.gz ?
[04:22] <pitti> Diziet: if it's built within 25 minutes, I can release it, otherwise it will have to wait until monday (I hate far away family events at the wrong time)
[04:22] <pitti> Diziet: yes, without -sa
[04:22] <pitti> Diziet: the orig is in the archive now
[04:23] <jbailey> Yagisan: Cool thanks.  The new kernel should apparently fix it.
[04:24] <infinity> pitti : It won't be built within 25 mins.
[04:24] <jbailey> Yagisan: If you have time, can you try the colony 5 CD in Vmware when it's released?
[04:24] <infinity> pitti : You need to wait for cron.daily, plus you may get stuck behind a kernel or two.
[04:24] <pitti> infinity: ok, so I'm doomed?
[04:24] <pitti> infinity: alright, then I release the other crack now and do warty/ffox separately
[04:25] <pitti> infinity: mdz can
[04:25] <Mithrandir> infinity: you volunteered?
[04:25] <infinity> mdz has rights to most of our tools, which means he's really not ideal to bug to USE most of them at any given time. :)
[04:26] <Yagisan> jbailey: sure
[04:27] <Diziet> infinity: Did you want to try out my now-really-improved lsb ?
[04:28] <Diziet> This ffox mouse scroll bug seems very odd.  It keeps coming and going.  Of course I don't see it because I have no scroll wheel mice.
[04:29] <infinity> Which bug?... Where scrolling works until you get halfway down the page, then suddenly stops working, then if you refocus the page, it may or may not start working again?
[04:30] <Diziet> I don't know if it's one bug or several.  The bugzilla is full of intermittent apparently-hard-to-reproduce bugs where the scroll wheel stops working.
[04:30] <infinity> Diziet : And nah, I'll test it on Monday, or whenever I'm back to work.  If I still hate it, I'll yell at you directly, or propose patches. :)
[04:30] <Mithrandir> Diziet: you might want to buy one, then?
[04:30] <ogra> Diziet, note that scrolling works only in focused frames on frame sites
[04:30] <Diziet> Sure.  If it still looks wrong, run the offending /etc/init.d by hand from within script(1) and put that in with the bug report.
[04:30] <Diziet> mith: I suppose I might :-/.
[04:31] <Diziet> ogra: Sure, I notice that myself with pageup and pagedown.
[04:31] <ogra> yup
[04:31] <ogra> so probably the focus changes somehow...
[04:32] <Diziet> Probably the site's fault.  They're awful for having lots of crap which steals the focus.
[04:32] <sivang> pitti: ok, it seems that the fds are opened in AcceptClient() defined in client.c , am I on the right spot? (re: cupsd)
[04:32] <Diziet> But it would be nice to feel confident and close the bugs.
[04:33] <pitti> sivang: you need to watch out for the network socket that is closed/reopened after sighup, not the select() calls
[04:35] <infinity> No, it's not about frames or the site being at fault.
[04:36] <infinity> Build an arbitrarily massive html file (or, say, browse the build logs at buildd.debian.org, again, pick a big one), start scrolling down.  It'll just stop scrolling at some point.
[04:36] <infinity> Refocussing will not always fix it, only sometimes.  Reloading the page will always fix it.
[04:36] <Diziet> pitti, that ffox is now in the queue.
[04:36] <pitti> Diziet: thanks
[04:37] <infinity> It's a longstanding fifrefox bug, and not one I've ever bothered to complain about, but there you have it.
[04:37] <jbailey> Yagisan: Awesome, thanks
[04:37] <infinity> And it's a firefox+GTK bug (though, that's pretty obvious, as I don't think scrolling happens at any other level of the code), since firefox+win32 and other GUI toolkits don't have the problem.
[04:38] <jcohen85> anyone know if the changes in 1.0.7 are in 1.5 beta1?
[04:39] <jcohen85> *firefox 1.0.7
[04:40] <infinity> Some of them almost certainly won't be, just purely based on the date it was released.
[04:47] <joh> BenC: About #16134, did you just update the patches in linux-source, or did you make any prebuilt kernel packages?
[04:49] <infinity> main/m/mozilla-firefox/mozilla-firefox_1.0.7.orig.tar.gz => main/f/firefox/firefox_1.0.7.orig.tar.gz
[04:49] <infinity> s/katie/katie's/
[04:50] <Kamion> I didn't know it did that
[04:50] <infinity> Has for ages.
[04:51] <Kamion> neat
[04:51] <infinity> I just happened to be tailing my mirror update log, that's all, and had a "hey, katie really doesn't suck" moment.
[04:52] <infinity> Not sure how many duplicate orig.tar.gzs we really have kicking around, but I like to see some bandwidth savings now and then. :)
[04:55] <mdke> the x-common problem is known right?
[04:55] <mdke> E: /var/cache/apt/archives/x-common_1.08_all.deb: trying to overwrite `/usr/lib/X11/fonts', which is also in package xfonts-base
[04:56] <infinity> Uh.
[04:56] <infinity> mdke : Which version of xfonts-base do you have installed?
[04:56] <mdke> <IP_ADDRESS>-3
[04:57] <mdke> the system is a standard breezy installed from PR
[04:57] <Nafallo> I can reproduce, and so can a lot of #ubuntu.se ;-)
[04:57] <infinity> Or, more to the point, why is /usr/lib/X11/fonts a file on your system, not a directory?
[04:57] <ogra> infinity,  thought there was a bug open ?
[04:57] <mdke> infinity, it is a dir
[04:58] <infinity> ogra : The only x-common problem i heard a lot about today was x-common trying to remove half the system.
[04:58] <Nafallo> infinity: symlink here :-)
[04:58] <Kamion> mdke: #16133
[04:58] <ogra> infinity, and the font stuff showed up afterwards
[04:58] <mdke> good
[04:58] <infinity> Ahh.
[04:58] <mdke> ty Kamion
[04:58] <infinity> I must have been at dinner when the font stuff happened. :)
[04:59] <thesaltydog> don't you think do give the user a choice on using usplash or not? I do prefer reading my boot sequence..
[05:00] <Robot101> you can escape from it trivially
[05:00] <ogra> thesaltydog, it shows you everything you'd see on console too...
[05:00] <Robot101> if you know enough to understand the boot messages, you know how to disable usplash anyway
[05:00] <sivang> thesaltydog: yes, and also if you need to do a fsck check once in a couple of mounts, it also exits
[05:00] <thesaltydog> ogra, almost...
[05:01] <infinity> It's a symlink in the package.  It's a directory in some other packages.  That's fine.  dpkg is supposed to "just deal" with that...
[05:01] <sivang> ogra: I think it dropps on any event of error
[05:01] <thesaltydog> ogra, ok. Let's say this: how can I have my console screen in small fonts (vga=791) AND usplash..?
[05:01] <infinity> And, of course, I also can't reproduce it.
[05:02] <infinity> thesaltydog : You can't.
[05:02] <mdke> thesaltydog, you can remove usplash by uninstalling it or by removing the word "splash" from the boot options
[05:02] <ogra> thesaltydog, you rewrite usplash, fix some hundrets of vga bioses to support more than vga16fb ?
[05:02] <thesaltydog> infinity, that's why I don't want usplash..
[05:02] <infinity> thesaltydog : Then use vga=foo, and usplash won't run.
[05:03] <ogra> infinity, he asks for BOTH :)
[05:03] <thesaltydog> infinity, ok.. Now the REAL question: from this morning, after update to kernel -9, it doesn't work anymore. I have only a black screen.
[05:03] <Diziet> If something is a directory in one package but a symlink (to a directory) in another, whether you get the link or the directory depends on the order of installation.
[05:03] <thesaltydog> ogra, I don't have the booting sequence on screen with vga=791 from today.
[05:03] <infinity> Diziet : Yes, that's known.  But in no case should it cause a CONFLICT...
[05:03] <infinity> Diziet : Which is the bug being reported.
[05:03] <Diziet> That's true.
[05:03] <thesaltydog> and if I type telinit 1, it goes single-user in a black screen!
[05:03] <Diziet> Perhaps the link is to a nondirectory.
[05:04] <magnon> ok, this is REALLY weird. My powerbook's sound driver and event devices just stopped working two days ago, I didn't bother much because I had too much work, and now they all of a sudden came back and work just as before :P
[05:04] <infinity> Diziet : A link to a link to another directory would be fine, I assume (as long as it eventually gets to a directory)?
[05:05] <Diziet> I think so but I'd have to check the code.
[05:05] <Diziet> It's a bug if not.
[05:05] <infinity> mdke : ping.
[05:05] <mdke> yo
[05:06] <infinity> mdke : You said /usr/lib/X11/fonts was a directory on your system, right?
[05:06] <mdke> infinity, it's a link
[05:06] <mdke> lrwxrwxrwx  1 root root 21 2005-09-16 12:51 /usr/lib/X11/fonts -> ../../share/X1                                                                                1/fonts
[05:06] <sladen> thesaltydog: then remove 'splash' from the kopts line and type 'update-grub'
[05:07] <infinity> mdke : Ahh, kay.  And does that target exist?
[05:07] <thesaltydog> sladen, I will try again and be back soon. Tnx
[05:07] <mdke> infinity, yes
[05:07] <infinity> mdke : And the target is... A directory?
[05:08] <mdke> infinity, yes
[05:08] <mdke> matt@kalliope:/usr/share/X11/fonts$ ls
[05:08] <mdke> 100dpi  75dpi  encodings  misc  Type1
[05:08] <infinity> Diziet : Well, there you go.  Any theories? :)
[05:08] <ogra> the link is there for backwards compatibility afaik
[05:09] <infinity> Diziet : Note that x-common is trying to unpack a symlink identical to the one already there, even.  Which is even stranger that it should die.
[05:09] <Nafallo> fwiw, that bug is arch: all ;-)
[05:09] <infinity> Nafallo : No big shock, so is the package.
[05:09] <ogra> shouldnt that be in postinst and only link if the link doesnt exist ?
[05:10] <Nafallo> I know :-). just tried to change it on the bugreport, but couldn't.
[05:10] <infinity> ogra : Shipping a link is fine.
[05:10] <Diziet> Oh, hold on, two packages are trying to unpack the same symlink ?
[05:11] <sladen> jbailey: interesting.  Does /removal/ of usplash cause an initramfs rebuild?
[05:11] <infinity> ogra : Trying to forcefully CHANGE a directory to a link requires postinst hackery, but shipping a link (that may or many not match up with a directory) is supposed to work.
[05:11] <ogra> infinity, not if you probably would overwrite it... then i'd put it in postinst in at least one of the packages
[05:11] <Diziet> Can I have the bug number, package names and versions, and stuff like that ?
[05:11] <jbailey> sladen: No.
[05:11] <infinity> Diziet : No, only one package contains a link, AFAIK.
[05:11] <infinity> Diziet : #16133
[05:11] <sladen> jbailey: so, given that retorical question, should it?
[05:12] <jbailey> sladen: Sure.  A bit late in breezy's cycle for it, though.
[05:12] <jbailey> sladen: The pieces are all there to do it.
[05:12] <infinity> Diziet : x-common contains a link.  The rest of the packages with that directory almost certainly have it as a directory. On disk on mdke's system, it's already a link from a previous x-common installation.
[05:12] <Diziet> What version of xfonts-base is installed ?
[05:12] <infinity> Diziet : There's sure to be something broken in some attempt at symlink migration in the maintainer scripts (which can and should be fixed), but I'm more curious about dpkg's behavior in this case.
[05:13] <infinity> Diziet : mdke said it was <IP_ADDRESS>-3
[05:13] <mdke> do you want a login to this system?
[05:14] <mdke> ah actually, I can't help :/ the office firewall will get in the way
[05:14] <Diziet> <IP_ADDRESS>-3 isn't in pool any more.
[05:14] <mdke> it is latest breezy :/
[05:14] <Diziet> Oh, hold on, it's changed place in pool.
[05:14] <infinity> Yeah. :)
[05:15] <Kamion> ogra: IME it's more reliable to ship the .debs the way you want the system to end up (i.e. ship the link) and clean up the old directory in the preinst.
[05:16] <ogra> Kamion, but if i have another package that needs the link that i could install separately, i'd do the postinst solution to avoid a clash if they are both installed...
[05:16] <Diziet> When xfonts-base was installed, /usr/lib/X11/fonts was just a directory.
[05:16] <Diziet> I assume.
[05:16] <Kamion> ogra: *shrug* I can only speak from my experience of what actually works
[05:16] <Diziet> How did it come to be a symlink ?
[05:17] <Diziet> Oh, hold on, I think I see what's happening.
[05:18] <Diziet> It notices that usr/lib/X11/fonts is a in xfonts-base, so it asks itself, well, what kind of thing is it in xfonts-base ?  It lstats it and finds it's a symlink.  So it then assumes that xfonts-base must have had it as a symlink.
[05:19] <Diziet> But it's processing x-common, which contains a symlink.  So that's two symlinks, a conflict.
[05:19] <infinity> Oh, argh.
[05:19] <Diziet> Can you grep usr/lib/X11/fonts /var/lib/dpkg/info/x-common.list ?
[05:19] <Diziet> and .../xfonts-base.list ?
[05:20] <Diziet> Has something recently changed in the organisation of these X packages ?
[05:20] <infinity> I doubt it was recent, but maybe.
[05:20] <infinity> Oh, yes it was.
[05:21] <mdke> the problem is present on my system since yesterday
[05:21] <infinity>   * Add /usr/lib/X11/fonts -> /usr/share/X11/fonts symlink (closes:
[05:21] <infinity>     Ubuntu#11057).
[05:21] <infinity> That was in the 1.06 upload... On the 29th of August... That's hardly recent.
[05:21] <mdke> hmm
[05:21] <mdke> i definitely upgraded successfully yesterday evening
[05:22] <mdke> this morning there was that "remove all things X", then later this afternoon, this problem
[05:22] <infinity> Diziet : Anyhow, yes, in the .list, both claim to own that file on my system.  But, on my system, it works fine because it's a directory.
[05:22] <infinity> mdke : Oh, did you end up removing X stuff, rather than just waiting for fixed packages?
[05:22] <mdke> no i waited
[05:22] <infinity> Or... Not.
[05:22] <mdke> lol
[05:23] <thesaltydog> sladen, ping
[05:23] <Diziet> inf: That sounds like a plausible bet.
[05:24] <infinity> Diziet : Yet already refuted by mdke. :)
[05:24] <ogra> infinity, it also affects upgrades that didnt suffer from the removal breakage
[05:24] <Diziet> On my breezy test system (last dist-upgrade a day or two ago) it's a link.
[05:24] <ogra> i had some people mention it in #edubuntu
[05:24] <thesaltydog> ogra, this is my /proc/cmdline root=/dev/hdb6 ro vga=791 , and during boot the screen is completely black... until gdm starts.
[05:24] <infinity> Diziet : So, if it's a link on your system, dpkg should have a hissy if you apt-get --reinstall install x-common...
[05:24] <Diziet> Right.  My mirror is overnight's so has the dependency problems.
[05:24] <infinity> Diziet : Or upgrade, or whatever.
[05:24] <Nafallo> this one is a previewinstall, and I see it :-)
[05:25] <Diziet> But if I  dpkg --force-conflicts -i x-common_1.07_all.deb  I can reproduce the bug.
[05:25] <infinity> Check.
[05:25] <ogra> thesaltydog, i guess removing usplash and running dpkg-reconfigure for your kernel image should help
[05:25] <Diziet> Oh dear, this is quite bad really.
[05:25] <infinity> It really is non-obvious behavior.
[05:25] <Diziet> 1.06 does it too.
[05:25] <infinity> We can easily work around it in the packages, but dpkg still seems wrong to me.
[05:26] <Diziet> `non-obvious'> ITYM `wrong'.
[05:26] <thesaltydog> ogra, by "removing" are you meaning apt-get remove?
[05:26] <ogra> yup
[05:26] <thesaltydog> mmh.. let's try
[05:27] <Diziet> I think for now dpkg should not mind if a package steals a symlink to a directory by replacing it with another symlink to the same directory.
[05:27] <mdke> thesaltydog, also perhaps filing a major bug against usplash if that is the cause
[05:27] <ogra> thesaltydog, then regenerate your initrd by running dpkg-reconfigure linux-image-`uname -r`
[05:27] <thesaltydog> mdke I don't believe usplash is guilty.. maybe kernel -9
[05:27] <Diziet> I'm going to have to leave early today, in only a few minutes.  I'll think about this problem and propose a fix, perhaps tomorrow.
[05:27] <mdke> thesaltydog, you'll find out if you remove it
[05:27] <ogra> neither is guilty...
[05:27] <mdke> ogra, something is...
[05:28] <thesaltydog> ogra, removing usplash will remove ubuntu-desktop, don't like..
[05:28] <Diziet> I think this will be OK if we fix dpkg.  'cos the fixed dpkg and the existing x-common will be installed at the same time, and then the user will never see the bug (unless they've been testing breezy for us, of course).
[05:28] <mdke> thesaltydog, just remove it to test whether usplash is causing the problem, then put it back
[05:28] <ogra> mdke, its not usplash...
[05:28] <infinity> Diziet : Right, and for dist-upgrades, apt always configures dpkg (well, its dependencies, then dpkg) first.
[05:28] <mdke> ogra, it's you that recommended he remove it, not me :p
[05:28] <Diziet> It's not a question of configure, it's a question of execute.
[05:28] <thesaltydog> mdke, it happened this morning after the kernel update
[05:28] <ogra> you cant run higher resolutions with vga16fb
[05:29] <Diziet> As in, if you're executing the new dpkg it will work.
[05:29] <mdke> ogra, but that shouldn't happen without splash on the kernel boot options right?
[05:29] <Diziet> Shall I reassign 16133 to me ?
[05:29] <infinity> Diziet : s/configure/unpack/
[05:29] <ogra> mdke, yes, but only because thesaltydog wants a non default setup
[05:29] <Diziet> Does it arrange to invoke it again after unpacking the new one ?
[05:29] <thesaltydog> ogra, let's speak about freedom in a free world..
[05:29] <ogra> mdke, afaik the splash line is for grub...
[05:29] <infinity> Diziet : Yes, it does multiple dpkg runs.
[05:30] <ogra> mdke, which has nothing to do with usplash
[05:30] <infinity> Diziet : So it will do dpkg -i (dpkg deps), dpkg -i (dpkg), dpkg -i (everything else), for instance.
[05:30] <mdke> ogra, but without splash in the kernel options, usplash doesn't start
[05:30] <mdke> right?
[05:30] <ogra> thesaltydog, yes, you have the freedon to regenerte your initrd after removing a default program :)
[05:30] <thesaltydog> ogra, I only want back my nice fonts in console as I had until this morning..
[05:30] <infinity> Diziet : Not at all like that in reality, but that was the fastest way to type it. :)
[05:30] <Diziet> Right.  I will take this bug and it'll be fixed real soon next week.  I should have a proposal tomorrow.
[05:30] <mdke> thanks Diziet
[05:31] <ogra> hmm, does that mean we wont have a colony then ?
[05:31] <mvo> thesaltydog: not sure if that was already mentinoed, but can't you just remove the "splash" from your grub config?
[05:31] <ogra> i think a broken xorg-common is a quite serious blocker for that
[05:32] <Kamion> ogra: it's fine on fresh installs, no?
[05:32] <Diziet> I think you only see this if you upgrade it.
[05:32] <thesaltydog> mvo, my /proc/cmdline is this: root=/dev/hdb6 ro vga=791
[05:32] <Diziet> k: Right.
[05:32] <infinity> ogra : It'll be fine on fresh installs, because x-common will always be installed first.
[05:32] <ogra> Kamion, no idea, i only had users that upgraded from a daily from this week...
[05:32] <infinity> (In fact, a mess of stuff pre-depends on x-common, rather anally)
[05:32] <mvo> thesaltydog: and you get a splash with that?
[05:33] <thesaltydog> mvo, no, I get a black screen... No boot sequence displayed, until gdm
[05:33] <infinity> OTOH, that means that upgrades AFTER a fresh install will be bitten by this bug every time, cause it will be a link for sure.
[05:33] <ogra> mvo, isnt the "splash" in grub not for the grub splash image ?
[05:33] <infinity> So, we can't upload a new x-common until the dpkg bug is fixed. :)
[05:33] <mdke> ogra, we're talking about splash in the kernel boot options dude
[05:33] <thesaltydog> ogra, I believe so.
[05:33] <ogra> mdke, me too
[05:33] <mdke> ah
[05:33] <mdke> it's for usplash
[05:34] <Diziet> Right, must go now.
[05:34] <thesaltydog> mdke, the "splash" in the grub line is not for usplash
[05:34] <mdke> kernel/vmlinuz-2.6.12-8-386 root=/dev/sda5 ro quiet splash <-- ogra that one?
[05:34] <ogra> yup
[05:35] <mvo> ogra: without splash I don't get a usplash here
[05:35] <mdke> removing it on my system causes it to start withou usplash afaik
[05:35] <mvo> thesaltydog: so it seems like vga=791 is failing for you?
[05:35] <thesaltydog> mdke, the only way top get rid of usplash is to set a vga=... on grub. But no more since this morning...
[05:35] <thesaltydog> mvo, on 2 different PCs
[05:35] <mdke> thesaltydog, removing splash in the kernel options works for me
[05:36] <thesaltydog> mdke, do you have a vga= in grub?
[05:36] <mdke> no
[05:37] <mvo> thesaltydog: same here
[05:37] <thesaltydog> ogra, anyway, as things were working yestarday and are no more working starting with the kernel update this morning (on 2 PCs) I'm afraid there is a bug.
[05:37] <thesaltydog> mvo, confirm?
[05:37] <ogra> thesaltydog, but you had a usplash after upgrade ?
[05:37] <ogra> (when you didnt have vga= in the line ?)
[05:37] <thesaltydog> ogra, no I haden't even before..
[05:37] <sladen> thesaltydog: see the bit that says 'splash' on the boot line (which you must have, because you edited it to set vga=)  just *remove* it
[05:38] <thesaltydog> sladen this is my line: root=/dev/hdb6 ro vga=791
[05:38] <ogra> sladen, thats not for the grub splash image anymore ?
[05:38] <Kamion> ogra: read the usplash initramfs hook
[05:38] <Kamion>         case $x in
[05:38] <Kamion>         splash*)
[05:38] <Kamion>                 SPLASH=true;
[05:38] <ogra> oh
[05:38] <ogra> ok
[05:39] <thesaltydog> anyway, I don't have it.
[05:39] <thesaltydog> but I don't even have anymore text
[05:39] <mdke> must be a kernel bug then
[05:39] <Kamion> it never was for the grub splash image
[05:39] <Kamion> that happens before kernel parameters are handled
[05:39] <ogra> hmm
[05:40] <thesaltydog> Kamion, I said that...agree
[05:40] <Kamion> thesaltydog: you said the opposite
[05:40] <ogra> i know i had to set it in my pre warty times in debian to get that grub splash shown
[05:40] <thesaltydog> Kamion, anyway I am not wuestioning on usplash. I just need my boot text back!
[05:40] <ogra>  but that was 2.4 most likely
[05:40] <Kamion> ogra: not as a kernel parameter. you might have had to set it in menu.lst
[05:40] <sladen> splashimage=  is for the grub splash
[05:40] <mdke> ogra, i think you are confused between splash as a grub option and splash as a kernel option
[05:40] <ogra> ahh
[05:40] <ogra> ok
[05:41] <ogra> yes, i mixed it up then
[05:41] <sladen> maybe the splash option on the kernel command line should be made 'usplash'
[05:41] <thesaltydog> sladen, ++
[05:42] <mdke> users will understand splash better than usplash when they see it in boot-admin
[05:42] <ogra> will we ship boot-admin ?
[05:43] <seb128> Keybuk: I did not put this Conflicts, not need to Cc: me on the nice explanation :p
[05:43] <mvo> ogra: we do right now at least
[05:43] <ogra> mvo, yes, i meant for final
[05:43] <Keybuk> seb128: you're one of the worst offenders <g>
[05:43] <sivang> Keybuk: I'm on for your PackageHeaders BOF :-)
[05:43] <thesaltydog> ogra, I have re-configured the kernel. I am going to reboot.. back soon
[05:44] <sladen> thesaltydog: did you run 'update-grub'?
[05:44] <mdke> heh
[05:44] <seb128> Keybuk: ah ah, slackers :p
[05:44] <mdke> sladen, splash wasn't on his boot options
[05:45] <mdke> the kernel must have a problem with his vga setting
[05:45] <mvo> ping BenC
[05:47] <thesaltydog> ogra, it must definitively be a kernel bug..
[05:48] <ogra> did you run update-grub ?
[05:48] <thesaltydog> ogra, c'mon Oliver...
[05:48] <ogra> thesaltydog, if you think its a bug, look if its in bugzilla and if not, file one :)
[05:49] <thesaltydog> ogra, did it. Tnx
[05:50] <thesaltydog> It is something related to this morning's update.
[05:53] <sladen> mdke: then why is he complaining about usplash?
[06:01] <ogra> Keybuk, so with your example, ubuntu-desktop should depend on x-window-system-screensaver ?
[06:03] <jcohen85> jbailey,
[06:04] <jcohen85> jbailey, it looks like the new intramfs-tools package isn't in the repository. I'm leaving this afternoon for New York. If it gets in before 3 PM EST i can still send you the file
[06:04] <Keybuk> ogra: no.
[06:04] <Keybuk> ogra: ubuntu-desktop should depend xscreensaver
[06:04] <Keybuk> as that's the particular package we want
[06:04] <Keybuk> gnome-screensaver being installed or not should be irrelevant
[06:04] <ogra> Keybuk, even if they dont share common files they break badly if you got both installed
[06:05] <ogra> Keybuk, that doesnt work
[06:05] <Keybuk> ogra: there's no dpkg "Breaks" header I'm afraid
[06:05] <ogra> Keybuk, that caused me to add the Conflicts...
[06:05] <Keybuk> Q. If ubuntu-desktop Depends xscreensaver, and gnome-screensaver is installed which Conflicts xscreensaver, does this:
[06:05] <ogra> you *cant* install them at the same time
[06:05] <Keybuk> a) upgrade ubuntu-desktop and remove gnome-screensaver
[06:05] <Keybuk> or
[06:05] <Keybuk> b) cause ubuntu-desktop to be kept back
[06:06] <ogra> we did a
[06:06] <ogra> which is right imho
[06:06] <seb128> I had both xscreensaver and gnome-screensaver for 2 months
[06:06] <Keybuk> bzzzt.   You?
[06:07] <seb128> not a reason to use a Conflicts though
[06:07] <Keybuk> *shrug*  so people who followed breezy get two menu entries
[06:07] <ogra> seb128, the daemons try to grab the same ressources it cant work
[06:07] <Keybuk> if they file a bug, tell them to remove gnome-screensaver
[06:07] <seb128> what deamon?
[06:07] <ogra> screensaver
[06:08] <seb128> g-s-d explicitly uses gnome-screensaver first
[06:08] <seb128> and start xscreensaver only if this one is not installed
[06:08] <ogra> run them both and you know what i mean...
[06:08] <seb128> I had both install for 2 months as said
[06:08] <seb128> and I accepted the upstream g-s-d patches for that
[06:08] <Keybuk> ogra: this is all very nice, it still doesn't change the fact that what you've done to the package won't prevent this
[06:09] <seb128> so I know how it works thanks
[06:09] <ogra> i.e. gss starts with the session, now open xss config tool, it offers you to run the daemon...
[06:09] <Keybuk> ogra: and that there's no way to do anything to the package to prevent this either
[06:09] <seb128> xscreensaver is not used by GNOME is gnome-screensaver is installed
[06:09] <ogra> seb128, sure, if you open the settings panel
[06:09] <ogra> (of xss)
[06:09] <seb128> bah, if the xscreensaver tools are bugged that's not my issue
[06:10] <sivang> bddebian: working on fixing #6224
[06:10] <ogra> seb128, thats what we support and ship currently
[06:10] <seb128> yeah, fix them
[06:10] <seb128> they are supported :)
[06:10] <ogra> seb128, they are fine as they are
[06:10] <jdub> GOOD MORNING FREEDOM LOVERS!
[06:10] <seb128> hey hey jdub
[06:10] <bddebian> sivang: Nice
[06:10] <sivang> yo jdub da MAN :-)
[06:10] <bddebian> Heya jdub
[06:10] <Robot101> jdub: moin
[06:11] <sivang> bddebian: Can I use use as a tester shall I be done in the nxt coupld of hours ?
[06:12] <bddebian> sivang: Sure, unless you need X :-)
[06:12] <sivang> bddebian: you're X is broken? ;)
[06:12] <ogra> Keybuk, btw i never used rpm in my life :)
[06:12] <ogra> since you refer to it
[06:12] <sivang> ogra: good for you, you are pure :)
[06:12] <ogra> but i'll visit your BOF ;)
[06:12] <Keybuk> ogra: unfortunately it seems that you've never used dpkg either ... :)
[06:13] <ogra> :p
[06:13] <Keybuk> now, could you get rid of that Conflict please
[06:13] <bddebian> sivang: No, I'm ssh'd in from work and I don't have x-forwarding on :-)
[06:13] <ogra> Keybuk, and let the users break their systems ?
[06:13] <ogra> ok
[06:14] <Keybuk> ogra: *sigh* could you go read my comment again please
[06:14] <ogra> your call
[06:14] <Keybuk> that Conflict will not prevent users breaking their systems, and will, instead, prevent users from upgrading their systems
[06:14] <seb128> ha ha ha
[06:14] <ogra> Keybuk, i read it... you say there is *no* possibility to prevent them beoing installed together
[06:14] <Keybuk> yup
[06:14] <sivang> Keybuk: maybe you can dd ot that BOF of yours also overview of the multitude of packaging "solutions" we currently have, e.g. cdbs, dbs, debhelper, and some specific stuff to cdbs? tarball.mk and gnome.mk ? ;-)
[06:14] <seb128> and I'll say it again
[06:14] <Keybuk> sorry, that's just the way it is
[06:15] <seb128> having both installed is useful
[06:15] <ogra> Keybuk, which will break their system
[06:15] <Kamion> sivang: I'd rather people actually learnt about the basics
[06:15] <seb128> GNOME uses gnome-screensaver by default
[06:15] <Keybuk> ogra: seb128 disagrees
[06:15] <seb128> but you may want to uses xscreesanver with KDE on the same box
[06:15] <Keybuk> ogra: and again, that's a side-argument to the fact there's no way a package maintainer can prevent that anyway
[06:15] <sivang> Kamion: cdbs is rather, non basic stuff, or am I mistaken?
[06:15] <Keybuk> dpkg and apt simply don't provide you the headers to stop them doing it
[06:15] <Kamion> sivang: correct. people should learn about dpkg, because apparently nobody does any more
[06:16] <Kamion> sivang: and in any case this discussion is unrelated to packaging *helper* tools, which is what you mentioned
[06:16] <sivang> Kamion: as a user of dpkg, or know it's internals?
[06:16] <Kamion> sivang: its semantics
[06:16] <seb128> cdbs has nothing to do with dpkg
[06:17] <sivang> Kamion: you're right. I actually was more thinking of "use Y for purpose X, use Z for purpose T etc.." but that could be a BOF by its own regard
[06:17] <infinity> Drilling the "unpack phase walkthrough" from Debian ploicy into people's heads, as well as a good and solid understanding of what all the control fields actually do is rather valuable.
[06:17] <infinity> Much moreso than learning the latest whizbang patch system.
[06:17] <ogra> Keybuk, is filig a enhancement bug for dpkg ok with you then ? i mean, how do other apps solve that if they need to access the same ressource ?
[06:18] <seb128> fix the app to not do anything if the ressource is already used
[06:18] <seb128> do nothing and say why to the user
[06:18] <Keybuk> ogra: you mean like #15103 ? :)
[06:18] <Kamion> the fewer Conflicts (and similar) we have in the system, the better
[06:18] <Keybuk> and cf. http://www.dpkg.org/Breaks
[06:18] <ogra> Keybuk, in a sidenote i was asked by mdz to add that Conflict, please add him to CC
[06:19] <Keybuk> that Conflict is wrong
[06:19] <Keybuk> like I said ^^, it prevents ubuntu-desktop being upgraded
[06:20] <ogra> yes, i understand now
[06:20] <Keybuk> rather than forces the removal of gnome-screensaver
[06:20] <ogra> it shall nor force removal of gnome-screensaver
[06:20] <Keybuk> which is almost, but not quite, entirely the opposite of what you intended
[06:20] <ogra> it should prevent both packages being installed at the same time
[06:20] <seb128> NO
[06:20] <Keybuk> it would only do that if xscreensaver Conflict/Replace gnome-screensaver, and gnome-screensaver Conflict/Replace xscreensaver
[06:21] <seb128> again, people maybe want to use one for GNOME and the other for KDE on the same box
[06:21] <Keybuk> but then that would prevent us changing to gnome-screensaver for dapper
[06:21] <ogra> seb128, yes
[06:21] <seb128> Suse does that by default
[06:21] <ogra> seb128, that was the intention of that cnflicts
[06:21] <ogra> regardless if you think thats right, it was its intention
[06:21] <seb128> which is plainly wrong
[06:22] <seb128> there is no reason to force that, both can be installed and used on the same box
[06:22] <ogra> might be
[06:22] <seb128> sure both can't be used by the same user
[06:22] <ogra> they can, just not in the same session on the same display
[06:22] <seb128> but some box have several users
[06:22] <seb128> right
[06:22] <seb128> so no reason to force to have only 1 installed
[06:23] <Keybuk> and this, folks, is why we should be more careful about adding dependencies to ubuntu-desktop
[06:23] <Keybuk> 'cause when we change our minds (*cough*polypaudio*cough*howl*cough*) later, it's bloody hard to get them off the user's system agai
[06:23] <Keybuk> oh, and *cough*gamin*cough*
[06:23] <sivang> what's the questioned dependency ?
[06:23] <Keybuk> I'd almost forgotten about that one <g>
[06:24] <ogra> Keybuk, ubuntu-desktop has the right dependency...
[06:24] <seb128> Keybuk: :)
[06:24] <Keybuk> maybe what we really need to learn is not to listen to jdub <g>
[06:24] <ogra> it always had...
[06:24] <seb128> no
[06:24] <seb128> it has been changed
[06:24] <Keybuk> ogra: it had gnome-screensaver for a while
[06:24] <seb128> and changed back
[06:25] <ogra> Keybuk, yes, and you pointed out a wrong Conflicts in gnoem-secreensaver, which is a gss issue but not a u.d issue
[06:25] <ogra> dont blame u-d for my errors in gss
[06:25] <Keybuk> the conflict is there to try and get around the fact that we've installed gnome-screensaver on some boxes and now installed xscreensaver as well, no?
[06:25] <ogra> Keybuk, nope
[06:26] <Keybuk> so if seb128 claims it all works fine (and it seems to here too), then why's it there?
[06:26] <ogra> Keybuk, the conflict was there because they clash in gnome desktop and have two times the same menu entry
[06:26] <Keybuk> I've just noticed that xscreensaver was never removed from by box
[06:26] <Keybuk> so they have two preferences icons?
[06:26] <ogra> yup
[06:26] <Kamion> using Conflicts is a big deal
[06:27] <Keybuk> couldn't gss ship a hack to make xscreensaver's invisible?
[06:27] <Kamion> don't do it for cosmetics reasons
[06:27] <Kamion> s/cosmetics/cosmetic/
[06:27] <ogra> and xss tries to start the screensaver daemon if you open its panel
[06:27] <Keybuk> and what happens if it does?
[06:27] <Keybuk> I just got a "couldn't start daemon" error here
[06:28] <ogra> Keybuk, it could, but i already lost 4 days to it and we wont support it in breezy... i wont work on it before dapper
[06:28] <Keybuk> won't support which in breezy?
[06:28] <jdub> gnome-session and gnome-settings-daemon kill kittens
[06:28] <ogra> Keybuk, g-s-s
[06:28] <jdub> hopefully the new gnome-session will land for 2.14
[06:28] <Simza> is Broadcom wireless network cards supposed to work automatically in Breezy? (needs ndiswrapper in Hoary)
[06:28] <seb128> jdub: what do you have g-s-d
[06:29] <Keybuk> ogra: ok, so if people have it installed, they get a bit of trouble -- it's a universe package
[06:29] <seb128> jdub: outside NOW
[06:29] <ogra> Keybuk, yup
[06:29] <seb128> s/have/have against/
[06:29] <Kamion> Simza: as far as I know we still have no free drivers for them
[06:29] <jdub> haha
[06:29] <jdub> Keybuk: don't be a cock
[06:30] <jdub> seb128: it's just a painful mess
[06:30] <Keybuk> jdub: you know I love you, really
[06:30] <seb128> jdub: what are the plan for gnome-session? replace it? or make it using libgnomeservice?
[06:30] <jdub> seb128: yeah, libgnomeservice - but that mostly means replacing it in reality anyway
[06:30] <seb128> right
[06:31] <seb128> and for g-s-d ?
[06:31] <seb128> what is the issue with it? it does its job most of the time
[06:31] <jdub> we just need to start thinking about it instead of throwing crap into it all the time
[06:31] <jdub> so, example
[06:32] <jdub> i start random gnome app on my windows xming display
[06:32] <jdub> looks like poo
[06:32] <jdub> so i start gnome-settings-daemon
[06:32] <jdub> which happily goes off and starts the screensaver, does fifteen other pointless things
[06:32] <jdub> so watch my surprise when xscreensaver kicks in on my windows display
[06:33] <seb128> you want to make a different daemon for every single feature we start?
[06:33] <jdub> we just have to think more critically about how these things fit together
[06:33] <seb128> some people complain about it changing fonts
[06:33] <seb128> some other about it changing theme
[06:34] <seb128> some other starting the screensaver
[06:34] <seb128> the other way is to split to like 15 daemons
[06:34] <jdub> our ability to work within other XSETTINGS environments seems to be crap, hey? :)
[06:34] <jdub> no, that's not the only way out
[06:35] <jdub> for instance, with the screensaver, that could be started by the uber session daemon
[06:35] <seb128> uber session daemon
[06:35] <jdub> with XSETTINGS... that requires a lot of other thought
[06:35] <ogra> jdub, dholbach is not desktop-> main o_O
[06:35] <ogra> ?
[06:35] <jdub> ogra: his interest has been universe
[06:35] <Keybuk> will the new stuff mean that I can shutdown my machine, and when I boot it again all my applications are where I left them, on the right desktop, with the right working directory and web pages loaded, etc. ?
[06:36] <ogra> jdub, he does a lot in main now :)
[06:36] <seb128> Keybuk: the current stuff already does that
[06:36] <Keybuk> seb128: it doesn't *work* though
[06:36] <seb128> Keybuk: but apps have to register correctly to the sesison
[06:36] <seb128> session
[06:36] <seb128> Keybuk: yeah, app bog
[06:36] <jdub> Keybuk: half of that is app side (web browser), half of that is wm (right workspace? not atm), etc.
[06:36] <Keybuk> I've never seen an app start on the right desktop
[06:36] <dholbach> ogra: desktop -> main?
[06:36] <jdub> Keybuk: 'workspace'
[06:36] <dholbach> jdub: my interest?
[06:36] <dholbach> ogra, jdub: what are you talking about?
[06:36] <ogra> dholbach, see ubuntu-desktop
[06:37] <jdub> dholbach: ogra is referring to the desktop team stuff
[06:37] <jbailey> Is there anyplace where old packages are stored?  morgue.ubuntu.com seems to have stoped some time ago.
[06:37] <Keybuk> cause I still want my ideal "user session" stuff I talked about at LCA to be a reality <g>  No more logging in and logging out, just switch users and shutdown
[06:37] <jdub> we
[06:37] <jdub> we'll be closer to it with a saner codebase
[06:38] <Keybuk> cool
[06:39] <dholbach> ogra, jdub: if you have a bit of time later today, feel free to tell me slowly, what you were talking about, thanks
[06:39] <jdub> dholbach: see the mailing list
[06:39] <ogra> dholbach, just read your mails
[06:42] <Kamion> jbailey: that's the only place, apart from jackass (which you don't have access to AFAIK)
[06:42] <Kamion> jbailey: I don't know why the morgue mirror on rookery is broken
[06:42] <jbailey> Kamion: 'kay, thanks.
[06:45] <Kamion> jbailey: stick it in sysadmin's RT?
[06:45] <jbailey> Kamion: YezBoz.
[06:49] <jordi> seb128: hey
[06:49] <jordi> is smeg part of breezy? If so, what's the product name in launchpad?
[06:50] <seb128> jordi: it is, no clue ... launchpad has hoary packages only no?
[06:50] <jordi> no, breezy should be there
[06:51] <seb128> that's a question for launchpad guys
[06:51] <seb128> you can use bugzilla for bugs
[06:54] <\sh> phew
[06:55] <\sh> extreme ubz spec writing is making me sweat
[06:55] <ogra> \sh, sweetie :)
[06:56] <\sh> u read it?
[07:02] <Keybuk> \sh: you're not supposed to write the specs until UBZ ... :p
[07:03] <\sh> Keybuk: damn..;) it's already done ;)
[07:03] <\sh> Keybuk: and it rocks man ;)
[07:03] <Keybuk> \sh: which spec?
[07:03] <\sh> ken and barbie are using ubuntu, btw ;)
[07:03] <\sh> https://wiki.ubuntu.com/MOTUIM/DesktopIntegrationSIPIM
[07:04] <\sh> I have to link it to the correct BoF anyways..
[07:05] <Keybuk> but doesn't that mean there's nothing to talk about at UBZ now? :p
[07:05] <Kamion> you wish
[07:05] <\sh> Keybuk: of course someone has to defend this braindead idea ,-)
[07:07] <Keybuk> Kamion: mmm, ThinClientIntegrationBOF
[07:11] <Kamion> Keybuk: hmm?
[07:11] <Keybuk> Kamion: see /Quotes
[07:13] <ogra> Keybuk, ??
[07:15] <Kamion> Keybuk: oh, heh
[07:17] <ogra> Keybuk, you mean the clustering ? thats on the edubuntu roadmap for dapper
[07:18] <Keybuk> <Kamion (on the way to the loo)> I'm on my way to the ThinClientIntegrationBOF
[07:18] <Keybuk> UDU
[07:19] <ogra> lol
[07:24] <Keybuk> Kamion: how's C5 coming along, btw?
[07:25] <mdz> Keybuk: aaaiigighhh
[07:25] <Keybuk> mdz: morning
[07:25] <mdz> (EE) xf86OpenSerial: Cannot open device /dev/input/mice
[07:25] <mdz>         No such file or directory.
[07:25] <Amaranth> Nice.
[07:25] <Keybuk> whuh ... which udev?
[07:25] <mdz> ii  udev           0.060-1ubuntu14
[07:25] <Keybuk> anything in /dev/input at all?
[07:25] <mdz> er
[07:25] <mdz> never mind, my fault
[07:25] <Keybuk> yes, I thought it might be
[07:26] <Keybuk> what did you do?
[07:26] <mdz> heh
[07:26] <Keybuk> said "no" to the conffile prompt when you upgraded?
[07:26] <mdz> commented out mousedev in /etc/modules and forgot abouti t
[07:26] <Keybuk> rofl
[07:26] <bddebian> He pulled a bddebian ;-)
[07:26] <Keybuk> the alternative to it being your fault was that I was going to have a nervous break down
[07:26] <mdz> psmouse, to its credit, does load via isapnp just fine on this box
[07:26] <Kamion> Keybuk: about to build after this cron.daily
[07:26] <Keybuk> yeah, it's when it doesn't show up on the ISA bridge that we have problems
[07:26] <Kamion> only NINE HOURS into the day
[07:27] <Keybuk> it should show up through the kernel's serio stuff, but we, uh, kinda don't hotplug that *eep*
[07:27] <mdz> why is it that psmouse doesn't pull in mousedev anyway?
[07:27] <Keybuk> it's kinda not a dependency
[07:27] <Keybuk> more of a recommends or suggests :p
[07:28] <Keybuk> because there are INSANE PEOPLE who don't want /dev/input/mice
[07:28] <Keybuk> cf. why is unix.ko?
[07:28] <Keybuk> "if it can be optional, it must be optional!" :D
[07:29] <Amaranth> a desktop without a mouse is a bit hard to imagine
[07:29] <Keybuk> one of these days, I'm going to boot a kernel and wonder why "scheduler" is in lsmod output
[07:29] <BenC> irq.ko
[07:29] <mdz> Keybuk: looks like the mailstrom scared off several of the CCs on the udev bug ;-)
[07:29] <Keybuk> yes
[07:29] <Keybuk> I was worrying for your health when you opened ubuntu-bugs
[07:30] <Keybuk> HOW MANY NEW MAILS? *cry*
[07:30] <mdz> Keybuk: unix.ko is loaded if you use unix sockets.  mousedev, being the interface to mice in the input layer, makes sense to load if an input driver for a MOUSE is loaded
[07:30] <jdub> mdz: do you have any strong opinions on ubuntu-devel/forum mirroring?
[07:30] <Amaranth> kill it!
[07:30] <Keybuk> it's not the interface to mice, it's a multiplexer that fakes a ps/2 mouse for any connected mouse
[07:31] <mdz> Keybuk: how is it that a permissions issue caused that HTTP error?
[07:31] <Keybuk> you can get to a mouse through /dev/input/mouse0 etc. without loading it
[07:31] <mdz> jdub: mirroring?
[07:31] <jdub> mdz: mirroring the list on the forum
[07:31] <Keybuk> mdz: I've no idea, Bugzilla crap I guess.  debzilla uses the multi-change interface, which needs editbugs permissions, and it seems to spit the "YOU CAN'T DO THAT" before it spat the http header
[07:31] <mdz> Keybuk: and you can use /dev/kmem to access sysctl values
[07:32] <Amaranth> jdub: make it die, all we get is a lot of noise from people saying "me too" and people responding to spam
[07:32] <Keybuk> mdz: I'm entirely agreeing with you, btw; I'm just giving the reasons I've been told why it can't be either a dependency or compiled in <g>
[07:32] <mdz> jdub: I thought it was supposed to be read-only, but clearly it isn't
[07:32] <infinity> jdub : If they made it a read-only copy of the list, I'd be fine with it.
[07:32] <jdub> mdz: would you prefer a policy change in that regard? :)
[07:32] <infinity> jdub : gating the forums back to the list is just horrible.
[07:32] <mdz> jdub: I'm wary of discriminating based on user interface
[07:33] <Keybuk> I guess, in the end, even if we didn't detect a mouse we STILL want to load mousedev
[07:33] <mdz> jdub: but everything I see coming from the forums to ubuntu-devel is noise
[07:33] <Keybuk> so it's a non-issue
[07:33] <infinity> I loved the guy today who posted a followup to himself because he couldn't "edit his post"... These people have no idea they're even BEING gated to a list.
[07:33] <ogra> infinity, yes, made me laugh too
[07:33] <mdz> and why should they?
[07:34] <mdz> jdub: there's plenty of noise which comes in via email, too, mind
[07:34] <Keybuk> *shrug* I've followed up to my own list posts before
[07:34] <mdz> S/N on ubuntu-devel is poor now
[07:34] <ogra> to not reply to spam if the form filter doesnt work
[07:34] <Kamion> we desperately need to get the signal-to-noise ratio on ubuntu-devel back up so that it's worth reading again, so people should be told that it's the developers' main coordination channel
[07:34] <jdub> mdz: we're working on fixing that
[07:34] <jdub> mdz: but forums... harder.
[07:34] <mdz> Kamion: the only way we're going to maintain that is through moderation
[07:34] <Kamion> mdz: I wouldn't say no
[07:35] <mdz> I would; there will always be a flow of new people joining who don't know what's expected of them
[07:35] <mdz> it's the usenet problem
[07:35] <Amaranth> i've started just looking for interesting subjects and not reading it all, i don't have time for all that anymore
[07:35] <Keybuk> "The never-ending September 2004"
[07:36] <BenC> if the installer could not detect storage and ethernet modules automatically, and they were selected manually, shouldn't the installer add those to initramfs modules list to force them being included?
[07:36] <Kamion> mdz: moderation offers a number of ways to solve that, such as moderators contacting people to explain what's expected of them
[07:36] <Kamion> which is often friendlier than 100 people flaming them on the list because they did something wrong that they didn't know about
[07:36] <mdz> Keybuk: more like 1993
[07:36] <jdub> moderation is a very expensive solution
[07:36] <\sh> mdz: btw...made a decision on amarok 1.3.2?
[07:36] <Kamion> BenC: hmm, possibly - bit late for breezy but we could do for dapper
[07:37] <Keybuk> mdz: now you're doing it too, "I've been using Ubuntu since 1993" :p
[07:37] <BenC> well, it only affected a sparc64 install, so it's not terribly important
[07:37] <mdz> Kamion: are you agreeing that  moderation is the solution?  I assumed 'no' was a typo for 'so'
[07:38] <mdz> moderation isn't that expensive if it's shared among a larger group of people
[07:38] <Kamion> mdz: I am, yes
[07:38] <Kamion> or at least *a* valid solution
[07:38] <Kamion> I haven't heard other ways to get the noise down yet
[07:39] <jdub> mdz: atm, i'm setting up team for moderation, which will help, but that doesn't make it much less expensive
[07:39] <Kamion> mdz: that explains your earlier comment then, which I took for precisely the reverse of its actual meaning
[07:39] <jdub> it just distributes the load
[07:39] <mdz> Kamion: it's also occurred to me that your 'n' and 's' are not adjacent
[07:40] <mdz> unless you've switched to dvorak
[07:40] <Kamion> mdz: I have not :-)
[07:40] <jdub> mdz, Kamion: are you actually suggesting we whitelist participants (rather than all subscribers)? "moderation" doesn't describe a solution
[07:40] <mdz> jdub: that's not a bad idea
[07:40] <jdub> ok then, sorry, i disagree. it's a terrible idea
[07:41] <Kamion> exact forms of whitelisting are an implementation detail; I've seen moderation done all sorts of ways
[07:41] <Kamion> up to and including weird voting systems
[07:42] <jdub> right, but that's the significant part of the solution
[07:42] <jdub> not "let's moderate!"
[07:42] <Kamion> but fundamentally we need not everything (aside from spam) that people send to ubuntu-devel to get through
[07:42] <jdub> we already moderate, in a particular way
[07:42] <dholbach> elmo: ping
[07:43] <Kamion> I could also agree with holding just thread-starting posts for moderation
[07:43] <elmo> dholbach: ?
[07:44] <bddebian> elmo!!
[07:44] <dholbach> elmo: could you please sync tct and gnokii from debian sid? they should build on amd64 then too
[07:44] <Kamion> or there's the lkml-style policy of "if a thread gets out of hand, a moderator posts to say that it will be forcibly ended soon if it doesn't get more reasonable"
[07:44] <bddebian> elmo: Are you waiting to do something with memaid-pyqt?
[07:44] <dholbach> elmo: ok to override our changes
[07:45] <Kamion> (which is a bit on the dictatorial side, but hey, look how people still actually use lkml for real work despite its volume)
[07:45] <jdub> Kamion: lkml is not always a good role model. ;-) you can always just say at the beginning of a meltdown (either start of thread or start of insanity), "hey, let's take this elsewhere".
[07:45] <elmo> dholbach: done
[07:45] <elmo> bddebian: I'm just behind
[07:45] <dholbach> elmo: merci beaucoup
[07:45] <Kamion> jdub: I know it isn't, and I hope my more recent comment clarified that
[07:45] <jdub> quiet, reasonable education seems to work well
[07:45] <bddebian> elmo: No problem, I'm just trying to clean up the lists.  You want me to take a look?
[07:45] <jdub> we just haven't tried that enough yet
[07:46] <jdub> and i would prefer to do that before getting into the more serious forms of moderation
[07:46] <elmo> bddebian: er, what do you mean have a look?
[07:46] <Kamion> for all its faults, lkml has done a good job of keeping traffic generally reasonable for its size, while generating remarkably few complaints
[07:46] <bddebian> elmo: Do the merge and upload
[07:46] <jdub> while scaring away contributors... ;-)
[07:46] <elmo> bddebian: umm - either it's a sync, in which case I'm involved, or it's not a sync and what's it got to do with me?
[07:47] <Kamion> jdub: I don't see a shortage of contributors to the Linux kernel
[07:47] <bddebian> elmo: It's assigned to you on bugzilla
[07:47] <jdub> Kamion: they scare a lot of people awya
[07:47] <Kamion> the kernel needs long-term contributors, not drive-bys
[07:47] <jdub> yeah, and long-term ones are hard to grow without satisfied drive-bys
[07:47] <Kamion> I'd argue that kernel contributors need to be able to cope with the traffic in order to be able to cope with the kernel development model
[07:48] <jdub> traffic, yes. behaviour, no.
[07:48] <mjg59> jdub: I've found lkml to be one of the more reasonable mailing lists I've been on
[07:49] <mjg59> Technical ones, at least
[07:49] <jdub> mjg59: i will put that in context of flaming plastic ____ death. ;-)
[07:49] <Kamion> wow, and people complain about our installer. *How* many times do I have to tell the Windows installer that my locale is "English (United Kingdom)"?
[07:49] <bddebian> elmo: Never mind then, I'll just look at it. :-)
[07:49] <mjg59> Kamion: Weirdly, you *don't*
[07:49] <elmo> bddebian: please do - it shouldn't be assigned to me
[07:50] <bddebian> OK, sorry
[07:50] <elmo> mjg59: umm, yeah you do
[07:50] <Kamion> mjg59: hm? I just had to tell it about five times
[07:50] <mjg59> Kamion: One of the machines I got defaulted to correct ones after I'd selected my timezone
[07:50] <mjg59> So it's *possible* for it to be sane
[07:51] <infinity> OEM installers cut corners, the full Windows install doesn't guess at anything, and so asks you about timezone, language, keyboard, etc.
[07:51] <infinity> Then again, after poor experience with Windows localisation (long, LONG ago, mind you), I lost all faith, and just always install in en_US anyway now.
[07:53] <mjg59> Linspire won't let you choose any english keymap except US
[07:55] <spstarr_work> erm, network-manager build is broken in breezy
[07:56] <spstarr_work> there's no NetworkManagerInfo binary in the packaging
[07:56] <spstarr_work> 0.4.1+cvs20050817-0ubuntu4
[07:57] <ogra> mdz, regarding your ltsp change, i thought to do it by just setting the right environment vars in ldm
[07:57] <dholbach> spstarr_work: i suggest taking this to
[07:57] <dholbach> spstarr_work: i suggest taking this to  #ubuntu-motu
[07:58] <tseng> are there recent kernel changes related to capabilities?
[07:58] <tseng> the most recent changelog doesnt shed light on much
[07:58] <tseng> before reboot, sudo ethereal = works
[07:58] <tseng> after, ethereal cant set its capabilities
[07:58] <tseng> it tries to drop most of them
[07:59] <mdz> ogra: my change only affected the console
[07:59] <ogra> oh
[07:59] <ogra> ok
[07:59] <mdz> ogra: I would welcome a branch which does the same for X debconf
[07:59] <mdz> but it is low priority for breezy
[07:59] <ogra> mdz, i'll do one, also with dhcp.conf generation
[08:00] <mdz> ogra: first, mark needs to be happy with the xscreensaver dialog ;-)
[08:00] <ogra> yup
[08:00] <ogra> but the dhcp.conf stuff is essential, i need to have it solved before release ;)
[08:00] <tseng> oh wow this is emabarassing
[08:01] <ogra> ayway, i got a dog waiting, brb
[08:01] <mdz> Riddell: you have editcomponents now if you want to set default assignees for components in Bugzilla
[08:01] <tseng> capability module isnt loaded
[08:01] <jdub> ogra: the hoary dialogue was good, how about going back to that?
[08:01] <tseng> mdz: id be willing to say thats a pretty serious bug somewhere?
[08:01] <bddebian> tseng: Is that you that has gtksourceview and the mono* stuff on the bugzilla Merge list?
[08:01] <ogra> jdub, sabdfl wants me to mimic the g-s-s dialog ... i'll do that as much as i can ...
[08:01] <tseng> bddebian: probably.
[08:02] <jdub> ogra: but the g-s-s dialogue is crap ;-)
[08:02] <bddebian> tseng: Do you know of any holdup with the gtksourceview one?
[08:02] <Riddell> mdz: ok, thanks
[08:02] <ogra> jdub, in fact sabdfl wants: https://wiki.ubuntu.com/ScreenSaver
[08:02] <tseng> bddebian: is there a problem?
[08:02] <bddebian> tseng: Nope, just trying to clean up MOTU lists :-)
[08:02] <jdub> yeah, sure, but that's totally not breezyable
[08:02] <ogra> but i'm not sure if ui can make it to have a unlock button, that requires heavy code changes
[08:02] <tseng> bddebian: there is no good reason to touch it at this point imo
[08:03] <jdub> ogra: this is such a low-impact change, can't we convince him to be less concerneda about it? simple solution would be better than mucking around.
[08:03] <ogra> jdub, 90% of it are already there its just a matter of moving the pieces to the right place and making the dialog a bit less heigh
[08:03] <jdub> ok
[08:04] <jdub> so long as you don't have to do silly things to make it like that
[08:04] <bddebian> tseng: So reject the merge bug?
[08:04] <ogra> i dont think i can add the unlock button now
[08:04] <ogra> and the rest is fine...
[08:04] <ogra> anyway, dogwalk... brb
[08:05] <bddebian> elmo: OK, please sync memaid-pyqt 0.2.3-4 from unstable.  Our changes can be overwritten.  Thanks.
[08:07] <elmo> bddebian: done
[08:08] <bddebian> elmo: Thanks
[08:09] <bddebian> elmo: Now hit all my e-mails ;-P
[08:10] <bddebian> \sh: You have oo2c to merge on bugzilla ;-P
[08:11] <\sh> bddebian: it's done already..but I need clamav...;)
[08:11] <\sh> bddebian: but not toda
[08:11] <\sh> y
[08:11] <bddebian> Ahh OK :-)  I should have known :-)
[08:14] <\sh> well..beer == klsch here ,-)
[08:21] <ogra> prost \sh
[08:21] <Keybuk> mvo: update-notifier's gone grey again ... what's it doing?
[08:22] <\sh> ogra: cheers friend :)
[08:22] <ogra> Keybuk, ps ax ?
[08:23] <Keybuk> no dpkg or apt running
[08:23] <mvo> Keybuk: grey? does the tooltip say anything useful?
[08:23] <Keybuk> I'll tell you next time it does it
[08:23] <twoSharp> is the gksudo with partially transparent background gone? i lost it after updating...
[08:23] <mvo> Keybuk: it sometimes lags a bit behind in noticing
[08:23] <Keybuk> mvo: by days?
[08:23] <mvo> twoSharp: yes, gone
[08:23] <mvo> Keybuk: I hope not ;)
[08:23] <ogra> twoSharp, yes luckily
[08:23] <Keybuk> I last ran apt yesterday
[08:24] <mvo> Keybuk: anacron and the automatic apt-get update maybe?
[08:24] <twoSharp> mvo, is there any way to get it back? or why did it get removed?
[08:24] <ogra> twoSharp, it look terrible...
[08:24] <ogra> looks even
[08:24] <mvo> twoSharp: the UI team decided that it is visually too strong, sorry, no option to get it back
[08:24] <Keybuk> mvo: at 7:30pm?  nope
[08:24] <Treenaks> ogra: matter of taste, the terrible-ness
[08:24] <Keybuk> that was 12 hours ago
[08:25] <ogra> Treenaks, i dont think so...
[08:25] <twoSharp> where can i get the source code then?
[08:25] <Treenaks> ogra: I liked it :)
[08:25] <mjg59> Keybuk: Any chance of you installing Windows at some point
[08:25] <ogra> Treenaks, its just implemented wrong... the idea is great though
[08:25] <Treenaks> is the wiki known slow?
[08:25] <mvo> twoSharp: apt-get source gksu and remove debian/patches/08_no_fadding.patch and rebuild
[08:25] <ogra> Treenaks, once we'll use composite all over the X server you can have it back, but fade like xscreensaver
[08:26] <Keybuk> mjg59: on what?  and for what reason?
[08:26] <dholbach> Treenaks: for me too
[08:26] <ogra> the wiki is slow since days
[08:26] <mjg59> Keybuk: Your laptop, so I can get tbm to stop whining at me to fix suspend
[08:26] <mvo> Keybuk: you didn't run dpkg by any chance? that triggers it as well (the grey)
[08:28] <Keybuk> mvo: nope, I didn't
[08:28] <Keybuk> mjg59: yeah, I can do; do you know how to netinst windows?
[08:29] <mjg59> Keybuk: Nope
[08:29] <Keybuk> I don't have a CD drive for this laptop
[08:29] <Keybuk> I have the driver disk for it somewhere though, if that would help you?
[08:29] <sivang> ogra: what is the current status wrt xss ? have you started working on gss yet?
[08:30] <dholbach> Keybuk: somebody explained me how to usb-inst windows, it was horribly complicated and i forgot it again :(
[08:30] <sivang> why does Keybuk need windows?
[08:30] <ogra> sivang, as i said yesterday, there wont be much to do on g-s-s, upstream is adopting most of our changes already, by the time we will have to care for it the changes will be minor
[08:31] <sivang> ogra: I see, so what is all the fuss about? ;-)
[08:31] <ogra> which fuss ?
[08:34] <ogra> sivang, you mean the discussion before ? that was more general about packaging...
[08:38] <\sh> dholbach: use windows pe ,-)
[08:39] <ogra> \sh, pe ? pendrive edition ?
[08:40] <\sh> ogra: it's the version which u can pxe/net/usb boot ,-)
[08:40] <ogra> heh
[08:41] <\sh> ogra: but regarding the fact, that it costs money and I don't use copied versions of windows, it's no solution for me to reinstall my laptop...cheaper is to borrow the usb dvd rom of dmitry ;)
[08:42] <mdz> Keybuk: is the joystick issue also resolved now?
[08:43] <ogra> \sh, heh
[08:44] <Keybuk> mdz: no, not yet
[08:44] <Keybuk> I have two different versions of udev which may resolve it
[08:44] <Keybuk> but I'm going to wait until C5 is done before picking one
[08:44] <Keybuk> just so I don't make Colin's day worse <g>
[08:48] <zyga> hmm okay this is not a support question
[08:48] <zyga> I've just burned a dvd with gnome baker, this is a 30-minutes-before upgraded breezy
[08:48] <zyga> the burning went fine without any interrutpion
[08:49] <zyga> afterwards the DVD was automatically ejected so I put it back in to verify the contents
[08:49] <zyga> first I could not mount the cd at all (bad filesystem)
[08:49] <zyga> then I could not eject the disk (invalid argument)
[08:49] <zyga> sudo eject did work though