[12:04] <Kamion> mdz: I'm waiting for the i386 kernels to build
[12:04] <Kamion> or be NEW-processed or whatever, not sure where they are
[12:05] <mdz> Kamion: I mean, does that require a 2-day cycle to get into d-i and then onto the CD?  or does it go straight to the CD?
[12:05] <mdz> on a previous occasion you said that a particular update would take 2 days to propagate
[12:05] <Kamion> http://people.no-name-yet.com/~lamont/buildLogs/l/linux-kernel-di-i386-2.6/0.64ubuntu4/linux-kernel-di-i386-2.6_0.64ubuntu4_20040927-2023-i386-successful says it built OK
[12:05] <mdz> they're probably waiting in NEW, then
[12:05] <Kamion> mdz: I'm going to be doing a debian-installer upload today anyway, so it'll get into that
[12:06] <Kamion> since it's needed for the new kernels
[12:06] <mdz> I wonder if NEW processing can be automated for warty, for new binary packages from existing source
[12:06] <Kamion> and I have a few minor boot screen changes from Mark
[12:06] <mdz> or more importantly, if elmo would explode
[12:06] <Kamion> dunno, I tend to think it's a good sanity check
[12:07] <Kamion> at the very least it would have to validate against germinate output, I think
[12:08] <Kamion> mdz: to answer your earlier question properly, the new kernel .debs go straight to the CD, but the new .udebs require a d-i build and then a CD build
[12:08] <Kamion> if you forget about the d-i build stage, then the CD is essentially unusable for a day
[12:08] <mdz> Kamion: so the end result is that if they get processed in time for your d-i build, they'll be on tomorrow's CD
[12:08] <Kamion> mdz: since I'm waiting for it ... :)
[12:08] <Kamion> yes
[12:09] <Kamion> I'll hopefully be doing a CD build tonight, maybe calling it Sounder 9 if it works
[12:11] <mdz> I tested a CD install after fixing vim, and it worked for me
[12:11] <mdz> so hopefully it should be in good shape
[12:11] <elmo_> NEW cleared
[12:12] <elmo_> anything else before I head back to the hotel?
[12:12] <mdz> elmo_: don't think so, thanks
[12:13] <mdz> elmo_: oht, wait
[12:13] <Mithrandir> elmo_: sync gftp, please?
[12:13] <Mithrandir> elmo_: you've got mail about it, and mdz approved it
[12:13] <mdz> elmo_: myspell-en-us and myspell-en-gb hadn't yet been added to desktopp when you did the resync, I think
[12:13] <mdz> I've added them now
[12:13] <Mithrandir> but I haven't seen it, so I guess you've forgotten?
[12:13] <Mithrandir> or not done yet
[12:13] <mdz> those should be in desktop for sounder 9 if at all possible
[12:14] <mdz> so that spell checking works
[12:14] <elmo_> Mithrandir: it wasn't on ftp.uk earlier - I'll check
[12:14] <Mithrandir> elmo_: it was in incoming when I wrote the mail. :)
[12:14] <elmo_> yeah, I don't sync from incoming, that feels like crossing a line
[12:15] <Mithrandir> makes sense
[12:15] <mdz> likewise for openoffice.org-hyphenation
[12:15] <Mithrandir> mdz: we've had an ooo upload since my amd64 build, right?
[12:15] <mdz> Mithrandir: I think so, yes
[12:15] <Mithrandir> mdz: do you know if anybody has done the amd64 upload as well?
[12:16] <Mithrandir> if not, I should get around to it tomorrow
[12:17] <Kamion> elmo_: hm, will you be able to byhand the debian-installer upload tonight?
[12:17] <Kamion> elmo_: if not, I'll defer Sounder 9 'til tomorrow
[12:22] <mdz> Mithrandir: I do not think it has been done yet
[12:23] <Mithrandir> nope, doesn't look like it.
[12:23] <Kamion> elmo_: just uploaded debian-installer 20040801ubuntu16, so it should build soon
[12:31] <lamont> linux-source-2.6.8.1_2.6.8.1-7_i386.changes REJECTED
[12:31] <lamont> hrmpf
[12:31] <tseng> =/
[12:32] <tseng> did the builder pickup mono yet?
[12:37] <lamont> tseng: source package name mono?
[12:38] <tseng> all the mono stuff we talked about the other day
[12:38] <tseng> update from sid.
[12:40] <lamont> not showing up as of 5 minutes ago
[12:41] <lamont> still, taht is
[12:41] <tseng> hm, ok.
[12:42] <lamont> elmo about?
[12:43] <lamont> "sure, we can get you in and out in a just a couple of hours".. sigh.
[12:45] <elmo_> kamion: processed
[12:46] <Kamion> kewl, ta
[12:46] <elmo_> mdz: myspell done, I think ooo-hyphen stuff was done earlier
[12:46] <elmo_> Mithrandir: done
[12:46] <Mithrandir> elmo_: thanks a lot
[12:46] <elmo_> anything else?
[12:46] <Kamion> ok, I think I need a drink before the parted-code-review-of-doom
[12:47] <Kamion> back in a bit
[12:47] <lamont> elmo_: hints on all the reject mail I got earlier today?
[12:47] <elmo_> lamont: the contrib shit?
[12:47] <elmo_> if so, you can ignore it
[12:47] <lamont> that and some stale amd64 bits
[12:47] <lamont> and some apparently empty changes..
[12:50] <elmo_> who uploaded docbook, sgml-data and gnomemeeting?  it got wrong distributioned
[12:52] <elmo_> seb128: gnomemeeting is you 
[12:52] <elmo_> (ignore the other two, they were daniels and he fixed)
[12:52] <seb128> ok
[12:53] <mdz> elmo_: thanks
[12:53] <mdz> elmo_: -en-gb was seeded, but -en-us was not
[12:54] <mdz> elmo_: looks like -en-us is still in universe
[12:55] <elmo_> yeah, fixed
[12:55] <mdz> thanks
[12:55] <elmo_> really going now, it's 30 mins back to hotel :(
[12:55] <mdz> elmo_: good night
[12:56] <mdz> thanks for staying
[01:29] <azeem> did you guys see the ubuntu review featured on /. already?
[01:42] <mdz> the one which is just a link to the extremetech story?
[01:42] <mdz> (if so, yes)
[01:42] <azeem> yes
[01:43] <azeem> there's another one on osnews, though
[01:47] <Mithrandir> mdz: argh, sorry, I just uploaded ooo-amd64 to sync; I guess that's ok?
[01:47] <Mithrandir> if not, I can still pull it
[01:48] <Mithrandir> no, I can't.
[01:48] <mdz> azeem: yes, that one is already linked from http://www.ubuntulinux.org/ubuntu/press/
[01:48] <mdz> Mithrandir: it's ok
[01:48] <Mithrandir> mdz: sorry about not asking for confirmation.  Shouldn't upload when tired. :/
[01:48] <mdz> good night
[01:53] <jdub> uuuggghhh
[04:16] <tseng> hiya jdub 
[05:38] <fabbione> morning
[05:39] <daniels> morning fabbione
[05:39] <fabbione> hi dani
[05:50] <daniels> jdub: ok if I claim 1394?
[06:00] <fabbione> daniels: do you happen to have Rene Rebe email addredd?
[06:00] <fabbione> address even
[06:00] <daniels> who's rene rebe? :)
[06:01] <fabbione> it's someone that commits code to Xfree86
[06:01] <fabbione> if i knew who he was i wouldn't ask :-)
[06:01] <fabbione> but google returns only one possible match
[06:01] <daniels> heh
[06:01] <daniels> which code has he touched?
[06:02] <fabbione> ok i found him
[06:03] <fabbione> i think i even meet him at LinuxTag
[06:09] <daniels> heh!
[08:48] (jdub/#ubuntu-devel) mdz: anyway, you pinged?
[08:48] <mdz> jdub: I think I wanted to ask you about what ended up becoming #1851
[08:51] <fabbione> mdz: i need to wait to upload X
[08:51] <fabbione> mdz: Overfiend spotted a possible licence problem with one fix i imported from xfree86
[08:52] <fabbione> we already mailed the guy asking for copyright/licence clarification
[08:52] <fabbione> the fix shouldn't be important for the nv driver but it's good to have
[09:02] <jdub> most annoying widget when you have audio turned on: the option list!
[09:04] <jdub> mdz: oddly, g-s-t doesn't even grok that my device is wifi
[09:05] <jdub> argh
[09:08] <mdz> pitti: did you see my report to the list with the new utopia stack crashing?
[09:08] <mdz> fabbione: ok
[09:08] <pitti> mdz: not yet, I look
[09:08] <pitti> mdz: I'm still at processing my inbox...
[09:08] <mdz> ok
[09:09] <mdz> jdub: it seems so strange that it doesn't let you configure an encryption key, since the backend support seems to be all three
[09:09] <mdz> s/three/three/
[09:09] <mdz> s/three/there/
[09:09] <jdub> i can't even configure an essid atm
[09:10] <pitti> mdz: ugh, it crashes in gnome-vfs?
[09:11] <pitti> mdz: I have an idea for a slightly easier method of unmounting
[09:11] <pitti> mdz: I will prepare a test package and send it to you
[09:12] <mdz> pitti: great, I will be awake for a bit, but not too long
[09:12] <mdz> pitti: do you not experience the crash?
[09:12] <pitti> mdz: no, it worked fine for me
[09:12] <mdz> interesting
[09:12] <pitti> mdz: I tried burning to an unmounted and to a mounted RW+
[09:12] <mdz> this is basically a clean warty install
[09:13] <mdz> I did a daily cd install test 2 days ago
[09:13] <pitti> mdz: hmm, I apt-upgraded yesterday
[09:13] <mdz> jdub: what's the deal on wvdial?  shall we suck it up and add wvdial to desktop?
[09:13] <pitti> mdz: but this stuff must work with all versions, not just with one combination
[09:14] <jdub> mdz: i think that's the only way forward at this stage
[09:14] <mdz> done
[09:16] <pitti> mdz: re capability module loading: was there a hotplug update to handle this? I don't have the modules in /etc/modules
[09:16] <jdub> "The biggest flaw I see with this distro ..."
[09:16] <jdub> "Is its name. I mean, what the hell is an Ubuntu? :) I could think of a million names better than this one."
[09:17] <jamesh> as opposed to a Linspire or a Suse?
[09:21] <mdz> pitti: I have no idea; I thought it was in the same situation as ppp_generic, ide-disk, etc. where there was simply no trigger to load it
[09:22] <pitti> mdz: maybe it's loaded automatically as soon as hal starts
[09:22] <pitti> mdz: I will try that out
[09:22] <Mithrandir> ARGH.
[09:22] <Mithrandir> apt-get upgrade hangs, but works if I strace it.
[09:23] <Mithrandir> I wonder how I am to generate an useful error report out of this..
[09:23] <pitti> mdz: hmm, now n-c-b crashes at my box _with_ the fix I had in mind...
[09:24] <pitti> mdz: I wanted to unmount the CD the Gnome way, to get rid of device locks and have the preumount signal
[09:24] <pitti> mdz: but these APIs are not documented yet; if that fails, I can revert to just calling pumount for the device
[09:27] <mdz> jdub: you can configure the essid; it's just sneaky about it
[09:27] <mdz> jdub: essid == "network name"
[09:27] <mdz> jdub: which nobody _ever_ guesses (#1295) and I think we should fix if possible
[09:29] <jdub> mdz: no seriously -> g-s-t does not grok that eth1 is a wireless device. (so doesn't offer *any* of those options.)
[09:30] <mdz> jdub: sux0r, works for me
[09:30] <jdub> also, where do bluetooth devices show up?
[09:30] <mdz> jdub: what do you get when a cross an elephant with a rhino?
[09:30] <pitti> mdz: http://www.piware.de/nautilus-cd-burner_2.8.3-0ubuntu1_i386.deb
[09:30] <pitti> mdz: works for me
[09:30] <jdub> /proc/bluetooth has stuff in it, but the device doesn't seem to be listed anywhere sane
[09:30] <mdz> pitti: I'll give it a try
[09:38] <mdz> Mithrandir: when did this problem appear?
[09:39] <Mithrandir> mdz: some time ago -- a week or two, I think.
[09:39] <jdub> mdz: confirmation for gdm upload that changes conf stuff only?
[09:39] <Mithrandir> I've upgraded to the latest kernel, so it's at least not that.
[09:39] <jdub> four changes in total:
[09:39] <jdub> -#GtkTheme=Default
[09:39] <jdub> +GtkTheme=Human
[09:39] <Mithrandir> mdz: and it's worked around easily enough with LD_ASSUME_KERNEL, but I fear some end-user will run into it.
[09:39] <jdub> -#AllowGtkThemeChange=true
[09:39] <jdub> +AllowGtkThemeChange=true
[09:39] <jdub> -#GtkThemesToAllow=all
[09:39] <jdub> +GtkThemesToAllow=Human,HighContrast,HighContrastInverse,LowContrast
[09:40] <jdub> -#UseCirclesInEntry=false
[09:40] <jdub> +UseCirclesInEntry=true
[09:40] <jdub> 
[09:40] <mdz> jdub: yes (didn't we do that some time ago?)
[09:40] <mdz> at least GtkTheme=Human I thought we had done
[09:40] <jdub> nup
[09:41] <jdub> that was the gdm default theme
[09:41] <jdub> not the gtk theme
[09:41] <mdz> Mithrandir: I've seen no other reports :-/
[09:57] <Mithrandir> mdz: neither has I.
[09:57] <Mithrandir> I'm running on a p4 with the smp kernel, though
[09:57] <Mithrandir> I don't know if that's unusual
[10:06] <seb128> morning
[10:17] <elmo_> aiee
[10:18] <elmo_> seb128: that new gnomemeeting pulled in a whole bunch of stuff to main - known?
[10:18] <seb128> which stuff ?
[10:19] <elmo_> db2, docbook-defguide, docbook-ebnf, fftw, tidy, wvdial, wvstreams
[10:19] <seb128> that's due to gnomemeeting ?
[10:19] <seb128> I've uploaded previous version with only "libpt-plugins-v4l | libpt-plugins-avc | libpt-plugins-dc" in the depends
[10:21] <elmo_> hmm, maybe not, sorry, I think it's gnome meeting plus some seed changes
[10:21] <seb128> ok, no problem
[10:21] <seb128> wvdial is required for ppp config with gnome-system-tools
[10:22] <seb128> somebody probably added it to a seed
[10:22] <seb128> dunno for the others
[10:22] <elmo_> yeah, matt did
[10:22] <elmo_> most of them seem to be pulled in as build-deps for wvdial
[10:22] <elmo_> evil
[10:22] <seb128> ok
[10:25] <sivang> fabbione , here?
[10:26] <mdz> Mithrandir: does it go away if you use the non-smp kernel?
[10:26] <sivang> or daniels?
[10:26] <mdz> elmo_: how bad is it?
[10:26] <mdz> I knew it pulled in one other package, but didn't look beyond that
[10:26] <elmo_> oh
[10:26] <mdz> fftw??
[10:27] <elmo_> you're still awake
[10:27] <elmo_> mdz: b-d of wvstreams
[10:27] <elmo_> (which is b-d of wvdial)
[10:27] <mdz> yeah
[10:27] <elmo_> all the ones I listed above are source packages that'll be pulled in
[10:27] <mdz> what crap
[10:27] <sivang> anyone besides fabbione/daniels can help to work a 100hz working X config?
[10:27] <elmo_> all due to wvdial
[10:28] <mdz> I wonder if wvstreams can be pared down not to require those
[10:28] <mdz> certainly the doc stuff
[10:28] <sivang> I've been munging it for a couple of hours, X just won't agree to use 100Hz for vrefresh. Although monitor supports it
[10:29] <elmo_> mdz: want me to add it in the meantime?
[10:30] <mdz> elmo_: that is way too much cruft for my comfort
[10:30] <mdz> I wish we didn't need wvdial itself either
[10:34] <fabbione> sivang: yes i am around but please move the discussion to #ubuntu
[10:34] <sivang> fabbione : ofcourse
[10:40] <fabbione> crack of day doesn't install
[10:40] <fabbione> libdns16 is not going to be installed
[10:54] <mdz> fabbione: uploading a new debootstrap
[10:58] <elmo_> gar, main depends on restricted now?
[10:58] <elmo_> is that valid?
[11:01] <mdz> elmo_: I emailed you and colin twice, weeks ago, asking your opinion on that, and neither of you replied
[11:02] <mdz> pitti: your new nautilus-cd-burner fixes the segfault
[11:02] <elmo_> you mentioned that, but I couldn't find any mail about it
[11:02] <mdz> pitti: but the original problem is not fixed
[11:02] <pitti> mdz: okay, thanks for the report
[11:02] <pitti> mdz: which original problem?
[11:02] <mdz> pitti: the device is still mounted in the middle of the write operation
[11:02] <pitti> mdz: even with the new hal/gvm?
[11:02] <mdz> Version: 0.2.98-1ubuntu1
[11:02] <mdz> Version: 1.0.2-0ubuntu1
[11:03] <pitti> mdz: when you start to burn, hal-device-manager should display some info.lock* properties
[11:03] <pitti> mdz: it worked fine for me, so I thought that were handled...
[11:04] <mdz> pitti: I did not see any; is that the right version of hal?
[11:04] <pitti> mdz: this locking stuff is not perfect anyway; it is an advisory lock for gvm, and you can still pmount the device or use a manual mount (right-clock in context menu)
[11:04] <pitti> mdz: yes, right hal version
[11:05] <elmo_> mdz: I've re-searched and really can't find this mail - can you give me a subject/msg-id?
[11:05] <mdz> 02:05:24.253 [I]  linux/block_class_device.c:2312: Directory /etc changed
[11:05] <mdz> 02:05:24.253 [I]  linux/block_class_device.c:2226: /etc/mtab changed, processing all block devices
[11:05] <pitti> mdz: I also could reproduce this once, but I tried yesterday and it did not "work" (the bug reproduction)
[11:05] <mdz> pitti: that is all I see from hal when the write starts
[11:06] <pitti> mdz: I don't know whether the lockign stuff is logged; can you look into hal-device-manager?
[11:06] <mdz> elmo_: I'll look; I don't _think_ I hallucinated it
[11:07] <mdz> elmo_: but basically I think it comes down to naming.  I'd like to have a metapackage which depends on both linux-image and linux-restricted-modules, and probably another one which just depends on linux-image
[11:07] <pitti> mdz: I just got another grave bug report against the new hal; it can destroy USB stick file systems
[11:07] <mdz> but I can't think of reasonable names
[11:07] <pitti> mdz: new upstream versions...
[11:08] <mdz> elmo_: Message-ID: <20040917001908.GR5721@alcor.net>
[11:08] <mdz> elmo_: Subject: Re: Metapackages for linux-restricted-modules
[11:08] <mdz> pitti: great :-/
[11:08] <mdz> pitti: anyway the burning seems to work correctly at least
[11:08] <pitti> mdz: yes, great that I did not upload the stuff immediately :-/
[11:08] <mdz> it is just disconcerting to have it open and close during the process
[11:09] <pitti> mdz: oh, when it happened to me, the burning failed
[11:09] <pitti> mdz: maybe because my burner is very old and does not have burnproof and the like
[11:09] <pitti> mdz: locking still should work, this was the primary reason for the new upstream stuff
[11:09] <pitti> mdz: I take a look at this today
[11:11] <elmo_> mdz: okay, sorry I did get that but managed to completely lose it somehow
[11:11] <elmo_> mdz: anyway, I really think violating the main-is-a-self-contained-unit thing is a bad plan, but I can't really justify it beyond that
[11:13] <fabbione> mdz: 1405. i dunno. i can't really check right now since my test box can't be installed until debootstrap is built and uploaded
[11:14] <mdz> elmo_: I agree; I was looking for something more in the way of a solution
[11:14] <mdz> fabbione: it is already built and uploaded
[11:15] <elmo_> mdz: you should have learnt not to have such unreasonable expectations by now, dude
[11:16] <mdz> eek, hal just segfaulted on me
[11:16] <mdz> after I powered off my burner
[11:16] <mdz> 02:15:24.905 [I]  linux/block_class_device.c:637: Disc in /dev/sr0 has audio
[11:16] <mdz> 02:15:24.905 [I]  linux/block_class_device.c:666: get_disc_type returned 0x360a
[11:16] <mdz> 02:15:24.905 [I]  linux/block_class_device.c:1027: Media in no_partitions device /dev/sr0
[11:16] <mdz> [1] +  Segmentation fault      sudo hald --drop-privileges --daemon=no --verbose=yes
[11:16] <pitti> mdz: do you run this with --daemon=no?
[11:16] <elmo_> mdz: but seriously, there are no solutions beyond "don't do that" surely? i.e. using, like you  said, two meta packages
[11:16] <mdz> pitti: correct
[11:16] <pitti> mdz: or where do you get these messages from?
[11:17] <mdz> elmo_: <mdz> elmo_: but basically I think it comes down to naming.  I'd like to have a metapackage which depends on both linux-image and linux-restricted-modules, and probably another one which just depends on linux-image
[11:17] <elmo_> I think two meta packages is more correct anyway as not all of us are going to want the restricted crap installed
[11:17] <pitti> mdz: incidentially, my hal also crashed
[11:17] <mdz> I guess we could have linux-<flavour> as the image+restricted one
[11:17] <mdz> and create a linux-image-<flavour> for just the image
[11:17] <pitti> mdz: but no segfault, it just hangs uninterrupibly
[11:17] <mdz> ok, I need to get to bed
[11:17] <mdz> more on all of this tomorrow
[11:18] <pitti> mdz: sleep well! If you can reproduce the crash, can you please try to run it in gdb?
[11:18] <fabbione> mdz: well it's not on auckland yet :-))
[11:21] <seb128> hum
[11:21] <seb128> I've added "libpt-plugins-v4l | libpt-plugins-avc | libpt-plugins-dc" to the gnomemeeting depends ... we need to update seed too to get these into main ??
[11:22] <seb128> -?
[11:24] <elmo_> seb128: I did that already
[11:25] <elmo_> seb128: but please mail me when you do stuff that adds deps on stuff in universe - it's not automated
[11:25] <seb128> ok, thanks 
[11:25] <seb128> sorry, I'll remember next time
[11:25] <elmo_> no prob
[11:26] <seb128> I was thinking that depends for stuff in main were automatically in main ...
[11:27] <elmo_> no, because a) the wiki's wide-open and that's where the seed lists are, b) even additions by our venerable CTO (e.g. wvdial) lead to unexpected and unwanted changes
[11:32] <seb128> ok
[11:32] <elmo_> kiko would like you all to not do any work because he couldn't code his way out of a wet paper bag
[11:32] <elmo_> even pylint says so
[12:05] <Mithrandir> mdz: yes, non-smp kernel fixes it.
[12:19] <fabbione> mdz, jdub: permission to upload initscripts to fix #1405
[12:25] <thom> *drool*
[12:26] <daniels> thom: gar
[12:26] <daniels> thom: i'll let you keep the hard drives if you send me the LCD
[12:26] <thom> har har
[12:26] <daniels> thom: sound fair?
[12:26] <thom> you're so kind
[12:26] <daniels> i know. the Mother Teresa of the open source world.
[12:27] <daniels> fascists.
[12:27] <daniels> they called me at 11am (!) and then said they'd email me all the details I needed to actually pay them in half an hour
[12:27] <daniels> that was a good 9 hours ago now
[12:28] <thom> heh
[12:29] <fabbione> who is going to approve uploads if both mdz and jdub are not available?
[12:29] <fabbione> elmo?
[12:31] <daniels> hm, sabdfl, mdz and jdub all unavailable
[12:32] <ross> fabbione: i'm sure its fine to upload
[12:32] <daniels> i sense this is an extension of the dsl bug; more anti-canonical agents, I suspect
[12:32] <fabbione> ross: eheheh i know it's fine.. but we are deep freeze and uploads require authorization
[12:40] <elmo_> fabbione: no, not me, I'm just the archive bitch, nothing to do with RM
[12:41] <Mithrandir> fabbione: mdz should be up in five-ish hours, though.
[12:41] <fabbione> elmo_: well you are still cool enough to do RM too :P
[12:41] <fabbione> Mithrandir: yeah but i won't be around in 5 hours..
[12:41] <fabbione> Mithrandir: gotta go and talk with the electrician.
[12:41] <Mithrandir> I should set up 1-hour DELAYED, 2-hour DELAYED and so on for us.
[12:42] <elmo_> Mithrandir: gar no
[12:42] <fabbione> the little punk he sent to me to make a job proposal didn't get a clue that i need a nuclear power plant in the garden
[12:42] <Mithrandir> elmo_: jk. ;)
[12:43] <thom> Mithrandir: i have a pair of 200s, as it happens
[12:43] <Mithrandir> thom: smallish, then.
[12:43] <Mithrandir> thom: I have a pair of 400s.
[12:44] <thom> that seems a little over the top
[12:44] <Mithrandir> not for a backup box
[12:44] <thom> given that i have windows and two warty installs on a single 40GB drive, 200GB is gonna feel huge
[12:44] <thom> Mithrandir: ah. see, this is for my desktop
[12:44] <Mithrandir> my ~ is 20G.
[12:44] <jdub> fabbione: you need approval for 1405?
[12:45] <thom> 4.9G  4.4G  506M  90% /home
[12:45] <jdub> man, hardly worth answering questions on u-u anymore, given the multiple answers all the time
[12:45] <thom> it gets very uncomfortable when building firefox ;-)
[12:46] <fabbione> jdub: yes
[12:47] <Mithrandir> thom: I can imagine.. that's the size of my mail dir
[12:47] <jdub> fabbione: ok, approved
[12:49] <fabbione> jdub: thanks
[12:49] <fabbione> done
[01:03] <trukulo> jdub: good night
[01:43] <ross> Kamion: i take it tomorrows daily images will have the new kernel in?
[01:43] <Kamion> today's already do
[01:43] <Kamion> they don't work for other reasons
[01:44] <ross> ah, ok. will tomorrows work? :)
[01:44] <Kamion> huh, wait a sec
[01:44] <Kamion> aha, today's *didn't build* :P
[01:44] <ross> aah
[01:45] <Kamion> and that would be because people *still* need to warn me when they're going to change the base system. gah.
[01:50] <elmo_> sorry (I didn't request it, but I could have blocked it/whined at NEW)
[02:07] <Kamion> ah well
[02:07] <elmo_> Purging configuration files for nautilus ...
[02:07] <elmo_> rmdir: `/etc/X11/starthere': No such file or directory
[02:07] <elmo_> dpkg: error processing nautilus (--purge):
[02:07] <elmo_> seb128: getting that on one of the machines in the DC - known/fixed problem?
[02:08] <seb128> no, not known
[02:08] <seb128> I'll have a look
[02:09] <lamont> morning world
[02:09] <thom> yo
[02:09] <seb128> hey lamont 
[02:10] <seb128> elmo_: ok, I'll fix it
[02:10] <lamont> gotta take kids to school in a few.
[02:10] <elmo_> seb128: cool, thanks
[02:10] <elmo_> seb128: want me to file a bug you can point jdub/mdz at?
[02:11] <elmo_> seb128: btw, it's all 3 directories mentioned in the postrm, but I guess you knew that
[02:11] <seb128> no, that's fine. I'm allowed to fix GNOME bugs without asking :)
[02:11] <seb128> yes, I know, but thanks :)
[02:12] <elmo_> haha, Jeff's RM-ing is just such an excuse for him to ignore the rules for "feature goals" (i.e. what he cares about :P)
[02:12] <lamont> elmo_: duh...
[02:13] <lamont> it's _ALWAYS_ that way.  When it's not, you have a boring RM. :-)
[02:13] <elmo_> Looking for keymap to install:                                                                                                  
[02:13] <elmo_> \mac-usb-uk
[02:13] <elmo_> oh my god, not that stupid bug still!
[02:13] <elmo_> (the \ is a pasto, ignore that)
[02:13] <Kamion> hm? mac-usb-uk's correct here
[02:13] <elmo_> kamion: not on a HP DL380, it's not
[02:13] <Kamion> !
[02:14] <elmo_> that happened as part of the upgrade
[02:14] <Kamion> console-data must be on good crack
[02:14] <Kamion> I'm afraid I only barely understand what's going on in console-data.config, though
[02:15] <Kamion> 'dpkg-reconfigure console-data' ought to at least let you clear it up ...
[02:21] <elmo_> GOD DAMN IT
[02:22] <pitti> sjoerd: here?
[02:22] <sjoerd> pitti: yeah
[02:23] <pitti> sjoerd: I looked at this mount locking stuff when a CD-RW is burned
[02:23] <pitti> sjoerd: currently only the hal package supports locking; but shouldn't gvm actually check this lock before mounting a device?
[02:23] <pitti> sjoerd: do you know whether this is already implemented upstream?
[02:24] <sjoerd> pitti: it's in gvm's unstable branch
[02:24] <sjoerd> pitti: i intend to patch debians gvm 1.0.2 with it before uploading
[02:24] <pitti> sjoerd: I was already wondering why cd burning still sucks...
[02:24] <sjoerd> but first hal needs to get out of new...
[02:24] <pitti> sjoerd: thanks; I will grab it from there
[02:24] <pitti> sjoerd: do you happen to have the CVS URL at hand?
[02:25] <pitti> sjoerd: don't bother, I have it
[02:25] <sjoerd> hehe
[02:25] <sjoerd> pitti: although for debian it's still somewhat useless, because nothing uses it
[02:25] <pitti> sjoerd: we urgently need that to fix cd burning
[02:26] <pitti> sjoerd: the half-written cd is mounted during burning, which breaks the further burning
[02:26] <pitti> sjoerd: and the user can still manually mount the cd
[02:26] <sjoerd> autch
[02:27] <sjoerd> only that some drives abort burning when nautilus polls media status
[02:27] <pitti> sjoerd: ah, I have the patch
[02:27] <sjoerd> s/nautilus/hal/
[02:28] <pitti> sjoerd: when I'm at fixing gvm, what does this 03_browse_fixup patch do?
[02:28] <pitti> sjoerd: does it open a nautilus window if gthumb is not invoked?
[02:29] <sjoerd> pitti: yes
[02:29] <pitti> sjoerd: nice
[02:29] <sjoerd> pitti: same for when inserting dvd's when video playing action is disabled
[02:30] <pitti> sjoerd: will it go upstream?
[02:30] <pitti> sjoerd: I don't want to diverge from upstream behavior too much
[02:30] <sjoerd> pitti: i've sent it but it wasn't applied 
[02:30] <pitti> sjoerd: we already discussed that; this should probably be another option in the removable device configuration dialog
[02:31] <sjoerd> pitti: ?
[02:32] <pitti> sjoerd: Ubuntu has a nice dialog where you can configure what happens with your removable devices
[02:32] <pitti> sjoerd: This is no Ubuntu invention, it must be there in Debian, too
[02:32] <sjoerd> pitti: you mean gnome-volume-properties 
[02:32] <pitti> sjoerd: probably :-)
[02:33] <sjoerd> what do you mean by ``this'' there. Opening nautilus when the import photo's option is disabled ?
[02:37] <pitti> sjoerd: by "this" I mean "fall back to browsing if no other handling was applied"
[02:37] <sjoerd> ok
[02:37] <pitti> sjoerd: IMHO it makes sense
[02:38] <pitti> sjoerd: but some users might not want it
[02:38] <sjoerd> hmm.. well a mass storage camera is just removable storage, for which gvm makes an exception
[02:38] <pitti> sjoerd: AFAICS this gvm patch only inhibits automatic mounts during CD Burning
[02:38] <pitti> sjoerd: users can still mount it manually
[02:39] <pitti> sjoerd: so maybe gnome-vfs2 shoudl respect info.locked as well?
[02:39] <sjoerd> that would be nice
[02:40] <pitti> sjoerd: this still won't help against a command line "mount", though
[02:40] <pitti> sjoerd: that's the reason why I implemented this in pmount
[02:41] <azeem> pitti: who sould mount a CD while it is getting burned?
[02:41] <pitti> sjoerd: but matt prefered the upstream solution
[02:41] <azeem> eh, s/sould/would/
[02:41] <pitti> azeem: users do stupid things.. :-)
[02:41] <azeem> yeah, but you don't patch coreutils to prevent rm -rf $HOME either, do you?
[02:41] <sjoerd> there is a certain level where the user is just doing stupid things
[02:41] <pitti> azeem: no
[02:42] <pitti> sjoerd: agreed :-)
[02:42] <sjoerd> you can't prevent that :)..
[02:42] <azeem> I mean, if somebody uses the command-line, he should know what he does
[02:42] <azeem> or she
[02:42] <sjoerd> preventing accidental mounts from nautilus sounds nice though
[02:42] <pitti> sjoerd,azeem: Implementing it in pmount was no big deal, so it would have been nice
[02:42] <sjoerd> Is ubuntu's cdrecord patched to use O_EXCL btw ?
[02:43] <pitti> sjoerd: I will implement this if the current packages are uploaded
[02:43] <pitti> sjoerd: I don't know
[02:43] <pitti> sjoerd: but that sounds sensible; I added it to my ~/.todo
[02:44] <sjoerd> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262678 for some more info about it
[02:48] <sjoerd> same goes for all other burning programs ofcourse
[02:48] <pitti> sjoerd: like these dvd+rw-utils?
[02:50] <sjoerd> pitti: if that's the same as dvd+rw-tools in debian
[02:51] <sjoerd> and libburn and cdrdao
[02:56] <pitti> sjoerd: thanks for pointing me to that; we don't have this patch
[03:32] <daniels> thom: what's it done now?
[03:35] <Kamion> lamont: can you remind me how the buildds manage to install linux-image-* in a chroot?
[03:36] <Kamion> elmo_: or if you know, for that matter ...
[03:40] <T-Bone> lamont: ping, btw
[04:12] <thom> i can see why mark likes mozilla so much. it's the ultimate "ooh shiny" development menthodology
[04:12] <thom> methodology, even
[04:13] <thom> "hey, corba in javascript sounds cool!"
[04:16] <ross> with XML and RDF!
[04:16] <ross> and and and
[04:16] <ross> things!
[04:16] <thom> and C++!
[04:16] <thom> gar
[04:17] <thom> oh well, i shall hack on php for a bit to save my poor brain
[04:28] <daniels> thom: C++ is love, kiddo :)
[04:28] <daniels> (C# more so, however)
[04:29] <ross> sjoerd: thanks for the patch :)
[04:30] <ross> sjoerd: have the cd-drive patches been applied to n-c-b already?
[04:30] <ross> i can't believe i left HAL_CFLAGS out
[04:30] <sjoerd> sjoerd: no idea
[04:30] <sjoerd> ross: no idea
[04:31] <sjoerd> beh
[04:31] <ross> k
[04:36] <Kamion> Subject: Processed: only in Keny^Wwoody
[04:36] <Kamion> haha
[04:44] <lamont> Kamion: on the buildd's, I do this:
[04:44] <lamont>     echo do_initrd = Yes > ${chroot}/etc/kernel-img.conf
[04:44] <lamont>     install -m644 /etc/fstab ${chroot}/etc/fstab
[04:44] <lamont> although (technically) you just need the root filesystem'sentry in /etc/fstab in the chroot.
[04:44] <Kamion> heh, ok, thanks
[04:44] <Kamion> as it turned out I got bored and nobbled the postinst :)
[04:44] <Kamion> but I'll know for next time
[04:45] <lamont> OTOH, it would be much better if the postinst actually noticed that it was in a chroot, and just dealt with it.
[04:48] <Kamion> lamont: aye
[04:49] <T-Bone> ladude!
[04:49] <lamont> t-dude
[04:50] <lamont> T-Bone: let me guess: "So how do I make that thar archive thang?"
[04:50] <T-Bone> lamont: lol, roughly
[04:51] <lamont> man dpkg-scanpackages :-)
[04:51] <T-Bone> hmm, isn't apt-ftparchive easier to use?
[04:51] <lamont> truthfully, put all the _ia64.deb's and _all.debs (harvested from an i386 warty box, or the mirror of your choice) into one directory, and run your archive creator of choice.
[04:52] <lamont> yeah, whatever. :-)
[04:52] <T-Bone> lamont: thx to you, i _have_ a local mirror ;)
[04:52] <lamont> then comes the tricky part...
[04:52] <lamont> ah, yes. well.
[04:53] <lamont> once you have that repository built, then you have to:
[04:53] <lamont> A) decide if you think you can debootstrap from it or not.
[04:53] <T-Bone> lamont: bad news: perl won't build
[04:53] <lamont> assume "not"
[04:54] <lamont> that would be a definite "not". :-)
[04:54] <T-Bone> lol
[04:54] <T-Bone> make[1] : *** [lib/Config.pm]  Segmentation fault
[04:55] <lamont> so.  Add your freshly created ia64 (incomplete) repository to sources.list in the chroot, _BEFORE_ snapshot.d.n
[04:55] <lamont> apt-get clean
[04:55] <lamont> apt-get update
[04:55] <lamont> apt-get -udy dist-upgrade, see how ugly it looks, then probably really upgrade.
[04:56] <lamont> repeat all those steps iteratively until such time as you have a debootstrappable repository.
[04:56] <lamont> (from apt-ftparchive through dist-upgrade/sbuild)
[04:56] <lamont> the sbuild happens after the dist-upgrade, but before the "repeat" :-)
[04:56] <T-Bone> lol
[04:57] <T-Bone> looks like it's not gonna be a "one shot"
[04:58] <Kamion> iva
[04:58] <Kamion> oops
[04:58] <Kamion> focus-follows-touchpad. boo.
[04:58] <Kamion> lamont: fluxbox, as it happens, and this is *normally* the behaviour I want ...
[04:59] <thom> daniels: nothing about C++ is love
[04:59] <T-Bone> lamont: assuming glibc builds cleanly this time, we only have perl left, and we hope that rebuilding it from an almost ubuntu chroot will make it build, right?
[04:59] <lamont> right.
[04:59] <lamont> at this point, the only things we worry about rebuilding are things we need to debootstrap
[04:59] <Kamion> lamont: the kernel clobbers /proc/$$/root when viewed from inside the chroot, so there are at least some attempts to make it hard to tell
[04:59] <daniels> thom: eh, there are a lot of things to like.  classes, inheritance, all the good stuff.
[05:00] <lamont> then we (1) save this chroot, because we'll need it later, and (2) create a fresh new warty chroot, throw everything away, and let the building begin.
[05:00] <T-Bone> lamont: ok. Then afterwards we'll get into the "real" step2, where we'll debootstrap from this archive a new ubuntu ia64 chroot under which we'll rebuild main one more time, correct?
[05:00] <lamont> of course, at any point that you have enough to play with a CD set, you can start playing with that...
[05:00] <lamont> Kamion: yeah
[05:00] <lamont> it's supposed to not be easy.
[05:00] <T-Bone> lamont: right, CD set is the top item on my todo list
[05:01] <lamont> Then again, if you're on ext[23]  and / isn't inode 2, you're in a chroot..:-)
[05:01] <Kamion> heh
[05:01] <lamont> Kamion: but if it _is_ to, then you may or may not be in a chroot.
[05:01] <T-Bone> lamont: actually, i don't want to rebuild everything then in the "stage1-2" phase, i'm only trying to rebuild perl, right?
[05:02] <lamont> in our bastardized half-breed chroot, we just want to build enough to create our new chroot.
[05:02] <lamont> and additional gravy as desired.
[05:03] <lamont> that is, we'll eventually want a fully-built warty tree, built on the bits we built in stage 1
[05:03] <lamont> but for working on the CD's, you really only care that you have bits.
[05:03] <T-Bone> ok. So i can save time in sbuilding only what's needed to debootstrap, during the bastardized stage
[05:04] <lamont> shlib deps and such may be issues, hence the stage 2 build.  But I expect that you'll hit DI issues before you hit stage1 vs 2 issues
[05:04] <lamont> right.
[05:04] <T-Bone> okay
[05:04] <lamont> and then later (in full-blown stage2 timeframe), you'll discover circular build-deps that you need to bastardize back into existance because they didn't build in pure-stage 1
[05:04] <lamont> hence we keep the bastard chroot
[05:04] <T-Bone> lol
[05:05] <lamont> the process is very much objective-focused.. :-)
[05:05] <lamont> step i) "do whatever it takes to" ...
[05:05] <lamont> for all values of i.
[05:06] <T-Bone> lol
[05:06] <T-Bone> and i thought that bootstraping an arch was something "clean" ;)
[05:06] <lamont> with a footnote to remember anytime you kludge something horribly, because it'll come back and bite you in your backside later when the buildd's start bootstrapping from your chroot...
[05:06] <T-Bone> come to think of it, i recall some dirtyness during the fist days of palinux ;))
[05:06] <lamont> yeah
[05:07] <lamont> it's never pretty at the start...
[05:07] <T-Bone> even more fun, we had to crosscompile
[05:07] <lamont> kinda like working with raw sewage, sometimes...
[05:07] <T-Bone> yeah ic ;)
[05:07] <lamont> elmo/elmo_: as a note... When we upstream-version-freeze, could we pretty please snag a consistant archive for all the architectures we _don't_ support, too? :-)
[05:08] <T-Bone> LOL!
[05:08] <lamont> or maybe one of the architecture boot-strap teams could help snapshot.d.n get good archive-by-date Packages files..
[05:08] <lamont> T-Bone: I meant _upstream_ archive, not ours.
[05:09] <elmo_> lamont: sure.. just remember to remind me ;)
[05:09] <lamont> 'l
[05:09] <lamont> 'k, even
[05:10] <lamont> t-bone: btw, my stage-1 build is up to gcc-3.3 finally
[05:12] <lamont> Kamion: I got it....  Do the chroot-escape hack, and if you wind up at the same place, then you're not in a chroot.. :-)
[05:13] <T-Bone> lamont: hehe, as a matter of fact, rx2600 is much faster than i2000 ;) hppa is building #633
[05:13] <lamont> yeah
[05:13] <Kamion> lamont: :-)
[05:13] <lamont> T-Bone: once my wife's conference is over this weekend, then I'll worry a little bit about getting the zx2000 powered up somewhere useful.
[05:14] <Kamion> so, this hideous parted C/H/S bug is apparently fixed in parted 1.6.12
[05:14] <T-Bone> lamont: hehe ;)
[05:14] <T-Bone> lamont: i'll setup apache so that you can access my archive anyway
[05:14] <daniels> Kamion: huzzah!
[05:14] <Kamion> I'm contemplating just upgrading us to that directly, because I really don't trust the Debian parted maintainers to have come up with a sane parted 1.6.11+patch-based package
[05:14] <Kamion> particularly because until I noticed it last night the relevant patch wasn't even being APPLIED, so it's clearly had no testing
[05:14] <daniels> is timshel still maintaining it?
[05:15] <Kamion> no, luther
[05:15] <daniels> oh god
[05:15] <lamont> T-Bone: I'll mail you my list of .changes: let me know if you want any .debs from the pile...
[05:15] <Kamion> does anyone here actually have a system which manifests the problem?
[05:15] <T-Bone> lamont: ok
[05:15] <Kamion> I don't, which makes it problematic
[05:15] <T-Bone> lamont: asa i'll have setup the repo, i'll mail you the url as well
[05:16] <lamont> sent
[05:16] <T-Bone> thx!
[05:17] <T-Bone> i'll send some feedback to u-devel about the progress we're making, too.
[05:18] <lamont> mdz: they closed the debian bug wrt SIGILL/powerpc (#1596 for us)... Can I close it here too?  or do we want to actually look for the bug?
[05:18] <lamont> :-)
[05:21] <lamont> fabbione: _ANOTHER_ xfree86?  sihg.
[05:21] <lamont> sigh,even.
[05:22] <lamont> Kamion: can you verify that 1711 is fixed by adding postfix reconfig back to base-config?
[05:23] <Kamion> lamont: give me a sec, I'll do a fresh install
[05:23] <lamont> Kamion: anytime in the next 10 hours or so would be wonderful... :)
[05:39] <lamont> T-Bone: still there, yep.
[05:40] <T-Bone> hehe ;)
[05:47] <Kamion> lamont: well. newaliases gets run, but the only entry in /etc/aliases is still postmaster: root
[05:47] <lamont> hrmpf.
[05:48] <lamont> Kamion: any chance you could mail or /msg me the output from debconf-show postfix?
[05:49] <Kamion> lamont: I'll have to transcribe it, give me a second
[05:49] <Kamion> no network connectivity on that box
[05:56] <lamont> Kamion: what exactly is in base-config?  dpkg-reconfigure -pcritical postfix?
[05:57] <Kamion> -       exec dpkg-reconfigure --unseen-only --default-priority postfix
[05:57] <lamont> and after the user gets added, yes?
[05:57] <lamont> is there any way for postfix to know that debootstrap is why it
[05:57] <lamont> s being configured?
[05:58] <Kamion> well after the user gets added
[05:58] <Kamion> why does it need to know?
[05:58] <Kamion> I don't understand why these problems exist
[05:58] <Kamion> I also don't understand why you think dpkg-reconfigure might help given that everything of any interest in postfix.postinst is guarded by != "No configuration"
[05:59] <lamont> postfix's config/postinst is being too smart for itself, I fear.
[06:00] <Kamion> I still don't understand; when I took that question out, it was partly because I looked through postfix.postinst and concluded that reconfiguring it was an absolute no-op
[06:00] <Kamion> questions in debootstrap rarely get the seen flag set, but they may get their value set
[06:00] <lamont> it may be...  But I think it shouldn't be a no-op. :-(
[06:00] <Kamion> the former is a bug currently assigned to me
[06:01] <Kamion> lamont: I can do another install and get you debconf-show before the reconfiguration, if you like
[06:02] <lamont> that would be great
[06:02] <lamont> and then I shall ponder. :-(
[06:02] <lamont> but in the meantime, I'm going to wander off to the shower for a bit
[06:31] <T-Bone> ouch
[06:33] <T-Bone> happy netsplit
[06:35] <Kamion> only two of you
[06:39] <npmccallum> fabbione: ping
[06:42] <T-Bone> lamont: would it be normal that i don't get any input in glibc's build log for 25 minutes?
[06:45] <daniels> is hoary open for uploads?
[06:46] <elmo_> t-bone: in the test suite, it's possible yes
[06:46] <elmo_> daniels: no
[06:46] <daniels> elmo_: 'kay
[06:46] <T-Bone> elmo_: ok, it's actually in the test suite
[06:46] <elmo_> hoary doesn't really exist in katie, if you try, you'll probably make her cry
[06:46] <fabbione> npmccallum: pong
[06:48] <daniels> elmo_: er, stress-testing crucial infrastructure?
[06:48] <elmo_> daniels: ?
[06:49] <npmccallum> fabbione: can you take a look at bug #1753?  I'm not that familiar with Xcursors
[06:49] <daniels> elmo_: by uploading stuff targetted at hoary
[06:49] <daniels> npmccallum: is it about a solid black X staying on screen?
[06:49] <npmccallum> daniels: no
[06:49] <daniels> oh
[06:50] <elmo_> daniels: no, it's just half-configured I mean
[06:50] <daniels> npmccallum: that's just a case of bad theming, though
[06:50] <fabbione> npmccallum: no idea what it can be, but i am sure it's not an X bug
[06:51] <daniels> npmccallum: there's nothing actually wrong, it's just that someone needs to draw a better cursor
[06:51] <daniels> fabbione: it's the cursor being inconsistent in the actual theme, not our bug
[06:51] <npmccallum> fabbione: I'm pretty sure that that X cursor theme comes packaged with X, no?
[06:51] <fabbione> npmccallum: no
[06:51] <daniels> npmccallum: ehm, I think in this case, no
[06:51] <daniels> the jimmac cursors are provided by gnome iirc
[06:52] <npmccallum> what format are the cursors in?
[06:52] <daniels> erm
[06:52] <daniels> probably xpm or some obscure crap
[06:52] <daniels> they're generated from png iirc
[06:53] <T-Bone> elmo_: Is the box being idle, and ps show "ld-linux-ia64.so.2 --library" for the same amount of time to be also considered as "normal"?
[06:53] <T-Bone> +ing
[07:09] <T-Bone> lamont: i'll need your glibc deb. My build is stuck for good
[07:13] <npmccallum> daniels: man xcursor
[07:13] <npmccallum> daniels: x cursors are their own format, no mention of how to convert them
[07:16] <daniels> npmccallum: xcursorgen
[07:17] <npmccallum> daniels: is it in the archive?
[07:17] <daniels> should be, yah
[07:17] <npmccallum> daniels: nevermind :)
[07:18] <npmccallum> daniels: its installed with X I believe
[07:18] <daniels> probably, yeah
[07:18] <daniels> just like half of the rest of the archive
[07:18] <daniels> any linux distribution is comprised of stuff installed from x, ooo's i18n, and miscellany
[07:19] <npmccallum> lol
[07:23] <npmccallum> daniels: what does cursor size mean? number of pixels?
[07:23] <daniels> yep
[07:24] <daniels> 32x32, 64x624, et al
[07:24] <mdz> lamont: that's the powerpc-random-segfault thing?
[07:24] <lamont> mdz: yeah
[07:24] <lamont> s/segfault/SIGILL/
[07:25] <lamont> mozilla made it through on try #3. :-(
[07:25] <mdz> lamont: that one seems like it is, er, still open
[07:25] <mdz> considering it makes our powerpc builds fail?
[07:25] <lamont> mdz: yeah.  it's still a bug.
[07:26] <lamont> although we have a workaround. :-)
[07:26] <pitti> Hi mdz!
[07:26] <mdz> lamont: the work around being...you? :-)
[07:26] <mdz> pitti: morning
[07:27] <lamont> mdz: nah - the autodepwaiter just retries anything that was 'terminated by signal 4'. :-(
[07:27] <lamont> although that didn't seem to be working with mozilla...
[07:28] <pitti> mdz: if you have a minute, can you please take a look at #1864?
[07:28] <mdz> lamont: I've never seen it on the G4
[07:28] <mdz> lamont: maybe it's a G5 thing...I think justdave has one
[07:31] <thom> mdz: can i upload firefox (#1790) ?
[07:31] <mdz> thom: isn't "move to dpatch" just a tiny bit intrusive to change the user-agent string? :-)
[07:32] <mdz> or is dpatch only used for that one patch?
[07:32] <daniels> heh
[07:35] <mdz> anyone here have an i386 system with >=2GB of RAM?
[07:35] <thom> mdz: no, it stops me having to juggle about 8 patches to the default firefox, plus our branding. it's a huge time saver, and much *less* intrusive than, say, moving it to DBS
[07:35] <thom> ;-)
[07:36] <thom> 1GB is the most i have
[07:37] <Kamion> would amd64 do? I have == 2GB there
[07:38] <Kamion> hm, no, I don't, only 1GB
[07:38] <daniels> thom: nah man, DBS is love
[07:38] <thom> *g*
[07:38] <daniels> thom: anything you're after a co-maintainer for? :)
[07:39] <mdz> thom: if you've rediffed it and checked that no regressions were introduced by the dpatch conversion, it's ok by me
[07:39] <thom> daniels: sure, but nothing i'm letting you choose the packaging system for
[07:39] <thom> mdz: yeah, i have
[07:39] <thom> several times
[07:39] <daniels> thom: heh
[07:40] <thom> actually, i'll leave it till tomorrow to upload, since i'm just about to install a new mobo
[07:43] <npmccallum> daniels: Is the cursor mentioned in that bug hardwired to X?  I can't seem to change it
[07:46] <mdz> npmccallum: you have an i386 box with >=2GB RAM, right?
[07:48] <daniels> npmccallum: not at all
[07:50] <npmccallum> mdz: no, >=1GB ram
[07:50] <npmccallum> daniels: do you know which image actually changes that cursor?  I assumed "cross", but nothing happens when I add it and restart...
[07:51] <daniels> npmccallum: ehm, not really sure off the top of my head, sorry
[07:51] <npmccallum> daniels: none of the themes actually change that cursor
[07:52] <daniels> it looks non-core to me
[07:52] <npmccallum> it certainly does...
[07:56] <sladen> npmccallum/daniels: is the plan to replace the default X cursor with a completely transparent one?
[07:56] <daniels> ... *completely*?
[07:56] <daniels> as in, invisibl
[07:57] <daniels> e
[07:59] <npmccallum> sladen: actually we are just going to remove mouse support from X :)
[07:59] <sladen> daniels: yeah, without reading the scrollback, I wondered if it might be a kludgy solution for cards where the hardware cursor isn't being used, but the default cursor is still loaded and left bang in the centre of the screen
[07:59] <npmccallum> sladen: see bug #1753
[07:59] <daniels> sladen: ow, dude, my head
[07:59] <daniels> core cursors don't have an alpha channel, anyway
[07:59] <daniels> (iirc)
[08:01] <sladen> daniels: presumbly their two-bit.  One black/white map;  and one transparent/opaque map ?
[08:01] <daniels> i can't remember
[08:01] <daniels> .
[08:04] <mdz> Mithrandir: can you try backing out to an older/simpler kernel or anything, regarding that futex bug?
[08:04] <mdz> Mithrandir: none of the userland programs involved have changed in several weeks
[08:05] <elmo_> we're still shipping wth 2.6.9 right?
[08:05] <elmo_> err 2.6.8
[08:06] <daniels> elmo_: 2.6.8.1
[08:06] <elmo_> right
[08:10] <elmo_> why does our apt-listchanges read changelogs if it's not going to bother displaying any of them?
[08:10] <elmo_> or does "Reading changelogs" actually mean "Reading changelogs and news" ?
[08:11] <mdz> elmo_: the latter
[08:12] <pitti> mdz: re 1864: yes, this libsg is just a subdirectory of cdrecord, it's not actually a shared lib. I will upload this thing, thanks for approving it
[08:13] <daniels> pitti: what are you doing to libscg?
[08:13] <pitti> daniels: #1864
[08:13] <pitti> daniels: I added a patch which opens the burning devices exclusively
[08:13] <daniels> hm
[08:13] <pitti> daniels: this avoids interference with hal
[08:13] <daniels> be very, very careful wrt licence
[08:14] <pitti> daniels: oh? it should be DFSG, not?
[08:14] <daniels> half of libscg is 'you may not breathe on this without adding "schily is god, all hail schily" prominently' all through it
[08:14] <daniels> pitt	ish
[08:14] <mdz> pitti: by the way, if you want to operate on a Debian bug in bugzilla, just tell me and I can import the bug itself with all comments
[08:14] <pitti> daniels: wasn't xfree 3.5 rejected because of this particular reason?
[08:15] <daniels> pitti: libscg requires you to change version on modification
[08:15] <pitti> mdz: ah, I forgot that again. Next time :-)
[08:15] <mdz> daniels: didn't you close that bug saying that our version was old enough that it didn't have the evil problems?
[08:15] <daniels> pitti: xfree86 4.4 was rejected because you were required to do advertising in documentation
[08:15] <pitti> daniels: okay, then I will add an ubuntu branding. mdz, is that okay for you? (trivial patch)
[08:15] <daniels> mdz: there's a difference between utter crap and non-dfsg-free
[08:15] <daniels> pitti: do you want to let me handle this in the morning?
[08:16] <daniels> mdz: since 2.0, libscg has required you to change versions if you change certain parts of it
[08:16] <mdz> daniels: what matters is whether or not it meets the Ubuntu guidelines; does it?
[08:16] <daniels> mdz: very recently, it was changed to actually violate the licence quite blatant
[08:16] <daniels> ly
[08:16] <daniels> we're unaffected by the latter
[08:16] <daniels> mdz: yes, but it's still obnoxiously crap
[08:16] <pitti> daniels: if you mean that you want to change the version string, for my sake yes
[08:16] <daniels> it meets the dfsg, dude
[08:17] <daniels> pitti: i'd just be a little more comfortable if I handled it
[08:17] <mdz> pitti: if you need to change the version string, that's fine
[08:17] <daniels> mdz: essentially, yes
[08:18] <pitti> daniels: okay, I send you my current interdiff, you mangle the version string and upload. Okay?
[08:18] <daniels> pitti: sure
[08:19] <pitti> daniels: I attach the interdiff with a comment to the bug and add you as CC
[08:20] <daniels> pitti: awesome, thanks
[08:25] <pitti> Guys, the current installation is AWESOME!
[08:26] <Kamion> kewl :-)
[08:37] <pitti> Kamion: the therm_adt746x module is still not loaded automatically on ppc; I have to reopen #1606 :-(
[08:37] <Kamion> pitti: which image?
[08:38] <pitti> Kamion: today's daily
[08:38] <Kamion> pitti: please include a tarball of /proc/device-tree
[08:38] <pitti> Kamion: anything particularly wrong with that?
[08:38] <Kamion> shouldn't be
[08:38] <pitti> Kamion: I'll do
[08:38] <Kamion> so it's not in /etc/modules?
[08:38] <pitti> Kamion: no, not in /etc/modules and not loaded
[08:39] <Kamion> note that it won't be loaded in the installer environment, hope you weren't expecting that
[08:39] <pitti> Kamion: no, installation is finished, gnome runs
[08:39] <Kamion> ok
[08:57] <daniels> hooray -- we've actually been violating the cdrecord licence for a whlie
[09:01] <mdz> Kamion: what's the status of sounder 9?
[09:04] <daniels> pitti: ok, you've got an updated #20 dpatch back; my builds are being really weird for some reason
[09:04] <daniels> 0505 is bedtime, however
[09:05] <elmo_> Setting up gnome-panel-data (2.8.0-0ubuntu5) ...
[09:05] <elmo_> We're a laptop
[09:05] <elmo_> laptop configuration
[09:05] <elmo_> is that considered a featuree?
[09:05] <mdz> apparently so
[09:06] <mdz> there's an explicit echo in postinst; presumably for debugging
[09:07] <elmo_> k
[09:09] <T-Bone> gack, perl is still failing :P
[09:10] <Kamion> mdz: if you don't want me to put the parted fix into it (I had been thinking about doing that to force wider testing), it can go out as soon as I test all three arches
[09:14] <mdz> Kamion: hmm, sounds risky for a milestone release at the last minute
[09:14] <mdz> Kamion: maybe push out sounder 9, and then drop new parted onto the daily CDs?
[09:15] <Kamion> well, I wonder how much point there is doing sounder 9 if we really want people to use the dailies
[09:15] <Kamion> I've got a Windows XP CD now and am installing using it to see if I can reproduce the problem myself
[09:16] <Kamion> (current amd64 works, BTW)
[09:18] <T-Bone> looks like there's a circular dep in gcc-3.3 ubuntu:
[09:19] <T-Bone> gcc-3.3: Depends: libgcc1 (>= 1:3.3.4-3) but 1:3.3.4-2 is to be installed
[09:19] <mdz> Kamion: we need to have a "last known good" thing to point people to for the download link on the websit
[09:19] <mdz> Kamion: so that they don't download a broken CD
[09:19] <Kamion> T-Bone: libgcc1 comes from gcc-3.4
[09:20] <T-Bone> according to the .dsc, the package gcc-3.3 provides libgcc1
[09:20] <Kamion> $ madison -s warty -S gcc-3.4
[09:20] <Kamion> ...
[09:20] <Kamion>    libgcc1 | 1:3.4.2-2ubuntu1 |         warty | amd64, i386, powerpc
[09:20] <T-Bone> Kamion: nope, see http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-3.3/gcc-3.3_3.3.4-9ubuntu5.dsc
[09:20] <Kamion> the .dsc is not always reliable for such things
[09:20] <T-Bone> hmm
[09:20] <T-Bone> so gcc-3.3 is borked ?
[09:20] <Kamion> not really
[09:20] <Kamion> the newest binary is taken
[09:20] <Kamion> build gcc-3.4
[09:21] <T-Bone> how am i supposed to install gcc-3.3 then?
[09:21] <Kamion> by building gcc-3.4?
[09:21] <T-Bone> btw, i got this while trying apt-get install build-essential
[09:21] <Kamion> this sort of thing happens during bootstrapping :)
[09:21] <T-Bone> yeah
[09:21] <T-Bone> gonna have to bastardize my chroot a bit more :P
[09:26] <T-Bone> shit i fucked up my chroot
[09:47] <T-Bone> Checking correctness of source dependencies...
[09:47] <T-Bone> After installing, the following source dependencies are still unsatisfied:
[09:47] <T-Bone> libgtk2.0-dev(inst 2.4.3-1 ! >= wanted 2.4.4-2)
[09:48] <T-Bone> Kamion: that's why i couldn't build it the first time alas
[09:57] <pitti> Since very recently ago, I repeatedly see messages like "tar: Read 2560 bytes from -"; does anybody else have this problem?
[10:06] <T-Bone> awesome
[10:06] <T-Bone> i can't build gcc-3.4. It build depends on gcc-3.3 ubuntu which i can't install for the above mentionned reason
[10:07] <T-Bone> i'm looking for some help there...
[10:11] <pitti> sjoerd: I'm just uploading a new cdrecord with O_EXCL. Thanks for the hint!
[10:11] <mdz> pitti: yes; seems fairly harmless
[10:12] <pitti> mdz: the tar message?
[10:12] <mdz> pitti: yes
[10:13] <mdz> I've seen them for some time, in Debian as well
[10:13] <sjoerd> pitti: nice
[10:13] <mdz> pitti: ask bdale
[10:13] <pitti> sjoerd: I will send the patch to the Debian BTS
[10:13] <mdz> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264050
[10:13] <sjoerd> pitti: :)
[10:13] <pitti> mdz: thanks
[10:19] <Kamion> ew! WinXP's installer has a bloody Clippy-a-like!
[10:31] <Keybuk> MS Bob ... the software that just won't die
[10:34] <Keybuk> http://toastytech.com/guis/bobwriter.gif
[10:38] <T-Bone> can somebody please educate me about how to override builddeps with sbuild? I have tried various combinations of -f and -b and can't find the solution :P
[10:39] <T-Bone> s/-b/-a/
[10:51] <mdz> Kamion: do you have a sounder 9 candidate for me to download and test?
[10:52] <mdz> T-Bone: sounsd like you need lamont
[10:52] <mdz> he should be around
[10:52] <T-Bone> mdz: yeah, unfortunately he's very busy atm
[10:53] <T-Bone> i'm stuck with that gcc-shit before being able to go over stage 2 (building warty against warty binaries)
[11:53] <seb128> jdub: just checking, but that's still ok for GNOME point releases (epi 1.4.1 and evo/eds/... 2.0.1) ?