[12:02] <jdub> holy cow
[12:29] <mdz> jdub: ping?
[12:29] <mdz> jdub: someone commented on -users that the -users mailman archive is broken, and it looks like they're right
[01:39] <jdub> mdz: carlos mentioned it too; checking it out.
[01:43] <Kamion> mdz: gah, we clashed on discover1-data :)
[01:44] <Kamion> I'll do another upload, I had seven more PCI IDs to add for forcedeth
[01:48] <elmo_> pcmcia-cs -> ship?  like huh?
[01:48] <Kamion> elmo_: like yeah
[01:48] <Kamion> elmo_: hw-detect installs it if you actually have PCMCIA
[01:49] <bob2> I don't think it's that smart
[01:49] <bob2> it installed it on my ibook which has no slots
[01:50] <sivang> who is responsible to the ubuntu-sounds pkg? lamont?
[01:50] <elmo_> as opposed to what
[01:50] <Kamion> bob2: bet you have /sys/class/pcmcia_socket/ though
[01:51] <bob2> Kamion: ah, I do indeed
[01:51] <sivang> such cool sounds. especially the gnome bootplash sound
[01:51] <bob2> Kamion: is that a kernel bug?
[01:51] <Kamion> bob2: go have a long talk with your kernel then ;)
[01:51] <Kamion> bob2: dunno, could be
[01:51] <Kamion> bob2: maybe there really are slots internally
[01:52] <Kamion> sivang: look at the Maintainer: field ...
[01:52] <sivang> Kamion : oh right..
[01:52] <bob2> heh, I could belive apple did weird shit like that
[01:53] <sivang> ah! hooray for Nathanial!
[01:53] <Kamion> elmo_: anyway, yeah, mdz and I argued this out and agreed this was best, since you so aren't going to upgrade a machine to have PCMCIA when it didn't before
[01:53] <bob2> are end-users encouraged to file bugs themselves or discuss it on a list first (ie Debian vs Subversion modes)?
[01:54] <sivang> Kamion : that install went more swiftly than the previous I Had. after I fixed /etc/fstab and excluded from fsck, everything runs fast and sound :-)
[01:57] <mdz> Kamion: re: discover1-data, I was going to do another upload to sync up with the kernel anyway, thanks
[01:59] <mdz> Kamion: regarding ntfs resize, how much of a hack is the partman enhancement?
[01:59] <mdz> Kamion: anything we should look at for Warty?
[02:00] <Kamion> mdz: hacktastic
[02:00] <Kamion> mdz: not proven to work yet AFAIK
[02:02] <elmo_> kamion: I don't understand still - where was it before?
[02:02] <elmo_> anyway, sorry doesn't matter I can stop being lazy and look myself
[02:03] <Kamion> elmo_: base
[02:03] <Kamion> elmo_: it used to be installed on every system, even desktops without PCMCIA
[02:03] <Kamion> moving it to ship means we can apply detection to it
[02:04] <Kamion> mdz: anton's hacks often need a certain amount of polishing before they're production-ready :-)
[02:04] <Kamion> joeyh normally does that ...
[02:04] <npmccallum> sivang: thanks :)
[02:05] <mdz> sounds like hoary material
[02:05] <sivang> npmccallum : you put out some nifty sounds package! Did you make the sounds with a synth or are they gnome's ?
[02:05] <Kamion> mdz: my inclination at the moment is to wait even though it's a nifty feature
[02:06] <npmccallum> sivang: mixture of a synth and actual recordings
[02:06] <Kamion> people can always use partition magic or whatever
[02:06] <sivang> npmccallum : hand made by you?
[02:06] <npmccallum> sivang: yes
[02:06] <sivang> npmccallum : superb :-)
[02:07] <npmccallum> sivang: thanks, though the phone sound and the card shuffling sound are from gnome.  You can't much improve on them
[02:08] <sivang> npmccallum : i really like to gnome bootsplash sound. so calming ;)
[02:08] <npmccallum> sivang: thanks
[02:08] <sivang> npmccallum : are you a musician at days when you're not hacking ubuntu ? 
[02:08] <npmccallum> sivang: though I have to say, just about anything would be an improvement on most of the sounds in gnome-audio
[02:09] <npmccallum> sivang: I'm a musician at night when I'm not hacking during the day :)
[02:09] <sivang> npmccallum : well, I havn't heared such a nice splash theme in some time now....:)
[02:10] <npmccallum> sivang: I haven't had so much praise in some time now ;)
[02:13] <sivang> no, I really like it. as opposed to every single sound theme I checked in the past year on gnome/kde
[02:14] <sivang> either they were too noisy,
[02:14] <sivang> or didn't make a difference.
[02:14] <sivang> KDE's default window close sound is something of a bug material I think :-)
[02:14] <Kamion> mdz: I'd be happy to deal with #1872, it's not particularly amd64-specific
[02:17] <mdz> Kamion: you have more than your share of RC bugs already, I think; I'd prefer that you hand amd64 stuff off to tollef so that you can work on other things, unless it's trivial and you're touching that package anyway
[02:17] <Kamion> mdz: fair enough, discover1-data was to hand that's all :)
[02:17] <Kamion> well, followed up to that bug asking for more info anyway
[02:20] <sivang> mdz : I'd like to take some RC bug reproduction and investigation work, if it's possible :) if you have anything you'd wanted someone to look at, please let me know.
[02:22] <lamont> Kamion: aye.  pri < high.
[02:22] <lamont> grumbl
[02:22] <lamont> e
[02:26] <jdub> can you exclude a file from diff.gz generation?
[02:27] <jdub> i have a file with bollocks changes that can't be easily cleaned, so i want to ignore it
[02:28] <Kamion> dpkg-buildpackage -i<regexp>
[02:28] <Kamion> look at the top of /usr/bin/dpkg-source for the default regexp, you'll need to copy it and append to it; you can put defaults for debuild in ~/.devscripts to avoid figuring out the regexp every time
[02:33] <lamont> Kamion: if debconf asked all the questions before, does it even run config on a reconfigure?
[02:33] <Kamion> lamont: config is always run
[02:33] <lamont> ok.
[02:33] <lamont> more pondering tonight.  sigh.
[02:34] <Kamion> debconf does not even consider whether it might have asked all the questions, since in general it can't know that
[02:34] <lamont> ok
[02:34] <Kamion> due to config being programmatically arbitrarily complex
[02:34] <lamont> (forget I asked that...)
[02:34] <Kamion> mdz: is #1683 really RC? there are probably quite a number of these issues for various languages that need to be looked at in some detail
[02:35] <Kamion> they've historically been a bit of a nightmare
[02:39] <lamont> Kamion: do you have a cookbook for rolling i386 install CD's?
[02:40] <jdub> Kamion: so i can't put smoething in debian/rules?
[02:42] <lamont> seb128 about?
[02:58] <Kamion> jdub: rm it in debian/rules clean?
[02:59] <jdub> i kinda thought that might affect the diff, but it seems the removal will be ignored
[02:59] <jdub> thanks
[02:59] <Kamion> lamont: drop in new .deb; edit dists/warty/main/binary-i386/Packages with new Version:, Filename:, MD5sum:, Size:; gzip -c dists/warty/main/binary-i386/Packages > dists/warty/main/binary-i386/Packages.gz; edit dists/warty/Release with new md5sums and sizes for Packages and Packages.gz
[03:00] <Kamion> lamont: then "mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386", substituting wherever your CD tree is for new-i386
[03:05] <sivang> Kamion : regarding #1566, i can still use my xphome, although when booting linux i get a CHS warning.
[03:06] <sivang> Kamion : I used some similar tool to resize my partitions at first, but this was on my first ubuntu install
[03:18] <Kamion> sivang: after fixing the CHS warning using the directions provided in the bug, if you could try the referenced CD image and verify that it does not make the CHS warning come back, that would be good
[03:20] <sivang> Kamion : i will, however it didn't damage my fat32 installation, but it'd be better to fix that I guess.
[04:29] <mdz> jdub: so who needs a nudge to fix the list archive?
[04:31] <jdub> me
[04:31] <jdub> nudged already
[04:31] <jdub> getting to it
[04:31] <tseng> hah jdub = the man.
[04:34] <mdz> sivang: everything of severity >= major is considered release-critical
[04:34] <mdz> sivang: we'd appreciate any help you are willing to provide with those
[04:35] <mdz> Kamion: we should include a Makefile on the CD which regenerates Packages and Release with apt-ftparchive
[04:42] <fabbione> morning guys
[04:42] <bob2> hey fabbione 
[04:42] <fabbione> hey bob2
[05:16] <fabbione> 1888 <- notwarty becuase WE know how to backport patches ;) :P
[05:20] <fabbione> mdz: what do you thing about 1905?
[05:20] <fabbione> it looks a safe patch to me
[05:21] <mdz> fabbione: yes, looks safe, feel free to upload it
[05:21] <fabbione> ok
[05:49] <fabbione> mdz: samba is up
[06:02] <fabbione> --- SIGFPE (Floating point exception) @ 0 (0) ---
[06:02] <fabbione> how bad is this message?
[06:02] <fabbione> it's the first time i see it
[06:20] <lamont> Kamion: where does boot.cat come from?
[06:25] <mdz> fabbione: could be as simple as division by zero
[06:25] <mdz> if it's randomly occurring, it could be bad
[06:26] <fabbione> mdz: hmmmm it seems to be reproducible (coming from one user of the new nv driver)
[06:26] <fabbione> but it's only report.. 
[06:26] <mdz> brb, reboot
[06:26] <fabbione> nobody else reported
[06:26] <fabbione> ok
[06:32] <lamont> mdz bouncing?
[06:34] <mdz> rebooting to check more kernel stuff for 1632
[06:46] <lamont> so why is it that OO says that it's going to print on LETTER, yet the printer asks for A4?
[06:54] <lamont> a: because the document really wants a4. :-(
[06:58] <fabbione> mdz:
[06:58] <fabbione>     nvclks = 3; /* lwm -> sync. */
[06:58] <fabbione>     nvclks += 2; /* fbi bus cycles (1 req + 1 busy) */
[06:59] <fabbione> the second line here is the one that create that segfault
[06:59] <mdz> err
[06:59] <mdz> fabbione: consistently?
[06:59] <fabbione> compiler error?
[06:59] <fabbione> yes
[06:59] <mdz> is nvclks a float?
[06:59] <fabbione> int
[07:00] <mdz> are those lines really adjacent, or is there other code between?
[07:00] <fabbione> exactly as you see them
[07:00] <mdz> why not nvclks = 5??
[07:00] <fabbione> no idea..
[07:00] <mdz> I guess you'll need to look at the disassembly
[07:02] <fabbione> eh...
[07:02] <fabbione> if it was on my machine...
[07:17] <mdz> fabbione: context?
[07:17] <mdz> is this not with an ubuntu package?
[07:19] <fabbione> mdz: 1883
[07:19] <fabbione> mdz: the info are missing because the submitter did post a 1.2MB file
[07:19] <fabbione> mdz: but it's in the Debian BTS
[07:20] <mdz> fabbione: if he is using the binary from debian, and you know exactly where it is crashing, you can disassemble the debian binary
[07:21] <fabbione> mdz: it says in the gdb.txt
[07:21] <fabbione> it crashes at line 417 of nv_hw.c
[07:21] <fabbione> that the code i did show you before
[07:22] <fabbione> but it doesn't happen here
[07:22] <fabbione> and i use the same driver
[07:22] <mdz> you're certain that his binaries correspond to your source code?
[07:23] <mdz> users are sneaky sometimes and will run a different X server :-)
[07:23] <fabbione> mdz: pretty sure...
[07:23] <fabbione> but i can check again
[07:23] <fabbione> how do you suggest to debug?
[07:23] <fabbione> s/debug/disassemble
[07:25] <mdz> use gdb
[07:25] <mdz> disassemble <function> or disassemble <line>
[07:25] <mdz> or <memory location>
[07:25] <fabbione> ah so i still need to ask him to do so
[07:26] <mdz> nah, you can do it on your binary
[07:26] <mdz> it is the same code
[07:29] <fabbione> do you know how to read i386 assembly? I know m68k upside down...
[07:31] <mdz> I can read some
[07:31] <mdz> enough to find problems usually
[07:31] <mdz> if you have the gdb output from the user, it should show the exact address of the crash
[07:31] <mdz> and so you can find the exact instruction
[07:32] <fabbione> Program received signal SIGFPE, Arithmetic exception.
[07:32] <fabbione> 0x080e2188 in nv10CalcArbitration (fifo=0xbffffa60, arb=0xbffffa40)
[07:32] <fabbione>     at nv_hw.c:471
[07:32] <fabbione> 471     nv_hw.c: Aucun fichier ou rpertoire de ce type.
[07:32] <fabbione>         in nv_hw.c
[07:34] <fabbione> what should be the address to look at?
[07:36] <fabbione> ok got it :-)
[07:36] <fabbione> 0x080e2188 <nv10CalcArbitration+614>:   idivl  (%ecx)
[07:41] <mdz> hmm
[07:41] <mdz> that is of course an integer divide instruction
[07:41] <mdz> which makes much more sense
[07:42] <mdz> but would seem to indicate that it is NOT line 471 of nv_hw.c
[07:42] <mdz> because that is an addition expression
[07:44] <mdz> fabbione: I'd disassemble nv10CalcArbitration (the whole function, hope it is small) and try to find what it corresponds to in the source
[07:44] <mdz> pitti: good morning
[07:44] <pitti> Morning!
[07:45] <pitti> mdz: I will go for some patch cherrypicking from hal CVS today; according to upstream, this "don't recognize at first plugin" bug is fixed in CVS HEAD
[07:45] <mdz> oh, nice
[07:46] <mdz> daniels: ping?
[07:46] <fabbione> mdz: it's what i am doing now
[07:46] <fabbione> mdz: and no.. it's not line 417
[07:47] <fabbione> and that makes me wonder how the hell gdb can believe that's line 417
[07:53] <fabbione>       us_n = nvclks*1000*1000 / nvclk_freq;/* nvclk latency in us */
[07:53] <fabbione> found it
[07:57] <daniels> mdz: pong, just eating lunch
[07:57] <daniels> mdz: 'sup?
[07:58] <daniels> fabbione: nvclk_freq == 0?
[08:01] <fabbione> daniels: yes. there is a bug in static void nv10UpdateArbitrationSettings (
[08:01] <daniels> fabbione: yay
[08:01] <daniels> anyoen here familiar with the hig?
[08:01] <fabbione> MClk can be unitializied and possibly = 0
[08:03] <fabbione> daniels: ideally static void nvGetClocks(NVPtr pNv, unsigned int *MClk, unsigned int *NVClk)
[08:03] <fabbione> is the one to check
[08:03] <fabbione> if somebody can understand the magic behind it :-)
[08:03] <fabbione> brb
[08:04] <daniels> fabbione: heh, not I, sorry
[08:20] <fabbione> re
[08:25] <fabbione> i think i have a simple fix for it
[08:25] <fabbione> that code is unreadable
[09:02] <daniels> jdub: permission to upload http://people.ubuntu.com/~daniels/g-s-m/gnome-system-monitor_2.7.0-0ubuntu2-to-ubuntu3.diff ?
[09:02] <daniels> jdub: (i can't make the configure changes any smaller -- cdbs insists on re-running autoconf every time you build, even source)
[09:03] <daniels> jdub: also, right now we can't get any useful errors back from sudo (only 'child exited with error status 1'), so I just hard-coded the error to 'Error (killing process|changing process priority): incorrect password?'
[09:03] <daniels> jdub: if you have any HIGgy suggestions, please bounce them back my way and I'll fix it up.  i'm new to this whole GNOME thing ;)
[09:08] <fabbione> mdz: 1889 imho is not major
[09:18] <pitti> mdz: hmm, cherrypicking CVS patches did not help, but the CVS HEAD version works perfectly
[09:20] <m_tthew> pitti: no fear, cherry pick the whole shebang ;)
[09:20] <pitti> mdz: what do you think about the following: I upload the current packages now, package the CVS head version and put that into my unofficial repository?
[09:20] <fabbione> hey m_tthew 
[09:20] <m_tthew> fabbione: I don't have full context, but nvglx does not tank X with MGA video
[09:20] <fabbione> m_tthew: did you manage to test that setup?
[09:20] <m_tthew> fabbione: I will try with the ATI card asap
[09:21] <fabbione> m_tthew: ok.. great!
[09:21] <m_tthew> fabbione: ATI is non-trivial because I have to cannabilize my desktop for the test setup
[09:21] <m_tthew> fabbione: MGA has no 3d, it is a very old card
[09:21] <fabbione> m_tthew: doesn't really matter
[09:21] <daniels> fabbione: if you want, I can test ATI tomororw
[09:21] <daniels> fabbione: I can start a dist-upgrade now, and then leave, and when I get back tomorrow, try video
[09:21] <fabbione> daniels: whatever.. if you can good otherwise tought luck
[09:21] <m_tthew> daniels: that would be helpful, I cannot take my desktop down until saturday.
[09:22] <m_tthew> fabbione: I will test ATI saturday if no one beats me to it.
[09:22] <fabbione> m_tthew: thanks
[09:22] <daniels> fabbione: do you have an updated ati_drv, or do we need the entire server package?
[09:22] <fabbione> daniels: the problem is not the ati driver
[09:23] <fabbione> it has been reported that X crashes when nvidia-glx is installed
[09:23] <daniels> oh
[09:23] <fabbione> even without using the nvidia driver
[09:23] <daniels> yeah
[09:23] <fabbione> so it's not really a question of newer ati driver
[09:23] <daniels> doesn't it divert away libglcore/libglx?
[09:23] <fabbione> but as a general mess
[09:23] <pitti> jdub: what do you think about uploading the utopia crack now?
[09:23] <daniels> if so, that will break anything that loads them and expects normal libglcore/libglx
[09:23] <fabbione> daniels: i think so yes
[09:24] <fabbione> daniels: you should check the package
[09:24] <fabbione> daniels: but the point is that i can run it ok, like many other people around
[09:24] <daniels> fabbione: how big is it?
[09:24] <fabbione> i don't believe all testers have nvidia
[09:24] <fabbione> what?
[09:24] <fabbione> the nvidia?
[09:25] <fabbione> Size: 2815272
[09:25] <fabbione> that's the -glx
[09:25] <daniels> hm
[09:25] <daniels> might download that while I'm in the shower
[09:25] <daniels> but yeah, if it diverts libglx (which I'm pretty sure it does), we're in deep trouble
[09:25] <daniels> since it's not going to be the ABI that the other drivers were built with
[09:26] <daniels> what we need is a wrapper around X that reads the config file and diverts on the fly to whichever one is appropriate ;)
[09:26] <daniels> brb
[09:26] <daniels> well, bbiab
[09:31] <pitti> Everybody get a grip! New uptopia stack coming now! :-)
[09:32] <m_tthew> tastes like hope
[09:37] <pitti> m_tthew: It's uploaded, now wait for it to build, then go ahead and beat me up :-)
[09:43] <mdz> pitti: yes, please do upload the current packages
[09:43] <mdz> ah, you did
[09:44] <pitti> mdz: yes, since you already agreed to upload the current hal package :-)
[09:44] <mdz> right
[09:44] <pitti> mdz: nevertheless, cvs head works even better, but the interdiff is some 8000 lines (due to some refactoring)
[09:45] <pitti> mdz: I currently run the cvs version, I will put that on my unofficial archive. We can upload it in one or two days if it behaves sanely
[09:48] <jdub> ahr
[09:49] <daniels> jdub: comments on g-s-m stuff?
[09:50] <jdub> haven't installed it yet
[09:50] <jdub> updating...
[09:50] <daniels> jdub: rad
[09:51] <jdub> YAY UTOPIA CRACK!
[09:51] <jdub> pitti: woo :)
[09:51] <jdub> hrm, not all of it yet
[09:51] <jdub> daniels: hrm, no g-s-m yet
[09:52] <pitti> jdub: what's still missing?
[09:52] <pitti> jdub: these are the packages that needed upgrading
[09:53] <daniels> jdub: haven't uploaded yet
[09:53] <daniels> jdub: http://people.no-name-yet.com/~daniels/g-s-m/
[09:53] <jdub> pitti: don't think they've built yet, i saw your uploads though
[09:53] <jdub> daniels: 
[09:53] <jdub> ah
[09:53] <daniels> jdub: that contains ubuntu3, which uses gksu in a pretty HIGgy way
[09:53] <pitti> jdub: ah okay, just a matter of time :-)
[09:54] <daniels> jdub: as per the comment in procdialogs.c, gksu doesn't deliver a useful error message back from sudo, so the error suggests that the password might be wrong
[09:55] <jdub> oh
[09:57] <daniels>                 if (type == 0)
[09:57] <daniels>                         errorMessage = _("Couldn't kill process: incorrect password?");
[09:57] <daniels>                 else
[09:57] <daniels>                         errorMessage = _("Couldn't change process priority: incorrect password?");
[10:02] <daniels> jdub: ok to upload?
[10:03] <jdub> hold on :)
[10:06] <daniels> jdub: rad :)
[10:06] <daniels> mdz: i have a trivial patch to xresprobe to make it respect $TMPDIR -- ok to upload?
[10:06] <jdub> checking for libgnome-2.0 >= 2.0.0 libgnomeui-2.0 >= 2.0.0 gconf-2.0 >= 1.1.5 libgtop-2.0 >= 2.5.2 libwnck-1.0 >= 2.5.0 gtk+-2.0 >= 2.3.0 libgksuui1.0 >= 0.15.0 libgksu1.2 >= ... Comparison operator but no version after package name 'libgksu1.2' in file '(command line arguments)'
[10:06] <jdub> ^ daniels 
[10:06] <jdub> bong
[10:07] <daniels> jdub: ugh, bong
[10:07] <daniels> hold on a sec
[10:08] <jdub> somehow there's an extra I there
[10:08] <daniels> yeah
[10:09] <daniels> new version on its way to the same place
[10:09] <daniels> mdz: http://people.ubuntu.com/~daniels/xresprobe/xresprobe-0.4.9-to-0.4.10.diff
[10:09] <daniels> jdub: new .diff.gz/.dsc up
[10:09] <daniels> (and changes, and interdiff, etc, etc)
[10:15] <jdub> daniels: looks good
[10:16] <daniels> jdub: rad
[10:19] <seb128> morning
[10:21] <daniels> time to head home for dinner
[10:28] <mdz> daniels: fine by me
[10:31] <Keybuk> wait!  vicky hasn't returned from lunch yet!  we can't leave the shop floor UNMANNED!
[10:39] <thom> morning
[10:40] <seb128> hello thom 
[10:40] <seb128> daniels: patches in debian/patches for GNOME packages please
[10:40] <thom> seb128: got anything more you'd like me to test with nautilus? :-)
[10:40] <seb128> the changes in the diff.gz are a pain
[10:40] <mdz> fabbione: what is your opinion on #1878?
[10:40] <seb128> thom: re a bug report ? 
[10:41] <mdz> seb128: the nautilus-cd-burner thing, I assume
[10:41] <seb128> I was thinking to that too, but not sure
[10:41] <seb128> thom: gnome-vfs guy is pretty surprised that gnomevfs-info gives the same result with FAST and SLOW for mime detection
[10:42] <seb128> are you sure you patched it right ? :)
[10:42] <seb128> they are thinking to a problem with one or the 2 detections, but since the 2 versions seems to return the right information with gnomevfs-info ...
[10:44] <fabbione> mdz: we knew that via can't be probed. Either we ban probing in xresprobe or we backport the driver, but the latter won't get enough testing before release
[10:45] <mdz> fabbione: daniels suggested not only skipping the probe, but forcing vesa. does that seem correct to you?
[10:49] <fabbione> mdz: hmmmm
[10:49] <thom> seb128: i'm pretty sure, unless the build does crackful things :-)
[10:50] <fabbione> mdz: i am not happy to force vesa
[10:50] <seb128> thom: ok
[10:50] <fabbione> mdz: i much rather prefer to ask teh resolution question
[10:50] <fabbione> mdz: we did try already to force vesa if gfx card probe fails and we have seen that it is not good
[10:51] <seb128> thom: I'll talk again with gnomevfs guys and probably ping you with a small test case after that :)
[10:52] <thom> seb128: sure it's not nautilus screwing up? :-)
[10:52] <thom> ok
[10:53] <seb128> thom: the mime are handled in the gnomevfs level, there is not real reason for nautilus to act in a different way, but I'll check
[10:54] <thom> fair enough
[11:02] <mdz> fabbione: so it is only the probe which fails, and the X server running normally should not crash?
[11:09] <fabbione> mdz: there are 2 bugs in the via drive
[11:10] <fabbione> 1) it does not store panel information in the bios that means that probing will never be succesful
[11:10] <fabbione> 2) if probed when X is running it would crash X
[11:10] <mdz> if skipping the probe means that their X server will still crash, then we should use vesa
[11:10] <mdz> if it will not crash, we can stay with via
[11:10] <fabbione> mdz: if we do NOT probe, there is no problem
[11:11] <fabbione> the 2 bugs above are in case of probe
[11:11] <mdz> fabbione: ok, then, let's just skip the probe but still use the driver
[11:11] <fabbione> mdz: that's what it should be already
[11:11] <fabbione> i explicitly remove the probe ban on the via chipset because daniels told me that xresprobe should take care of it
[11:12] <fabbione> and xresprobe shouldn't be probing via afaik
[11:12] <fabbione> so yes. we use the driver, we don't probe and we ask for resolution
[11:12] <fabbione> that's the best path
[11:12] <fabbione> and it is the same as like everything else (given a failed probe)
[11:13] <mdz> fabbione: xresprobe is definitely probing via, that's #1878
[11:13] <fabbione> the day that we will switch to X.org it will be enough to remove the ban
[11:14] <fabbione> bah
[11:14] <fabbione> daniels: that's not what we agreed
[11:14] <fabbione> well i will write in the bug
[11:17] <fabbione> done
[11:24] <fabbione> mdz: 1911
[11:26] <fabbione> mdz: afaik new subversion requires new libswig<something>
[11:26] <fabbione> mdz: should we take a look to a patch?
[11:27] <mdz> fabbione: I thought in unstable libswig was gone
[11:27] <mdz> breaking subversion
[11:27] <fabbione> there was joshk discussing it this morning on d-d
[11:29] <fabbione> debian has the same version as we have basically
[11:31] <fabbione> oh well he uploaded .8 but it's not built on i386 yet
[11:32] <mdz> jdub: what's the status of the list archive inquiry?
[11:35] <seb128> somebody know why hal 0.2.98 is missing in the archive ?
[11:35] <seb128> +on i386
[11:37] <thom> http://people.no-name-yet.com/~lamont/buildLogs/h/hal/0.2.98-1ubuntu3/hal_0.2.98-1ubuntu3_20040930-0909-i386-failed
[11:38] <thom> python-dbus not new enough
[11:41] <seb128> http://people.no-name-yet.com/~lamont/buildLogs/h/hal/0.2.98-1ubuntu3/hal_0.2.98-1ubuntu3_20040930-0935-i386-successful
[11:41] <seb128> too
[11:45] <thom> dunno then
[11:45] <thom> give elmo a poke on jabber
[11:49] <elmo_> it's new
[11:49] <seb128> why ?
[11:49] <elmo_> hal-device-manager is a NEW package
[11:49] <seb128> oh ok
[11:49] <elmo_> (NEW in katie terms, I'm not shouting at you ;)
[11:50] <seb128> yes, I was thinking to this NEW :)
[11:50] <seb128> but since the amd64/ppc binaries are in the archive
[11:50] <elmo_> i386 build arch: all, and h-d-m is arch: all ...
[11:50] <elmo_> I've processed it..
[11:50] <seb128> oh ok
[11:50] <seb128> thanks elmo_
[12:03] <Mithrandir> mdz: seems like the kernel hasn't been upgraded, or at least not upgraded to another binary-incompatible one.
[12:03] <Mithrandir> elmo_: is there any way I could acess the morgue?  I have a fun problem to track down (1854)
[12:06] <elmo_> Mithrandir: ask me/thom for what you need?  or do you need the whole thing particularly?
[12:06] <Mithrandir> elmo_: I'd like something like snapshot.d.n to see if I can track it down with a binary search..
[12:07] <Mithrandir> but given that we don't have that in place, I can try to pull selected debs by hand.
[12:07] <elmo_> well, you can't have that :P (unless you implement it) but you can have access to the morgue I guess
[12:07] <elmo_> the rhona dir is date based, but there's no Packages/Sources files like with ssnapshot
[12:08] <Mithrandir> ok, that's fine; it's a full tree or just the files removed on a certain day?
[12:20] <elmo_> sec
[12:26] <elmo_> the latter
[12:26] <jdub> mdz: meeting atm
[12:27] <Mithrandir> elmo_: ok, thanks a lot. :)
[12:32] <elmo_> Mithrandir: copying to rookery:/srv/archive.ubuntu.com/morgue - it'll take a while tho, the IO problems are particularly bad between rookery and jackass for reasons I've yet to track down
[12:32] <elmo_> it'll also, unhelpfully copy in the wrong order (oldest first)
[12:32] <Mithrandir> elmo_: ok, no hurry, I should write on my thesis today anyhow. :)
[01:01] <pitti> mdz: thanks for approving #1509 - nightshift today?
[01:01] <mdz> pitti: must...sleep...
[01:01] <fabbione> mdz: 1911 almost done... testing the results right now
[01:01] <pitti> mdz: mdz.sleep(8*3600)
[01:02] <mdz> hehe
[01:02] <mdz> so many bugs remain
[01:02] <fabbione> mdz: 45 approx.
[01:02] <mdz> I just found one that lamont forgot to close; that is always nice :-)
[01:02] <mdz> I count 42
[01:04] <Kamion> lamont: boot.cat's on the CD already
[01:04] <fabbione> mdz: 41 in a few secs :PO
[01:04] <elmo_> Mithrandir: done (somehow)
[01:04] <fabbione> s/secs/mins/
[01:07] <Keybuk> did anyone notice that LWN are now carrying Ubuntu Traffic
[01:07] <fabbione> ah cool
[01:07] <mdz> I noticed it was linked from distrowatch
[01:08] <mdz> the LWN issue with the first Ubuntu article just opened to the public today
[01:11] <mdz> I don't know what to do about #1724
[01:11] <mdz> (nvidia drivers breaking everything)
[01:12] <mdz> I don't think it's something that we can fix ourselves
[01:12] <fabbione> mdz: not without sources ;)
[01:12] <mdz> downgrading
[01:16] <fabbione> how long does it take to run that damn test suite
[01:17] <elmo_> mdz: btw, vanilla 2.6.8-rc2 is working just fine with >= 2GB on emperor, but not with debian style config
[01:17] <elmo_> err, s/debian/ubuntu/
[01:17] <mdz> elmo_: mind attaching a copy of the config to the bug?
[01:18] <mdz> just for giggles
[01:18] <mdz> maybe I'll try a build with that config and see if it makes a difference for me
[01:18] <elmo_> it's not even using initrd tho, I mean
[01:18] <elmo_> but can do, sure
[01:18] <mdz> initrd doesn't make a difference; it breaks in the non-initrd case too
[01:18] <elmo_> ok
[01:27] <fabbione> mdz: i count 39 bugs now
[01:28] <mdz> fabbione: I just had to import a new one from Debian :-/
[01:28] <mdz> (possible php4 security issue)
[01:28] <fabbione> yeah.. that one included
[01:28] <mdz> I have downgraded a few
[01:28] <mdz> the pcmcia-cs bug is not RC now, because we only install pcmcia-cs if the hardware is present
[01:28] <mdz> so downgraded
[01:28] <mdz> downgraded nvidia breakage
[01:29] <fabbione> subversion is done
[01:29] <fabbione> i am waiting katie but the bug is closed
[01:30] <fabbione> we have approx 14 days to close the others
[01:30] <fabbione> that's hard
[01:30] <Kamion> mdz: not getting a whole lot of feedback on this parted thing; just lots of people saying that the preview worked for them
[01:30] <thom> oh, that php4 one looks joyous
[01:30] <mdz> Kamion: yeah, I think the original issue was a bit inflated
[01:30] <Kamion> well, no, I agree it was a major issue
[01:31] <mdz> well, it was painted as "installing alongside XP fucks the partition table"
[01:31] <Kamion> I think everybody acknowledged it wasn't broken on all systems; it depends on your BIOS settings and indeed on the make of your BIOS
[01:31] <mdz> and it seems to be much more narrow than that
[01:31] <Kamion> it's a system-specific thing, but it's *very* bad on the systems where it's broken
[01:31] <mdz> maybe the submitter will help
[01:31] <mdz> if not, the best we can do is regression-test it
[01:31] <fabbione> later guys
[01:31] <mdz> fabbione: good night/afternoon
[01:31] <fabbione> mdz: yeah just one hour of sleep..
[01:32] <fabbione> otherwise i will die
[01:32] <thom> mdz: i'll take the php one
[01:32] <fabbione> and hopefully i can sleep one hour
[01:32] <fabbione> :(
[01:32] <mdz> thom: php security vulnerabilities are the BEST
[01:33] <elmo_> lol
[01:33] <thom> *g*
[01:34] <trukulo> fabbione, good night
[01:34] <trukulo> fabbione, night?
[01:34] <trukulo> it has to be midday there
[01:34] <trukulo> well, sleep well
[01:34] <thom> mdz: i think your definition of "best" is disimilar to the rest of the world's ;-)
[01:44] <Keybuk> I used to get excited about PHP security vulnerabilities too
[01:44] <Keybuk> but you know how it is when the radio just plays the same great song again and again, and suddenly it's no longer great and enough to make you change station?
[01:45] <mdz> thom: does your X40 power off correctly?
[01:49] <thom> with laptop-mode, or otherwise?
[01:49] <thom> (yes in both cases last i checked)
[02:10] <Mitario> aloha
[03:00] <Kamion> mdz: even if we don't take the partman ntfsresize support (which apparently works now ...), we should take the ntfstools-udeb and put it on the CD, so that we can point users at it if necessary
[03:01] <sjoerd> pitti: did you check if the patch i sent to the hal list yesterday fixes your problem
[03:01] <pitti> sjoerd: not yet, by now I uploaded 0.2.98 proper
[03:02] <pitti> sjoerd: but I tested today's cvs head, this seems to work; is your patch already included?
[03:03] <pitti> sjoerd: I already debugged the code to the point you patched away; the last_hotplug_seqnum was nonsense
[03:04] <sjoerd> pitti: with yesterdays cvs i could still reproduce it here
[03:04] <jdub> anyone having probs with the server?
[03:04] <sjoerd> pitti: and it isn't applied yet
[03:04] <pitti> jdub: sometimes I cannot connect to archive
[03:05] <jdub> hrm, working now
[03:05] <jdub> hmm
[03:06] <pitti> sjoerd: thanks so far. I will wait until David or sb else verifies this, and then upload a new hal version
[03:07] <sjoerd> pitti: still weird that cvs head fixes it for you though :)
[03:08] <pitti> sjoerd: I did not test this very extensively, it just worked at the first time after hal restart
[03:08] <pitti> sjoerd: OTOH, it also seems to work some times with the current hal (0.2.98)
[03:08] <pitti> sjoerd: so I guess this is sort of a race condition and it is not really fixed in CVS HEAD
[03:09] <seb128> jdub: do we want the new sound-juicer with some hal love in ?
[03:09] <pitti> seb128: what does s-j with hal? (being curious :-) )
[03:10] <sjoerd> pitti: yeah.. it's only triggered if your usb device triggers the first hotplug events and those events come in out of order
[03:10] <pitti> sjoerd: yesterday I thought it was just a matter of properly initializing this last_hotplug_seqnum
[03:11] <seb128> pitti: CD detection
[03:11] <pitti> sjoerd: but if removing the code completely helps, so much the better :-)
[03:11] <pitti> seb128: ah, thanks
[03:11] <sjoerd> pitti: see my explaination in that mail :)
[03:12] <sjoerd> seb128: your need cvs stuff to get sj+hal to compile btw
[03:12] <pitti> sjoerd: I saw, that's why I want to wait for comments :-) Thanks for your work, though!
[03:12] <seb128> sjoerd: ?
[03:12] <seb128> sjoerd: I've a package ready ...
[03:12] <sjoerd> seb128: 0.5.13 vanilla ?
[03:13] <seb128> oh no
[03:13] <seb128> with the fix post release for hal build
[03:13] <seb128> sorry :)
[03:13] <sjoerd> hehe ;)
[03:18] <seb128> since it needs hal 0.2.98
[03:18] <seb128> and debian doesn't have it
[03:19] <seb128> probably no :p
[03:19] <sjoerd> seb128: debian has it as soon as it comes out of NEW :)
[03:19] <seb128> oh, that's why
[03:19] <seb128> hal-device-manager NEW ?
[03:19] <sjoerd> yes
[03:20] <sjoerd> it's been there since sunday
[03:33] <thom> can people grab http://people.no-name-yet.com/~thom/popularity-contest_1.22ubuntu2_all.deb and run: "/usr/sbin/popularity-contest|/usr/sbin/popcon-upload" please
[03:46] <thom> i'm watching the logs you slackers, get to it
[03:57] <Kamion> thom: s'pose you want this on an Ubuntu machine
[03:58] <thom> Kamion: it'd be nice, please
[04:05] <Kamion> damnit, no working Ubuntu system at the moment; /me fires off an install
[04:06] <thom> heh
[04:07] <Kamion> welcome to the life of an installer guy; it's just not worth getting too attached to the installs ...
[04:35] <daniels> seb128: sorry
[04:36] <daniels> seb128: want me to re-upload?
[04:36] <seb128> no problem
[04:36] <seb128> no, that's fine
[04:36] <elmo_> what webserver log analyzing tools (analog, webalizer, etc.) have people used/do you recommend?
[04:36] <seb128> daniels:  the changes are pretty easy to get out of the diff for the next upload :) But when you have a bunch of patches mixed here that's a pain
[04:36] <daniels> fabbione: the two choices are either blanket via->vesa mapping in xserver-xfree86, or via->vesa in discover1-data
[04:37] <daniels> seb128: yeah, sorry. i thought I looked for debian/patches, but obviously I'm on crack :)
[04:39] <thom> daniels/seb128/elmo: please test popcon :-)
[04:40] <Keybuk> so, why don't we ship anacron in Ubuntu?
[04:40] <elmo_> your not watching MY computer, Big Bro^WThom
[04:40] <azeem> Big Thom?
[04:42] <thom> just test it and stop whining, ya bitch :-)
[04:43] <elmo_> done
[04:43] <thom> thankee
[04:44] <thom> seems to work, too
[04:45] <Kamion> thom: you'll get a weird broken upload from this machine, hope you don't mind, it's a via so installation breaks with the xresprobe bug
[04:45] <Kamion> thom: did that work?
[04:45] <daniels> thom: i'm not near an ubuntu machine atm
[04:46] <daniels> Kamion: can you start X at all -- is it X breaking, or the extra probe breaking (a la i8550?
[04:46] <daniels> s/8550/855)/
[04:46] <Kamion> daniels: so just type 'X', you mean?
[04:48] <thom> Kamion: yep, ta
[04:48] <daniels> Kamion: startx, yah (assuming you have a halfway valid XF86Config-4 which lists the via driver)
[04:48] <Kamion> sec
[04:50] <daniels> arse, something tells me `signfile' won't be installed on suse
[04:50] <Kamion> daniels: it's kind of hard to tell because it breaks while it's trying to write XF86Config-4 :P
[04:50] <daniels> Kamion: heh :) you can just copy one out from OH MY GOD
[04:50] <daniels> (any working system)
[04:50] <Kamion> I have working systems?
[04:50] <thom> auckland (archive|cdimage) is doing a GB/min currently. that's awesome
[04:50] <Kamion> I'll just nobble the xresprobe call
[04:50] <daniels> this is a jackie chan movie that I think I would made if I smoked a beer bong and then drank all the water.
[04:50] <daniels> it is the most incredibly bizzare thing I've ever seen in my life, and I've used yast
[04:51] <daniels> thom: !
[04:51] <daniels> thom: doesn't that mean we're maxing out our ... what the hell? ... link?
[04:52] <Kamion> daniels: startx breaks
[04:52] <daniels> Kamion: huzzah.
[04:52] <Kamion> oh, oh, no, startx comes back to a prompt
[04:52] <daniels> Kamion: mind if I quote you on BTS?
[04:52] <daniels> (oh my god, Jackie Chan in a schoolgirl outfit as Chun-Li)
[04:52] <Kamion> it's really hard to tell, not sure I'm reproducing everything properly
[04:53] <Kamion> [drm]  failed to load kernel module "via"
[04:53] <Kamion> relevant?
[04:53] <daniels> non-fatal
[04:53] <daniels> if the driver's that flakey, it deserves to be locked in a room with Lazarus Long
[04:53] <Kamion> you can have the log file if you like
[04:53] <daniels> nah, it's OK thanks
[04:54] <Kamion> but the symptoms of 'startx' are similar until it comes back to a prompt - screen goes blacker, fan pitch rises
[04:54] <Kamion> yeah, feel free to quote me wherever
[04:54] <daniels> Kamion: thanks
[04:54] <Kamion> daniels: do you need the xresprobe debugging stuff mdz suggested?
[04:54] <Kamion> I'll happily give that a go
[04:55] <daniels> Kamion: not really; if the driver is total arse under X, then it needs to be blacklisted totally
[04:55] <Kamion> ok
[04:55] <Kamion> suppose I should try the other Via machine here ...
[04:56] <daniels> is that laptop or desktop?
[04:56] <Kamion> laptop
[04:57] <daniels> it's probably broken also
[04:59] <Kamion> I'll chuck the CD in there anyway on the off-chance
[05:00] <Kamion> will take a while, crydee's not the beefiest of boxes
[05:00] <Kamion> T-Bone: if gdm comes up at all this probably isn't the same problem
[05:02] <T-Bone> Kamion: on second read yah. If i try to login, it'll segault in session-manager, bringing me back to GDM, and if i try to click on "Session", whatever choice I make (including no choice, just starring at the choice panel) restarts X
[05:04] <pitti> Gosh, can anybody tell me why gstreamer crashes on reading a file, but does not do so any more if you compile it with debugging symbols? 
[05:04] <pitti> Hi npmccallum
[05:05] <daniels> pitti: welcome to a heisenbug :) probably gcc optimising out the file opening code or something to save space
[05:05] <pitti> daniels: so gcc optimized in a segfault? Nice.
[05:06] <daniels> Kamion: it's not urgent; as I said, if the driver really is that broken, we shouldn't be using it in X at all, although more data points are always nice (if not essential) :)
[05:06] <daniels> pitti: file = open("foo", rw); file->stuff();
[05:06] <daniels> pitti: to file->stuff()
[05:06] <daniels> pitti: you don't need to waste time on this whole opening the file thing
[05:06] <T-Bone> lol
[05:07] <pitti> daniels: thanks. It was only meant as a rhetorical question anyway :-/
[05:08] <T-Bone> Kamion: what should be my starting point in building an installer for ia64 (assuming I have an archive ready)?
[05:08] <pitti> daniels: it could be worth a try to compile with symbols, but optimize
[05:08] <daniels> pitti: -g3 -O2
[05:08] <T-Bone> pitti: alternatively you can try to compile with symbols, then strip them out ;)
[05:08] <Kamion> T-Bone: get all the udebs built, backport linux-kernel-di-ia64-2.6 from Debian, try to build debian-installer
[05:09] <pitti> T-Bone: I don't think that the symbols spoil the show, I think it's the optimization
[05:09] <T-Bone> pitti: that way you'll be sure of it
[05:09] <Kamion> T-Bone: I can probably upload a version of debian-installer with a bit of ia64 support, otherwise try to merge the general spirit of i386/amd64/powerpc in Ubuntu debian-installer with the specifics of ia64 in Debian debian-installer
[05:10] <T-Bone> Kamion: ok. I have a couple of builder issues to solve in the meantime tho, but I'll follow these lines
[05:11] <npmccallum> pitti: hi :)
[05:13] <Kamion> T-Bone: just mailed mdz/jdub asking for approval to upload non-risky d-i ia64 changes
[05:14] <T-Bone> Kamion: thx
[05:14] <T-Bone> Kamion: i'm stuck with some gcc-3.4 building troubles that i'm currently tweaking to get done, as soon as I can have a working gcc-3.4 i'll be able to bootstrap stage2, aka "warty built on warty".
[05:15] <T-Bone> the fact is that gcc-3.4 is so damn SLOW to build
[05:15] <T-Bone> :P
[05:16] <Mithrandir> you can turn off the tests when debugging
[05:17] <T-Bone> Mithrandir: ?
[05:18] <Keybuk> thom: that kacpid bug does look exactly like what's affecting my laptop
[05:19] <daniels> 'A new hard disk was detected\nOpen with: kfmclient openURL file:/media/storage/usb-storage-odd-0x0c76-0x0005:0:0:0p1 ?\n[Yes]  [No] '
[05:20] <Mithrandir> T-Bone: it runs a huge number of compiler tests
[05:20] <T-Bone> Mithrandir: right, i'm currently parsing the rules* files to find where to disable them
[05:21] <azeem> you should be able to do so with DEB_BUILD_OPTIONS=nocheck, but that's not implemented yet
[05:21] <Mithrandir> azeem: notest, iirc
[05:21] <azeem> Mithrandir: last time I checked, gcc doesn't support it
[05:21] <azeem> maybe I didn't look well enough
[05:21] <T-Bone> $ grep DEB_BUILD_OPTIONS *
[05:21] <T-Bone> [varenet@envy ~/build/gcc-3.4-3.4.2/debian] $ 
[05:22] <azeem> Mithrandir: the glibc package, cdbs, and automake upstream use 'nocheck' already, so I think that's better than 'notest'
[05:22] <azeem> eh, automake uses 'check'
[05:22] <daniels> tv is weird tonight. some documentary about the falklands islands entitled 'fuckland' that featured the words to god save the queen at some point.
[05:23] <Mithrandir> set with_check in debian/rules.defs
[05:24] <T-Bone> Mithrandir: I owe you a beer for that one! ;)
[05:24] <azeem> Mithrandir: ah, thx
[05:24] <Mithrandir> T-Bone: where can I collect it? ;)
[05:25] <T-Bone> Mithrandir: I'll find a way ;)
[05:25] <T-Bone> Mithrandir: btw, is it normal that when running dpkg-buildpackage, the package rewrites its own control file?
[05:25] <Mithrandir> not too common, no, but glibc and gcc does it at least.
[05:25] <Mithrandir> they're kinda special
[05:25] <Mithrandir> look in debian/control.in/ probably
[05:26] <Mithrandir> for fragments
[05:26] <T-Bone> this is pissing me off, cause I have an unmet dependency i'm trying to work around
[05:26] <azeem> all those packages using type-handling also do this, AFAIK
[05:26] <Kamion> it's not unknown, linux-kernel-di-* do that too
[05:26] <T-Bone> i've changed it in the control file, but i guess that it'll be problematic if gcc erase it, when the package will actually be built?
[05:27] <azeem> I used to do that in one of my library packages to automatically write the correct library package name from the soname in configure.in
[05:27] <T-Bone> is there a way for me to "properly" change a build dependency?
[05:27] <Keybuk> T-Bone: edit debian/control or debian/control.in ?
[05:27] <T-Bone> Keybuk: as i said, debian/control gets overwritten. There's a control.m4 tho.
[05:28] <Mithrandir> T-Bone: debian/control.m4 for gcc
[05:28] <T-Bone> Mithrandir: thx! ;)
[05:28] <Mithrandir> mathias  sick, it seems.
[05:28] <Mithrandir> using m4.
[05:53] <Kamion> daniels: confirmed that the Via C3 laptop locks up too
[05:54] <daniels> Kamion: huzzah :\
[05:54] <daniels> vesa it is!
[06:08] <daniels> mdz: looking at #1897, would this logic be sane -- write out stanza saying '## this file written by dhcp3-client'; then only molest the file if either it doesn't exist, or has that stanza in it?
[06:09] <daniels> mdz: (or the standard '## OMGDEBCONF' markers or whatever)
[06:25] <lamont> Kamion: Figured out about boot.cat after asking - took me a minute to realize we were rolling a CD from a CD, rather than virgin plastic
[06:25] <lamont> thanks
[06:26] <Kamion> lamont: oh right, yes
[06:35] <lamont> daniels: gnome-system-tools hates you.
[06:36] <lamont> pitti: ditto fro nautilus-cd-burner
[06:36] <daniels> lamont: ?
[06:36] <daniels> lamont: gnome-system-monitor? seb uploaded g-s-t
[06:36] <lamont> daniels: path config barfage
[06:36] <lamont> 1295     Sep 30 Daniel Stone    (  44) Accepted gnome-system-monitor 2.7.0-0ubun
[06:36] <pitti> lamont: what's wrong with ncb? I'm just following #ubuntu-meeting, I did not listen
[06:37] <lamont> same issue.
[06:37] <lamont> may just be bad build-deps - I'll toss them back into the fray
[06:37] <lamont> we'll see how they don on retry
[06:38] <daniels> lamont: argh! thankyou.
[06:38] <daniels> lamont: g-s-m is missing b-d on libgksu1.2-dev/libgksuui1.0-dev
[06:38] <daniels> did them in one tree, forgot to copy them over to the other
[06:38] <daniels> lamont: i'll upload to fix and also move the patch to debian/patches in a bit; thanks for the heads-up
[06:38] <seb128> :)
[06:38] <lamont> daniels: np
[06:38] <seb128> what's the problem with n-c-b ?
[06:39] <seb128> I'm going to do an upload, I've a patch to fix a reported bug
[06:39] <pitti> lamont: oh, it did not build?
[06:39] <lamont> pitti: no.
[06:40] <lamont> seb128: checking for glib-2.0 >= 2.4.0 libgnome-2.0 >= 2.0.0 gtk+-2.0 >= 2.4.0 gnome-vfs-2.0 >= 2.1.3.1 libglade-2.0 >= 2.0.0 libgnomeui-2.0 >= 2.0.0 hal >= 0.2.98... Requested 'hal >= 0.2.98' but version of hal is 0.2.92
[06:40] <seb128> ok
[06:40] <seb128> will upgrade the build-dep
[06:40] <seb128> thanks
[06:41] <pitti> lamont: I uploaded hal at the same time; a simple rebuild should work
[06:41] <lamont> pitti: yeah
[06:41] <lamont> I tossed them back in the pond, see what we catch this time.. :-)
[06:41] <pitti> seb128,lamont: seb, if you upload a new ncb anyway, the next build should just work
[06:41] <seb128> no a reason to have bad depends
[06:41] <lamont> daniels: but yours failed. :-)
[06:41] <lamont> seb128: true
[06:41] <daniels> heh :)
[06:42] <daniels> lamont: mine will always fail, unless you pre-seed it with the two libraries
[06:42] <lamont> daniels: yeah.  But you said that _after_ I did the 6 give-backs.. :-)
[06:43] <daniels> lamont: heh
[07:05] <lamont> enlightenment uploaded, btw
[07:25] <amu> successfully upgraded a ppc from unstable to warty, gnome 2.8 looks nice 
[08:14] <sabdfl> mjg59: what's the status of swsuspend in k2.6 these days?
[08:22] <Keybuk> sabdfl: to disk generally works, to memory works on a select few laptops, standby generally works aiui.
[08:23] <lamont> Kamion: still about?
[08:24] <Kamion> lamont: sure
[08:25] <lamont> is there a way to ask debconf if it would ask a question, or just looking at the return from input?
[08:25] <Mithrandir> look at the seen flag?
[08:26] <lamont> I'm thinking of noticing that things are bad in the first config run, and deferring questions that weren't asked until run 2 (where they still won't be asked, but the default value will then be correct...)
[08:26] <lamont> Kamion: and could I get your debootstrap/whatever change (seen flag)?
[08:26] <Kamion> lamont: bug #1781
[08:27] <Kamion> what I still want to know is *why* are things bad in the first run?
[08:27] <lamont> Kamion: because the defaults are based on system state, not hard coded.
[08:27] <Kamion> mdz: mind if I upload the debootstrap half of #1781? it's harmless on its own and will make testing easier
[08:27] <lamont> and said state isn't there...
[08:27] <Kamion> lamont: system state *should* be sane at that point though
[08:28] <lamont> uid 1000 isn't created by the first run, so we decide to use 'NONE' for the default.
[08:28] <Kamion> aha!
[08:28] <Kamion> right, that explains a lot
[08:28] <lamont> so I need to decide to do that one over.. :-)
[08:28] <lamont> and then I'll calculate a good default, and we still won't actually ask the user, and life is good.
[08:28] <Kamion> mdz: approval to restore mta configuration step to base-config based on what lamont just said?
[08:29] <Kamion> (won't introduce a new question, just a dpkg-reconfigure)
[08:31] <lamont> Kamion: alternatively, the same code that adds uid 1000 to sudoers could add the root alias and run newaliases...
[08:31] <Kamion> that's possible too, although would prefer not to duplicate code if possible
[08:32] <lamont> actually, my code is based on _not_ finding a root alias in the map, and picking a default, whereas the baseconfig code would be just 'add this user'
[08:32] <Kamion> I guess it would be less complex
[08:33] <Kamion> don't care really, recommend something and assign a bug to me :)
[08:33] <lamont> ok.
[08:33] <Kamion> npmccallum: what do the diffs look like for those packages?
[08:33] <lamont> Kamion: you getting close to bedtime, or want somethign soon?
[08:34] <Kamion> lamont: it's 19:30 here
[08:34] <npmccallum> Kamion: same stuff as was happening with ssh, et al
[08:34] <Kamion> I might be getting close to pubtime :)
[08:34] <Kamion> npmccallum: which languages though?
[08:34] <Kamion> never mind, I guess I can check
[08:34] <lamont> doh
[08:34] <npmccallum> Kamion: I'll look, I have diffs
[08:35] <lamont> Kamion: I'll get you what I think should work sometime today, and try to get a patch together tomorrow morning.
[08:36] <lamont> but I need to go help my wife with some precon crap today before we head down there tonight.
[08:36] <npmccallum> Kamion: fr, he, nn, tr, id at first glance
[08:37] <sivang> lamont : any help needed with 'he' ?
[08:38] <Mithrandir> npmccallum: I can look at nn
[08:38] <Mithrandir> it's my least-favorite kind of norwegian, but I do it ok-ish.
[08:38] <lamont> sivang: he?
[08:38] <sivang> ah sorry, that was directed to someone else.
[08:39] <sivang> npmccallum : he = hebrew? ;)
[08:39] <npmccallum> Mithrandir, sivang: the bug is here -- https://bugzilla.ubuntu.com/show_bug.cgi?id=1329
[08:39] <Kamion> npmccallum: will look, might just be package-specific
[08:42] <Mithrandir> npmccallum: which are the exact packages that break?
[08:44] <npmccallum> Mithrandir: its all listed in the bug
[08:45] <Kamion> npmccallum: the only reason exim4 breaks is because the last upload was an Ubuntu upload built with the old po-debconf
[08:46] <npmccallum> Kamion: howto fix then?
[08:47] <Kamion> don't
[08:48] <Kamion> the exim4 change restores things to the correct state of affairs
[08:49] <Kamion> let's look at mgetty, that seems different
[08:49] <Kamion> I can't reproduce any problem with mgetty ...
[08:51] <npmccallum> hrm... all I changed was the initscript and the changelog
[08:52] <Kamion> could you attach the debdiff to the bug?
[08:53] <npmccallum> sure thing
[08:54] <Kamion> ta
[08:54] <npmccallum> Kamion: there you go
[08:58] <Kamion> npmccallum: those changes aren't a problem, closing, you can upload the source package like that safely
[08:58] <Kamion> it's normal for po-debconf to fiddle with .po files, sometimes when timestamps change and things; the Debian maintainer will probably pick up the same change eventually
[09:00] <npmccallum> Kamion: ok, great
[09:00] <npmccallum> Kamion: I'm not great with translation stuff, thanks for helping!
[09:01] <Kamion> npmccallum: the thing to watch out for is when msgstrs change encoding and stuff, then it's worth paying some attention to make sure it's sane
[09:01] <Kamion> no worries, po-debconf is ... eccentric sometimes
[09:01] <seb128> lamont: any news about 1123 ? I've a friend who have the problem right now
[09:03] <lamont> seb128: that'll get fixed with what I'm giving kamion..
[09:04] <seb128> ok
[09:04] <lamont> meanwhile, as root: newaliases
[09:04] <seb128> any workaround for people having the problem right now ?
[09:04] <seb128> ok, thanls
[09:04] <seb128> thanks
[09:05] <lamont> Kamion: does sounder 9 have the 2nd postfix config?
[09:05] <Kamion> 2nd?
[09:05] <Kamion> oh
[09:05] <Kamion> no
[09:05] <lamont> ok
[09:07] <Kamion> npmccallum: with regard to po-debconf:
 debconf-updatepo... also known as "I'm feeling unproductive today.
[09:07] <Kamion>         Please give me a huge diff to check in"
[09:07] <Kamion> :-)
[09:08] <npmccallum> lol
[09:08] <lamont> heh
[09:11] <mdz> morning
[09:12] <lamont> morning mdz
[09:13] <seb128> hello mdz
[09:25] <lamont> wifely one is now ready.  I'm gone.
[09:41] <Kamion> mdz: hm, does your changing the state of #1606 to PENDINGUPLOAD mean you've uploaded it?
[09:53] <sivang> lamont : what convention?
[09:53] <Kamion> mdz: approval for last diff sent to #1781?
[09:53] <Kamion> pub time
[09:53] <mdz> Kamion: yes
[09:54] <Kamion> good, will upload later tonight
[10:06] <thom> mdz: have you laughed at^W^Wapproved my python script for popcon yet? :-)
[10:11] <pitti> Hi again!
[10:11] <mjg59> sabdfl: It's got the best chance of working of any suspend mechanism, at the moment
[10:11] <mjg59> The 2.6 implementation is pretty solid on the hardware it works on. It's fairly slow, though.
[10:16] <sivang> mjg59v : what steps are needed to enable it onto a already installed ubuntu laptop system?
[10:17] <sivang> mjg59 : just install the package?
[10:19] <mjg59> sivang: Heh. I'd have a better idea if I had an ubuntu laptop system :)
[10:19] <mjg59> In principle, echo -n 4 >/proc/acpi/sleep
[10:19] <thom> kernel patch too, no? (i've no idea what we have and don't have past standard 2.6.8.1 + latest stable acpi)
[10:20] <npmccallum> thom: I don't think swsusp is in the kernel
[10:21] <mjg59> swsusp is part of the standard kernel.org kernel - I don't know if we build it, though
[10:21] <mjg59> There's probably no harm in doing so...
[10:21] <thom> grep -r SUSP /boot/config-2.6.8.1-3-amd64-k8
[10:21] <thom> # CONFIG_SOFTWARE_SUSPEND is not set
[10:22] <sivang> mjg59 : the support is completely kernlish? no user mode utils?
[10:22] <npmccallum> thom: should we file a bug to get it turned on?
[10:23] <thom> npmccallum: i'd prefer not for warty at this point
[10:23] <thom> we can't support it, really
[10:55] <npmccallum> thom: we can file a bug now with target milestone for hoary (thats what I was referring to)
[10:55] <thom> oh, sure
[10:55] <thom> i think there is one alreayd
[10:55] <npmccallum> ok, cool
[10:56] <npmccallum> the bug could be more general too, "Suspend doesn't work" :)
[11:13] <mdz> thom: yes, I did
[11:33] <sladen> *** the proxy in front of www.ubuntulinux.org appears to be dead ***
[11:35] <sladen> elmo: thom: mdz:
[11:35] <Mithrandir> sladen: we're aware of it and working on it.