[12:04] <srbaker> is ubuntu in debconf high or critical?
[12:07] <mdz> srbaker: critical in the installer, high in the installed system
[12:07] <srbaker> cool
[01:00] <tseng> hi all.
[01:02] <lamont> hrm.. no jdub, eh?
[01:54] <Mithrandir> mdz: can we sync gftp with debian? -6 fixes RC bug for both us and them; the fix is in incoming; our bug # is 1806
[01:54] <Mithrandir> (we have -5 already)
[01:54] <mdz> Mithrandir: just saw that
[01:54] <mdz> yes, fine with me
[01:54] <mdz> please request it
[01:55] <Mithrandir> willdo
[01:55] <sivang> night all
[01:56] <sivang> has anyone bumped into _very__very_ slow disk performance under inspiron 8200 laptop? I recently install a daily from about 4 days ago, and it just crewles..
[01:56] <sivang> Is this more appropriate at #ubuntu ? :)
[01:58] <sivang> night Mithrandir
[02:18] <sivang> :
[02:18] <sivang> :)
[02:18] <sivang> any urgent bugs?
[04:40] <lamont> justdave: happiness?
[04:40] <justdave> lamont: yep
[04:40] <lamont> what was it?
[04:41] <justdave> I accidently nuked a paren when I added the -f
[04:41] <lamont> ouch
[04:41] <justdave> because my stupid terminal was sending the wrong code for backspace :)
[04:41] <lamont> heh
[04:43] <justdave> guess postfix isn't as picky about that stuff as sendmail (or at least not by default)
[04:43] <justdave> sendmail makes you grant users permission to use -f
[04:43] <lamont> fehj
[04:43] <justdave> which is why I assumed I needed admin support :)
[04:43] <lamont> nc localhost 25
[04:44] <lamont> yeah.  then again, postfix's sendmail is mode 555
[04:44] <lamont> and just writes a file into /var/spool/postfix/maildrop
[04:44] <justdave> one of these days soon, bugzilla will do smtp by default anyway
[04:46] <lamont> if you do, there's always sendmail -bs for those that can't run on port 25. But that's a gross hack from days gone by
[04:47] <justdave> back in 30 or so
[04:47] <lamont> later
[06:44] <fabbione> morning guys
[06:55] <daniels> fabbione: morning
[06:55] <fabbione> hey dani
[06:56] <fabbione> daniels: i start to be a bit worried about Dec conf.
[06:56] <fabbione> jane talks about end nov. mid dic
[06:56] <fabbione> mark isn't sure...
[06:56] <fabbione> personally i don't mind
[07:18] <jdub> oh man
[07:18] <jdub> the gnome-cups-manager test pages are all line-based, not font-based
[07:18] <jdub> ie. can't just s/XIMIAN DESKTOP/UBUNTU/g :)
[07:19] <lamont> ew!
[07:20] <lamont> jdub: btw, if you or anyone else can tell me how to preserve categories for contacts into evo2.0 and back, that'd be the last thing that's keeping me on jpilot...
[07:20] <jdub> lamont: to and from palm?
[07:21] <lamont> yes
[07:21] <lamont> the only use I have for evo is to sync my palm. :-)
[07:21] <jdub> heh
[07:22] <lamont> I _like_ the MUA I use, don't want some stupid gui MUA. :-)
[07:22] <jdub> lamont: so why do you sync with evolution at all?
[07:22] <lamont> atm I don't/
[07:23] <lamont> but if I could preserve my address book categories, then I could drop jpilot.
[07:23] <lamont> the wifely one is using evo, because I didn't want to make her non-conformist...
[07:23] <jdub> ok, why do you want to sync with eovlution insetad?
[07:23] <jdub> oh
[07:23] <lamont> she discovered this evening that if you drop 5 concurrent events into evo, it segv's trying to print it... ;)
[07:24] <lamont> jdub: I'm _trying_ to be a good warthog/
[07:24] <lamont> and it would be nice to share calendars in the house.
[07:25] <lamont> daughter wants up at 5, instead of the normal 5:30.
[07:25] <lamont> I hate getting up early.
[07:26] <lamont> anyway, g'night
[07:27] <mdz> night
[07:29] <mdz> jdub: pstoedit?
[07:31] <jdub> mdz: thought about that, but doesn't convert to anything inkscape likes
[07:31] <jdub> but i could screw around with xfig
[07:32] <mdz> WWBJD?
[07:33] <mdz> jdub: there is a pstoedit SVG output plugin
[07:33] <mdz> maybe you could ask Ximian for whatever source format they have for the page
[07:33] <jdub> :)
[07:34] <jdub> it should probably be fixed in gnome cvs anyway
[07:34] <jdub> mdz: where's the svg output plugin?
[07:34] <mdz> http://www.pstoedit.net/plugins
[07:34] <mdz> eww, it's a binary
[07:35] <jdub> yeah
[07:35] <jdub> "Unless you get a key, these drivers will slightly distort the generated output. Colors will be changed and the letter e will be replaced by $."
[07:36] <mdz> oh hey
[07:36] <mdz> are you sure pstoedit doesn't support svg out of the box?
[07:36] <mdz> it looks like it can use the libplot svg output
[07:37] <mdz> pstoedit -f plot-svg xd2-testpage-a4.eps /tmp/test.svg
[07:37] <mdz> Interpreter finished. Return status 0
[07:39] <jdub> mdz: it just gave me 0 length output\
[07:39] <mdz> inkscape seems to like it fine
[07:39] <jdub> oh, now it's working
[07:39] <jdub> bong
[07:40] <jdub> ugh, the output is horrible
[07:40] <mdz> it's a little cracked out
[07:40] <jdub> might even be worth doing our own ;)
[07:41] <mdz> for some reason everything is covered by black circles
[07:41] <mdz> s/circles/shapes/
[07:41] <mdz> if you delete that crap, the good stuff is underneath
[07:41] <mdz> maybe it's some weird printer magic
[07:42] <mdz> all of the objects are there, it's just the colours that are borked
[07:43] <jdub> mine are all misshapen
[07:45] <mdz> inkscape crashed on me
[07:46] <mdz> probably worth making our own :-)
[07:46] <mdz> I liked all the little test patterns they provided though
[07:48] <jdub> mmm
[07:48] <jdub> will see if the output sucks or not ;)
[07:53] <pitti> Hi guys!
[07:53] <mdz> pitti: good morning
[07:53] <pitti> mdz: Morning. Exhausting weekend...
[08:11] <jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
[08:11] <jdub> anyone want to check those out?
[08:14] <jdub> hmm
[08:14] <jdub> that looks pretty good
[08:23] <doko> jdub: ERROR 404: Not Found.
[08:24] <jdub> that makes ithard to test
[08:25] <fabbione> mdz: 1808 what do you want me to do with this one?
[08:25] <fabbione> jdub: ^^
[08:25] <jamesh> pitti: does this sound like it could be related to pmount? https://bugzilla.ubuntu.com/show_bug.cgi?id=1715
[08:26] <jamesh> pitti: I can easily fix up my gnome-vfs patch, but I'm wondering why the problem occured just recently.
[08:27] <jdub> fabbione: oh, that reminds me
[08:27] <jdub> fabbione: pipka's laptop only supports the full resolution of the lcd at 16bit
[08:28] <jdub> fabbione: which means the configuration fails :|
[08:29] <fabbione> defaulting to 16 bits or let 24 bits?
[08:29] <fabbione> one way or another we will get bug reports
[08:29] <jdub> do you mean in the general case?
[08:29] <fabbione> "it doesn't work at 24 bits but only at 16"
[08:29] <jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
[08:29] <fabbione> "GRAVE BUG: my video card supports 24 bits and you only init at 16"
[08:29] <jdub> ^ try again :)
[08:29] <jdub> fabbione: ;-)
[08:29] <pitti> jamesh: this is indeed the same bug as #1599.
[08:30] <fabbione> jdub: yes as a general case... it's either one or another
[08:30] <mdz> fabbione: if there is some way to auto-detect the situation, great
[08:30] <pitti> jamesh: this is not directly a pmount problem, it's a gvfs bug
[08:30] <mdz> fabbione: if not, close it
[08:30] <mdz> fabbione: either way, it's not important for the release (hence severity; enhancement)
[08:30] <jdub> mdz: hhhrrrmmm, it ends up being important
[08:30] <pitti> jamesh: seb recently uploaded a new gvfs, and my patch (which worked fine with the older one) does not play well with the new upstream version
[08:30] <mdz> jdub: what does?
[08:30] <pitti> jamesh: so I disabled it temporarily
[08:30] <jamesh> pitti: I can probably get the computer:/// and network:/// patches to only move "connect to server" type entries.  That would solve the problem, right?
[08:30] <fabbione> mdz: well there is a way, but that will require xresprobe to return me the amount of ram on the video card and according to resolution set the depth
[08:30] <jdub> mdz: when the resolution chosen does not work at 24bit
[08:31] <pitti> jamesh: yes, this would solve both bugs.
[08:31] <fabbione> mdz: but do you feel to implement it at this point in time?
[08:31] <mdz> fabbione: no, I really don't
[08:31] <pitti> jamesh: if you know the guts of gvfs well enough, it would be great! 
[08:31] <fabbione> mdz: i realize we did never discuss this problem before
[08:31] <fabbione> mdz: so it's a point, but up to you
[08:31] <jamesh> pitti: okay.  I'll put together a patch, and we can see if it solves things.
[08:31] <mdz> this is only an issue with older graphics cards which do not have enough RAM, right?
[08:31] <jdub> fabbione: i'd say hoary
[08:31] <pitti> jamesh: I actually thought that I had to write new code to make the devices appear in Disks, but if that code already exists, so much the better
[08:31] <pitti> jamesh: thanks!
[08:32] <jdub> mdz: that's a lot of machines
[08:32] <jdub> mdz: not just older
[08:32] <jamesh> pitti: my patch moves all GnomeVFSVolumes that don't have an associated GnomeVFSDisk object to network:///
[08:32] <mdz> jdub: video cards sold today have more ram than most of my computers
[08:32] <pitti> jamesh: ah, maybe that was the reason why my previous patch just did not work any more
[08:32] <jamesh> pitti: I'm not sure why things like the firewire and USB drives don't have a Disk object now though.
[08:32] <jdub> mdz: in ricer machines, sure
[08:32] <mdz> jdub: in something you buy from Dell or HP
[08:33] <jamesh> pitti: s/GnomeVFSDisk/GnomeVFSDrive/
[08:33] <jdub> mdz: it's a significant bug, but something that can probably wait until hoary
[08:33] <pitti> jamesh: upstream version only shows Disks which have an fstab entry
[08:33] <fabbione> mdz: yes
[08:33] <mdz> jdub: I don't see that we can do anything intelligent in that situation; we would need to ask a question
[08:33] <pitti> jamesh: my previous patch "faked" such an entry by modifying the function which read fstab; it added the user-entries of mtab
[08:33] <mdz> "what's more important: colours or resolution?"
[08:33] <jamesh> pitti: okay then :)
[08:34] <pitti> jamesh: but with the new upstream version, it became unreliable and breaked the trash
[08:34] <jdub> mdz: it's easy to determine from available video ram
[08:34] <mdz> jdub: you can't determine whether the user would prefer a higher resolution with fewer colours, or a lower resolution with more colours
[08:35] <mdz> that's the tradeoff, isn't it?
[08:35] <jdub> not on an lcd :-)
[08:35] <jdub> but it's something you can decide that they can reconfigure later
[08:35] <jdub> (on a crt)
[08:36] <mdz> that's what we do today :-)
[08:36] <jdub> they can't, because their system doesn't work
[08:36] <mdz> why not?
[08:37] <mdz> can the driver not detect that the mode is no good and fall back?
[08:37] <jdub> we don't do that today
[08:37] <jdub> when pipka installed her machine
[08:37] <jdub> it chose the right resolution for the lcd
[08:37] <jdub> and the wrong colour resolution
[08:37] <jdub> were she not a kung-fu master, she would not have got out alive
[08:38] <mdz> ah, ok
[08:38] <mdz> so the LCD was configured correctly, but the card can't drive it
[08:38] <jdub> if you can determine two useful configurations from the video ram
[08:38] <mdz> in the LCD case there is no tradeoff
[08:38] <mdz> you just need to drop the depth
[08:38] <jdub> then on a laptop you can choose the correct one for the lcd
[08:39] <jdub> on a crt you can make up some reason why you'd choose one over the other
[08:39] <jdub> and let the user configure it how they want later
[08:39] <mdz> #1808 is a different case
[08:40] <mdz> I think the emulator just sucks, but I wasn't sure
[08:40] <jdub> no, same case
[08:40] <jdub> it's just not hardware ;)
[08:40] <mdz> oh, you have a copy of microsoft virtual PC?
[08:40] <mdz> that'll come in handy for testing the fix
[08:41] <jdub> i don't, but i know it emulates an s3
[08:41] <jdub> i think i can get access to a copy
[08:41] <mdz> I don't think the chipset is relevant
[08:41] <jdub> but probably don't need it, the fix is described above :)
[08:42] <jdub> the chipset isn't relevant, it's the 'hardware environment'
[08:42] <mdz> the 'hardware environment' in this case seems like a buggy emulator
[08:42] <mdz> which is a very differetn case from a card which is short on video ram
[08:42] <mdz> the amount of video ram can generally be probed
[08:42] <jdub> dude, it emulates a video card that can't do that
[08:42] <jdub> nothing wrong with the emulator
[08:42] <mdz> I _have_ an S3 card, and it _does_ to 24-bit colour
[08:43] <mdz> s/to/do/
[08:43] <doko> jdub: eps: maybe let the user know how many lines around the edges he is supposed to see?
[08:43] <jdub> apart from making a bad choice of hrdware setup
[08:43] <jdub> doko: hrm, that'd be a software issue ;)
[08:43] <jdub> doko: just replacing the poopie eps shipped with gnome-cups-manager
[08:45] <doko> jdub: no, just print it somewhere on the page, "you should see ... if not, adjust your setup, help at ..."
[08:46] <mdz> fabbione: hmm, there is also a tradeoff with DRI
[08:47] <mdz> my mga card can only run 1600x1200 with DRI disabled due to lack of RAM
[08:48] <fabbione> mdz: ok.. should we default to 16 bits?
[08:48] <mdz> fabbione: hell no :-)
[08:48] <mdz> fabbione: just another thing to think about when we decide to look at this issue in the future
[08:48] <fabbione> mdz: we need to rewrite all the autodetection code anyway
[08:48] <fabbione> and do a hell of a lot of a cleanup
[08:49] <daniels> s3s do do 24-bit, yes
[08:52] <jdub> http://www.robertmoir.co.uk/win/vpcfaq/VPCFAQ7-KnownIssueswithVP.html#7.3
[08:52] <jdub> http://vpc.visualwin.com/
[08:52] <jdub> ^ mentions ubuntu ;)
[08:53] <mdz> hah, nice
[08:55] <mdz> Colin Barnhorst seems to have tried many different operating systems
[08:55] <mdz> hah, even knoppixmyth is on there
[08:56] <jdub> sick puppy ;)
[08:57] <doko> but "does it worK? no"
[08:59] <mdz> hah, that page describes linux boot parameters as "cheat codes"
[08:59] <jdub> up-up-up-b-b-a-start-down-- WOOHOO! KERNEL 2.6!!!!
[08:59] <mdz> ^^vv<><>ABAB START
[09:00] <doko> try to submit an entry for "Small Ubuntu Server", maybe it shows up in the front then ;)
[09:03] <jdub> let's choose that name for the next release which requires new glibc, new gcc, new kernel, new X and new just about everything else
[09:04] <daniels> mdz: i like PokeyPenguin
[09:04] <doko> that's Hoary, or Hoary+1 ?
[09:05] <daniels> hoary+2 is meant to be PerkyPenguin
[09:10] <jdub> ok bong-sippers
[09:10] <jdub> what do you think about those printer pages
[09:10] <jdub> ?
[09:10] <jdub> otherwise i'm just going to upload the suckers
[09:11] <daniels> ubuntu.
[09:14] <mdz> where are the printer pages?
[09:15] <mdz> ah, missed the 'try again'
[09:15] <jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
[09:16] <mdz> jdub: definitely fixes the bug :-)
[09:25] <jdub> heh
[09:25] <jdub> you like?
[09:25] <mdz> fabbione: any idea about  1724?
[09:26] <jamesh> pitti: I just bugzilla'd the new gnome-vfs patch.
[09:26] <mdz> jdub: I think it would be nice to have some test patterns and stuff, but for Warty purposes, what you have is more than sufficient
[09:26] <jdub> patterns rather than colours?
[09:26] <pitti> jamesh: thanks! Does it work now?
[09:27] <pitti> jamesh: I will take a look at it (out of curiosity :-) )
[09:27] <mdz> jdub: text in a few different fonts, stipple pattern, parallel lines, etc.
[09:27] <jdub> mmm
[09:27] <jamesh> pitti: it doesn't cause any problems here, and the patch to computer-method.c is a lot simpler
[09:27] <jamesh> pitti: which means that it should behave more like upstream
[09:28] <mdz> jdub: I say ship it
[09:28] <jdub> SHIP IT!
[09:29] <jamesh> pitti: I've only got a limited number of volume types to test on this box, which is why I'd like to know if it works well in other situations.
[09:29] <pitti> jamesh: still quite a big patch, but it looks as if it _could_ go upstream...
[09:29] <pitti> jamesh: I think there's only one possibility to find that out :-))
[09:29] <jamesh> pitti: it is a replacement for a patch we already have in gnome-vfs, and it is a bit smaller than the one it replaces.
[09:30] <jamesh> pitti: the diffs between the two patches are quite small.
[09:30] <pitti> jamesh: shall I build and test the package before you ask mdz to approve it?
[09:30] <jamesh> pitti: that would be useful, yes.
[09:31] <pitti> jamesh: do you already have a i386 deb somewhere?
[09:31] <jamesh> no.
[09:31] <pitti> jamesh: okay, I build it myself.
[09:36] <jamesh> this version of the patch could probably be sent upstream (the last version wasn't as clean)
[09:50] <pitti> Morning seb128!
[09:50] <seb128> morning
[09:51] <jdub> yo seb128 
[09:51] <seb128> grrr, 30 hours to fix the dsl connection, apparently dsl people don't work sunday
[09:51] <jdub> seb128: got my mail?
[09:51] <jdub> ouch
[09:51] <seb128> just back from 30 hours internet-less
[09:51] <seb128> my fetchmail/spamassassin/... is working :)
[09:52] <pitti> jamesh: patch works fine for me
[09:53] <jamesh> pitti: great.
[09:53] <pitti> jamesh: this bug report was great; so far I thought that the new device would not appear in Nautilus at all
[09:54] <pitti> jamesh: I would have never come to the idea to look in "Network" for it :-)
[10:02] <seb128_> funny, I'm getting 2 weeks old mails for 3 days (WTF with my @debian)
[10:04] <pitti> jdub: the new hal 0.2.98 does not work with the current g-v-m, so I need to upload a new gvm
[10:04] <pitti> jdub: there is a new upstream version 1.0.2 of g-v-m which just adds some new translations
[10:04] <jdub> :)
[10:04] <trukulo> seb128_: read planet.debian.net, there was a problem with mail server
[10:04] <pitti> jdub: may I upgrade g-v-m- while I'm at it?
[10:05] <jdub> pitti: yes thanks
[10:06] <jdub> http://www.extremetech.com/article2/0,1558,1651228,00.asp
[10:06] <jdub> ^ (p)review
[11:30] <pitti> seb128: the nautilus-cd-burner in warty does not yet use the new locking mechanism of hal to prevent further mounts; is this already upstream?
[11:30] <seb128> yes it's upstream
[11:30] <seb128> but need hal >= 0.2.98
[11:30] <seb128> so it's not buildable for the moment
[11:30] <pitti> seb128: I just packaged crack-of-the day hal/dbus/gvm
[11:30] <pitti> seb128: now I test CD burning
[11:31] <seb128> ok
[11:31] <seb128> cool
[11:31] <pitti> seb128: I cannot find any trace of lockign in the n-c-b sources
[11:31] <seb128> it's in 2.8.3
[11:31] <pitti> seb128: ah, so I'm going to package this as well
[11:31] <pitti> seb128: unless you want to do that...
[11:32] <seb128> pitti: that's just a matter of dch -i, New upstream release and update the hal depends
[11:32] <seb128> pitti: so as you want :)
[11:32] <pitti> seb128: okay, since the other stuff is at my hd and not uploaded yet, I would do it
[11:32] <seb128> ok, thanks
[11:32] <pitti> seb128: so the guys can test the complete new stack from my archive without having it to upload first
[11:33] <seb128> yeah
[11:33] <fabbione> jdub:
[11:34] <fabbione> xfree86 (4.3.0.dfsg.1-6ubuntu22) warty; urgency=low
[11:34] <fabbione>   * Update 000_stolen_from_HEAD.diff:
[11:34] <fabbione>     + Include Xv/framebuffer fix for xf86xv.c.
[11:34] <fabbione>   * Update 030_Xserver_and_driver_region_primitive_fixups.diff:
[11:34] <fabbione>     + Fix REGION_EQUAL call in nv_driver.c.
[11:34] <fabbione>   * Update Czech debconf template translations (thanks, Miroslav Kure).
[11:34] <fabbione>   * Apply fix for Keycodes for PrintScreen and SysRq. (Closes: #1762)
[11:34] <fabbione>  -- Fabio M. Di Nitto <fabbione@fabbione.net>  Mon, 27 Sep 2004 07:58:55 +0200
[11:34] <pitti> seb128: http://ftp.gnome.org/pub/GNOME/desktop/2.8/2.8.0/sources/ just has n-c-b 2.8.0
[11:34] <pitti> seb128: where do you pull new sources from?
[11:35] <pitti> seb128: ah found it
[11:35] <pitti> seb128: sorry for disturbing
[11:35] <seb128> np
[11:40] <seb128> jdub: ok, changes done for the -fr list
[11:47] <pitti> seb128: hmm, ncb 2.8.3 still does not attempt to umount the CD-RW
[11:48] <pitti> seb128: how easy is it to add an _extra_ unmount option to the context menu? (By now you just have eject)
[11:48] <seb128> no idea
[11:48] <seb128> should ask jamesh about this, he had a look on that
[11:50] <jamesh> seb128: I haven't looked at the exact nautilus code, but I could.
[11:50] <seb128> ok
[11:50] <pitti> jamesh,seb128: I think I can add the unmounting to n-c-b
[11:51] <seb128> jamesh: have you replied to my question about pygtk/gnome the other day ?
[11:51] <pitti> jamesh,seb128: but having a separate unmount option for CDs is a good idea nevertheless
[11:51] <seb128> pitti: why do you want to umount in n-c-b ?
[11:52] <pitti> seb128: by now you insert an RW, it is mounted automatically; if you want to burn on it, it is busy
[11:52] <pitti> seb128: however, there is no possibility to unmount it, it is ejected
[11:52] <seb128> you want to add an umount "option" ?
[11:52] <pitti> seb128: so we could pumount -l the device before burning
[11:52] <seb128> yes, but not an option
[11:52] <seb128> just umount it 
[11:52] <pitti> seb128: okay, then without -l
[11:53] <pitti> seb128: by now, there is just a "TODO: unmount the device..." in the ncb code
[11:53] <seb128> I can ping an upstream about this
[11:54] <pitti> seb128: maybe a good idea; I don't know much about the code
[11:54] <pitti> seb128: I can add the umount there and try if it works
[11:54] <seb128> ok
[11:58] <jamesh> seb128: I talked a bit with jdahlin about it.  The fix is probably the right thing for Python < 2.3.5
[11:58] <jamesh> pitti: btw, the code for handling unmount/eject context menu item is in real_update_menus_volumes() in src/file-manager/fm-directory-view.c
[11:59] <jamesh> pitti: it seems to use the same verb for both eject and unmount
[11:59] <pitti> jamesh: so the decision is taken at a lower level?
[11:59] <pitti> jamesh: that would mean it is nontrivial to add, isn't it?
[12:02] <jamesh> pitti: the decision between eject and unmount is in the eject_for_type() function
[12:02] <jamesh> pitti: which is set to show an eject option for cdroms, zip and jaz drives, and unmount for others
[12:02] <pitti> jamesh: I saw this once; it does not seem to be designed for just unmounting
[12:03] <pitti> jamesh: well, if its nontrivial to change and cd-burner supports automatic unmounting, it's not such a big deal, I suppose
[12:03] <jamesh> pitti: unmount_volume_callback() uses the result of eject_for_type() to decide whether to eject or unmount
[12:03] <jamesh> pitti: and the code for setting up the context menu uses eject_for_type() to decide whether to call the item eject or unmount.
[12:04] <jamesh> it isn't a case of showing one item and hiding the other
[12:04] <pitti> jamesh: ugly...
[12:04] <pitti> jamesh: at least for having two commmands...
[12:04] <jamesh> it is just a single menu item with a different label depending on the drive type.
[12:05] <jamesh> pitti: well, other than the case you mentioned, when is a user going to want to unmount a cdrom or zip disk?
[12:05] <jamesh> pitti: the correct fix would be to get n-c-b to do the unmount
[12:05] <pitti> jamesh: I would do it if I wanted to repartition my USB stick, ZIP drive or whatever
[12:06] <pitti> jamesh: but if I want to do that, I can as well type umount by hand
[12:06] <pitti> jamesh: I want to fix n-c-b anyway
[12:06] <jamesh> pitti: actually, you probably couldn't umount by hand ...
[12:06] <jamesh> if the stick has a trash dir
[12:06] <pitti> jamesh: these device locks, I suppose
[12:07] <pitti> jamesh: but that shouln't happen on CD-ROMs, no?
[12:07] <pitti> jamesh: seb128 suggested not to lazily unmount the CD, but do that normally
[12:07] <jamesh> pitti: the Gnome vfs umount/eject stuff has a "pre unmount" signal so that apps like nautilus can stop monitoring directories
[12:08] <jamesh> since fam/gamin's dnotify watches hold the device open
[12:08] <pitti> jamesh: hmm, so actually n-c-b should call this instead of umounting directly?
[12:09] <Sledge> morning...
[12:09] <pitti> morning Sledge
[12:10] <jamesh> pitti: yep.  Get the GnomeVFSVolume or GnomeVFSDrive object for the cd drive and call its unmount() method.
[12:10] <pitti> jamesh: any idea how I can do that in n-c-b? I only have the device string (/dev/hdc or so)
[12:11] <jamesh> pitti: gnome_vfs_volume_monitor_get_volume_for_path() might do it.
[12:15] <pitti> jamesh: do I have to call the pre_umount method myself or does GnomeVFSVolume's umount() method care for that?
[12:15] <jamesh> pitti: the gnome_vfs_volume_unmount() routine handles it all for you.
[12:15] <pitti> jamesh: thanks a lot for your help!
[12:19] <jamesh> pitti: if inotify existed a few years back, things wouldn't be so complicated ...
[12:32] <seb128> does somebody already had problems to boot the warty iso on a powerbook ?
[12:34] <thom> seb128: define problems
[12:34] <seb128> the powerbook doesn't boot on the CD
[12:34] <seb128> it doesn't see it as a bootable one or something like that
[12:34] <thom> seb128: hold 'c' as you power on
[12:35] <seb128> ok, not for me, I'm telling that to the guy ;)
[12:35] <seb128> thanks
[12:35] <thom> sure
[12:35] <seb128> and for shared-mime-info, yes it was 0.15 :)
[12:36] <thom> right, well, that bug is still occurring then :-/
[12:36] <seb128> thom: 'c' doesn't work, the guy says it already does that
[12:36] <seb128> debian CDs boot ok
[12:36] <seb128> warty doesn't boot
[12:36] <seb128> s/it/he/
[12:41] <jamesh> seb128: btw, I did a patch for bug 1715 (firewire volume showing up under Network)
[12:42] <seb128> cool, thanks
[12:42] <jamesh> seb128: pitti tested it, and it fixes 1599 too
[12:42] <seb128> ok, I'll do an upload soon
[12:42] <seb128> thanks
[12:52] <fabbione> jdub, mdz: ping
[01:05] <Kamion> seb128: I'd check that it burnt correctly; the CD build processes for Debian and Ubuntu are practically the same
[01:06] <seb128> the guy has burnt several time the debian and the ubuntu iso, the Debian always boot, the Ubuntu one not ... weird
[01:15] <Kamion> very odd
[01:15] <Kamion> is he certain that he downloaded the Ubuntu ISO correctly?
[01:15] <seb128> yes
[01:15] <Kamion> rsync shows no changes?
[01:16] <Mithrandir> make sure to run rsync with -c
[01:17] <seb128> I'm checking, but I think he downloaded the preview and one daily, and he can mount them without any problem
[01:17] <seb128> he deleted the iso and is downloading it again ...
[01:19] <Kamion> the preview has certainly booted on lots of machines
[01:48] <pitti> jamesh: still here?
[01:49] <jamesh> pitti: yep.
[01:49] <pitti> jamesh:  gnome_vfs_volume_monitor_get_volume_for_path delivers a VFSVolume* with device path 'none' and umounting does not work
[01:49] <pitti> jamesh: do I need to initialize the monitor somehow?
[01:50] <pitti> jamesh: by now I just create an instance with GnomeVFSVolumeMonitor* gvm = gnome_vfs_get_volume_monitor()
[01:50] <pitti> jamesh: sorry for askign so much, but this stuff is not documented yet
[01:50] <jamesh> pitti: hmm.  I'm a bit new to the APIs myself.
[01:51] <pitti> jamesh: do you know what these _ref and _unref methods are for?
[01:51] <pitti> jamesh: maybe I need to call them
[01:52] <jamesh> pitti: imaybe gnome_vfs_volume_monitor_get_volume_for_path() expects a path on the mounted volume
[01:52] <pitti> jamesh: argh; maybe. By now I give it the device node path
[01:52] <pitti> jamesh: I don't have the mount path in n-c-b...
[01:53] <jamesh> pitti: the other thing to try would be to use gnome_vfs_volume_monitor_get_mounted_volumes() to get the list of mounted volumes, and gnome_vfs_volume_get_device_path() to find the device path for each mounted volume
[01:53] <jamesh> find the volume that matches the device file name.
[01:54] <pitti> jamesh: sounds possible (although pretty much code for such a simple thing :-) )
[01:55] <jamesh> pitti: maybe that's why n-c-b doesn't currently do it :(
[01:56] <pitti> jamesh: :-) So, off to doing it
[01:56] <jamesh> pitti: of course, the unmount may still fail if other apps have files open ...
[01:56] <pitti> jamesh: but I think this is reasonable in this case
[01:57] <jamesh> pitti: but it will get nautilus to stop holding the volume open
[01:57] <pitti> jamesh: ncb will show a dialog "drive busy", then the user can close the app and click "OK" to try again
[02:00] <fabbione> seb128: 1762: who the screenshot stuff is supposed to work?
[02:00] <fabbione> if i press print or alt+print, where is the screeshot saved?
[02:02] <seb128> fabbione: desktop or home, not sure
[02:02] <seb128> let me check
[02:03] <seb128> fabbione: it should open the screenshot dialog (same as in the computer menu)
[02:03] <jamesh> there's a Sun guy working on adding printing support to the screenshooter dialog ...
[02:03] <fabbione> seb128: ok thanks. than the fix doesn't work
[02:05] <fabbione> seb128: does it need anything special installed? like gnome-foo-bar?
[02:05] <seb128> gnome-panel
[02:05] <seb128> that's all
[02:05] <seb128> it runs gnome-panel-screenshot
[02:06] <ross> fabbione: pressing print or alt-print generally doesn't work in debian's X
[02:06] <fabbione> ross: that's what i am trying to understand
[02:06] <fabbione> ross: there is a patch missing
[02:06] <ross> i've seen a patch to fix it
[02:06] <seb128> ross: that's the purpose of the bug report yes
[02:07] <ross> aaah i see
[02:07] <fabbione> ross: yes but the patch doesn't fix apparently
[02:07] <ross> :)
[02:07] <seb128> ross: http://bugzilla.ubuntu.com/show_bug.cgi?id=1762
[02:08] <fabbione> xc/programs/Xserver/hw/xfree86/common/xf86Events.c @ 3.147
[02:08] <fabbione>    8. Fix for non-PC keyboard bug introduced by changes to make SysRq
[02:08] <fabbione>       generate the same keycode as PrtScrn (Ivan Pascal).
[02:08] <fabbione> HMM
[02:08] <mjg59> Is there any reason we don't modprobe apm on boot by default?
[02:08] <Mithrandir> it would seriously suck for my laptop, for instance.
[02:09] <mjg59> It won't do anything if acpi is already running
[02:10] <Mithrandir> we should make sure acpi is loaded first, then.
[02:10] <Kamion> Mithrandir: the initrd already loads thermal/fan
[02:10] <Kamion> that should be enough, shouldn't it?
[02:10] <mjg59> acpi is built into the kernel
[02:11] <mjg59> Kamion: Does that happen in Debian, too?
[02:11] <Mithrandir> Kamion: if you load apm on my system the modifier keys behave really badly, they get sticky.
[02:12] <ross> pitti: i've forgotten pmount policy again -- would an external firewire hdd be mounted without a line in fstab?
[02:12] <pitti> ross: Should work, yes
[02:12] <ross> hm, it isn't
[02:13] <mjg59> Mithrandir: Really, apm won't do anything unless acpi is either implicitly or explicitly disabled
[02:13] <pitti> ross: does it appear in Device Manager=
[02:13] <mjg59> There's no way to build modular acpi
[02:13] <pitti> ross: s/=/?/
[02:14] <ross> urgh.  hald has hung in scsi_wait_req and is dead
[02:14] <Kamion> mjg59: in d-i, yes; in the installed system, no
[02:14] <Kamion> mjg59: (unless it was done somewhere different from where I was expecting)
[02:14] <pitti> ross: can you kill it and try again?
[02:14] <ross> nope, its totally dead
[02:17] <mjg59> Kamion: Bleah. We /still/ need to fix that. It does kill hardware.
[02:17] <pitti> ross: I packaged a newer hal, maybe it fixed the crash...
[02:23] <fabbione> it looks to me that code is not even reached
[02:23] <fabbione> either with the xfree86 patch or the x.org one
[02:29] <lamont> moof
[02:29] <Mithrandir> moof, lamont
[02:29] <fabbione> hey lamont 
[02:30] <daniels> fabbione: which code, the radeon suspend shit, or the xkb stuff?
[02:30] <fabbione> daniels: print and <alt>+print
[02:31] <daniels> ahr
[02:31] <fabbione> we have both the fixed from xfree86 and x.org but alt+print still = SysRq
[02:31] <daniels> crap
[02:31] <fabbione> it gives me the feeling that the part of the code is not used at all
[02:31] <fabbione> let me try a gdb sessions
[02:32] <fabbione> where for SURE it will work
[02:32] <fabbione> therefor making the problem untraceable
[02:49] <ross> hm, why is my numeric keypad not working at all
[02:54] <ross> gar
[02:54] <ross> how am i supposed to shoot people over lunch if my numeric keypad doesn't work
[02:54] <ross> works at the console but not in X
[02:59] <fabbione> seb128: 1762 it's a gnome problem :-)))))
[02:59] <fabbione> seb128: i just finished a gdb session on X and the keyboard mapping is working fine
[02:59] <fabbione> seb128: meaning that something else (!=xfree86) is mangling the keyboard
[02:59] <fabbione> and you know what is the best part...????
[02:59] <seb128> ok
[02:59] <fabbione> I CAN PROVE IT :P
[03:00] <ross> fabbione: any idea why in X my numeric keypad wouldn't work at all?
[03:00] <fabbione> (gdb) n
[03:00] <fabbione> 579       if (scanCode == KEY_SysReqest)
[03:00] <fabbione> (gdb) n
[03:00] <fabbione> 580         scanCode = KEY_Print;
[03:00] <fabbione> this is the patch to xEvents 
[03:00] <fabbione> it maps the SysReq to Key_Print and that works
[03:00] <fabbione> (already the fact that is called means that it works)
[03:01] <seb128> fabbione: could you provide the evidences in http://bugzilla.gnome.org/show_bug.cgi?id=86506 ? :)
[03:01] <fabbione> seb128: do i need an account to write there?
[03:01] <seb128> probably yes
[03:01] <fabbione> seb128: humpf
[03:01] <fabbione> :(((
[03:01] <seb128> just reassign 1762 to me with details
[03:01] <seb128> I'll follow upstream
[03:02] <fabbione> ross: no.. keyboard? model? layout? laptop? desktop?
[03:02] <ross> fabbione: standard UK keyboard, pc105, desktop
[03:02] <ross> ah.  when i press the arrow keys xev reports motionevents
[03:04] <fabbione> ross: "Num lock"???
[03:05] <ross> moves the mouse cursor when its on and off
[03:07] <ross> aha
[03:07] <ross> i pressed shift-alt-numlock
[03:07] <ross> obviously
[03:08] <fabbione> WTF
[03:14] <fabbione> IT
[03:14] <fabbione> IT'S UNUSEABLE
[03:18] <seb128> thom: 1221, the return mime for gnomevfs-info is still the same ?
[03:19] <thom> seb128: MIME type         : application/x-cd-image
[03:23] <jdub> Kamion: ping
[03:24] <thom> i think fedora's bugzilla css is about as good as it gets
[03:24] <jdub> thom: aye.
[03:25] <jdub> ours is pants.
[03:25] <jdub> it makes me cry
[03:25] <jdub> so does planet.u.o
[03:26] <seb128> thom: could you try to patch with GNOME_VFS_FILE_INFO_FORCE_FAST_MIME_TYPE instead of SLOW and try again with gnomevfs-info ?
[03:27] <fabbione> jdub: permission to upload 1821
[03:29] <jdub> fabbione: approved in comments
[03:29] <fabbione> ok
[03:34] <thom> seb128: i'll give it a try in a bit, sure
[03:34] <seb128> thom: thanks
[03:34] <thom> jdub: OH MY EYES
[03:34] <thom> (i just looked at planet)
[03:34] <jdub> uh huh
[03:35] <ross> ARRRG
[03:35] <jdub> thom: seen our website recently?
[03:35] <thom> jdub: planetplanet?
[03:35] <jdub> www.u.org
[03:36] <ross> huh? a book shop?
[03:37] <jdub> ross: ubuntulinux
[03:45] <Kamion> jdub: pong
[03:45] <thom> jdub: 1787, please confirm ;-)
[03:45] <jdub> Kamion: how was oldentown? gothamburg? whereveryouwent? ;)
[03:46] <azeem> oldenburg
[03:46] <azeem> burg == castle, roughly
[03:47] <Kamion> jdub: went well, got lots done, didn't *quite* get the graphical installer booting because mklibs hates me, otherwise good
[03:47] <jdub> Kamion: so there was some discussion a while back about switching off the hidden-menu grub setting if other OSes were detected... did that come to anything?
[03:48] <jdub> Kamion: noice.
[03:48] <Kamion> jdub: I think it came to "good idea, put on Colin's to-do list"
[03:48] <jdub> ahr
[03:48] <Kamion> (which is fine by me, will do it ...)
[03:48] <jdub> Kamion: did it have a milestone attached?
[03:50] <Kamion> jdub: not sure it had a bug attached, even ...
[03:50] <Kamion> PS several uploads waiting for approval
[03:50] <mjg59> Kamion: What's the graphical installer based on at the moment?
[03:50] <Kamion> mjg59: gtk
[03:50] <Kamion> (er, not quite sure what you mean)
[03:51] <mjg59> Just using the gtk debconf front-end, or something nicer?
[03:51] <mjg59> And is this framebuffer or X?
[03:51] <Kamion> just cdebconf-gtk for now, will have more bolted onto it
[03:51] <Kamion> framebuffer
[03:51] <Kamion> running AWAY from X
[03:51] <mjg59> Hrm. Has anyone ported atk to the framebuffer?
[03:51] <mjg59> It's quite X specific at the moment
[03:52] <mjg59> It'd be nice to get the accessibility support for free
[03:52] <Kamion> atk? the accessibility library?
[03:52] <Kamion> dunno
[03:52] <mjg59> Yeah
[03:52] <mjg59> What's the main problem with X?
[03:53] <Kamion> big pile more complexity that we don't need?
[03:53] <Kamion> plus size; even with gdk-directfb we're going to be hitting initrd size limits on many systems unless we're very careful
[03:54] <Kamion> powermac netboot already has no chance
[03:54] <mjg59> Ah, ok - I'd assumed you'd be using a filesystem mounted off the media for graphical install
[03:54] <mjg59> My (not very strongly founded) recollection is that RH doesn't do graphical installs when netbooted
[03:55] <Kamion> we don't get to mount the installation media until after cdebconf has already displayed some questions
[03:55] <jdub> night all
[03:55] <Kamion> www.directfb.org is probably the place to look for any accessibility stuff
[03:55] <Kamion> there is XDirectFB, but I suspect daniels will consider it BONG; dunno
[03:56] <mjg59> Looks like there's no support at the moment
[03:56] <mjg59> That's a shame - an accessible installer would rock
[03:56] <Kamion> in theory we could restart cdebconf with a different frontend, but it's not going to be trivial ...
[03:57] <Kamion> has anyone tried to get the directfb frontend merged into gdk proper, I wonder?
[03:57] <jdub> mjg59: i'm going to do an accessible derivative
[03:58] <mjg59> jdub: Rock
[03:58] <azeem> did you consider using plain GTK for the first stage, and just map the user directions to the debconf-database?
[03:58] <jdub> mjg59: there's a lot of bong requirements that sighted people will just baulk at
[03:58] <Kamion> azeem: what do you mean?
[03:58] <mjg59> jdub: Oh, most of your posts to ubuntu@ seem to appear twice
[03:58] <jdub> mjg59: i have a local testing team too ;)
[03:58] <jdub> mjg59: some; evo bug. :|
[03:58] <jdub> anyway
[03:58] <jdub> good night
[03:59] <azeem> Kamion: IMHO debconf-gtk looks pretty different from usual GNOME applications, so it might be more work to get it look right than just do it natively
[03:59] <azeem> haven't looked at it, of course
[03:59] <Kamion> azeem: that would really, really suck
[03:59] <azeem> heh :)
[03:59] <Kamion> azeem: you're talking about writing a new installer, not porting the existing one.
[04:00] <Kamion> azeem: we need to use cdebconf, otherwise it is not maintainable
[04:00] <Kamion> azeem: also, nobody's even touched the cdebconf gtk frontend since March (and not seriously for much longer, I think), so it's not surprising that it's raw
[04:01] <Kamion> I did some work a few days ago to start cleaning it up, but it'll take a while
[04:01] <azeem> well, I meant just redoing the UI dialogs and using cdebconf to set the values, based on what the user does
[04:01] <Kamion> azeem: we have some glade-related plans that will have that kind of effect, but it's not that simple
[04:02] <azeem> yeah, I guess
[04:02] <Kamion> azeem: there is a lot of code in the installer that does things like setting the range of values presented to the user based on the answers to previous questions in the same udeb
[04:02] <pitti> jamesh: can I please ask you for help again?
[04:03] <Kamion> azeem: if we bypass and duplicate that code, the result won't be maintainable, so we need to come up with a way to keep it (db_callback or similar)
[04:03] <pitti> jamesh: on www.piware.de/gvfs-unmount.c I put a version of my unmounting procedure
[04:03] <azeem> true
[04:03] <Kamion> (I suggested db_callback to joeyh on Saturday and he shuddered ... :-))
[04:04] <azeem> :)
[04:07] <pitti> Anybody here who knows about gnome-vfs programming?
[04:11] <Kamion> anyone know of anybody selling boxes with Ubuntu preinstalled yet?
[04:18] <pitti> seb128: have you ever programmed some stuff with gnome-vfs2? Do you know how to correctly unmount a device?
[04:18] <seb128> yes and no
[04:19] <pitti> seb128: My function for unmounting the cd in the gvfs way worked after ten minutes
[04:19] <pitti> seb128: but it makes n-c-b crash when it starts to burn
[04:19] <seb128> utch
[04:19] <pitti> seb128: so I assume I have to free some resource or whatever to make it wok
[04:19] <pitti> work
[04:19] <pitti> seb128: www.piware.de/gvfs-unmount.c shows my current version
[04:23] <pitti> seb128: do you think it will hurt much if I just call "pumount /dev/whatever" instead of going through the gvfs calls?
[04:23] <pitti> seb128: respective pumount -l
[04:23] <seb128> do whatever you feel right
[04:23] <pitti> okay
[04:23] <seb128> I've > 100 bugs in my list now, I don't really have time to look on this
[04:23] <seb128> sorry
[04:25] <pitti> seb128: np, just asked
[04:26] <pitti> seb128: I don't know much about this gvfs stuff...
[04:26] <seb128> where are you testing this function ?
[04:26] <pitti> seb128: it's not documented at all
[04:26] <seb128> I know ...
[04:26] <pitti> seb128: where? on my pc?
[04:26] <seb128> in nautilus
[04:26] <seb128> or as a standalone soft ?
[04:26] <pitti> seb128: I call n-c-b /path/to/image
[04:27] <seb128> ok
[04:28] <seb128> speaking with a gnome-vfs guy, he says that you should start to test it out of nautilus-cd-burner
[04:53] <pitti> seb128: I think I have found my error
[04:54] <seb128> oh ?
[04:54] <pitti> seb128: can you tell me which function to call when I'm waiting for something?
[04:54] <pitti> seb128: while(...) sleep(1) is not good since it does not process callback functions
[04:54] <pitti> seb128: is there something like a gnome_sleep_but_process_events()?
[04:56] <seb128> you can use g_idle_add ()
[04:56] <pitti> seb128: I call gnome_vfs_drive_unmount with a callback and must wait for the callback to be called
[04:56] <ross> while (gtk_events_pending ()) gtk_main_iteration ();
[04:56] <ross> might do what you want
[04:57] <seb128> yes, but that's ugly, isn't it ?
[04:57] <ross> depends what you want to do
[04:57] <seb128> you should use async stuff in nautilus
[04:57] <pitti> seb128: actually I want to unmount the CD synchronously
[04:57] <pitti> seb128: that's why I have to wait for the callback to happen
[04:57] <ross> you can probably block on a signal arriving
[04:59] <thom> seb128: yeah, still no change with FAST
[04:59] <seb128> same mime in gnomevfs-info ?
[05:00] <thom> yep
[05:01] <seb128> ok, thanks
[05:04] <pitti> l
[05:14] <thom> gar. does cdbs really annoy anyone else? :(
[05:14] <Kamion> thom: yep
[05:15] <daniels> thom: it's not that bad
[05:15] <daniels> i use it for all my xlibs packages, and it's used in dbus
[05:15] <daniels> what's wrong with it?
[05:15] <daniels> (then again, I have been known to like dbs)
[05:16] <thom> it just feels totally over engineered, and makes it far too hard to work out what's going on under the hood
[05:16] <thom> Kamion: oh good :-)
[05:21] <daniels> thom: how come acpi-support doesn't use dbs?
[05:22] <seb128> thom: bah, cdbs is cooool :)
[05:24] <thom> daniels: shuttit,foo
[05:24] <thom> seb128: you're french, though. i've seen french attempts at cool before ;-)
[05:25] <Kamion> cdbs is yet another of those things that the maintainers of packages who uses it love, and anybody else who tries to understand what's going on in those packages hates
[05:25] <Kamion> s/uses/use/ # I knew the grammar seemed funny when I wrote that
[05:25] <seb128> Kamion: you don't have to understand what's going on, the debian/rules has 3 lines most of the time
[05:25] <Kamion> seb128: oh yes I do
[05:25] <Kamion> when something breaks, as it does
[05:26] <Kamion> or when I want to change something
[05:26] <Kamion> I'm very very scared of any piece of software where somebody says "you don't have to understand what's going on" :-)
[05:26] <seb128> yes, cdbs is missing some documentation on the internals
[05:26] <seb128> yeah, but we use it for almost all the GNOME packages
[05:26] <Kamion> because it usually means that when I need to understand it I won't be able to
[05:26] <seb128> and no problem at all
[05:27] <Kamion> GNOME has a sane upstream, that's different ...
[05:27] <seb128> true
[05:36] <Kamion> I guess I can hack the new package into my local Ubuntu archive and debootstrap
[06:18] <pitti> l
[06:18] <pitti> sorry, wrong window...
[06:31] <pitti> mdz: already awake?
[07:07] <npmccallum> Kamion: can I get approval for 1516?
[07:08] <mdz> pitti: awake
[07:08] <pitti> mdz: Good morning!
[07:08] <pitti> mdz: The new utopia stack is ready
[07:08] <mdz> pitti: do you have i386 debs I can try?
[07:08] <pitti> mdz: but instead of typing it into IRC, I'm just writing an announcement to u-devel; might be better to test this on a broader basis
[07:08] <pitti> mdz: http://people.no-name-yet.com/~pitti/utopia/  (aptable)
[07:09] <pitti> mdz: The announcement will be on the list in a few minutes
[07:09] <mdz> ok
[07:11] <pitti> mdz: its now on the list
[07:13] <npmccallum> pitti: I did a dist-upgrade with your site in sources.list, it only upgraded dbus: no hal, etc
[07:13] <pitti> npmccallum: that's odd, let me look...
[07:13] <pitti> npmccallum: speling error :-) Packges.gt
[07:14] <pitti> npmccallum: can you please try it again=
[07:14] <pitti> npmccallum: s/=/?/
[07:15] <npmccallum> nope, not yet
[07:16] <Kamion> npmccallum: whoops, forgot about that. comment added. I want to look at that debconf encoding stuff before we blindly work around whatever the problem is.
[07:16] <npmccallum> pitti: I mean, I tried again, but its still not working
[07:17] <pitti> npmccallum: odd, http://people.no-name-yet.com/~pitti/utopia/Packages.gz now exists and shows all packages
[07:17] <pitti> npmccallum: did you apt-get update'd again?
[07:17] <npmccallum> yes
[07:18] <Kamion> npmccallum: (because it might indicate some problem in debconf's internationalization support, and if it does then we *must* fix that)
[07:18] <npmccallum> ok, I removed it from sources.list, readded it, re apt-get updated, and its working now
[07:18] <npmccallum> but it wants to remove GVM!?
[07:19] <pitti> npmccallum: the new hal conflicts to the older gvm
[07:20] <pitti> npmccallum: you have to upgrade gvm, too
[07:20] <pitti> npmccallum: can't apt work this out automatically?
[07:20] <npmccallum> but its not upgrading it
[07:20] <npmccallum> pitti: it should, but its not
[07:21] <npmccallum> pitti: you have no GVM package in your ~pitti/utopia directory
[07:21] <pitti> npmccallum: bad. In fact the Conflicts: even existed before, I just bumped the version
[07:21] <pitti> npmccallum: good point
[07:21] <pitti> npmccallum: sorry, I upload it
[07:23] <pitti> npmccallum: uploaded
[07:27] <pitti> npmccallum: does it work now?
[07:29] <Mithrandir> heh
[07:29] <Mithrandir> C-u does that
[07:29] <pitti> Mithrandir: tell that to a seasoned vim user :-)
[07:30] <npmccallum> pitti: everything is working well here, though I haven't done extensive testing
[07:30] <pitti> npmccallum: so apt-upgrading now works? Without any dpkg questions?
[07:30] <fabbione> YES
[07:30] <fabbione> YES
[07:30] <fabbione> YES!
[07:31] <fabbione> mdz: permission to upload X ubuntu22
[07:31] <npmccallum> pitti: yes, everything now works
[07:31] <fabbione> Xv extensions are working now
[07:31] <fabbione> confirmed by the testers
[07:31] <npmccallum> pitti: the new version even picks up my usb key :)
[07:31] <npmccallum> pitti: the old hal didn't :)
[07:31] <pitti> Mithrandir: not for me, BTW. ^U does nothing
[07:31] <mdz> fabbione: nice catch :-)
[07:31] <pitti> npmccallum: has it partitions?
[07:31] <mdz> fabbione: any other changes?
[07:31] <fabbione> mdz: ps i will upload tomorrow morning
[07:31] <npmccallum> pitti: yes
[07:31] <pitti> npmccallum: huh, what did hal-device-manager say to it?
[07:32] <pitti> npmccallum: anyway, great if it works now
[07:32] <fabbione> mdz: xfree86 (4.3.0.dfsg.1-6ubuntu22) warty; urgency=low
[07:32] <fabbione>   * Update 000_stolen_from_HEAD.diff:
[07:32] <fabbione>     + Include Xv/framebuffer fix for xf86xv.c.
[07:32] <fabbione>   * Update 030_Xserver_and_driver_region_primitive_fixups.diff:
[07:32] <fabbione>     + Fix REGION_EQUAL call in nv_driver.c.
[07:32] <fabbione>   * Update Czech debconf template translations (thanks, Miroslav Kure).
[07:32] <fabbione>   * Apply fix for Keycodes for PrintScreen and SysRq. (Closes: #1762)
[07:32] <fabbione> mdz: the first 2 are for the Xv extensions
[07:32] <mdz> fabbione: right, looks good, OK to upload
[07:32] <fabbione> mdz: third one.. you guess it
[07:32] <fabbione> mdz: hold on.. the latter.. please read what i wrote on the bug
[07:32] <mdz> fabbione: I remember the bug
[07:32] <fabbione> mdz: i added info
[07:32] <fabbione> mdz: with gdb info
[07:33] <fabbione> mdz: i applyed the patch from X.org but the problem is not in X
[07:34] <mdz> fabbione: so there is more than one bug, one of them not in X?  or there is no bug in X (in that case, what does the patch do)?
[07:34] <fabbione> mdz: the patch remaps SysRq (<alt>+print) to print
[07:34] <fabbione> mdz: it is applied in 2 points of the code
[07:34] <fabbione> mdz: but apparently applications still do not understand it
[07:35] <mdz> why should SysRq be remapped to print?
[07:35] <fabbione> mdz: the gdb session shows it clearly
[07:35] <mdz> I thought PrintScrn was the key to take a screenshot
[07:35] <fabbione> mdz: yes.. on i386 they are the same key
[07:35] <fabbione> mdz: that's correct
[07:36] <mdz> so print screen should -> Print and alt+print screen should -> SysRq
[07:36] <mdz> or is there no keysym for sysrq?
[07:36] <fabbione> mdz: that's what is actually happening
[07:36] <fabbione> apparently SysRq is used for screenshot of a window
[07:36] <fabbione> while print is for the entire screen
[07:36] <mdz> ahh, ok
[07:36] <fabbione> in both cases gnome fails to detected it
[07:37] <fabbione> so they bounced the crap down to xfree86
[07:37] <fabbione> xfree86 now has this lame remapping all over
[07:37] <fabbione> but applications still fail to get it
[07:37] <fabbione> anyway
[07:37] <fabbione> i am off for today
[07:38] <fabbione> mdz: someone needs to update linux-restricted
[07:38] <fabbione> with the latest kernel
[07:38] <mdz> ok
[07:38] <mdz> good night
[07:38] <fabbione> cya tomorrow
[07:38] <mdz> I don't see why X needs to remap that stuff, but if you think it is correct to include that patch, it's OK with me
[07:39] <fabbione> goody
[07:39] <fabbione> i will upload tomorrow
[07:59] <elmo_> Kamion: ?
[08:03] <Kamion> elmo_: yep?
[08:15] <elmo_> kamion: linux-image bumped soname (or whatever) - can you let me know when I can remove the old ones?
[08:15] <elmo_> (no rush)
[08:18] <Kamion> npmccallum: the new default bash colours are really foul; when you pop up a terminal you get bright green on white for the username/hostname, which is bordering on painful to read
[08:18] <Kamion> can we have some slightly more background-neutral ones?
[08:19] <npmccallum> Kamion: I'm not sure what you mean -- There are no colors on by default
[08:20] <Kamion> npmccallum: I just installed from a daily build and got these
[08:20] <Kamion> (amd64, but I'm sure it doesn't matter)
[08:20] <npmccallum> Kamion: it wasn't my doing then
[08:20] <Kamion> npmccallum: ah, maybe doko's changes
[08:21] <Kamion> I thought he talked to you about those
[08:21] <Kamion> elmo_: ok, will do, need to rev linux-kernel-di-*
[08:21] <npmccallum> He mentioned that he found a typo (rogue colon)
[08:21] <npmccallum> but that was it
[08:21] <npmccallum> maybe he did some other stuff too, I have no idea
[08:24] <Kamion> npmccallum: 1164     Sep 25 Matthias Klose  (  50) Accepted bash 2.05b-2-15ubuntu4 (source)
[08:27] <Kamion> nevertheless, perhaps colours which look somewhat better with our default terminal would be a good idea
[08:28] <npmccallum> Kamion: I turned on colors for the terminal a while ago and almost got shot :)
[08:28] <Kamion> yeah, I don't think colours-by-default is going to be too popular :)
[08:28] <npmccallum> its not with people coming from the debian world, but it is with people coming from gentoo and the like
[08:29] <Kamion> do they really like eye-bleedingly painful colours? :-)
[08:29] <npmccallum> the colors that I originally put in are from Gentoo, though I don't know if they have been changed or not
[08:29] <Kamion> (I wouldn't be too upset with darker ones)
[08:29] <npmccallum> bright green looks good with a black background
[08:29] <Kamion> perhaps Gentoo's terminal has a black background by default
[08:30] <npmccallum> it does
[08:30] <npmccallum> well, not the gnome one
[08:30] <Kamion> of course, I switch the terminal to a black background first chance I get, but ...
[08:30] <npmccallum> me too :)
[08:31] <npmccallum> there isn't
[08:31] <npmccallum> its all ansi escape codes
[08:31] <Kamion> didn't think so - oh well
[08:31] <Kamion> well, you can retrieve the background colour using ANSI escape codes
[08:31] <Kamion> it's just painful
[08:32] <mdz> elmo_: speaking of the kernel, there should be more NEW enjoyment for linux-meta now, and linux-restricted-modules shortly
[08:33] <mdz> I'm not sure that linux-meta is quite right yet
[08:33] <npmccallum> Kamion: we should just make gnome-terminal's colors white on black by default ;) (if you want to get shot that is)
[08:33] <mdz> Kamion: do you agree that it would be nice to have a single metapackage which would install matching versions of the kernel and restricted-modules, for d-i purposes?
[08:33] <Kamion> mdz: definitely
[08:34] <npmccallum> mdz: that would fix bug #1835
[08:34] <Kamion> mdz: although I'm not sure how well it plays with people who want to remove the restricted-modules
[08:34] <mdz> Kamion: right
[08:34] <mdz> the question is whether we should have two
[08:34] <mdz> one which gives you the latest recommended kernel
[08:34] <mdz> and one which gives you the kernel + restricted-modules
[08:34] <mdz> and if we should, what do we call them?
[08:35] <Kamion> no good ideas on naming I'm afraid
[08:36] <mdz> currently we have linux-<flavour> which depends on both image and modules
[08:36] <mdz> but it's in main, and depends on restricted
[08:36] <mdz> so it seems to want to be split for that reason as well
[08:36] <Kamion> I can deal with installing two packages
[08:36] <mdz> well, we also need it for upgrades
[08:37] <mdz> otherwise the image gets upgraded and the modules never do
[08:37] <mdz> and they just vanish
[08:37] <Kamion> you could make the restricted-modules metapackage depend on an exact version of the kernel metapackages
[08:38] <Kamion> s/s$//
[08:38] <Kamion> then you'd have to upgrade it or remove the metapackage, and if people remove the metapackage then we can't help them anyway
[08:38] <mdz> hmm
[08:39] <Kamion> and since the two come from the same source package, there's no maintenance issue with having Depends: linux (= ${Source-Version})
[08:39] <Kamion> (or whatever)
[08:39] <mdz> well, the modules concrete package depends on an exact kernel version
[08:39] <mdz> so if we start installing the modules metapackage rather than the concrete, we should get reasonable upgrade behaviour
[08:40] <Kamion> right
[08:41] <mdz> tying them together with a metapackage seems like the right thing to do, there is only this naming problem
[08:41] <mdz> Jane bailed us out of the last naming roadblock; I'll ask her
[08:41] <mdz> hm, she left
[08:41] <Kamion> this is relatively easy to do in base-installer, but I was holding off fixing the bug that made it not work until I had a restricted-modules metapackage
[08:41] <doko> kamion: my mistake, I left the color prompt enabled after testing. I'll have to make a new upload disablint it.
[08:41] <Kamion> mdz: you don't get reasonable upgrade behaviour just from that, actually
[08:42] <Kamion> mdz: since the old kernel concrete package stays installed
[08:42] <mdz> Kamion: aptitude will remove it
[08:42] <Kamion> which is why I think metapackage dependencies are necessary
[08:42] <mdz> but arguably it should stay installed, in case the new one breaks
[08:42] <Kamion> what? that's insanity
[08:42] <mdz> well, the install kernel should always stay, since that was installed explicitly
[08:42] <mdz> but things pulled in by metapackage dependencies will be removed by aptitude when the dependency goes away
[08:42] <Kamion> won't the kernel package stay, since the prerm bails out if it's the currently running kernel?
[08:43] <mdz> hmm, possibly
[08:43] <mdz> I bet that pisses aptitude off
[08:43] <mdz> anyway, speaking of kernels, it's time for a couple of reboots to test if -3 fixes my issues
[08:43] <mdz> brb
[08:44] <Kamion> elmo_: linux-kernel-di-* uploaded, let me know when you've NEW-processed them since I need to change debian-installer at that point
[08:47] <elmo_> Kamion: hmm, don't see them?
[08:47] <elmo_> oh, right, being built
[08:48] <Kamion> yeah
[08:49] <mdz> yay, fixes the APIC issue with my system
[08:49] <Kamion> mdz: been trying to fix the debconf noninteractive/seen thing; turns out to be amusing to fix, my current attempt causes the aa_DJ locale to be generated by default on new installations
[08:50] <mdz> Kamion: aa_DJ and only aa_DJ?  or all of them?
[08:50] <Kamion> (I'm relatively sure we don't have enough Afar speakers to merit that :-))
[08:51] <Kamion> mdz: only aa_DJ; the default implementation of the noninteractive select element sets the value to the first item in the list
[08:51] <Kamion> and evidently I've slightly changed the behaviour there, not so unexpectedly ...
[08:52] <elmo_> linux-restricted-modules-2.6.8.1_2.6.8.1.1-6_i386.changes
[08:52] <elmo_> SKIP (too new)
[08:52] <elmo_> Rejected: nvidia-kernel-source_1.0.6111-1ubuntu2_i386.deb: old version (1.0.6111-1ubuntu2) in warty >= new version (1.0.6111-1ubuntu2) targeted at warty.
[08:56] <mdz> oh EW
[08:57] <mdz> need to manually update debian/rules for every new version
[08:58] <mdz> uploading -7
[08:59] <Kamion> off to karate, back in a couple of hours
[09:09] <mdz> hmm
[09:09] <mdz> is it just me, or are linux-meta and linux-source now building some of the same binaries?
[09:09] <tseng> hi.
[09:09] <mdz> elmo_: I suppose that's something that ought to be fixed in short order?
[09:18] <elmo_> mdz: it's not disastrous from my POV?
[09:18] <mdz> elmo_: which one will end up in Packages?
[09:18] <elmo_> whichever is newer
[09:18] <elmo_> if they're the same one will be  REJECTed
[09:18] <mdz> fascinating.  that happens to be the right thing in this case
[09:19] <mdz> er, no it doesn't
[09:19] <mdz> -meta is at 2.6.8.1-5, and -source is at -8
[09:20] <mdz> elmo_: if I remove the metapackages from linux-source, will that do the right thing and let the -meta ones come out, or will it disappear?
[09:21] <elmo_> mm, people are wanting to go for food
[09:21] <elmo_> mdz: nothing will disappear automatically
[09:21] <mdz> elmo_: so I should upload linux-meta with a higher version number, I suppose
[09:22] <elmo_> mdz: yeah, sounds like a plan
[09:22] <mdz> elmo_: ok, don't let me keep you. a thumbs up/down on that plan would be great
[09:22] <mdz> ok
[09:26] <fabbione> bah i can't sleep
[09:32] <thom> or a copy of the X protocol specs
[09:32] <thom> i guess either would work
[09:33] <Mithrandir> sounds icky
[09:33] <fabbione> thom: ?
[09:38] <fabbione> thom: dude.. what's going on?
[09:51] <doko> mdz: as I need to disable the colorprompt anyway, should #1758 (lesspipe) really be enabled by default in the profile?
[09:52] <mdz> doko: you need to disable the prompt why?
[09:53] <doko> mdz: the ugly color prompt I left enabled by default
[09:53] <mdz> doko: oh, did it become enabled in your last upload or something?
[09:54] <doko> yes, I accidentally left it on after trying.
[09:54] <mdz> eek
[09:54] <mdz> I see, it is only in the skel
[09:54] <mdz> doko: do you see any harm in enabling lesspipe by default?
[09:55] <doko> in that case I would like to alias more to less, so that the user has the same experience with both commands.
[09:56] <mdz> that doesn't make sense to me; they have different user interfaces
[09:59] <doko> for a beginner, they are about the same, but "more changelog.gz" and "less changelog.gz" should have the same experience.
[10:01] <mdz> I think that enabling lesspipe in less and aliasing more to less are entirely separate propositions
[10:02] <doko> welcome to the can of worms of user profiles ;-) I'll add the lesspipe suggestion, but I would prefer to leave it commented out.
[10:02] <mdz> some programs can view compressed files, and some cannot (e.g., vim/emacs vs. gedit), but they should remain distinct because users expect to get what they ask for
[10:03] <mdz> ok, if you have doubts, please raise the issue for discussion on ubuntu-devel
[10:15] <mdz> doko: please don't wait to fix the colour prompt bug; that must be fixed for the next daily CD build
[10:16] <doko> fine, and for now I added the lesspipe line as well (commented out).
[10:25] <thom> fabbione: either one would help you sleep ;-)
[10:26] <fabbione> thom: ehehe i got it.. very late ;)
[10:26] <thom> just converted firefox to dpatch
[10:44] <npmccallum> Kamion: thanks for fixing the po-debconf bug :), you should probably report something on #1329
[11:14] <Kamion> npmccallum: it was waiting for a sync, hadn't yet read the mail that the sync was done
[11:14] <Kamion> I did update the status whiteboard on #1329 earlier :)
[11:16] <Kamion> npmccallum: oh, bugger, no I didn't, I had a mid-air collision in bugzilla and forgot to follow through. anyway, closing now
[11:58] <mdz> Kamion: how long before the new kernel propagates to a daily CD?