[12:48] <mdz> thom: the feedback on the 0.9.3 downgrade has been 100% positive, let's get it into warty straight away
[12:49] <seb128> mdz: hey
[12:49] <seb128> mdz: what about the new gst/totem packages and eagle-usb ?
[12:51] <jdub> mdz: oof :)
[12:51] <mdz> jdub: oof indeed
[12:51] <seb128> jdub: hey :)
[12:51] <thom> mdz: sat in the upload queue, although i think katie is sulking
[12:51] <seb128> jdub: same question :p
[12:51] <mdz> seb128: I thought I had upgraded to your new gst/totem, but I seem to have the same version as in warty
[12:52] <mdz> seb128: could you give me the sources.list entry again please?
[12:52] <mdz> thom: hmm. anyone roused elmo?
[12:52] <thom> mdz: the last security fix was a one liner to a javascript file, which was a nice surprise
[12:52] <mdz> thom: how very un-mozilla of them
[12:52] <thom> mdz: just pinged him on jabber, will text in a second
[12:52] <seb128> mdz: deb http://people.ubuntulinux.org/~seb128/gstreamer/  /
[12:53] <thom> mdz: indeed - the bug talks of suggestions of monster changes, and then someone goes "why not change remove from true to false" and that's what they did 
[12:53] <mdz> seb128: it is hard to say whether it is any better than the previous version; it still doesn't seem to play any video streams for me :-/
[12:53] <mdz> seb128: is there any video encoding that it is known to play properly?
[12:54] <seb128> theora ?
[12:54] <mdz> mizar:[/space/video/misc]  totem http://mirror.fluendo.com:8800/
[12:54] <mdz> zsh: segmentation fault  totem http://mirror.fluendo.com:8800/
[12:55] <mdz> (after saying it could not play for unknown reasons)
[12:56] <mdz> I had a theora stream which I tested with the previous version
[12:56] <mdz> the A/V sync was way off and the video choppy
[12:56] <mdz> ah, it was the RMS thing, I'll retry that
[12:57] <seb128> "totem http://mirror.fluendo.com:8800/" works here ...
[12:57] <mdz> hmmm
[12:57] <mdz> ii  totem-gstreamer     0.99.17-0ubuntu1    A simple media player for the Gnome desktop based on g
[12:57] <mdz> \
[12:57] <mdz> ii  libgstreamer0.8-0   0.8.7-1             Core GStreamer libraries, plugins, and utilities
[12:58] <Mithrandir> mdz: I've read through the binary diff and it seems the only things changed are timestamps and compiled-in paths (from the build directory)
[12:58] <seb128> mdz: yeah, current versions ...
[12:58] <Mithrandir> mdz: so if I could get permission to upload, I'd be very glad.
[12:58] <mdz> hmm, it is playing now
[12:58] <mdz> second try
[12:58] <seb128> weird
[12:58] <mdz> Mithrandir: OK
[12:58] <elmo_> I _really_ think #1854 needs bumped to RC
[12:58] <mdz> seb128: does gstreamer default to esd output on new installs?
[12:59] <elmo_> it's what's killing katie on jackass
[12:59] <mdz> seb128: mine seemed to be set for OSS, but I may have opened gstreamer-properties at some point
[12:59] <seb128> mdz: I've not changed the patches
[12:59] <elmo_> "don't use SMP kernels" isn't really a very good answer
[12:59] <Mithrandir> elmo_: what kind of box is jackass?
[01:00] <elmo_> Mithrandir: how do you mean ?
[01:00] <mdz> seb128: it still segfaults when I exit totem
[01:00] <Mithrandir> elmo_: cpu type?
[01:00] <Mithrandir> (and number)
[01:00] <mdz> elmo_: well, after Mithrandir you're the first person to be able to reproduce it, so by all means...
[01:00] <elmo_> 1 3.2Ghz Xeon HT
[01:00] <jdub> seb128: i support upgrading gst as a natural bugfix release from gnome
[01:00] <elmo_> but I also saw it on apt-extracttemplates on one of the 3.06GHz Dual Xeon boxes
[01:00] <jdub> (ie. 2.8 desktop packages)
[01:01] <jdub> and then totem on top of that is not a huge worry
[01:01] <seb128> ok
[01:01] <mdz> seb128: anyway, it doesn't seem to be any more broken than the previous version
[01:01] <Mithrandir> mdz: I think it's triggered by HT somehow, and HT isn't that common.
[01:01] <mdz> it still doesn't play theora streams or anything else for me
[01:01] <seb128> mdz: according to upstream a lot of bugs have been fixed
[01:01] <seb128> ok to push it ?
[01:01] <mdz> I can get about 2-3 frames from it and then it never draws a new frame
[01:01] <mdz> sure
[01:02] <seb128> we don't have a lot to loose, totem-gstreamer didn't work fine in all cases
[01:02] <Mithrandir> mdz: I'm going to try to reproduce it on a friend's FC box, in an ubuntu chroot, if so, we should find out whether it's the kernel or glibc (or possibly still unknown)
[01:02] <elmo_> Mithrandir: ?? it's ridiculously common in servers
[01:02] <mdz> seb128: I agree
[01:03] <mdz> elmo_: you're probably the only one on staff running Ubuntu on that grade of server at the moment
[01:03] <seb128> ok thanks
[01:03] <Mithrandir> elmo_: I think we have a small market share when it comes to workstations, but our server market share is probably ~0% on servers.
[01:03] <Mithrandir> uhm s/on servers//
[01:04] <Mithrandir> since people are a lot more likely to jump on the "new shiny distro" wagon for workstations and home boxes than for servers.
[01:04] <elmo_> Mithrandir: dude, we can't ship a product where gzip doesn't fricking work on any modern server and expect to be taken seriously
[01:04] <seb128> mdz: and about eagle-usb ? Sorry to ask again, but some french guys would be happy to get the change, and I don't think that eagle-adsl is used a lot, should not problematic neither ...
[01:04] <Mithrandir> elmo_: no, we can't, I'm just trying to guess why nobody but us two have stumbled across it so far.
[01:05] <mdz> seb128: ok, so currently we have neither eagle-adsl nor eagle-usb in warty, they are alternatives to each other, and you propose that we add eagle-usb to supported?
[01:05] <Mithrandir> I think it's a timing issue somewhere, since the only way to reproduce it is to run apt-extracttemplates a bunch of times.
[01:05] <Mithrandir> and strace makes the timing slightly off, so the problem then disappears.
[01:05] <mdz> Mithrandir: nothing else with a gzip pipeline triggers the problem?
[01:06] <Mithrandir> mdz: not that I've seen
[01:06] <seb128> mdz: hum, let me checked, but one should be in the shipped seed
[01:06] <mdz> elmo_: if you can put me in a position where I can debug it, I'll have a go
[01:06] <mdz> seb128: neither one seems to be in main
[01:06] <mdz> seb128: I thought we had discussed this before and agreed on it
[01:06] <Mithrandir> mdz: I can give you root on the box if you want, no problems. :)
[01:07] <mdz> Mithrandir: ok
[01:07] <mdz> Mithrandir: shall I send you an ssh key?
[01:07] <seb128> mdz: ok, eagle-usb-utils is in the shipseed
[01:08] <seb128> mdz: I've pinged you 2 times, but never go a "ok" ... you asked for details and we didn't get a conclusion
[01:08] <Mithrandir> mdz: just sent you a mail with host name and password; hope you have your key nearby.
[01:09] <seb128> mdz: BTW the module in the kernel package is the -usb one and the package is in the seed, so I'll upload it if you're ok
[01:09] <mdz> seb128: ok, my apologies
[01:09] <seb128> no problem
[01:09] <mdz> seb128: is eagle-usb-utils sufficient?
[01:09] <seb128> yes
[01:09] <mdz> 12	2004-09-24 00:38:11	852		MattZimmerman	add eagle-usb-utils
[01:10] <mdz> seb128: so we did agree and I added it to the seed
[01:10] <seb128> hum
[01:10] <seb128> there is a -data too
[01:10] <mdz> if we need the -data, that is fine with me
[01:10] <seb128> ok thanks
[01:11] <seb128> mdz: perhaps we agreed but I missed the agreement :) BTW that's ok now, thanks
[01:14] <elmo_> that's just fucking typical.  I reboot 19 machines when I'm physically there and they all come back fine. I reboot one machine when I'm 200 miles away and it dies
[01:14] <mdz> Mithrandir: yeah, I am at home.  logged in now
[01:14] <mdz> Mithrandir: so what's the easiest way to reproduce it?
[01:15] <mdz> elmo_: no iLO goodness?
[01:15] <Mithrandir> mdz: cd /var/cache/apt/archives 
[01:15] <Mithrandir> then run apt-extracttemplates apache2-mpm-worker_2.0.50-12ubuntu3_i386.deb
[01:15] <Mithrandir> like ten times.
[01:15] <mdz> I just did apt-extracttemplates *.deb and it hung right away
[01:15] <elmo_> mdz: no, not for this machine
[01:17] <mdz> fucking gdb
[01:17] <Mithrandir> mdz: have fun. :)
[01:19] <mdz> elmo_: there's a much simpler workaround than "don't use SMP"; just disable TLS/NPTLS/whatever
[01:19] <elmo_> mdz: blah, well, a little late for that now
[01:20] <Mithrandir> "disable NPTL" isn't an option in many cases either, though.
[01:20] <mdz> only if you're running a billion threads
[01:20] <Mithrandir> mdz: that's just my workstation, so feel free to hack away on it, but please don't kill /home, fyi.
[01:27] <Mithrandir> lamont: care to adjust PaS for linux-restricted-modules?  There's a version I'm uploading now with amd64 support.
[01:27] <mdz> (gdb) bt
[01:27] <mdz> #0  0x40108721 in pthread_setcanceltype () from /lib/tls/libc.so.6
[01:27] <mdz> (gdb)
[01:27] <mdz> gdb is so fucking useless with tls
[01:28] <mdz> Mithrandir: nice bandwidth :-)
[01:29] <Mithrandir> mdz: university network, so 100Mbit straight to the box.
[01:29] <Mithrandir> would have been nice with gbit, but it doesn't really matter.
[01:43] <doko> mdz: what about #2204 and #2216 for warty?
[01:44] <mdz> doko: 2204 is a one-liner, right?  OK with me
[01:44] <mdz> doko: regarding 2216, could you explain the problem a bit?
[01:46] <doko> mdz: 2204: yes. 2216: a file is deleted during the build. the patch makes sure that this file exists at all times and the python modules gets built.
[01:47] <mdz> doko: I don't understand the original problem, though. if this file is important, why is it disappearing?
[01:49] <doko> if I understand it correctly:   * debian/rules: Added a workaround for python/libxslt-py.c file to recover
[01:49] <doko>     its original state after build (to avoid pollution of svn and diff file).
[01:50] <doko> but that fails, if you build the package twice.
[01:50] <doko> (changelog from 1.1.6-1)
[01:52] <mdz> so the file is modified during the build, and the packagaing was trying to restore it?
[01:53] <doko> exactly, and misses the fact that it's remove by make realclean
[01:53] <mdz> doko: ok, thanks, I understand.  OK to upload
[01:53] <mdz> Mithrandir: I have a workaround for apt-extracttemplates at least
[01:54] <mdz> did elmo say if he saw it anywhere other than in apt-extracttemplates?
[01:54] <mdz> I don't think katie uses that
[01:54] <mdz> it's seeming like a glibc bug
[01:54] <Mithrandir> mdz: ok, what would it be?
[01:55] <mdz> Mithrandir: apt-inst's extracttar does this funny thing where it sends a signal to gzip right when it's supposed to be exiting, to make sure it's gone
[01:55] <mdz> Mithrandir: if I turn that off, it never hangs
[01:56] <Mithrandir> ok
[02:07] <thom> argh, it's 1am
[02:07] <doko> ugh, jackass is down?
[02:07] <thom> yeah
[02:07] <thom> elmo is en route currently
[02:07] <doko> from where?
[02:07] <thom> from his house to the data center
[02:08] <doko> this are a few miles ... :-(
[02:09] <thom> at this time of night, it's easier for him to drive than for me to try and get there *sigh*
[02:09] <doko> shit happens.
[02:10] <doko> good night!
[02:15] <daniels> ahar!
[02:15] <daniels> thom: all you need is acpi_sleep=s3_bios for x40 suspend
[02:15] <daniels> thom: mind if I package your /etc/acpi as acpi-support-x40 or something?
[02:18] <daniels> thom: (after cleaning it up a bit)
[02:18] <thom> no, not at all
[02:19] <lamont> Mithrandir: PaS is an elmo thing.
[02:20] <daniels> thom: rad, thanks
[02:20] <daniels> thom: my 'X40 on Ubuntu' page will consist of: 'First, boot with linux acpi_sleep=s3_bios when you install.  Secondly, when you're done, add in this APT source, and install acpi-support-x40.'
[02:22] <thom> heh, nod
[02:24] <mjg59> Teh x40 is teh rock
[02:24] <daniels> mjg59: that it is
[02:25] <daniels> indeed, it is love
[02:26] <thom> daniels: those scripts are originally mjg59's, and gpl'd (i'm sure i'll be corrected shortwith if my memory is broken :) )
[02:26] <mdz> thom: #1357 and friends should be trivial to fix now, yes?
[02:27] <thom> mdz: the language packs are just gonna need to be updated to accept our warped version numbers, yeah
[02:27] <thom> i'm intending to do that first thing tomorrow
[02:30] <mjg59> One of the Novell people at the expo told me something interesting
[02:30] <mjg59> NLD will ship with KDE in Europe and Gnome in the US, allegedly
[02:30] <thom> mjg59: *boggle*
[02:31] <thom> they really think the divide is that strong?
[02:32] <mjg59> Seemingly so
[02:32] <daniels> have you guys also experienced a random system beep?
[02:32] <mjg59> But also, I think all their EU support staff are originally SuSE
[02:32] <daniels> i'm getting one, and Googling shows it also happens under XP, but if you remove a device called 'Beep' from Device Manager (?!?), it all goes away
[02:33] <daniels> mjg59: dude, that's total bong
[02:33] <daniels> mjg59: so there will be SuSE, KDE NLD and GNOME NLD?
[02:33] <mjg59> daniels: Using wireless?
[02:33] <mjg59> And ifplugd?
[02:34] <daniels> mjg59: yes, and maybe
[02:34] <daniels> mjg59: does ifplugd run as a daemon?
[02:34] <mjg59> Yes
[02:34] <daniels> mjg59: ok. it's not running, but I've muted everything anyway.
[02:34] <mjg59> If so, it's probably the firmware resets on the wireless card
[02:34] <daniels> nope, not even installed
[02:34] <mjg59> Hmm
[02:35] <daniels> basically, it sounds like there's a hard disk write, then a system beep
[02:35] <mjg59> Check whether it correlates to those anyway
[02:35] <mjg59> Oh, are you /sure/ it's a beep?
[02:35] <daniels> http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2004-July/019160.html
[02:35] <mjg59> The drive makes an odd chirp noise when it parks
[02:35] <daniels> http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2004-August/019163.html
[02:35] <daniels> it's a beep-like sound, but it does sound a little different
[02:35] <daniels> can I make the drive shut the fuck up?
[02:35] <mjg59> Mine doesn't seem to do it now
[02:35] <mjg59> I've no idea what changed
[02:36] <thom> NetworkManager is hardcore crackadelia, by the way
[02:36] <daniels> thom: duh
[02:36] <mjg59> NetworkManager was a mess of race when I tried it
[02:36] <daniels> mjg59: which kernel are you running?
[02:36] <mjg59> 2.6.7
[02:36] <mjg59> +random patches
[02:37] <thom> it's now a mess of race, with broken dbus permissions
[02:37] <mjg59> It's irritating - Netapplet is the wrong solution, but it works
[02:37] <daniels> mjg59: are you running laptop-mode?
[02:37] <daniels> thom: urgh
[02:37] <mjg59> NetworkManager is the right solution, but implemented in an over-complex way
[02:37] <mjg59> daniels: Yeah
[02:37] <mjg59> Only on battery, though
[02:37] <thom> networkmanager will eventually get there, but may need a rethink and tears to get there
[02:38] <daniels> mjg59: right
[02:38] <daniels> mjg59: any clue as to which patches you're running?
[02:38] <daniels> yes, it definitely sounds like the drive parking
[02:39] <mjg59> daniels: ACPI + random stuff of my own to debug ACPI stuff
[02:39] <mjg59> Shouldn't be anything special
[02:39] <thom> the packages almost work, but there really needs to be a way to add NetworkManagerInfo to the user's gnome session :/
[02:39] <mjg59> Playing with the hdparm accoustic management stuff might help
[02:41] <daniels> hm
[02:41] <daniels> yeah, I just set it to 192 on a semi-whim
[02:41] <daniels> GAH
[02:46] <mjg59> 128 is the only one that's likely to do anything
[02:48] <daniels> yeah, tried that too
[03:15] <tseng> thom: patching the default session might be a start
[03:48] <jdub> yo mjg59 
[04:17] <mdz> I think we've found a paleobug in gzip
[04:20] <tseng> ew
[05:23] <fabbione> morning guys
[05:30] <chrisa> 13 RC till warty?
[05:30] <lamont> Rejected: libglib2.0-udeb_2.4.7-0ubuntu1_x86_64.udeb: architecture part of filename (x86_64) does not match package architecture in the udeb (amd64).
[05:31] <fabbione> chrisa: bug in discover1-data
[05:33] <fabbione> and thunderbird keeps crashing on me..
[05:36] <mdz> (downgraded a NEEDINFO bug which had been waiting for too long)
[05:36] <mdz> looked like it was fixed, but the submitter would not confirm
[05:37] <hornbeck> mdz: do you guys want the user manual's in yelp to be Ubuntu specific for Hoary?  If so I will start working on them if noone is
[05:37] <mdz> hornbeck: an updated user manual would be delightful
[05:38] <hornbeck> ok, I did not want to start without knowing it was needed
[05:38] <hornbeck> I am on it
[06:14] <fabbione> mdz: can i remove Build-Dep:  libstdc++5-3.3-dev ?
[06:14] <fabbione> according to debian any pkg providing libstdc++-dev is build-essential
[06:17] <fabbione> bah we can wait after warty
[06:21] <fabbione> daniels: you around?
[06:30] <fabbione> mdz: are you still around?
[06:33] <jdub> hornbeck: ROCK!
[06:34] <fabbione> ah jdub!
[06:35] <fabbione> jdub: i have a "design" problem here
[06:36] <fabbione> jdub: 2205, 2106, 1690 
[06:36] <fabbione> jdub: basically the problems are:
[06:36] <mdz> fabbione: here
[06:36] <fabbione> people that installs using an american/english language they get wrongly an US keyboard in X
[06:36] <fabbione> + there is a 50% 50% chance to get the keyboard model wrong on ppc
[06:37] <fabbione> now there is no easy solution for warty to any of these problems
[06:37] <fabbione> my suggestion is:
[06:37] <fabbione> if LAYOUT=us we ask to confirm the layout. For us people is one enter
[06:37] <fabbione> and for ppc users we need to ask to confirm the keyboard model
[06:38] <fabbione> all the other cases will NOT see the questions
[06:38] <fabbione> that's the best we can do atm
[06:38] <fabbione> mdz: i also reviewed again Kostantinos code
[06:38] <fabbione> and he keeps going for the LANG way that we know isn't complete
[06:38] <fabbione> or working in all cases
[06:39] <fabbione> what do you want me to do?
[06:39] <mdz> fabbione: can we use the answer to the keymap question in d-i?
[06:39] <fabbione> mdz: no. we don't have the mappings 
[06:39] <mdz> it is quite late to be making these changes
[06:39] <fabbione> mdz: + that question has been reintroduced not too long ago
[06:39] <jdub> hrm, makes me a little queasy
[06:40] <fabbione> mdz: asking for me is setting a variable
[06:40] <fabbione> it's not like i need to reimplement the code
[06:40] <fabbione> if [ $LAYOUT=us ] ; then PRIORITY=high; fi
[06:40] <fabbione> 2 lines like that
[06:41] <mdz> and that would ask the usual X keymap question?
[06:41] <mdz> which is two screens and text entry?
[06:41] <fabbione> mdz: that will ask only for the layout
[06:41] <fabbione> one question
[06:41] <mdz> users do not generally know how to answer that question
[06:41] <mdz> well debconf displays it as one screen of text and then a prompt for the keymap name
[06:41] <mdz> but more importantly, the user doesn't know the answer
[06:42] <fabbione> mdz: it's one screen only
[06:42] <fabbione> the message is hidden with priority low
[06:43] <mdz> ah, so that is actually a separate question
[06:43] <mdz> so the user would see "Please select your keyboard layout" and a text entry box
[06:43] <fabbione> when you get the 3 questions in a raw is because you are either reconfiguring or installing debian
[06:43] <mdz> that is extremely unfriendly
[06:44] <fabbione> well i can reenable messages if that's required
[06:44] <mdz> I think it's a problem either way
[06:44] <fabbione> but i think that as it is now is going to me the root of my headackes until hoary will have the "nice selector"
[06:46] <mdz> if it is not yet right for warty, I think it is time to say "oops" and let it go
[06:46] <mdz> we cannot make things worse for cases where it currently works
[06:50] <fabbione> http://people.ubuntulinux.org/~fabbione/boom
[06:50] <fabbione> ah nevermind
[06:50] <fabbione> it's missing one thing
[06:51] <fabbione> ok
[06:51] <fabbione> mdz, jdub: that's the changelog for the next X upload
[06:52] <fabbione> it should also fix 1089 but only for common layout as Denis specified
[06:52] <fabbione> so it's not a complete fix
[06:52] <fabbione> changelog is pedantic
[06:52] <fabbione> but the changes are minimal and tested
[06:53] <daniels> fabbione: sup?
[06:53] <hornbeck> jdub: thanks I will try to have some good docs in place
[06:54] <fabbione> daniels: check above url
[06:55] <daniels> fabbione: checking now
[06:56] <daniels> looks good to me
[07:00] <jdub> hornbeck: if you make any changes that would be appropriate for upstream, perhaps we should split those out and send them up
[07:00] <hornbeck> ok
[07:01] <hornbeck> jdub: Do you want all of the manuals in yelp to be Ubuntu specific?
[07:01] <hornbeck> or just updated to the releases
[07:05] <hornbeck> I am thinking of adding a Ubuntu tab under the "Help Contents/Categories" for strictly Ubuntu docs 
[07:06] <jdub> hornbeck: ideally, they should be well integrated
[07:06] <jdub> hornbeck: but upstream need to provide a way for that to be done easily
[07:06] <jdub> atm it's very hard
[07:07] <hornbeck> jdub: I noticed that the user guide shipping with Warty is for Gnome-2.6
[07:07] <hornbeck> is noone working on it anymore?
[07:07] <jdub> hornbeck: it hasn't had a lot of love for this release
[07:07] <hornbeck> hmm
[07:07] <jdub> hornbeck: the man to speak to for status is shaunm
[07:08] <hornbeck> jdub: I was working with him, but he kinda flaked out alot
[07:08] <hornbeck> over worked I guess
[07:08] <jdub> heh
[07:08] <jdub> he's been busy
[07:08] <hornbeck> yeah, I would have been flaking to
[07:08] <hornbeck> I will touch base with him
[07:09] <jdub> cool
[07:09] <jdub> unfortunately, that's an area that needs work (upstream + vendor documentation)
[07:11] <hornbeck> I just sent him a email about helping with the Gnome User Guide
[07:11] <hornbeck> if I can get it updated enough maybe it will help Ubuntu and Gnome
[07:17] <jdub> hornbeck: you're a legend, thank you :-)
[07:17] <hornbeck> haha
[07:18] <hornbeck> jdub: in cvs it looks like there is 2.8 docs
[07:19] <hornbeck> ahhh, it is maintained by the Sun GNOME Doc team
[07:24] <jdub> except not
[07:24] <jdub> because they can't keep up ;)
[07:24] <hornbeck> I guess that is where I come in 
[07:41] <fabbione> mdz: i added the warty bug info to the changelog.
[07:41] <fabbione> jdub: same for you
[09:48] <jdub> oh man
[09:48] <jdub> this is really scary
[09:48] <jdub> i've started typing: sudo apt-get source ...
[09:49] <Mithrandir> I did that too the other day.
[09:49] <Mithrandir> scary, yes.
[09:51] <fabbione> http://people.ubuntulinux.org/~fabbione/console-common_u3-to-u4.diff
[09:51] <fabbione> to fix: 2196
[09:52] <fabbione> anybody can review the "deep" changes? ;)
[09:52] <Mithrandir> looks good to me. :P
[09:53] <fabbione> jdub: ???
[09:54] <Mithrandir> fabbione: I think this falls into the "trivial" category.
[09:54] <fabbione> Mithrandir: i know :-))))
[09:54] <fabbione> i am just teasing jdub
[09:54] <fabbione> since nobody still approved my Xfree86 changes 
[09:54] <Mithrandir> ;)
[09:54] <fabbione> on the otherside nobody here smokes enough crack for that
[09:55] <Mithrandir> fabbione: could you look at http://raw.no/patches/nvidia-settings_1.0-4.amd64.diff and tell me if it looks sane to you?
[09:55] <Mithrandir> jdub: or you, possibly.
[09:56] <Mithrandir> this is almost like old times, sponsorwhining on IRC :D
[09:57] <fabbione> Mithrandir: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.7
[09:57] <fabbione> EXTINCSRC=/usr/X11R6/include/X11/extensions
[09:57] <fabbione> needs to be changed
[09:57] <fabbione> to /usr/include/X11/foobarbazcrap
[09:58] <Mithrandir> that makefile is imake-generated.
[09:58] <fabbione> imake sucks, didn't you know that?
[09:59] <fabbione> but i was talking about debian/rules
[09:59] <Mithrandir> tell nvidia, not me. :)
[09:59] <Mithrandir> oh, in rules
[10:00] <fabbione> anyway
[10:00] <fabbione> if you want to simplify that
[10:00] <fabbione> you can build-deps on xutils
[10:00] <fabbione> and use xmkmf
[10:00] <fabbione> that will generate the Makefile from the Imakefile on the fly
[10:00] <fabbione> otherwise you can use imake (still from xutils)
[10:00] <fabbione> imake -I/usr/X11R6/lib/config/ 
[10:01] <fabbione> or something like that
[10:01] <fabbione> DESCRIPTION
[10:01] <fabbione>        The xmkmf command is the normal way to create a Makefile from an Imake-
[10:01] <fabbione>        file shipped with third-party software.
[10:01] <Mithrandir> is running imake when building the preferred solution?
[10:02] <fabbione> no idea of what nvidia-setting does
[10:02] <fabbione> but i can see you are adding Makefiles
[10:02] <fabbione> the best way is to create them
[10:02] <fabbione> so that when imake/xmkmf will change
[10:02] <Mithrandir> ok, then I'll do that instead.
[10:02] <fabbione> it will be enough to reupload/rebuild the package
[10:02] <fabbione> other than recreating all the Imakefiles
[10:04] <Mithrandir> heh
[10:07] <suheimi> questions: it is said that python is integrated in ubuntu. How integrated is it?
[10:08] <Mithrandir> fabbione: so you're happier with http://raw.no/patches/nvidia-settings_1.0-4.amd64.2.diff ?
[10:09] <mdz> suheimi: a rich python environment is provided by default, and a greater degree of integration is coming in future releases
[10:09] <jdub> ahr, mdz
[10:09] <jdub> mdz: you happy with this patch for openldap2?
[10:09] <jdub> http://cvs.gnome.org/viewcvs/*checkout*/evolution-exchange/docs/openldap-ntlm.diff?rev=1.1.1.1
[10:09] <mdz> hmm, didn't we talk about this already?
[10:09] <jdub> yes, just making sure
[10:10] <jdub> as i'm about to upload
[10:10] <suheimi> is it going tobe like java and jds linux?
[10:10] <fabbione> Mithrandir: yes.. just check if it compiles at it should :-)))
[10:10] <jdub> suheimi: WAAAAAAAAY more integrated
[10:10] <fabbione> Mithrandir: but it looks much simpler than shipping a 200K Makefile
[10:10] <fabbione> ;)
[10:10] <Mithrandir> fabbione: "hey, it compiles!  Ship it!"
[10:10] <mdz> jdub: I assume there is a very good reason to do this for Warty?
[10:10] <Mithrandir> ;)
[10:11] <Mithrandir> fabbione: seems to build fine here, and it builds the .a, which it didn't do before.
[10:11] <jdub> mdz: making evolution-exchange useful for people who are using it in a real environment :-)
[10:11] <suheimi> jdub: can u explain ?
[10:11] <Mithrandir> mdz: http://raw.no/patches/nvidia-settings_1.0-4.amd64.2.diff -- happiness?
[10:11] <jdub> suheimi: we're planning on deep python scriptability for as much as we can throughout the OS
[10:12] <mdz> Mithrandir: hmmm
[10:12] <mdz> Mithrandir: presumably it includes an i386 binary which we currently use?
[10:12] <Mithrandir> mdz: correct.
[10:12] <mdz> Mithrandir: and now we are building it from source instead, even on i386?
[10:12] <Mithrandir> and somehow, that links on amd64, but blows up when running.
[10:12] <Mithrandir> yes.
[10:12] <Mithrandir> it's a gpl-ed library from nvidia
[10:12] <Mithrandir> they ship it as a binary because they think it's easier for people.
[10:13] <mdz> Mithrandir: but we have no idea whether it actually works when built from source on Ubuntu?
[10:13] <suheimi> jdub: you mean, the bash will be in python ?
[10:13] <Mithrandir> mdz: it works on amd64, at least.
[10:13] <mdz> Mithrandir: please get someone to test it on i386
[10:13] <Mithrandir> mdz: ok.
[10:13] <fabbione> Mithrandir: put up the .diff.gz
[10:13] <fabbione> i can test on i386
[10:13] <mdz> for all we know, it may never have been built with our gcc etc.
[10:13] <fabbione> and the dsc
[10:14] <fabbione> mdz: i can test it
[10:14] <jdub> suheimi: heh, no :-)
[10:14] <fabbione> no panic!
[10:14] <fabbione> NOBODY PANIC!
[10:14] <jdub> suheimi: like, scripting openoffice and stuff like that
[10:14] <fabbione> :P
[10:14] <Mithrandir> fabbione: thanks -- http://raw.no/tmp/nvidia-settings_1.0-4.dsc and http://raw.no/tmp/nvidia-settings_1.0-4.diff.gz
[10:14] <suheimi> ok, like vbscript then.
[10:14] <mdz> panic()
[10:15] <mdz> Mithrandir: did you see my notes on #1854?
[10:15] <mdz> I think it may be a gzip paleobug
[10:15] <Mithrandir> mdz: yeah, it might be.
[10:15] <Mithrandir> but I think it's also a libc/kernel bug -- you shouldn't end up with deadlocks like that.
[10:16] <mdz> if the situation is as I think it is, glibc and kernel are correct and gzip is buggy
[10:16] <mdz> a signal can arrive at any time, even inside a critical section
[10:18] <mdz> as to why no one else seems to have encountered this bug, I have no idea
[10:18] <mdz> at least Debian users should see it
[10:18] <Mithrandir> I think it's a race condition in glibc when two signals arrive closely together, but you seem to be correct.
[10:18] <mdz> it seems that the only requirement is a 2.6 SMP kernel
[10:19] <Mithrandir> possibly with HT.
[10:19] <mdz> hmm, didn't elmo experience it on a non-HT xeon?
[10:19] <Mithrandir> hmm, I have a dual celeron here.. I should be able to reproduce on it.
[10:19] <Mithrandir> not AIUI.
[10:19] <mdz> hmm
[10:19] <mdz> please do try
[10:20] <Mithrandir> I need to build a box around the mobo, though
[10:20] <fabbione> Mithrandir: it works fine here.
[10:21] <Mithrandir> fabbione: goodness.
[10:21] <fabbione> but i think the package should be 3ubuntu1 ?
[10:21] <fabbione> and not 4
[10:21] <Mithrandir> fabbione: yeah, of course, mea culpa.
[10:21] <fabbione> no problem ;)
[10:21] <Mithrandir> mdz: as it works on i386 as well, permission to upload?
[10:21] <rburton> is ubuntu-base a required package, or is it just used to bring in the default install?
[10:22] <Mithrandir> rburton: no, but it can be used for keeping up with the ubuntu-base task.
[10:22] <Mithrandir> if the task changes.
[10:22] <rburton> it wants to remove my mta (as it changed postfix)
[10:22] <mdz> Mithrandir: OK
[10:22] <rburton> so i'll remove it
[10:22] <mdz> feel free
[10:25] <mdz> Kamion: awake?
[10:42] <mdz> fabbione, daniels: #2239 doesn't seem RC; is there some justification?
[10:44] <fabbione> mdz: yes. if the hardware of that guy is ok, either discover1-data is broken or discover1 making X failing to work
[10:44] <fabbione> discover1-data seems to be ok
[10:45] <mdz> X not working on a particular piece of hardware is not usually an RC bug
[10:45] <fabbione> but something else can be badly broken
[10:45] <fabbione> mdz: i know that.. that's not the problem. X works on that machine, but the generated configuration is bad
[10:45] <fabbione> mdz: not getting the proper driver is much worst than running @60Hz or something
[10:45] <mdz> I understand that
[10:46] <fabbione> ok X i up
[10:56] <mdz> is anyone able to reproduce #1254?
[10:56] <mdz> there are several possible solutions, but since none of us can test, it is difficult
[10:56] <mdz> seems to hit many Dell laptop users
[10:57] <rburton> i take it i'd need to recompile the kernel to get the sysrq key working?
[10:57] <mdz> rburton: that, or wait for Herbert's next upload, where it'll be enabled
[10:57] <rburton> excellent
[10:57] <mdz> (assuming you're on i386)
[10:57] <mdz> it's already enabled on powerpc and amd64
[10:58] <rburton> yeah, i am. i'll wait
[11:11] <daniels> mdz: i suspect 1254 is people choking on the apic pipe
[11:11] <daniels> unreproducalbe
[11:11] <daniels> or whatever
[11:12] <mdz> daniels: noapic doesn't help those folks
[11:12] <mdz> read the comments
[11:13] <daniels> mdz: yeah, just finished reading them, and it's the BIOS being arse :\
[11:13] <daniels> jdub: kaping
[11:15] <daniels> jdub: (there were some X changes pending for Warty -- can you remember what they were?)
[11:15] <jdub> whowhat?
[11:25] <fabbione> memtest86+ (1.15-2ubuntu2) warty; urgency=low
[11:25] <fabbione>   * Fix bashishm in debian/make-memtest86+-boot-floppy.
[11:25] <fabbione>     (Closes: #2121/#275233)
[11:25] <fabbione>   * Add make-memtest86+-boot-floppy man page. (See #263708)
[11:25] <fabbione> trivial changes
[11:26] <fabbione> any objections?
[11:30] <mdz> fabbione: seems harmless enough
[11:30] <mdz> there are plenty of bigger bugs, though
[11:43] <fabbione> mdz: i am going trough "orphaned" bugs
[11:43] <fabbione> all the one assigned to nobody
[11:44] <fabbione> food time
[11:45] <Mithrandir> mdz: mind if I kill off your gzip processes?
[11:45] <mdz> Mithrandir: not at all
[11:53] <Mithrandir> gnome-cups-manager doesn't like cupsys to be upgraded underneath it.
[11:58] <sivang> mdz : could you please take a look at #2221 and tell me if it's major? (I've catagorized it minor)
[11:59] <sivang> mdz : minor = normal
[11:59] <mdz> sivang: normal is appropriate
[12:00] <mdz> I don't really expect network-admin to cope with the loopback interface being deleted out of /etc/network/interfaces
[12:00] <mdz> but it seems to try
[12:01] <daniels> ?!?
[12:01] <sivang> mdz : Ok. It's not that I deleted the spcific interface line, I erased the entire file just to see what will happen to a user that he's config would disappear.
[12:01] <sivang> mdz : It's currently unable to create interfaces file correctly from scratch.
[12:01] <mdz> sivang: that is true of most of the configuration files on the system :-)
[12:02] <sivang> mdz : I see :-) Shame I lost about 1 day (of which I should have rested while ill) to debug the little thingy off...Well, guess this is hoary material then? :-)
[12:03] <mdz> definitely
[12:03] <sivang> mdz : it also appeared that this happens on debian sid also..This should have raised a red light to me :-)
[12:06] <sivang> mdz : anyways, could you fill me up on what you and hornbeck agreed regarding yelp? I've got little lagged..
[12:06] <mdz> that was jdub
[12:07] <sivang> mdz : oh ok, I'll ping him then.
[12:08] <sivang> jdub : ping?
[12:11] <daniels> lifeless: how long do you think it will take to release the KDE arch archive? :)
[12:13] <jdub> daniels: haha
[12:13] <jdub> sivang: nothing about yelp
[12:16] <mdz> jdub: I think he means about the user manual
[12:16] <jdub> oh
[12:17] <sivang> jdub : he also mailed me about that you and him agreed on some thing etc..
[12:17] <sivang> jdub ; regarding what should go into yelp I think
[12:17] <jdub> hornbeck is going to work on updating bits from the 2.8 version and integrate ubuntu information
[12:17] <jdub> sivang: note that this has nothing to do with yelp (it's just the viewer)
[12:18] <sivang> jdub : Yes. (I might have needed to repharase my inquiry) He's going to work on gnome 2.8 manual and update it to fit Ubutnu quirks?
[12:20] <fabbione> 2251 <- doh.. this is becuase we disabled browsing, didn't we?
[12:20] <mdz> fabbione: yes, that is a feature
[12:21] <fabbione> mdz: invalid?
[12:21] <mdz> fabbione: enhancement
[12:21] <mdz> we do want to have automatic discovery of printers
[12:21] <mdz> but we will need to find a way to do it without opening a port continuously forever
[12:22] <mdz> the implementation is broken
[12:22] <sivang> jdub : also, what would be that last date to sumbit docs to get on the release? the 17th 0:-) ?
[12:23] <mdz> Keybuk: could I trouble you for a second opinion on #1854?
[12:24] <mdz> Keybuk: hypothesis: it is simply evil to exit() or free() in a signal handler
[12:24] <Keybuk> I don't think you can free in a signal handler
[12:24] <Keybuk> that's one of the forbidden actions
[12:24] <Keybuk> (the signal might happen inside malloc)
[12:25] <mdz> likewise for exit()
[12:25] <Keybuk> yeah, I tend to agree
[12:25] <mdz> because it flushes streams, and the signal might arrive while one is locked
[12:25] <mdz> I have no idea why no one else has encountered this, however
[12:25] <mdz> which is the only reason I doubt
[12:25] <mdz> I mean, this is _gzip_
[12:26] <mdz> something that gets piped and signalled and context-switched all day long on a wide variety of hardware
[12:26] <Keybuk> have FreeBSD not fixed this?  their system is very sensitive to malloc/free-in-signal issues
[12:26] <Keybuk> yeah, but how often does SIGINT really get thrown?
[12:26] <Mithrandir> mdz: I'm going to try reproducing it this evening.
[12:26] <Mithrandir> (on said celeron system)
[12:27] <mdz> Keybuk: it calls the same handler for SIGPIPE
[12:27] <mdz> and SIGTERM and SIGHUP
[12:28] <Keybuk> signal handlers should generally just set a flag which the main loop picks up; anything else is a bit dodgy :-/
[12:28] <mdz> _exit() and abort() should both be safe
[12:28] <mdz> according to POSIX
[12:28] <Keybuk> yes, that sounds right
[12:30] <mdz> Mithrandir: I attached a patch
[12:30] <Keybuk> I'd just call _exit() rather than do_exit() ... the kernel will free the memory quite adequately when it collapses the process
[12:31] <sivang> mdz : you have any ideas as to how make Ubuntu in (maybe _this_ specific?) Dell Inspiron 8200 - it's barely usable when firefox and startup take _so_ long.
[12:31] <mdz> Keybuk: that's exactly the patch I just attached to the bug
[12:31] <sivang> mdz : also, disk access seem to take _ages_.
[12:32] <mdz> sivang: I have no idea, make sure DMA is enabled on the hard drive, ask in #ubuntu
[12:34] <lifeless> daniels: not long if I get a tarball. the anoncvs servers seem to have a badly configured conection limit detector
[12:34] <mjg59> Oh dear. 1061 unread in ubuntu-users
[12:37] <mdz> Mithrandir: emailed you a gzip .deb to test
[12:38] <mdz> bah, I'm just going to upload it
[12:38] <mdz> it's only gzip, right? :-P
[12:39] <daniels> heh
[12:39] <mdz> could someone take care of forwarding the patch upstream?  I need to sleep
[12:42] <sivang> mdz : it's a matter of attaching the file and mail it to the upstream developer(s) ?
[12:43] <daniels> mdz: this is the mdz of legend? sleeping?
[12:43] <sivang> mdz also deserves to sleep once in a 3rd night ;-)
[12:44] <Mithrandir> mdz: I'm going to test it this evening.
[12:47] <Mithrandir> mdz: and you have root on the workstation -- it's not like you couldn't just install it and test yourself. :P
[01:02] <fabbione> 2252 looks like a missing reautoconfig --everything --r3g3r4t3 --4ut0t00l5
[01:03] <rburton> that bug ruined my plans for this morning :)
[01:04] <fabbione> rburton: rebuilding it seems to fix the problem
[01:04] <fabbione> rwxr-xr-x root/root         0 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/
[01:04] <fabbione> -rw-r--r-- root/root     39227 2004-10-11 13:03:15 ./usr/lib/python2.3/site-packages/libxslt.py
[01:04] <fabbione> -rw-r--r-- root/root     53388 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/libxsltmod.so
[01:04] <fabbione> -rw-r--r-- root/root      1021 2004-10-11 13:03:15 ./usr/lib/python2.3/site-packages/libxsltmod.la
[01:04] <fabbione> -rw-r--r-- root/root     67712 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/libxsltmod.a
[01:04] <rburton> yay, files
[01:05] <rburton> can you mail me that deb?  for some reason i can't get it from packages.debian.org :(
[01:05] <fabbione> but i wonder why it didn't build properly in the first place
[01:05] <fabbione> rburton: let em put it on the web
[01:05] <daniels> we need the build log
[01:05] <daniels> probably failed a config test, just non-fatally
[01:05] <daniels> so it didn't build half of it
[01:06] <daniels> most configure scripts don't actually error out when they need to
[01:06] <fabbione> rburton: people.u.o/~fabbione/
[01:06] <fabbione> http://people.no-name-yet.com/~lamont/buildLogs/libx/libxslt/1.1.7-1ubuntu1/libxslt_1.1.7-1ubuntu1_20041011-0737-i386-successful
[01:06] <rburton> fabbione: cheers
[01:07] <rburton> it doesn't build-dep on libxslt1-dev
[01:07] <daniels> huzzah
[01:07] <fabbione> ARGH
[01:07] <seb128> missing a build-dep on python apparently
[01:08] <fabbione> no it can't builde-dep on libxslt1-dev
[01:08] <fabbione> ok i am on it
[01:08] <seb128> python-dev used to dep on python
[01:09] <Kamion> mdz: hello
[01:09] <Kamion> mdz: oh, damn, you went to sleep
[01:09] <fabbione> seb128: afaik python is installed on all the buildd
[01:10] <elmo_> fabbione: it shouldn't be
[01:10] <seb128> fabbione: look on the log, python: no in the ./configure
[01:10] <thom> fabbione: doubt it, you need to depend explicitly
[01:10] <seb128> just add the build-dep on python
[01:10] <daniels> fabbione: chroots, dude
[01:10] <fabbione> elmo_: lamont installed it a long time ago... but anyway not a big deal
[01:11] <fabbione> daniels: i am testing in a chroot dude..
[01:11] <fabbione> thom: as per elmo
[01:11] <fabbione> seb128: thanks :-)
[01:11] <seb128> np
[01:11] <elmo_> fabbione: then lamont needs a beating
[01:11] <fabbione> elmo_: if he removed it.. i dunno..
[01:11] <elmo_> jdub: is this sync request for main?
[01:12] <fabbione> i remember he installed it in the beginning to let a bunch of stuff to build
[01:14] <fabbione> HMMM
[01:14] <fabbione> building in a fresh chroot works fine
[01:14] <fabbione> and it creates the stuff
[01:16] <fabbione> ok yeah
[01:18] <jdub> elmo_: which one?
[01:18] <elmo_> jdub: the mono one
[01:18] <jdub> elmo_: they're all in universe
[01:18] <elmo_> ok
[01:20] <daniels> jdub: permission to upload g-v-m with the gthumb bugfix discussed?
[01:21] <jdub> daniels: oh, ok.
[01:21] <fabbione> there.. fixed
[01:21] <jdub> daniels: kinda hoping azeem would have a chance to respond ;)
[01:21] <Mithrandir> elmo_: did you see mdz tracked down the apt problem?
[01:21] <seb128> jdub: any idea of why bugzilla.gnome.org is down ?
[01:21] <elmo_> Mithrandir: yeah, he phoned me about it while I was on the way down
[01:21] <daniels> jdub: heh
[01:22] <Mithrandir> elmo_: ok
[01:22] <daniels> jdub: i can test it locally if you like
[01:22] <jdub> seb128: might be some server probs atm
[01:22] <seb128> ok
[01:26] <sabdfl> jdub: if I do the image in black and white, is it possible to turn the white into transparency?
[01:26] <sabdfl> i don't know the gimp that well
[01:29] <eniac> and it's hard getting to know the gimp to
[01:30] <sabdfl> the design company work to very specific instructions and frankly haven't a clue about transparency
[01:30] <eniac> does ubunto work with a design company ?
[01:30] <sabdfl> elmo_: can we saturate 600 mbit/s with the current server setup?
[01:31] <sabdfl> and is plone setup properly for cacheing now?
[01:31] <sabdfl> is the reverse proxy setup for cacheing rather?
[01:31] <sabdfl> because we're going to get /.'d 
[01:31] <fabbione> hey sabdfl 
[01:31] <sabdfl> eniac: yes, but not very fruitfully thus far
[01:31] <sabdfl> jdub: go ahead on gnome-default icons
[01:31] <eniac> sabdfl: why not depend on the community ?
[01:31] <thom> i'll take another run through the site and check everything is caching properly
[01:31] <sabdfl> hay fabbione
[01:32] <sabdfl> thom: thanks
[01:32] <thom> last i checked, it was just broken settings on a bunch of the pages
[01:32] <sabdfl> also, the more mirrors we have wednesday the better, of course
[01:32] <sabdfl> what settings on the pages?
[01:32] <jdub> sabdfl: that's a pita to do *really* well.
[01:33] <jdub> sabdfl: tends to be easier to do it from the start with transparency in mind
[01:33] <jdub> sabdfl: happy to explain it to them in photoshop terms :)
[01:33] <sabdfl> jdub: you don't want to go there. very high latency link
[01:33] <sabdfl> i think we have to go with the single colour option for warty
[01:33] <sabdfl> we can do better for hoary
[01:33] <sabdfl> seems like chocolate was the preferred one from responses thus far
[01:33] <jdub> you mean single colour background + watermark?
[01:34] <sabdfl> jdub: single basic shade
[01:34] <sabdfl> will put the glow in
[01:34] <jdub> ok
[01:34] <sabdfl> then get the design company to add the figures
[01:34] <jdub> i'll whip a couple up tonight
[01:34] <sabdfl> default desktop will be colour + glow + ubuntu
[01:34] <sabdfl> like in the chocolate image
[01:34] <sabdfl> there will also be a plain one (colour plus glow) with no logo and no image
[01:35] <sabdfl> and then the calendar image will have colour, glow and one image
[01:35] <jdub> the glow without logo is really easy
[01:35] <jdub> and not a problem for different scales
[01:35] <jdub> but if you add the logo, making it work nicely across resolutions is a bit harder
[01:36] <sabdfl> jdub: erm, try doing the gradient on 1600x1200 with cubic interpolation, threshold at zero and max depth set to 6 on the adaptive supersampling
[01:36] <jdub> although, if you're happy with 4:3 images and stretching for other ratios for warty, that's cool
[01:36] <sabdfl> it... takes a while
[01:36] <sabdfl> jdub: good point, all of the above should be available in 4:3 and 16:9
[01:36] <jdub> we can't auto switch for the right ratio though
[01:37] <jdub> i'd lean towards making ratio-independent images
[01:38] <jdub> (which means you can't bleed, or it'll look like crap)
[01:38] <daniels> fabbione: 275973
[01:40] <thom> fabbione: dude, inventing new words now? (randomically)
[01:40] <Mithrandir> thom: it's just itaglish. :)
[01:40] <fabbione> daniels: saw that... no clue
[01:41] <fabbione> thom: tsk :-P
[01:41] <fabbione> thom: you should know by now ;)
[01:42] <thom> and aaargh, not *another* X upload
[01:42] <fabbione> daniels: probably related to the fact that -8 is missing the us_intl layout?
[01:42] <fabbione> daniels: while we have it?
[01:42] <fabbione> thom: there will be more.. be sure about that
[01:42] <Kamion> jdub: am I OK to upload d-i translation updates in general?
[01:43] <Kamion> doko: why is #1232 assigned to you rather than me? I'd've looked at it earlier if it had been assigned to me :)
[01:43] <daniels> fabbione: everyone should just use us layout anyway
[01:43] <fabbione> daniels: whatever kid ;)
[01:44] <fabbione> let see what Denis answers to it
[01:44] <daniels> he seems to have a grip on XKB
[01:44] <daniels> he can have it
[01:51] <daniels> jdub: oh, that's right -- the -br patch
[01:51] <daniels> jdub: so you've implemented all you need in gdm?
[01:51] <jdub> daniels: yeah, somehow it was lost along the way
[01:51] <jdub> daniels: i can send you a colour code later
[01:52] <daniels> jdub: 'kay
[02:05] <thom> sabdfl: sigh, they've still not fixed all the expires
[02:13] <azeem> if I enable remote gdm, I get a Debian swirl as greeter :)
[02:15] <azeem> jdub: well, I could extract the change from the unstable g-v-m package I guess, if you want it to be consistent and it's not uploaded yet
[02:15] <jdub> bah
[02:15] <jdub> could've told me before i did the last bugfix ;)
[02:15] <jdub> thanks ;-)
[02:15] <azeem> I was having lunch
[02:15] <jdub> azeem: looks like daniels is on the job
[02:16] <daniels> yeah, I'm taking care of it
[02:16] <daniels> just fixing up some dbus stuff first
[02:16] <azeem> okie then
[02:16] <hornbeck> jdub: is there anyway for the gnome 2.8 docs to make it into Warty?
[02:17] <jdub> hornbeck: oh! i thought that was part of what you were doing?
[02:17] <hornbeck> haha
[02:17] <hornbeck> well it can be
[02:17] <jdub> just a matter of a package upgrade ;)
[02:17] <hornbeck> most of the 2.8 docs are already there, in cvs
[02:18] <hornbeck> jdub: my main goal is super clean, easy to understand docs for Hoary
[02:18] <daniels> bloody brownouts.
[02:18] <jdub> hornbeck: seems like we might get quite a bit of help with that
[02:19] <hornbeck> jdub: that would be nice
[02:20] <hornbeck> how would you like me to submit docs to you?
[02:21] <jdub> i think we have to discuss that a bit among the documentation team when we get it rolling
[02:21] <jdub> i think docbook is an easy assumption, however
[02:22] <hornbeck> jdub: Do you want me to package it? Tell you where its at?
[02:23] <jdub> hrm
[02:23] <jdub> do you grok autofoo?
[02:23] <hornbeck> cause the 2.8 docs are there, and I think they are ready to roll
[02:23] <hornbeck> no, I don't but can learn
[02:25] <jdub> perhaps we should start by looking at the gnome user docs cvs module
[02:25] <hornbeck> yes
[02:25] <jdub> i'm not sure if that has xml2po loving yet
[02:25] <jdub> using gnome-doc-tools
[02:25] <Keybuk> then what do you do with the po?
[02:25] <jdub> but i think the combination of docbook, xml2po (in gnome-doc-utils) and regular translation tools will be the best bet
[02:25] <Keybuk> or is it the fo I mean?
[02:26] <jdub> Keybuk: translate as you would any other po files
[02:26] <Keybuk> ah, you're talking about something else
[02:26] <hornbeck> I think if we keep with the docbook style that is already there it would be best bet
[02:26] <Keybuk> the problem I always had with XML Docbook was that you could do the XML -> FO -> nothing
[02:26] <Keybuk> so you couldn't actually produce printables from it
[02:27] <jdub> hornbeck: yeah
[02:27] <daniels> fabbione: 275973 is not our problem, yay
[02:27] <jdub> Keybuk: oh right, yeah
[02:27] <rburton> Keybuk: fop works for me
[02:27] <jdub> rburton: shush, javur boy!
[02:28] <Keybuk> rburton: non-free
[02:28] <rburton> ;)
[02:28] <rburton> Keybuk: good point -- i've not tried it with gcj, though the fop maintainer did say he would try shortly
[02:28] <Keybuk> rburton: I tried, and never got it to compile
[02:28] <jdub> i bet you don't do fop processing on javacards
[02:28] <daniels> heh yeah
[02:29] <rburton> haha
[02:29] <daniels> fop is, um, interesting
[02:29] <rburton> yeah
[02:29] <daniels> since you can process it with java
[02:29] <daniels> and, um, java
[02:29] <rburton> by works i mean "doesn't crash"
[02:29] <rburton> another definition is "better than passiveTeX
[02:32] <hornbeck> jdub: What day do you need the final docs by?
[02:33] <jdub> hornbeck: none specified so far. let's make it the 18th.
[02:33] <hornbeck> ok, I will keep in touch with you on progress
[02:33] <hornbeck> have to go work now
[02:34] <jdub> rock!
[02:34] <jdub> have fun ;)
[02:44] <Kamion> quick review of http://people.ubuntulinux.org/~cjwatson/debian-installer-utils.diff?
[02:44] <Kamion> been meaning to do that for a while for completeness, we made a similar change to debootstrap a while back
[02:45] <fabbione> Kamion: seems ok to me
[02:46] <fabbione> daniels: 275973 - user error
[02:54] <plovs_work> in case the wiki-admin is here, the wiki seems messed up (css can not be found?)
[03:03] <daniels> fabbione: yeah, as I said :)
[03:04] <daniels> plovs_work: works fine for me
[03:06] <plovs_work> daniels, not for me, with a downgraded firefox 9.3 and a new profile?? did you refresh?
[03:06] <daniels> plovs_work: i'm still back on 1.0, but yes, I refreshed, then tried with Mozilla
[03:06] <daniels> plovs_work: try restarting your browser
[03:07] <plovs_work> daniels, I'll try it on windows down the hallway :) brb
[03:07] <daniels> plovs_work: (or it could be something in between -- I thought Planet Debian was busted, 'till I realised planet.debian.org/nudebian.css was getting caught by .*nude.* on my upstream proxy at the time)
[03:07] <Kamion> scunthorpe!
[03:13] <daniels> heh
[03:13] <daniels> Kamion: it also blocked fuckedcompany.com, among others
[03:13] <daniels> stupid fascist proxy
[03:21] <thom> yikes, i now have a catalan firefox
[03:26] <plovs_work> daniels, maybe this should be on #ubuntu but here the wiki does *not* work on firefox-linux-9.3, firefox-windows-1.0pre/9.3 but it *does* work in IE :(
[03:27] <thom> und auf deutsche
[03:28] <daniels> wow ... people actually hack on utah-glx
[03:41] <thom> wow, italian looks crazy
[03:52] <Kamion> Swedish? Norwegian?
[03:52] <thom> Norwegian
[03:53] <thom> no_NB
[03:53] <plovs_work> daniels, http://moinmoin.wikiwikiweb.de/ *does* work so it really is something at http://wiki.ubuntulinux.org
[03:56] <thom> testing firefox in languages you can't even guess at is fun
[03:58] <Kamion> two cron.daily runs in succession are hung at exactly the same place
[03:58] <Kamion> in *gzip*
[03:58] <Kamion> thom: could I have strace on little, please?
[03:58] <daniels> Kamion: i blame mdz
[03:59] <Kamion> daniels: gzip is version 1.3.5-9 on little, before mdz's change
[04:00] <Kamion> does sound like #1854
[04:01] <thom> Kamion: done
[04:01] <thom> want the new version of gzip just in case?
[04:02] <Kamion> both stuck in read()
[04:02] <Kamion> thom: yes please
[04:02] <thom> done
[04:03] <daniels> Kamion: hm
[04:03] <Kamion> thom: strange that it's only shown up since 20041010
[04:03] <Kamion> thom: oh, little got its kernel upgraded yesterday, didn't it?
[04:04] <pitti> jdub: can you please approve #2208 and #2209?
[04:04] <thom> yeah
[04:04] <Kamion> built from linux-source-2.6.8.1 2.6.8.1-10
[04:17] <Kamion> somebody wanna tell Herbert that his latest kernel package fails to build?
[04:17] <sivang> Kamion : hmm, is it a risky thing to do ? :)
[04:21] <Kamion> sivang: no, but I'm busy :)
[04:22] <sivang> Kamion : you have his bug# ?
[04:22] <Kamion> EPARSE
[04:32] <Sledge> Kamion: you available to talk about jigdo-related goodness?
[04:34] <Kamion> Sledge: sure
[04:35] <Sledge> cool
[04:35] <Sledge> sorry to keep you waiting around for a few days
[04:35] <Sledge> kind of stuck in hospital etc...
[04:36] <Kamion> yeah, sure :-/ did it go OK in the end?
[04:36] <Sledge> ish
[04:36] <Sledge> dad's still ill, but stable for now
[04:36] <Kamion> good luck ...
[04:36] <Sledge> they've let him home for a while
[04:36] <Sledge> cheers.
[04:37] <Sledge> so, what kind of snapshot layout are you looking for?
[04:37] <Kamion> one snapshot per CD build for all arches
[04:37] <Sledge> ok
[04:37] <Kamion> not much bothered about the exact layout but we might as well just snapshot the whole archive, I think
[04:37] <Kamion> hm, no
[04:37] <Kamion> snapshot the union of all files used in all three CDs
[04:38] <Sledge> so something like /snapshot/date/<stuff>
[04:38] <Kamion> or possibly date.suffix
[04:39] <Sledge> ok
[04:39] <Kamion> like in http://cdimage.ubuntulinux.org/daily/
[04:39] <Kamion> the cdimage build scripts need to own the version numbers there rather than having mkjigsnap guess them itself
[04:39] <Sledge> I'm thinking that you would set up sym links to specific dates for hoetcary/warty/
[04:39] <Sledge> ok
[04:40] <Kamion> or maybe just create a new hardlink tree, since they're notionally cheap
[04:40] <Sledge> yup, could do
[04:40] <Kamion> although I guess that would screw the jigdo files already generated
[04:41] <Sledge> you could just hand-edit the config file to fix that
[04:41] <Kamion> yeah, though I'd rather not make the process of making a release more complicated than it needs to be
[04:41] <Sledge> so, easiest way is to call mjs with a date option for each arch
[04:41] <Kamion> we tend to be in a hurry :)
[04:41] <Sledge> :-)
[04:41] <Kamion> right
[04:41] <Kamion> so the question is how to get that across the command-limited ssh trigger
[04:41] <Sledge> and simply overlay the snapshot trees on each other
[04:42] <Sledge> how limited is the trigger?
[04:42] <Kamion> you don't get arguments when you're using ssh command=
[04:43] <Kamion> it's all or nothing
[04:43] <Sledge> you sure?
[04:43] <Sledge> it works for me...
[04:43] <Sledge> oh, hang on
[04:43] <Sledge> I get you
[04:45] <Sledge> the way I get around it for tasks here is to run a limited shell for the user rather than use "command="
[04:45] <Kamion> I'm thinking of putting a trigger.conf file somewhere with a very simple format that the script can use to figure out what to do with mkjigsnap
[04:45] <Sledge> hmmm
[04:45] <Sledge> that'll be _tricky_
[04:45] <Kamion> or maybe that's not necessary
[04:46] <Kamion> what I think needs to happen is that the trigger needs to go through daily/ and make sure there's a matching snapshot for the latest one
[04:46] <Sledge> possibly
[04:46] <Sledge> or pass the args to the trigger script on stdin rather than as args
[04:46] <Kamion> occasionally I run the trigger manually when a daily has *not* just been generated
[04:47] <Kamion> oh, that would work too, yes
[04:47] <Sledge> simple perl/sh wrapper to read in options then pass them straight through to mjs
[04:47] <Kamion> so 'echo snapshot 20041011.1 | sync-auckland'
[04:47] <Sledge> yup, something lik
[04:47] <Sledge> e
[04:47] <Kamion> rather not have them be generic options, I suspect elmo would prefer maximum restriction
[04:48] <Sledge> ok
[04:48] <Sledge> but that bit should be easy enough to work out
[04:48] <Sledge> the backend on auckland can parse input and drop anything it doesn't like
[04:49] <Sledge> but I'll leave that bit to you... :-)
[04:49] <Kamion> so, let's assume that's trivial; it seems to just be that piece plus making mkjigsnap able to do all three arches at once
[04:49] <Sledge> simplest thing is a tweaked mjs with a -d <datestring> option
[04:49] <Kamion> right
[04:50] <Sledge> and of course you don't need to pass all three at once
[04:50] <Sledge> simply run it three times and have it write in the same dir
[04:50] <Sledge> so you scp the jigdo and template files into place, then run sync-auckland
[04:50] <Kamion> hm, does that work? ok
[04:51] <Sledge> it will do a "for file in *.jigdo; do mjs <stuff> ; done"
[04:51] <Sledge> I'll hack on mjs right now for the date and overlay change
[04:51] <Sledge> anything else you'd like?
[04:51] <Sledge> :-)
[04:53] <Kamion> thanks, that sounds sufficient to me
[04:53] <Kamion> mail it to me and I'll pass it straight on to admins@ with a usage note
[04:55] <Sledge> ok
[05:07] <pitti> Mithrandir: have you got a minute for an easy peer review?
[05:10] <rburton> seb128: new SJ if you want it -- fixes HAL build and the memory leaks.
[05:10] <rburton> should mean you can remove your patches
[05:10] <seb128> rburton: oh, nice :)
[05:26] <rburton> seb128: and i'll have a new c-l-a tonight probably which fixes the no sources bug, and a nasty crasher
[05:27] <seb128> cool :)
[05:27] <seb128> rburton: BTW, nice changelog entry for sj :p
[05:27] <carlos> seb128: do you have "my" gstreamer packages to test? :-P
[05:27] <rburton> seb128: :)
[05:28] <seb128> carlos: ?
[05:28] <carlos> seb128: the test packages for the new gstreamer, you said you will add them to be tested and evaluated before asking for inclusion in Warty...
[05:28] <carlos> or did I misunderstood it?
[05:29] <seb128> carlos: I've mailed ubuntu-devel with the url to the packages 4 days ago and uploaded them in warty today
[05:30] <carlos> O:-)
[05:30] <seb128> arf
[05:30] <seb128> and I've given the url on #ubuntu too ... perhaps you need to hang here ? :p
[05:31] <fabbione> GRRR
[05:31] <fabbione> i have been fighting all day to keep RC bugs down to 11
[05:31] <fabbione> as soon as i leave and come back it jumps up to 15
[05:31] <carlos> seb128: :-P
[05:31] <fabbione> :P
[05:31] <fabbione> thom: ping
[05:41] <pitti> carlos: Hi! Any news regarding your updated kernel patch for hfs+ ?
[05:42] <carlos> pitti: I did a new patch
[05:42] <pitti> carlos: I saw it
[05:42] <carlos> pitti: it's working except for the 99 magic behaviour
[05:42] <carlos> because I don't see a way to invalidate the cached inode
[05:42] <pitti> carlos: I saw that too, I think it is right for Linux to skip that
[05:42] <carlos> pitti: at this moment, it should work
[05:42] <pitti> carlos: IMHO it's just not the "Linux way" to have such a mess^Wmagic
[05:43] <carlos> except for that feature
[05:43] <carlos> pitti: but it's the way that filesystem works
[05:43] <carlos> well, it's not completely true
[05:43] <carlos> s:-)
[05:43] <carlos> :-9
[05:43] <carlos> grr
[05:43] <carlos> :-)
[05:44] <carlos> because I suspect that the 99 "magic" is done at system leve instead of the HFS+ driver
[05:44] <Mithrandir> pitti: pong
[05:44] <pitti> carlos: to be honest, I'm not unhappy that it doesn't work :-)
[05:45] <Kamion> I only briefly saw that 99 stuff in scrollback, but it sounds really really evil
[05:45] <pitti> Mithrandir: oh, hi! I would like to upload pmount with #2208 and #2209. Trivial patch, but the rules require a review. Do you have a minute for that?
[05:45] <carlos> pitti: I did also a change that will ignore the uid and gid arguments if the owner in the filesystem is root (not sure if that should be removed, but that's how it works in MacOSX)
[05:45] <Kamion> a near-future release of base-passwd is going to make group 99 be 'users'
[05:45] <Mithrandir> pitti: sure, url?
[05:45] <pitti> Mithrandir: patch is attached to #2208
[05:46] <carlos> pitti: I mean, all files that have an owner != 0 will use the uid argument, if the owner is root, it will be always root
[05:46] <pitti> Mithrandir: https://bugzilla.ubuntulinux.org/attachment.cgi?id=421
[05:46] <Kamion> how exactly are you proposing to use gid 99?
[05:46] <pitti> carlos: but wasn't the complete point of your patch to fix exactly that?
[05:46] <pitti> carlos: or are the files on the iPod usually owned by 99?
[05:47] <carlos> pitti: no, the iPod filesystem has as owner for the files an uid != 0
[05:47] <carlos> pitti: no, at this moment uid = 1000
[05:47] <pitti> carlos: hmm, then it's odd that it didn't work before.. this seems to be the easiest case
[05:47] <carlos> but the .Trashes folder and the .journal and other system files
[05:47] <pitti> carlos: BTW, the apple standard user also has uid=1000?
[05:48] <Mithrandir> pitti: apart from the fact that I think creation of /media belongs in base-files, it looks good to me.
[05:48] <pitti> Mithrandir: I know, and it is in fact done in base-files
[05:48] <carlos> pitti: I think I did not changed since last iPod "reinstall" so yes, seems like Apple uses uid=1000 by default
[05:48] <pitti> Mithrandir: but this was requested for upgrades from woody
[05:48] <Mithrandir> pitti: why not add a versioned dep rather, then?
[05:49] <pitti> Mithrandir: ?
[05:49] <pitti> Mithrandir: to what and for what?
[05:49] <Mithrandir> pitti: doesn't base-files create the directory if it doesn't exist (on upgrades)?
[05:50] <carlos> Mithrandir: no, it never creates it if it's not a new installation
[05:50] <Mithrandir> oh, ok.
[05:50] <pitti> Mithrandir: hmm, I'm not sure any more. Could be that I mixed up b-files with b-config
[05:50] <carlos> Mithrandir: (talking about Debian), not sure if we changed it with Ubuntu
[05:50] <Mithrandir> carlos: sounds like a bug to me.
[05:50] <Mithrandir> but, if it doesn't, it doesn't, so.. patch looks fine to me.
[05:51] <carlos> Mithrandir: it was done that way to prevent it to be created with every update if the sysadmin removes it by hand
[05:51] <carlos> there was a discussion about it in Debian some months ago
[05:51] <pitti> Mithrandir: I looked in base-file's postinst: media is created only on fresh installations
[05:52] <pitti> carlos, Mithrandir: hmm, then pmount would reintroduce this
[05:52] <pitti> Mithrandir: I could change the patch to only create /media if $2 == ""
[05:52] <pitti> Mithrandir: then we would have the same effect, but pmount would not work if the admin removes /media
[05:52] <Kamion> you could easily do it only on upgrades from less than the version that first creates /media
[05:52] <Kamion> dpkg --compare-versions, trivial
[05:53] <Mithrandir> pitti: I don't think so; having the system break horribly if you mess around with system directories is fine, IMHO.
[05:53] <pitti> Kamion: okay, that sounds reasonable
[05:53] <Kamion> if dpkg --compare-versions "$2" lt-nl whatever-version-you-introduce-it-in; then mkdir -m 0755 -p /media; fi
[05:54] <pitti> Kamion: but that reduces the "always override an admin's decision" to "only once override an admin's decision".
[05:54] <carlos> Base-files will not create the directories for /media, /opt and /srv on 
[05:54] <carlos> upgrades and according to the FAQ this is desirable behavior. As an 
[05:54] <carlos> alternative, please provide a script which creates these files or provide 
[05:54] <carlos> instructions on creating them with proper ownership, permissions, etc.
[05:54] <carlos> from #275416 (Debian BTS)
[05:55] <pitti> So can we regard this as a concensus? Attempt to create /media only once?
[05:56] <carlos> pitti: for me, warty should have always /media 
[05:56] <thom> fabbione: pong
[05:56] <carlos> pitti: in Debian it's not needed because we don't have (yet) pmount
[05:57] <Mithrandir> Kamion: 2256 looks like a d-i bug to me.
[05:57] <Kamion> if pmount must have /media, you could just ship /media in pmount.deb
[05:57] <pitti> carlos: well, the Golden Rule...
[05:57] <carlos> if a sysadmin removes it, pmount will be broken
[05:57] <Kamion> pitti: dude, the golden rule still doesn't allow admins to remove /usr :-)
[05:57] <carlos> :-P
[05:57] <pitti> Kamion: but if it already exists? As a symlink? Then package installation would fail, not?
[05:57] <Kamion> true
[05:57] <Mithrandir> pitti: no, it would work.
[05:58] <Kamion> no it wouldn't, dpkg fails in that case
[05:58] <Mithrandir> if it exists as a file, things will blow up.
[05:58] <pitti> Mithrandir: that's why I wanted to do that in the postinst
[05:58] <Kamion> dpkg does not allow overwriting a directory with a symlink or vice versa
[05:58] <pitti> (which is very sane :-) )
[05:58] <Mithrandir> pitti: just ship the directory in the deb.
[05:58] <Kamion> hm, let me check that
[05:58] <pitti> Mithrandir: see above, what if it already exists?
[05:59] <Mithrandir> pitti: dpkg handles that nicely.
[05:59] <Mithrandir> pitti: if the admin has stuck a /media file on his system, well, then it will break.  likewise if he puts a file as /usr/share/doc or a number of other things.
[06:00] <Kamion> however we should be able to operate if /media is a symlink to a directory
[06:00] <pitti> By now I have:
[06:00] <pitti>         if dpkg --compare-versions "$2" lt-nl 0.1-5;
[06:00] <pitti>             [ -e /media ]  || mkdir /media
[06:00] <pitti>         fi
[06:00] <Mithrandir> yes, and dpkg handles that fine.
[06:00] <pitti> Mithrandir: what does dpkg do in this case? Silently not install the directory? Or fail?
[06:01] <Kamion> hm, I think you're right
[06:01] <Mithrandir> not install the directory.
[06:01] <pitti> okay, I try that out.
[06:01] <Mithrandir> Kamion: I've run systems where /var has been a symlink to /usr/var or similar.
[06:01] <Kamion>         if ( mkdir(i->Name, i->Mode & ~S_IFMT) != 0 ) {
[06:01] <Kamion>                 if ( errno == EEXIST ) {
[06:01] <Kamion>                         struct stat s;
[06:01] <Kamion>                         if ( stat(i->Name, &s) != 0 || !(s.st_mode & S_IFDIR) )
[06:01] <Kamion>                                 return IOError(i);
[06:01] <Kamion> but stat() will give S_IFDIR so that's fine
[06:02] <Mithrandir> it confuses maintainers regularly, when they try replacing a symlink with a directory.
[06:02] <Mithrandir> and it doesn't work.
[06:02] <Kamion> in that case shipping /media in pmount.deb is exactly the right thing to do
[06:03] <Mithrandir> Kamion: but, wrt 2256, I think putting localhost first on the line in /etc/hosts is broken.
[06:03] <pitti> Mithrandir, Kamion: I just tried it with /media in the deb, works fine
[06:03] <pitti> Mithrandir, Kamion: thanks a lot!
[06:04] <Kamion> Mithrandir: possibly, kinda scared to change netcfg at this point though!
[06:04] <Kamion> particularly given I don't really know offhand what to change ...
[06:04] <Kamion> you're welcome to look though :)
[06:04] <Mithrandir> Kamion: understandable.
[06:07] <thom> fabbione: poke
[06:10] <pitti> Mithrandir: gosh, the directory is present in <pkgdir>/debian/pmount/, but the created .deb does not contain it. Do you happen to know about any debhelper magic which deletes such directories?
[06:11] <Kamion> you're sure you're using DH_COMPAT >= 2?
[06:11] <Kamion> (or debian/compat)
[06:11] <pitti> Kamion: yes
[06:11] <Mithrandir> hmm.. dpkg doesn't drop empty dirs, does it?
[06:11] <Kamion> shouldn't
[06:11] <pitti> Kamion: debian/compat is 4
[06:11] <Kamion> never has IME
[06:11] <pitti> odd
[06:11] <Kamion> try DH_VERBOSE=1
[06:11] <daniels> i don't believe it does/has
[06:11] <pitti> I didn't bother to look into the deb, I just looked into the package dir below debian
[06:13] <Mithrandir> pitti: I can't duplicate it, by putting a mkdir call in debian/rules
[06:15] <Kamion> Mithrandir: linux-restricted-modules failed to build, in case you hadn't noticed
[06:15] <pitti> Mithrandir: odd. Well, I will try some other methods. BTW, the package which does not include it is on www.piware.de/pmount/
[06:15] <Mithrandir> Kamion: argh
[06:15] <Mithrandir> mdz is going to kill me
[06:18] <pitti> Mithrandir: don't bother. It's actually a bug in midnight commander, it just does not display the media directory, but it's there
[06:18] <pitti> Mithrandir: sorry about the fuss! I'm going to fetch my brown paperbag now...
[06:18] <Mithrandir> pitti: oh, ok.
[06:21] <Mithrandir> I SUCK
[06:21] <Mithrandir> badly.
[06:22] <Mithrandir> I'm going to make some food, then fix the restricted modules
[06:27] <daniels> could someone please review http://people.ubuntu.com/~daniels/dbus/ ? fixes the problem whereby dbus-monitor segfaulted.  a lot. (probably need some dbus experience here)
[06:32] <daniels> likewise g-v-m at http://people.ubuntu.com/~daniels/g-v-m/
[06:32] <daniels> (the g-v-m stuff should enable proper gthumb support for cameras which do usb mass storage instead of proprietary protocols, and seems to work fine here)
[06:32] <daniels> (dbus wfm also)
[06:33] <pitti> daniels: oh, I also attached an interdiff to #1292 for the same problem
[06:33] <pitti> daniels: do you have an interdiff?
[06:33] <Mithrandir> I suck so badly I don't have words for it.
[06:33] <daniels> ah
[06:34] <daniels> pitti: interdiff is up now
[06:35] <pitti> daniels: this is Sjoerd's patch, AFAICS
[06:35] <daniels> pitti: oh, didn't see your interdiff in the bug
[06:35] <daniels> pitti: yeah, sjoerd's patch plus unbreaking the @#($ clean target
[06:35] <pitti> daniels: I moved the wrapper into /usr/lib/g-v-m and called gthumb with 'exec'. What do you think?
[06:35] <pitti> daniels: ah, fixing the clean target is a good idea
[06:35] <pitti> daniels: we should merge this
[06:35] <daniels> pitti: um, the wrapper should be /usr/share/g-v-m
[06:35] <daniels> pitti: give me a sec
[06:35] <pitti> daniels: oh, right
[06:36] <sjoerd> daniels,pitti: patch for me somewhere :) ?
[06:36] <pitti> daniels: BTW, if the patch already deletes gmo files, it could as well delete them all
[06:38] <pitti> sjoerd: we are using your patch for g-v-m and gthumb, but slightly modified it
[06:38] <pitti> daniels: your interdiff does not contain the gmo deletion
[06:38] <daniels> pitti: new interdiff/sources up
[06:38] <daniels> pitti: the deletion is done in debian/rules
[06:39] <daniels> pitti: be sure to look at ubuntu3-to-ubuntu4, not ubuntu2-to-ubuntu3
[06:40] <pitti> daniels: ah, I looked at the wrong file
[06:40] <pitti> daniels: why do you install the wrapper as 644? It should be executable, or not?
[06:40] <sjoerd> pitti: improvements are always welcome 
[06:41] <pitti> daniels: can you attach the updated interdiff to #1292, for mdz's approval?
[06:41] <daniels> pitti: sure
[06:41] <daniels> pitti: er, right, my bad
[06:42] <Mithrandir> could somebody look at and test http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff ?
[06:42] <daniels> pitti: good catch, thanks
[06:43] <pitti> daniels: now it looks fine to me
[06:47] <daniels> pitti: thanks
[06:47] <pitti> daniels: well, let's call it "peer review" instead of "redundant work" :-))
[06:48] <daniels> heh!
[06:48] <daniels> pitti: sorry, I had no idea you were working on it
[06:49] <daniels> pitti: i scrounged around on the BZ, but couldn't find anything
[06:49] <pitti> daniels: dame for me :-)
[06:49] <pitti> daniels: same, of course
[06:49] <daniels> can people please test cameras in g-v-m with http://people.ubuntu.com/~daniels/g-v-m/ ?
[06:49] <daniels> usb mass storage cameras should now work fine
[06:49] <pitti> daniels: I tested with my gphoto camera and MS, both work fine
[06:49] <daniels> pitti: well, I'm off to bed, it's 0252 here and in making the last source package I mistyped my GPG password about 5 times
[06:49] <daniels> pitti: cool
[06:50] <pitti> daniels: BTW, did you get two dialog boxes, too?
[06:50] <pitti> daniels: for a gphoto cam?
[06:50] <daniels> pitti: er, just the one
[06:51] <daniels> i'll have to debug it in the morning, though
[06:51] <sjoerd> Sjrd Simons ? :)
[06:51] <daniels> is it sjoerd rather than sjrd?
[06:51] <daniels> oh yeah
[06:51] <sjoerd> yeah
[06:51] <daniels> god, now I'm getting you mixed up with jrg schilling
[06:51] <daniels> sjoerd: sorry about that :\
[06:51] <sjoerd> pitti: you get one from gvm itself and one from gphoto (search the cam)
[06:52] <Mithrandir> Kamion: could you look at http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff , please?
[06:52] <thom> oh man, mortal insult
[06:52] <Kamion> Mithrandir: looked at it a moment ago, seemed fine to me, don't have time to do a test build though :-/
[06:52] <sjoerd> daniels: hopefully only in name, not in image 
[06:52] <daniels> sorry, updated sources up
[06:52] <pitti> sjoerd: I got the "would you like to import the photos" with OK and Cancel twice
[06:52] <Mithrandir> Kamion: ok :/
[06:52] <daniels> thom: you know it's really time to go to bed when ...
[06:52] <pitti> sjoerd: I suppose this is a hal bug since the camera creates two nodes
[06:53] <daniels> sjoerd: updated sources up -- sorry again about that
[06:53] <daniels> 'nacht
[06:53] <Kamion> can anyone review the patch in https://bugzilla.ubuntu.com/show_bug.cgi?id=993, please?
[06:53] <Kamion> (grub-installer menu/timeout stuff for dual-booters)
[06:54] <sjoerd> pitti: maybe a hal-hotplug-map bug..
[06:54] <sjoerd> daniels: np
[06:54] <pitti> sjoerd: I suppose
[06:55] <pitti> sjoerd: I have a camera node and a PTP node
[06:55] <pitti> sjoerd: I suppose hal regards both as a camera
[06:55] <sjoerd> pitti: check the info.category props if any
[06:56] <thom> Kamion: looks reasonable to me
[06:56] <daniels> Kamion: the only note would be that if that was called outside of d-i, it would break on /target != /
[06:56] <daniels> Kamion: other than that, looks good to me.
[06:56] <Kamion> sure, but grub-installer never will be
[06:56] <pitti> Kamion: the sed's look a bit scary and the second one could be made a bit easier with \+ instead of *, but otherwise it looks as if it does what it should
[06:56] <Mithrandir> Kamion: the busybox sed supports [:space:] ?
[06:56] <daniels> Kamion: oh, grub-installer, not grub.  phat.
[06:56] <Kamion> pitti: according to regex(7) \+ does not exist
[06:56] <Kamion> Mithrandir: yep - tested and everything
[06:57] <Mithrandir> then it looks good to me.
[06:57] <pitti> Kamion: oh, it's a GNU extention
[06:57] <daniels> Kamion: if busybox sed supports -i, that might be more elegant, but meh
[06:57] <Kamion> pitti: ah, it does seem to work in GNU sed
[06:57] <Kamion> dunno about busybox, didn't try
[06:57] <Kamion> does seem to work in busybox, oh well
[06:58] <Mithrandir> . o O ( busybox perl )
[06:58] <thom> damn, the subversion test suite takes forever
[06:58] <Kamion> daniels: apparently not
[06:58] <pitti> Kamion: BTW, it does not allow spaces in front of the keywords, but I suppose this cannot happen since the installer uses a file from scratch, right?
[06:58] <Kamion> pitti: right, it's called update-grub immediately beforehand
[06:58] <Mithrandir> thom: care to look at http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff , then, since you're idling anyhow? :)
[06:58] <Kamion> daniels: (unfortunately)
[06:59] <daniels> Kamion: much of a muchness, I'm used to the < foo > foo.ish && mv foo{.ish,} notation anyhoo
[06:59] <Kamion> yeah, it was stolen from immediately above in that script anyway :)
[07:00] <thom> Mithrandir: dumbass :-) looks reasonable
[07:00] <Mithrandir> thom: can you test it as well, to make sure I haven't fucked up?  I'd _hate_ to have two brown bag releases after each other. :)
[07:00] <thom> heh
[07:01] <thom> geez, i spose
[07:02] <sjoerd> time to eat
[07:03] <thom> Mithrandir: it'll have to wait till after the svn test suite, since i'm in x86 mode currently
[07:03] <Mithrandir> that's fine. :)
[07:34] <thom> 25 minutes for a full install. pretty good
[07:38] <thom> Mithrandir: well, that built
[07:39] <Mithrandir> thom: can you try to build on an i386 as well?
[07:42] <thom> gar
[07:42] <thom> that means rebooting again, you git :-)
[07:48] <Mithrandir> thom: I'll buy you beer
[07:50] <sabdfl> mdz: so... in the "big changes at the last minute to mission critical software" dapartment...
[07:51] <sabdfl> s/dap/dep/
[07:51] <sabdfl> i just learned that there is such a thing as PL?Python for POstGres
[07:51] <sabdfl> thom: nice duck on the epoch there, well done :-)
[07:53] <thom> sivang: poor deluded fool :-)
[07:54] <pitti> thom: hey, PostgreSQL _is_ nice!
[07:54] <pitti> let's start a flamewar (or better not...)
[07:54] <Kamion> sabdfl: current daily should be worth testing for ipw2[12] 00 support in the installer
[07:55] <sabdfl> kamion: will o
[07:55] <sabdfl> right o, will do, pick one
[07:55] <Kamion> doesn't seem to work with my acx card, but I think that's a driver issue rather than broken firmware support
[07:55] <Kamion> the firmware does get loaded according to syslog, but then it can't actually talk to anything - shrug, it's a cheapo card
[07:56] <sabdfl> ok.... command to detach from a screen session?
[07:56] <Kamion> C-a d
[07:57] <sabdfl> while it comes down... do we have an rsync module that is just the warty / hoary release / preview cd's, install and live, as discussed?
[07:57] <Kamion> not yet, I'm still due to talk with elmo about implementing that
[07:57] <Kamion> before Wednesday ...
[07:57] <sabdfl> yup.
[07:58] <sabdfl> well, tomorrow, for mirrors that can respond quickly
[07:58] <Kamion> ok, noted
[07:59] <Kamion> right, the acx card doesn't work in an installed system either, so not a d-i bug; good
[07:59] <sivang> thom : quite deluded (I caught up this virus that doesn't let go) yeah :) however one cannot not notice the license differences between the two ;-)
[08:00] <thom> sabdfl: see my email to you/lu about expires?
[08:00] <pitti> sivang: is your only concern about my/postgresql license stuff?
[08:00] <sivang> pitti : ofcourse not :)
[08:00] <sabdfl> thom not yet... catching up
[08:01] <thom> sivang: frankly, i prefer a db that cares about upgradability to a nicely licensed one *shrug*
[08:02] <thom> sabdfl: gosh, quick turnaround... d'you fancy issuing a "please make firefox less buggy" bounty? :p
[08:02] <sabdfl> thom: i considered asking the mozilla guys to get off their asses on the RC bugs we had, given the other support i've given them
[08:02] <azeem> easy. ln -s /usr/bin/epiphany /usr/bin/mozilla-firefox :)
[08:02] <sabdfl> but the list looked too long, and there were probably more lurking in there
[08:03] <Mithrandir> thom: you're happy with the package?
[08:03] <sabdfl> azeem: agreed, if epiph had the same feature set i'd back a native app any day
[08:03] <thom> Mithrandir: yes, it seems fine (I can't actually test any of the contents)
[08:04] <thom> sabdfl: yeah, it's unfortunate in the extreme that bug list seems to be growing as they near 1.0 :(
[08:04] <sabdfl> thom: inevitable with a psych milestone like 1.0, everyone wants their favourite patch to land
[08:05] <thom> yeah
[08:06] <Mithrandir> thom: ok, I'll build and upload, then.  Thanks for testing.
[08:14] <thom> Mithrandir: care to look at https://bugzilla.ubuntu.com/show_bug.cgi?id=2259#c2 by way of a swap? :-)
[08:19] <Mithrandir> thom: the patch from http://svn.collab.net/viewcvs/svn/branches/1.0.x/subversion/libsvn_subr/cmdline.c?rev=11018&r1=8524&r2=11018 seems like happiness to me.
[08:22] <thom> ta
[08:28] <Kamion> the patch is large due to *.po updates; the actual text under review is right at the end
[08:39] <Kamion> thom: did you mean to close #2259 too?
[08:48] <Mithrandir> elmo_: could you please adjust PaS for linux-restricted-modules-2.6.8.1?  It should be built on amd64 as well
[08:56] <elmo_> Mithrandir: as I told you the other day, it's not in p-0a-s
[08:56] <elmo_> Mithrandir: and you broke the i386 build
[08:56] <elmo_> linux-restricted-modules-2.6.8.1_2.6.8.1.3-2_i386.changes
[08:56] <elmo_> REJECT
[08:56] <elmo_> Rejected: nvidia-glx_1.0.6111-1ubuntu5_i386.deb: old version (1.0.6111-1ubuntu5) in warty >= new version (1.0.6111-1ubuntu5) tar
[08:56] <elmo_> geted at warty.
[08:56] <elmo_> etc. 
[08:58] <Mithrandir> elmo_: I didn't see that.
[08:59] <elmo_> you wouldn't - it wasn't the sourceful upload
[08:59] <Mithrandir> and, that was what mdz talked about. aaargh.
[08:59] <elmo_> yeah, even herbert himself gets bitten by that bug
[09:00] <Mithrandir> I'm beginning to hate that package.  A lot.
[09:01] <mdz> sabdfl: Python procedures in postgresql sounds very cool
[09:03] <mdz> Mithrandir: I had already tested that gzip change on your workstation
[09:03] <mdz> it does fix the bug
[09:03] <Mithrandir> mdz: ok, I'm installing a dual celeron now to see if I can reproduce it there.
[09:03] <Mithrandir> http://raw.no/patches/linux-restricted-modules-2.6.8.1.3-3.versionbump.diff <-- somebody please review?
[09:04] <mdz> fabbione ph33rz my gzip patch
[09:05] <mdz> Mithrandir: looks good
[09:05] <mdz> Mithrandir: that's what I did after I broke it
[09:05] <mdz> Mithrandir: and what Herbert did after he broke it
[09:06] <mdz> but it would be nice if someone would fix it permanently :-)
[09:06] <Mithrandir> how to fix it permanantly?  Store the version number in a file somewhere?
[09:06] <mdz> something like that, to allow for an error if you forget to update the other one
[09:06] <mdz> but don't let that delay your quick fix
[09:07] <mdz> pitti: your interdiff in #2208 looks good
[09:07] <doko> kamion: #1232 please feel free to reassign it to you, I just synced the translations from unstable and waited for some feedback.
[09:07] <elmo_> gst-plugins0.8 FTBFS on amd64
[09:08] <mdz> seb128: ^^^
[09:08] <Mithrandir> mdz: ok, thanks, uploaded.
[09:08] <seb128> mdz: ok
[09:08] <seb128> I'll have a look
[09:08] <mdz> elmo_: have you been brave enough to put the gzip fix on emperor?
[09:08] <elmo_> mdz: emperor?
[09:08] <elmo_> you mean jackass?
[09:09] <Mithrandir> mdz: we could take the revision number from l-r-m, s/-/./ and use that after ubuntu in the nvidia-glx version number
[09:09] <Kamion> mdz: thom installed the gzip fix on little, it fixed the hangs that reliably scuppered the 20041010 and 20041011 CD builds
[09:09] <elmo_> REJECT
[09:09] <elmo_> Rejected: libglib2.0-udeb_2.4.7-0ubuntu1_x86_64.udeb: architecture part of filename (x86_64) does not match package architecture
[09:09] <elmo_>  in the udeb (amd64).
[09:09] <elmo_> hmm...
[09:09] <pitti> mdz: great, can I regard this as approval?
[09:10] <Mithrandir> would give us 1.0.6111-1ubuntu2.6.8.1.3.3
[09:10] <Mithrandir> ugly, but should work.
[09:10] <mdz> pitti: yes
[09:10] <Mithrandir> or ubuntu+restricted+2.6.8.1.3+3
[09:10] <mdz> elmo_: lamont mentioned the same thing
[09:10] <mdz> elmo_: where did it come from?
[09:11] <elmo_> mdz: dunno - other amd64 udebs have been built since without such fucked filenames
[09:11] <elmo_> hmm, on a different host tho
[09:12] <Mithrandir> bug in libglib?
[09:13] <amu> guess the problem comes from uname : Linux amu.debian.net 2.6.8-3-amd64-k8 #1 Mon Aug 30 01:09:23 CEST 2004 x86_64 GNU/Linux
[09:14] <mdz> Kamion: thanks for taking care of #993, one FAQ down
[09:14] <mdz> but surely we've built libglib before
[09:14] <mdz> successfully
[09:14] <mdz> amu: hey, welcome
[09:15] <amu> mdz: *hi*
[09:16] <seb128> hum
[09:16] <seb128> for the udeb problem:
[09:16] <seb128> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275419
[09:16] <seb128> DEB_BUILD_GNU_CPU -> DEB_BUILD_ARCH
[09:16] <seb128> has been made by JHM
[09:16] <elmo_> yeah
[09:16] <elmo_> udebname=libglib$(apiver)-udeb_$(debversion)_$(shell dpkg-architecture -qDEB_BUILD_GNU_CPU).udeb
[09:21] <mdz> ick
[09:21] <elmo_> why on earth does DEB_BUILD_ARCH return 'i386' on hurd anyway?  that's so not the "Debian architecture of the build machine"
[09:23] <sabdfl> Kamion: didn't work with the ipw2200 test laptop :-(
[09:23] <sabdfl> this with the latest daily
[09:23] <elmo_> azeem: ?
[09:23] <Mithrandir> this is fun, grub is broken on this system.
[09:24] <Mithrandir> hangs on "GRUB loading, please wait"
[09:24] <amu> elmo_: http://lists.debian.org/deity/1999/06/msg00041.html 
[09:26] <elmo_> amu: whiuch is why 275419 doesn't make any sense
[09:27] <Mithrandir> heh, seems like the hpt366 controller fucks with grub.
[09:27] <mdz> elmo_: jackass, whatever
[09:28] <mdz> elmo_: I don't suppose you had a reliable way to reproduce it on that machine?
[09:28] <mdz> if you haven't upgraded it already, it might be worthwhile to try to apt-extracttemplates test
[09:28] <mdz> and then upgrade it and verify the fix
[09:28] <Mithrandir> Kamion: wantabug? :)
[09:28] <elmo_> mdz: it's running UP now, so the issue's latent
[09:29] <elmo_> and I'm so not rebooting that box again :-P
[09:29] <amu> elmo_: sorry I just read with one eye and till reading the mail, finally i thing problem comes from dpkg *ducks* 
[09:30] <mdz> elmo_: what went wrong with it last night?
[09:30] <elmo_> mdz: our kernel breaks if you add just 'nosmp' to the command line - it needs 'nosmp noapic'
[09:31] <mdz> elmo_: but a UP kernel boots fine without noapic?
[09:32] <mdz> amu: where can I download the ubuntu/gnoppix iso?
[09:32] <azeem> elmo_: yeah?
[09:32] <elmo_> mdz: I suspect so, but dunno for sure - I didn't want to experiment at the time (4am and all) - I'll do so next time I'm there on a less critical machine, and file a bug if so
[09:33] <elmo_> azeem: what's dpkg-architecture -qDEB_BUILD_ARCH return on hurd-i386 for you? 
[09:33] <azeem> hmm, one sec
[09:34] <pitti> sjoerd: still here?
[09:34] <sjoerd> pitti: somewhat yes
[09:34] <mdz> Kamion: I thought base-config already did mention sudo
[09:35] <pitti> sjoerd: I'm just at debugging the double camera dialog bug
[09:35] <amu> mdz: ;) http://www.gnoppix.org/pages/downloads/index.html Telefonica is probably the best connected  
[09:35] <azeem> 21:33 < jbailey> azeem: hurd-i386
[09:35] <azeem> :)
[09:35] <azeem> elmo_: ^--
[09:35] <pitti> sjoerd: I have two devices: the camera itself (with info.capabilities = camera and camera.libgphoto2_support = 1) and an "USB PTP Interface" with just the camera capability.
[09:36] <elmo_> azeem: thanks
[09:36] <pitti> sjoerd: what do you think: shall hal be fixed to report just one device as camera?
[09:36] <amu> btw. hi azeem 
[09:36] <elmo_> gar, I misread the bug - it's fine, we just need the same fix in our glib2.0
[09:36] <pitti> sjoerd: or shall we fix g-v-m to additionally check for camera.libgphoto2_support or camera.access_method?
[09:36] <azeem> elmo_: any other questions, otherwise I could summon jbailey
[09:36] <elmo_> azeem: nah, that's cool thanks
[09:36] <sjoerd> pitti: can you put lshal of that somewhere ?
[09:36] <mdz> Kamion: I think the text can be a bit less scary
[09:37] <seb128> elmo_: I'll fix it
[09:37] <elmo_> seb128: cool
[09:37] <azeem> amu: hey. noel just said you'll be in Frankfurt/LWE. I'll probably drop by as well :)
[09:37] <pitti> sjoerd: http://www.piware.de/lshal.cam
[09:37] <sjoerd> pitti: who is setting the camera only capability btw.. the hotplug map callouts always sets both 
[09:38] <pitti> sjoerd: I know, and in fact both nodes are valid to have a camera capability
[09:38] <pitti> sjoerd: because this camera can be used with the traditional gphoto access, and also with the newer PTP interface
[09:39] <sjoerd> pitti: one node is PtP the other is proprietary something ?
[09:39] <sabdfl> mdz: which scary text?
[09:40] <pitti> sjoerd: yes, historically every camera had its own access method, but the PTP is a common standard now
[09:40] <mdz> sabdfl: https://bugzilla.ubuntu.com/attachment.cgi?id=427
[09:41] <sjoerd> pitti: i've got a cam which can do multiple modes too (ptp and mass storage), but you need to choose one 
[09:42] <pitti> sjoerd: I'm currently not sure whether this is a hal or a g-v-m bug
[09:42] <Mithrandir> mdz: fwiw, can't reproduce the problem on dual celeron 466.
[09:43] <sjoerd> pitti: the second udi is the parent of the first.. so apperently capabilities go down to the children
[09:43] <Mithrandir> (sorry, dual 433)
[09:43] <pitti> sjoerd: my inclination is currently to fix that in g-v-m and choose the preferred interface there
[09:44] <pitti> sjoerd: both work; I can either cancel the first message box and accept the second, or the other way round
[09:44] <pitti> sjoerd: however, in the long run we should prefer the PTP protocol
[09:45] <Mithrandir> mdz: so, even though it's a bug in gzip, I also think it exposes a timing issue with HT, but I guess we should let it just be closed with the new gzip.
[09:45] <pitti> sjoerd: maybe hal shouldn't attach a camera capability for both a parent and a child node... This is so arbitrary...
[09:45] <amu> azeem: unfortunatley not, the government put me on jail :) too many guys go to lwe so i can make some nice days with hot ........ supportcalls :)  
[09:45] <sjoerd> pitti: i find it strange that the hotplug map callout has put the stuff on the parent, not on the child
[09:45] <sjoerd> pitti: also not the info.bus prop on both devices
[09:46] <mdz> Mithrandir: Herbert's comment on the bug is informative
[09:46] <sjoerd> pitti: i'm watching ST for a while, i'll have a real look afterwards :)
[09:46] <pitti> sjoerd: oh, have fun!
[09:46] <Mithrandir> mdz: yeah, but I somehow think it should have been exposed on this system as well.
[09:47] <Mithrandir> anyhow, I need sleep.
[09:47] <pitti> sjoerd: both nodes have identical product and vendor ids, so both are recognized by hal's hotplug_map
[09:47] <mdz> Mithrandir: night
[09:49] <sjoerd> pitti: maybe we need to fix hotplug_map to only set it on the node with info.bus == usb
[09:49] <sjoerd> pitti: need to test with my own cam to see how that behaves
[09:50] <pitti> sjoerd: I just noticed that we don't need to prefer a volume anyway, because gthumb will choose
[09:50] <lamont> moo
[09:51] <pitti> sjoerd: I would prefer not to set camera if the parent already has a camera capability
[09:51] <pitti> sjoerd: this seems more robust than selection by bus
[09:52] <lamont> elmo_: nvidia-glx was what you were mentioning just a bit back, yes?
[09:52] <sjoerd> pitti: i'll have a good look in 45 min. :) but that capability i'm currently guessing the capability on the parent is wrong
[09:53] <pitti> sjoerd: okay, I won't disturb you any further. ST^Weducation is important :-)
[09:53] <sjoerd> pitti: :)
[09:53] <mdz> can someone peer-review https://bugzilla.ubuntu.com/attachment.cgi?id=428&action=edit
[09:53] <mdz> ?
[09:54] <mdz> or rather, https://bugzilla.ubuntu.com/attachment.cgi?id=428
[09:55] <lamont> hrm...  OO.o build-depends a universe package.
[09:55] <lamont> (libaltlinuxhyph-dev)
[09:57] <doko> mdz: #2256, is the changed nsswitch.conf a better default?
[09:59] <lamont> mdz: gzip patch looks sane to me.
[10:09] <elmo_> lamont: yes
[10:09] <mdz> doko: why did you upgrade 2256 after I downgraded it?
[10:12] <doko> mdz: did I upgrade it? not by intent
[10:13] <mdz> doko: must have been a mid-air collision
[10:14] <doko> anyway, what about the suggested solution?
[10:15] <mdz> doko: not for warty
[10:16] <sabdfl> Kamion: it didn't detect my ipw2200 card
[10:17] <sabdfl> but if i switch to vc3 and modprobe ipw2200
[10:17] <sabdfl> then go back and rerun network hardware detection
[10:17] <sabdfl> it works
[10:17] <sabdfl> peachily
[10:17] <sabdfl> do you need lspci details?
[10:21] <sjoerd> pitti: weird i only get the capability on the parent 
[10:21] <pitti> sjoerd: so the child doesn't have vendor and product id?
[10:22] <sjoerd> pitti: it does.. but it's not hotplug_map that's setting the stuff on the child..
[10:22] <sjoerd> pitti: on your system thatis
[10:23] <pitti> sjoerd: not?
[10:23] <pitti> sjoerd: oh, I thought it was because the child and parent have identical vendor and product ids
[10:23] <sjoerd> pitti: if hotplug_map sets camera it also sets camera.access_method and camera.libgphoto2_support
[10:25] <pitti> sjoerd: ah, you are right
[10:25] <pitti> sjoerd: that would mean that hal can now detect cameras on its own?
[10:25] <pitti> sjoerd: ah, I think I know what's going on:
[10:26] <pitti> sjoerd: previous ubuntu versions added some fdi files for the A70 (I have that) and some other cameras which also add some attributes
[10:26] <sjoerd> ah.. so the capability comes from the fdi file
[10:27] <pitti> sjoerd: so I guess I just have to delete the fdi files; they are obsolete anyway
[10:28] <sjoerd> pitti: yeah that will fix it.. I'm now trying to find out why it's on the parent and not on the child
[10:28] <sjoerd> pitti: but that doesn't matter for g-v-m
[10:29] <pitti> sjoerd: right
[10:29] <pitti> sjoerd: nice that the solution is so trivial... :-)
[10:29] <sjoerd> hmm it seems that hotplug_map only does devices on bus usb_device
[10:32] <sabdfl> mdz: attachment#427 looks good to me
[10:33] <sjoerd> pitti: bah the hotplug maps don't have the info to choose one interface..
[10:34] <pitti> sjoerd: exactly, they only rely on product/vendor id presence
[10:34] <sjoerd> pitti: so we can't easily improve it, but removing the fdi's will help :)
[10:34] <pitti> sjoerd: that's why I thought that the error was there
[10:36] <sjoerd> pitti: for the right fix you probably have to call libgphoto itself to probe.. but as g-v-m doesn't provide the device to gthumb anyway this works..
[10:36] <sjoerd> suck when having multiple ptp cams attached though
[10:36] <pitti> sjoerd: why, each one should have its own device
[10:36] <sjoerd> pitti: you but gthumb will scan and find both, while it should just open the one you just plugged in
[10:37] <pitti> sjoerd: ah, right
[10:37] <pitti> sjoerd: so in the future, gthumb should get an (optional) parameter which device to scan
[10:38] <sjoerd> pitti: the future is in the libgphoto dbus service, so things will change anyway
[10:39] <sjoerd> i've got the same problem with sound-juicer though
[10:40] <mdz> sabdfl: I thought the bit about damaging your system was unnecessary; every single user is shown this message, even those who don't know what a command line is
[10:40] <sabdfl> ah, ok, agreed
[10:41] <sabdfl> is this on an existing prompt, btw, or a new one?
[10:41] <sjoerd> pitti: btw i was wondering how ubuntu handles cdrw on which you want to burn something new ?
[10:41] <pitti> sjoerd: the ubuntu version of n-c-b unmounts the cd before burning
[10:41] <sabdfl> either way, we are still going to get a lot of questions, because the 3l33t users who go for root immediately won't read anything we put on the screen during install :-)
[10:42] <sjoerd> pitti: ah nice ;)
[10:42] <mdz> sabdfl: this is an appended paragraph to an existing dialog
[10:42] <sabdfl> ok
[10:42] <sabdfl> thanks
[10:42] <mdz> Kamion: where do we stand on the kernel metapackages at install time?  that's very important for the release
[10:43] <pitti> sjoerd: want the patch?
[10:43] <sjoerd> pitti: did you send pci_pre_process_check_null.patch hal patch upstream ? it was the only one that wasn't in CVS yet
[10:44] <pitti> sjoerd: actually I sent all patches to David
[10:44] <pitti> sjoerd: he ack'ed most of them to me, but this patch came in a separate mail
[10:44] <pitti> sjoerd: so maybe he forgot about it
[10:44] <sjoerd> pitti: could be, i noticed it yesterday when i was integrating ubuntu's hal changes
[10:45] <pitti> sjoerd: oh, did you? Thanks
[10:45] <pitti> sjoerd: it's a pain to apply the ubuntu changes to new upstream/debian versions
[10:45] <sjoerd> pitti: guess you need to remind him :)
[10:45] <pitti> sjoerd: will do
[10:46] <pitti> sjoerd: I will ask him to remove the remaining camera fdi file as well
[10:46] <mdz> pitti: patch for #1292 looks good
[10:46] <sjoerd> pitti: ross maintains n-c-b, so maybe he would like the patch 
[10:46] <pitti> mdz: okay; daniels grabbed the bug in the meantime, so I'm not sure whether I shall upload it
[10:47] <mdz> pitti: have you tested it very thoroughly and to your satisfaction?
[10:47] <mdz> I am not entirely certain that it should go into warty
[10:47] <pitti> mdz: well, I tested it with the two devices that I have, and daniels tested with his'
[10:48] <pitti> mdz: so far it worked well and the patch looks straightforward
[10:48] <pitti> mdz: it is not elegant though (this required modification of g-v-m)
[10:48] <pitti> sjoerd: my new hal package works fine!
[10:48] <mdz> pitti: did anyone test for regressions with non-usbstorage cameras?
[10:49] <pitti> mdz: I have a gphoto camera, works fine
[10:49] <pitti> mdz: daniels, too
[10:50] <sjoerd> pitti: hehe, good thing i didn't put your fdi's in the debian packages :)
[10:51] <pitti> mdz: in fact the very same camera now works even better with the new hal package in #2264. Even easier patch :-)
[10:51] <pitti> sjoerd: right :-) But there's still one camera fdi in upstream
[10:51] <sivang> pitti : finally my USB Key works. thanks :-) (just retested)
[10:52] <pitti> sivang: finally some good news. thanks :-)
[10:52] <sjoerd> pitti: that has <match key="info.bus" string="usb_device">
[10:52] <sjoerd> pitti: so that will work
[10:52] <sivang> pitti : I had tested almost every time you published a patch, is is now working consitently :)
[10:52] <pitti> sjoerd: okay, but it is not really required any more anyway
[10:53] <sjoerd> pitti: true
[10:53] <pitti> sivang: nice to hear that two times before a release deadline :-)
[10:54] <pitti> mdz: patch for #2264 just reverts some supplemental fdi files that were introduced with an earlier warty version. Can I upload this?
[10:54] <sivang> pitti : my _pleasure_
[10:58] <sjoerd> pitti: http://luon.net/~sjoerd/hal/hal-0.2.98/ contains the latest debian hal packages (which is still stuck in NEW :( )
[11:01] <mdz> pitti: I'm making my way through my warty-bugs mailbox; just saw that one
[11:02] <pitti> sjoerd: just looked at the changelog, nice :-)
[11:03] <pitti> sjoerd: do you consider to add the "run as user" option as well? (With default file)
[11:03] <pitti> sjoerd: with default off for Debian, of course
[11:03] <sjoerd> pitti: i knew i forgot something :)
[11:04] <Kamion> sabdfl: yes please, send 'lspci' and 'lspci -n' output and I'll make it work
[11:04] <pitti> sjoerd: BTW, I made another change to the hal package which could interest you
[11:04] <Kamion> mdz: ok, happy to drop the "use this with caution" sentence; is it OK apart from that?
[11:04] <pitti> sjoerd: somehow the hal daemon isn't stopped if the package is upgraded, so the old process continues to run
[11:05] <sjoerd> pitti: that should be fixed in the debian package too
[11:05] <pitti> sjoerd: I fixed this by stopping hald already in the preinst (which seems to work fine)
[11:05] <Kamion> mdz: base-installer's on my list for tomorrow, honest :)
[11:05] <sjoerd> pitti: the debian package stops dbus in preinst now
[11:06] <sabdfl> Kamion: on its way
[11:06] <pitti>     # already stop hald before upgrading the package; this fails in the postinst
[11:06] <pitti>     start-stop-daemon --quiet --stop --oknodo --exec /usr/sbin/hald
[11:06] <pitti> fi
[11:06] <pitti> Oops, sorry, this should all go to sjoerd...
[11:06] <mdz> Kamion: yes, sudo text is fine with me with that change
[11:07] <mdz> Kamion: at this point, I'd be more than happy to add a super-magic-uuid-token to the description of the linux-foo packages for base-installer's sake
[11:07] <mdz> Kamion: and fix it better for Hoary
[11:08] <sivang> mdz : I'm starting work on the GNOME 2.8 manual for Ubuntu, I'm concerned about copyrights - which can I drop, which to change etc?
[11:09] <sivang> mdz : it's copyrighted Sun Microsystems.
[11:10] <pitti> sjoerd: did you fix the partition detection in Debian?
[11:10] <sjoerd> pitti: debian/patches/fs_probing.patch
[11:11] <Kamion> mdz: why don't I just grep for the ones we know are ours for warty?
[11:11] <Kamion> i.e. big hardcoded list
[11:11] <sjoerd> pitti: upgrades volume_id to the cvs version, which contains somewhat more fixes then just part. detection
[11:11] <Kamion> sivang: you need to have a very careful basis for your argument before dropping any copyright notices
[11:11] <pitti> sjoerd: yeah, I saw these patches
[11:11] <Kamion> sivang: if you want to drop a copyright notice, you must be sure that you've removed everything significant written by that copyright holder
[11:12] <pitti> sjoerd: otherwise I did not find anything, apart from the default file both packages are relatively close
[11:12] <sjoerd> pitti: when the pkg-utopia project on alioth, i'll put the hal and g-v-m packages in svn. Should make cooperating easier
[11:12] <sivang> Kamion : I see then. Keep sun's copyright notice, add our own?
[11:13] <Kamion> sivang: that would be normal practice
[11:13] <sivang> Kamion : or "Portion Copyright Ubuntu Linux" ?
[11:13] <sivang> Kamion : Portion(s)
[11:13] <Kamion> "Copyright (c) 2004 Canonical Ltd." is what I've been adding
[11:13] <Kamion> (or equivalent)
[11:13] <sivang> Kamion : ok, thanks!
[11:13] <Kamion> since you don't work for Canonical, perhaps "Copyright (c) 2004 Sivan Green" would be more appropriate
[11:13] <mdz> Kamion: that's fine with me
[11:14] <mdz> Kamion: but when I suggested that the last time, you sounded less than enthusiastic :-)
[11:14] <Kamion> you shouldn't say copyright some other organization unless you have an employment contract with them specifying copyright ownership, or you've filled out copyright assignment papers
[11:14] <Kamion> mdz: I am less than enthusiastic, but what works wins right now
[11:15] <mdz> wow
[11:15] <mdz> over 100 live CD downloads in the past 24 hours
[11:15] <mdz> via bittorrent alone
[11:15] <sivang> Kamion : however , if this document needs to be defendent at court, I think canonical copyright is better.
[11:16] <mdz> Kamion: agreed
[11:16] <sivang> Kmaion : I've read on the GNOME devels guidelines that regarding to Ximian
[11:16] <Kamion> sivang: unless you have a contract, Canonical has no right to defend it in court *anyway*.
[11:16] <Kamion> sivang: use your own name.
[11:16] <sivang> Kamion : Oh
[11:16] <Kamion> (since we're not the copyright holder unless you legally assign the copyright to us)
[11:17] <sivang> And me stating the copyright to canonical doesn't suffice as such?
[11:17] <Kamion> (which I imagine you could do if you wanted, but it's bureaucracy, and I don't think we're requiring it of Ubuntu contributors in general)
[11:17] <Kamion> see the GNU project's copyright assignment procedures
[11:17] <Kamion> they're a bit more involved than that
[11:18] <sivang> hmm, Well I'll assume that having sun on the copyright notice is fair enough by now, at least for warty :)
[11:19] <sivang> (assuming their microsoft agreement won't fiddle with those parts :-)
[11:21] <hazmat> is there a page with bounties for ubuntu or canonical?
[11:22] <pitti> hazmat: http://wiki.ubuntulinux.org/WartyWarthog_2fBounties
[11:24] <hazmat> ugh.. the wiki ui has turned all the actions links into a flat list.
[11:24] <hazmat> pitti, thanks
[11:25] <sivang> hazmat : I noticed that also, but only for specific parts. strange ha?
[11:25] <Kamion> sivang: if Sun have contributed legitimately to the documentation, and it's under a free licence, that's fine ...
[11:25] <hazmat> its does it for me on every page.
[11:26] <sjoerd> pitti: you should add some bounties for hal stuff :)
[11:27] <pitti> sjoerd: one for fixing all potential SIGSEGVs would be nice :-)
[11:27] <doko> kamion: will you care about #1232, or should I prefer packages for the 4 updated translations?
[11:28] <Kamion> doko: was planning to do it tomorrow, although I don't mind if you do it either before then
[11:29] <Kamion> doko: I'm doing a base-installer change anyway, so maybe it would be easier for locking purposes at this point if I took care of it
[11:29] <Kamion> mdz: are d-i translation changes in general OK?
[11:30] <mdz> Kamion: absolutely
[11:30] <doko> so, I can go ahead and merge the 2MB patch to the installer packages mentioned?
[11:31] <mdz> as long as it only touches .po files, sure
[11:32] <doko> ok, when is the last day for .po updates? I want to ask for updates for the translations, which still need to be done, on the users list.
[11:33] <jdub> pitti: still need 2208 and 2209 checked?
[11:33] <pitti> jdub: no, I already uploaded it. Thanks anyway!
[11:33] <jdub> ok
[11:33] <pitti> jdub: good morning, BTW! :-)
[11:33] <Kamion> doko: tomorrow
[11:33] <jdub> :)
[11:33] <mdz> doko: we can be quite flexible with translation updates; ask Kamion when he would need them in order to do the final CD build
[11:34] <Kamion> mdz: patch in #2136, untested yet
[11:34] <Kamion> oh, tomorrow for release candidate
[11:34] <Kamion> if mdz and jdub are happy with updates between RC and release, anything up to next Monday
[11:34] <Kamion> any later than that starts to get very risky
[11:34] <Kamion> as opposed to merely quite risky :)
[11:35] <mdz> Kamion: patch looks perfect, fire away
[11:35] <lamont> Kamion: s/very/extremely/; s/quite/very/
[11:35] <mdz> I'm happy with translation updates between RC and release
[11:35] <Kamion> lamont: :-0
[11:35] <Kamion> :-)
[11:35] <lamont> Kamion: are there any univers packages on the CD, btw?
[11:35] <Kamion> lamont: should certainly hope not :-0
[11:36] <lamont> just double checking my assumptions.
[11:36] <doko> ok, I'll send an email to the users list asking for updated translations and trying to get most of it done tomorrow (those which are merged from Debian).
[11:38] <Kamion> lamont: the cdimage build process does not even rsync universe or multiverse, just to make sure
[11:38] <lamont> Kamion: awesome
[11:40] <mdz> Kamion: regarding #2276, shall we add the package to the germinate workarounds section for now?
[11:41] <lamont> mdz: note that it's only a build-dep, not a dep.
[11:41] <Kamion> mdz: is dpkg-dev not already in a seed?
[11:41] <lamont> dpkg-dev is too new.
[11:42] <Kamion> too new?
[11:42] <lamont> ii  dpkg-dev       1.10.22ubuntu2 Package building tools for Debian
[11:42] <mdz> thom: ping?
[11:42] <Kamion> grief, no, apparently dpkg-dev is only pulled in via debhelper etc.
[11:42] <lamont> and the d-w says dpkg-dev (<<1.10)
[11:42] <Kamion> lamont: oh, duh, I see
[11:42] <mdz> that's one of those awful hacks to try to support building on woody with different build-deps
[11:43] <Kamion> and germinate doesn't do << deps? how broken
[11:43] <lamont> used to be it didn't...
[11:43] <Kamion> mdz: if you meant libaltlinuxhyph-dev, hell yeah
[11:43] <mdz> Kamion: I did, ok, will do
[11:44] <Kamion> I don't see any version-checking code, indeed
[11:44] <Kamion> probably doesn't understand >= etc. either