[00:28] <Snova> The link at the end of the topic is broken, probably because you seem to have hit the limit. :)
[00:31] <cjwatson> blink, pitti's client obviously allows a longer length than mine
[00:31] <cjwatson> hopefully gdm won't be an issue by the time alpha-3's released
[00:32] <slangasek> any bug numbers for that which ought to get milestoned?
[04:57] <coolbhavi> hello team if nobody has any objections I ll prepare diffs for some packages affected by https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/391165
[05:08] <lifeless> how do you choose login language now?
[05:12] <RAOF> Down the bottom of the GDM screen there's a listview.
[05:12] <RAOF> A _dreaded_ listview :).  Maybe we can make gdm crash :)
[05:14] <RAOF> This only appears when you've selected a user to log in as, though.
[05:20] <lifeless> not with todays gdm :P
[05:20] <lifeless> OTOH I'm getting other errors all over the place
[05:22] <RAOF> Heh.  I think I might still have gdm -ubuntu3 here, so...
[05:55] <wgrant> RAOF: Do you know of a bug about the listview crasher?
[05:56] <RAOF> wgrant: Yeah; it's...
[05:56] <RAOF> bug #391398
[05:56] <wgrant> RAOF: Thanks.
[05:56] <RAOF> It's apparently gtk using deprecated APIs internally, and missing the crucial difference between an int and a pointer.
[05:57] <wgrant> Haha.
[05:57] <wgrant> It's also incredibly annoying.
[05:57] <RAOF> Yes.
[05:57] <wgrant> I can't *quite* work out how to trigger it.
[05:58] <RAOF> There are some git commits referenced in that report, and, of course, sizeof(int) == sizeof(void *) for IA32.
[05:59] <RAOF> wgrant: Evolution is the best way of triggering it that I've found.
[05:59] <wgrant> RAOF: Some listboxes only do it when you manipulate them in a particular way.
[06:00] <wgrant> The OS selector in virt-manager, for example.
[06:00] <RAOF> Yeah.
[06:00] <wgrant> It's usable unless you use it wrong.
[06:00] <RAOF> Which is why I haven't rolled a local gtk package with those git commits added; it's insufficiently annoying.
[06:00] <RAOF> It's _just_ easy enough to work around :)
[06:01] <wgrant> Yep.
[06:02] <maxb> There'd be a PPA one by now, if the buildds weren't supersaturade
[06:02] <maxb> *supersaturated
[06:03] <wgrant> Yes...
[06:03] <wgrant> All those daily builds, and only three guaranteed buildds per arch...
[06:04] <ajmitch> wgrant: be glad it's not daily builds of bigger packages
[06:04] <wgrant> ajmitch: They are pretty big...
[06:08] <ajmitch> it shouldn't be so easy to cause a permanent backlog
[06:15] <maxb> I suppose it could be worse. It could be dailies of OOo :-)
[06:17] <ajmitch> maxb: I was thinking of that one, as well as ooo-l10n :)
[06:17] <Sarvatt> just hoping noone is trying to build 3 gcc's in there or else we'll be out another entire day :D
[06:18] <wgrant> Or a Linux or three.
[06:18]  * maxb wishes for bug 155758
[06:19] <wgrant> Unfortunately that wouldn't be reliable now.
[06:19] <Sarvatt> i'd put $10 on theres at least 10 linuxes lined up in that i386 queue
[06:19] <wgrant> As there are lots of P3As.
[06:19] <Sarvatt> its the new fad :D
[06:19] <wgrant> That bug has a nice activity log.
[06:21] <maxb> Unless P3A builds just vanish the builder from the builders page, there don't seem to be that many P3A builds
[06:22] <wgrant> maxb: The builders appear with a red X next to them. Sometimes there are lots, but sometimes there are none.
[06:24] <maxb> ok - I've not seen that for PPA builders very often
[06:24] <maxb> So I think a PPA +builds would still be adequately useful
[06:24] <wgrant> Maybe I just look at it at bad times.
[06:24] <wgrant> It would certainly still be useful.
[07:02] <dholbach> good morning
[07:03] <dholbach> pitti: can you merge  ~chrisccoulson/gnome-power/2.27.2-update  into  ~gnome-power-manager-team/gnome-power/trunk ?
[07:04] <dholbach> (I should have checked before, but I thought "it's going to be a ~ubuntu-desktop branch I can push to")
[07:07] <pitti> Good morning
[07:08] <pitti> cjwatson: hm, /topic looks fine for me indeed
[07:09] <pitti> but I think we can remove the gdm link tomorrowish
[07:17] <pitti> dholbach: pulled, and debcommit -r'ed; thanks!
[07:17] <dholbach> pitti: thank chrisccoulson :)
[07:17] <pitti> I will (and did yesterday), but not online ATM :)
[07:18]  * TheMuso sees that keyboard backlight devices/ambient light sensor support was removed, and wonders why, since the git log doesn't go into any detail.
[07:18] <TheMuso> from gnome-power-manager that is
[07:19] <pitti> TheMuso: this is currently a bit in flux
[07:19] <pitti> TheMuso: we don't use hal any more, and devkit-power doesn't have/isn't supposed to have that
[07:19] <pitti> the correct solution is to have this in X itself (XBACKLIGHT)
[07:19] <TheMuso> ah ok
[07:19] <pitti> http://lists.freedesktop.org/archives/devkit-devel/2009-July/000268.html FYI
[07:20] <TheMuso> tah
[07:21] <pitti> asac: did you see the "also introduces a bug" report in bug 220628 ?
[07:22] <pitti> sbeattie: thanks for all the vm-builder tests! I think it's good enough to move to -updates now
[07:23]  * mvo hugs sbeattie too
[07:24] <sbeattie> pitti|mvo: thanks, and I agree, it should go to -updates.
[07:26] <pitti> nice, 335 days in -proposed
[07:30] <TheMuso> ...oh and wow, what an argument. :)
[07:33] <\sh> moins
[07:33] <pitti> TheMuso: was pretty heated indeed :/
[07:35] <\sh> dear devs, please get rid of klibcs ipconfig for kernel nfs root mounts...it's really a pain in the a** *gnarf*
[07:37] <\sh> ipconfig + low cost table switches == works like a charm, but using cisco switches with spanning trees and portfast configs etc. it gives you really nightmares
[07:39] <\sh> the timeframe between bringing the NIC up and the first dhcp request from ipconfig is too fast and then it failes mostly with a kernel error: can't mount nfs rootfs , setting the timeout up to 180 secs (which should be more then enough to have ipconfig retry it's request) is not even enough...-t 240 to -t 360 is the only way to force ipconfig to redo the request...but that's far too long
[07:54] <YokoZar> jcastro: who is in charge of the web server?  there's a bug with videos.ubuntu.com
[07:54] <YokoZar> (it's showing wrong MIME type, labeling the videos as text/plain, so this happens (except in Firefox): http://i41.tinypic.com/14ub8xz.png
[07:57] <persia> YokoZar, You might try a bug against ubuntu-website (although it may be different)
[07:57] <YokoZar> persia: yeah i just had that thought
[07:57] <YokoZar> thanks
[08:30] <dholbach> are there bugs open for gdm-login-twice and gdm-gnome-session-can't-remember-bla?
[08:45] <pitti> dholbach: for the latter, yes
[08:45] <pitti> dholbach: for the former, what do you mean?
[08:45] <dholbach> the popup I get after logging in
[08:46] <dholbach> gnome-session couldn't save your bla something gdm-simple-greeter
[08:46] <dholbach> hiya chrisccoulson
[08:46] <pitti> dholbach: right, that's "the latter", and has a bug
[08:46] <pitti> dholbach: I mean "login-twice"?
[08:46] <dholbach> ah sorry :)
[08:46] <chrisccoulson> hi dholbach
[08:46] <pitti> hey chrisccoulson
[08:46] <dholbach> when I log in, it starts doing something, then I get the login window again
[08:46] <chrisccoulson> hi pitti
[08:46] <dholbach> so I have to log in twice
[08:47] <persia> dholbach, I had that, and TheMuso had that.  I had a hw failure when reproducing, and haven't filed.  If you do file, please subscribe me.
[08:48] <dholbach> hm, no /var/log/gdm?
[08:49] <dholbach> pitti: clearer now?
[08:49] <ion> I’m sorry, but i snickered at “I had a hw failure when reproducing”.
[08:49] <pitti> dholbach: ah, bug 396226
[08:50] <pitti> dholbach: that was extensively discussed, and the problem is understood, but not quite trivial to solve
[08:50] <pitti> dholbach: workaround: disable "splash"
[08:50] <dholbach> pitti: I'm not sure I have that problem - it's not several minutes
[08:50] <pitti> well, it depends what you are doing
[08:50] <dholbach> I boot, get gdm, log in, it does something for 1-2 seconds, then gives me the login window again
[08:51] <pitti> dholbach: and then it never crashes again?
[08:51] <dholbach> no, then I can go ahead and do my stuff
[08:51] <pitti> ok, sounds like that bug then
[08:51] <pitti> dholbach: try booting without splash, that should fix it
[08:51] <dholbach> ok, I'll try with the next reboot
[08:51] <dholbach> thanks pitti
[08:51]  * pitti hugs dholbach
[08:51] <dholbach> more power to the pitti!
[08:52] <geser> dholbach: is your other problem bug #395324?
[08:52] <dholbach> geser: yes, I guess so
[08:52] <persia> pitti, just with nosplash on the kernel cmdline?
[08:53] <pitti> persia: drop "splash"
[08:54] <persia> OK.  Booting with "nosplash" fixed it for me.  Trying again without any mention.
[09:00] <ajmitch> pitti: interesting, which gdm versions does that problem affect?
[09:00] <pitti> ajmitch: >= 2.26
[09:01] <ajmitch> I'm guessing it only affects some people, since I haven't had a problem since rebooting
[09:02] <persia> Booting without any mention of splash fixes it as well.
[09:02] <geser> ajmitch: check on which tty you currently are on: tty1 or tty7
[09:03] <ajmitch> persia: I know I have splash set, I had to wait through a fsck of 450GB
[09:03] <ajmitch> geser: X reports being on tty7
[09:03] <geser> ajmitch: then you are lucky
[09:04] <persia> ajmitch, Dunno then.  Just started happening to me yesterday on karmic.  Doesn't happen anymore without splash.
[09:04] <geser> it only happens when gdm and getty fight for tty1 and gdm loses
[09:04] <ajmitch> sounds like a fun bug to solve
[09:06] <persia> geser, Amusingly, I have X on tty7, once it works.
[09:07] <persia> Well, easy way to fix it is just to get the boot fast enough that we don't need splash, which I understood to be the goal.
[09:07] <geser> yes, it only happens to the first gdm, after one gets kicked gdm takes tty7
[09:34] <chrisccoulson> pitti - would you like to review the changes in https://code.edge.launchpad.net/~chrisccoulson/gnome-session/ubuntu ? It splits gnome-session in to 2 packages now. With the current single package, the new GDM dependency on gnome-session causes a broken gnome to be started on Xubuntu instead of xfce
[09:36] <pitti> chrisccoulson: right, this was discussed yesterday; is this a Debian merge? (they did the split)
[09:36] <chrisccoulson> the split is basically taken from debian, with a couple of minor changes. they also moved all the autostart files from /etc/xdg/autostart to /usr/share/autostart, which hasn't been copied across
[09:38] <chrisccoulson> and i put the helpers in gnome-session instead of gnome-session-bin, although these need splitting some more, as GDM requires the g-s-d helper it seems
[09:39] <chrisccoulson> and i've just noticed the gnome-settings-daemon dependency needs to move from gnome-session to gnome-session-bin, as that seems to be required by GDM too
[10:02] <ogra> cjwatson, please merge (once again) https://code.launchpad.net/~ogra/debian-cd/ubuntu ... for the armel kernel version bump
[10:04] <ogra> i'D really like to find a way to automate that ... even if its only screen scraping the d-i changelog
[10:08] <chrisccoulson> mr_pouit - i merged your changes on the gnome-session split last night
[10:08] <chrisccoulson> this would still leave you with 2 session managers on the default install though wouldn't it?
[10:10] <pitti> mvo: btw, did you see my reply in bug 392074?
[10:12] <dholbach> pitti: confirmed (gdm-login-twice)
[10:13] <mvo> pitti: I had this spec on hold until some linux-meta fixes, sorry - I will answer in the report, but the summary is that its (or seems to be) useful if the user wants to do a local retrace
[10:14] <pitti> mvo: it shouldn't; well, let's discuss it in the bug repor
[10:14] <pitti> t
[10:15] <mvo> pitti: maybe I don't understand apport well enough, but its seems to me that adding the information right away is cheap and useful.  it shouldn't means that it should not include this information?
[10:16] <mvo> we can as well talk here, its probably quicker :)
[10:16] <pitti> mvo: no, but the information you want (and more) is already collected
[10:16] <mvo> so fater a reboot the vmcore is converted to a crash file. at this point not a lot of info is there
[10:17] <pitti> right, you need to process it through apport
[10:17] <mvo> now if the user wants to run apport-retrace on this that will fail until it got processed further
[10:17] <pitti> (... UI)
[10:17] <mvo> so this should not be a supported use-case? or should apport-retrace add the info? or should it be first go through the UI and then do a local retrace?
[10:17] <pitti> mvo: phone, bbl
[10:18] <mdz> dholbach, happens to me too
[10:18] <mdz> is there a bug report for gdm-login-twice?
[10:18] <Laney> bug 396226?
[10:19] <dholbach> mdz: the workaround is to disable 'splash'
[10:19] <persia> Laney, That's not the same bug.
[10:20] <dholbach> persia: pitti said it was
[10:20]  * persia rereads the bug again
[10:22] <persia> Hrm.  I'm not sure how the race could persist for minutes, but perhaps.
[10:37] <ogra> hmm, isnt gdm supposed to run on tty1 with the latest upgrade ?
[10:37]  * ogra still has it on tty7
[10:37] <cjwatson> ogra: merged that debian-cd branch, thanks. The way to automate it is to get the kernel fixed so that we don't need it
[10:37] <ogra> cjwatson, indeed, but i was looking for an interim solution
[10:38] <ogra> the prob is that i only notice it a day after the builds failed
[10:38] <dupondje> damn gotto love flash :( NOT :(
[10:38] <ogra> and i dont want to trigger .1 builds ... just because i forgot once again to notice the d-i upload on -changes
[10:39] <ogra> though i'm starting to care for armel builds again, shouldnt be that often anymore if i'm really caring
[10:43] <cjwatson> ogra: ok, I've killed off the hardcoding
[10:43] <cjwatson> (though haven't tested the new code straight-through)
[10:44] <ogra> oh !
[10:44] <ogra> wow, thanks
[10:44] <ogra> i also noticed that someone already added the subarchitecture (armel+imx51) code to make-web-indicies :)
[11:02] <highvoltage> wow, switching between a VT and X on karmic is super fast.
[11:03] <StevenK> And that's one reason KMS is win
[11:08] <highvoltage> StevenK: totally :)
[11:13] <pitti> re
[11:13] <pitti> ogra: no, it's not really supposed to run on vt1, since it conflicts with getty there
[11:13] <pitti> mdz: ^
[11:13] <pitti> mvo: re
[11:14] <pitti> sorry, that was a long phone call
[11:14] <ogra> i though getty was gone in favour
[11:15] <enrico> mvo: any news on pdiff? Did you test the curret git of a-x-i? Can I just go ahead and upload?
[11:17] <pitti> mvo: (answered)
[11:23] <cjwatson> Keybuk: I have a udevd here which appears to be refusing connections from udevadm - I don't know if I'll be able to reproduce this, so is there anything I can do to debug things before I reboot?
[11:23] <cjwatson> (this is in d-i)
[11:25] <cjwatson> Keybuk: actually, they don't even seem to be getting the message from udevadm at all, judging from strace
[11:25] <cjwatson> it's like they've fallen off the Unix socket namespace or something
[11:28] <mdz> pitti, hmm?
[11:29] <cjwatson> ah, a udevd segfaulted somewhere ...
[11:30] <Keybuk> cjwatson: that's odd, normally it tends to go away on a segfault ;)
[11:32] <cjwatson> I guess some bit of it did but the rest hung around in a broken state
[11:35] <cjwatson> Keybuk: well, bug 396957, I don't know if there's anything useful that can be done with that but just in case
[11:36] <Keybuk> cjwatson: I wonder whether the daemon died and left some workers?
[11:36] <cjwatson> yes, it looks like it
[11:36] <Keybuk> do you have a copy of "ps" at the time?
[11:36] <cjwatson> at which time?
[11:36] <Keybuk> at the time you thought "oh, this has died"
[11:36] <Keybuk> also, no core dump?
[11:36] <Keybuk> have you looked in /var/crash?
[11:37] <cjwatson> it's got four "udevd --daemon --resolve-names=never" processes
[11:37] <cjwatson> do you need the whole thing?
[11:37] <Keybuk> sure, but the details of those four would be quite interesting
[11:37] <cjwatson> no /var/crash in d-i
[11:37] <Keybuk> ah, in d-i
[11:37] <Keybuk> damn
[11:37] <Keybuk> no /core ? :)
[11:37] <cjwatson> no, sorry :-/
[11:37] <Keybuk> can you attach dmesg to that bug report (not dmesg log)
[11:38] <Keybuk> oh, it's ok
[11:38] <cjwatson> done, and ps output too
[11:38] <cjwatson> I think dmesg all just goes to syslog though
[11:39] <Keybuk> yeah looks like it
[11:43] <cjwatson> Keybuk: if it's relevant, it's possible that udevadm trigger may be involved here, since the point where it failed is shortly after d-i installs extra udebs into memory which may contain new kernel modules
[11:43] <cjwatson> that may just be coincidental though
[11:44] <cjwatson> hmm, I don't suppose we keep separated debugging symbols for udebs anywhere ...
[11:45] <cjwatson> we do! bloody hell
[11:46] <cjwatson> pitti++
[11:51] <cjwatson> pitti: is there any way to get back from "udevd[663]: segfault at 4 ip 00959fbc sp bfbe7b78 error 6 in udevd[94f000+1c000]" to a line of source, assuming that I have the corresponding udevd with debugging symbols loaded in gdb?
[11:52]  * pitti scratches head
[11:52] <cjwatson> I assume relocation is going to screw me over somehow
[11:54] <Keybuk> yeah you need a core file
[11:55] <Keybuk> of course, "segfault at 4" is a bit damning in of itself ;)
[11:55] <cjwatson> oh, is that an address? :)
[11:55] <Keybuk> yes
[11:55] <Keybuk> well
[11:55] <Keybuk> it's _supposed_ to be the address ;)
[11:56] <Keybuk> "info symbol" might help
[11:56] <cjwatson> so it is
[11:56] <Keybuk> I assume it's karmic?
[11:56] <cjwatson> yes
[11:56] <cjwatson> udev-udeb 143-8
[11:56] <cjwatson> (i386)
[11:56] <pitti> list *(address) could also help
[11:56] <cjwatson> info symbol what?
[11:57] <pitti> would the IP be a valid address?
[11:57] <cjwatson> it doesn't like either 0x00959fbc or 0x1c000
[11:57] <pitti> list *(00959fbc) ?
[11:57] <Keybuk> cjwatson: i386 or amd64?
[11:57] <cjwatson> 11:56 <cjwatson> (i386)
[11:57] <cjwatson> pitti: nope
[11:58] <pitti> I used that for kernel panics and traces
[11:58] <cjwatson> 0x00959fbc - 0x0094F000 == 0xAFBC
[11:58] <cjwatson> which is apparently udev_list_node_remove + 11
[11:59] <cjwatson> that being 0x0000afbc <udev_list_node_remove+11>:  mov    %edx,0x4(%ecx)
[11:59] <cjwatson> and udevd.c:handle_signal calls udev_list_node_remove right after the last error message from udevd in the log
[12:00] <Keybuk> that sounds totally plausible
[12:01] <Keybuk> where did you get the 94f00 from?
[12:01] <cjwatson> udevd[94f000+1c000]
[12:01] <Keybuk> interesting
[12:01] <cjwatson> I guessed that that was a relocation base address
[12:02] <cjwatson> indeed it's vma->vm_start in the kernel
[12:02] <Keybuk> the next one being the size, I assume?
[12:02] <cjwatson> vma->vm_end - vma->vm_start
[12:02] <cjwatson> so yes
[12:03] <cjwatson> (this is print_vma_addr in mm/memory.c)
[12:06] <Keybuk>         next->prev = prev;
[12:06] <Keybuk> would be the crashing line then
[12:06] <cjwatson> or prev->next = next; ?
[12:06] <Keybuk> no, that one
[12:06] <Keybuk> info line *0xafbc
[12:06] <Keybuk> Line 76 of "../../udev/libudev/libudev-list.c" ...
[12:07] <cjwatson> ah, good call
[12:10] <cjwatson> Keybuk: is there anything more that might be extractable from the running image, or can I reboot it?
[12:13] <Keybuk> cjwatson: I don't think so :-/
[12:14] <cjwatson> bit of an exercise in telepathy
[12:14] <cjwatson> ok, let's see if it happens again ...
[12:16] <liw> mvo, python-apt is deprecating some stuff; is there a transition guide to convert them to new stuff?
[12:24] <cjwatson> Keybuk: oho, it happened again
[12:25] <cjwatson> let me see if I can make it happen a third time but this time with a core dump
[12:26] <Keybuk> cjwatson: neat
[12:29] <cjwatson> hmm. lots of workers unexpectedly exiting, but the daemon isn't crashing after ulimit -c unlimited ...
[12:41] <cjwatson> damn! I reproduced it and then alt-f4'ed kvm by accident
[12:41] <cjwatson> hate that keybinding
[12:42] <Keybuk> doofus
[12:43] <cjwatson> while :; do update-dev; kill -HUP $udevd_pid; done # seems to trigger it eventually
[12:43] <ion> pkill -HUP udevd? :-)
[12:43] <cjwatson> d-i
[12:43] <ion> Alright
[12:43] <cjwatson> thanks but there's no need to educate me in tools that I know about and also know are not available in this context ;-)
[12:44] <cjwatson> and in any case I explicitly don't want to kill the udevd children, only the parent
[12:44] <ion> Right
[12:44] <mvo> enrico: no news on pdiffs, sorry. but I tested it and it looks fine
[12:44] <cjwatson> gotcha
[12:45] <mvo> liw: no formal one afaik, but julianK may be preperaring one. its bascily "installVersion" -> install.version
[12:47] <liw> mvo, ok, I'll how that works for me
[12:48] <cjwatson> Keybuk: core dump on the bug now, though I'm having no luck at getting gdb to take it here
[12:52] <enrico> mvo: ok, then I'll just upload it as it is, and we can do an extra improvement step if the pdiff way is viable
[12:53] <evand1> cjwatson: Do you not use -no-quit?
[12:53] <evand1> in KVM, that is
[12:55] <mvo> enrico: excellent
[12:57] <cjwatson> evand1: I may do from now on :)
[12:57] <cjwatson> I didn't know about that
[12:57] <evand1> I think we all find out about it the hard way
[13:11]  * Keybuk weeps about how needlessly hard utmp/wtmp is
[13:13] <ion> Yeah
[13:13] <Keybuk> at least I finally figured out why "last" thinks all rebooted Upstart-based machines "crashed" :-)
[13:17] <Keybuk> cjwatson: mind applying http://people.ubuntu.com/~scott/d-i-udev-crash.patch and trying again?
[13:22] <tjaalton> is it ok to rebase an SRU candidate with the stable debian version, if the packages are derived from the same version?
[13:23] <cjwatson> Keybuk: thanks - rebuilding
[13:23] <cjwatson> tjaalton: not usually - keep the change minimal
[13:24] <tjaalton> cjwatson: ok, I
[13:24] <tjaalton> hrm
[13:24] <tjaalton> I'll just snatch the patches then
[13:26] <Keybuk> cjwatson: at the very least, this will add a message saying why it's about to crash :p
[13:48] <djsiegel_> pitti: ping
[13:48] <pitti> hey djsiegel_
[13:52] <djsiegel_> pitti: sorry, as soon as I contact you I get interrupted...
[13:52] <djsiegel_> 2 minutes...
[13:52] <djsiegel_> pitti: ok
[13:53] <djsiegel_> pitti: openSUSE, Jolicloud, and now moblin are integrating Do
[13:53] <djsiegel_> pitti: I have a lot of feedback from UNR users who installed Do and put it to great use
[13:53] <djsiegel_> I think it's even being considered for UNR already
[13:54] <djsiegel_> Mark asked me 8 months back about putting in main, and I said -1 because it's kind of an advanced user app
[13:54] <djsiegel_> but I am getting a lot of pressure from GNOME at GCDS to put it in GNOME (I think they are determined to)
[13:54] <djsiegel_> so, I think we should talk about shipping it with karmic
[13:55] <pitti> djsiegel_: hm, I haven't used it myself, but it seems to me that gnome-shell does a lot of this as well?
[13:56] <djsiegel_> pitti: no, it's very different
[13:56] <djsiegel_> pitti: and are we shipping gnome-shell in Karmic?
[13:56] <pitti> djsiegel_: not by default, but it'll be available
[13:56] <ogra> we would if upstream did
[13:56] <djsiegel_> Do is tested, translated, and has millions of installs
[13:56] <djsiegel_> gnome-shell will not be on in 2.28
[13:57] <djsiegel_> it indexes your online contacts, docs, twitter friends, etc etc etc
[13:57] <pitti> using tracker?
[13:57] <djsiegel_> no, its own indexer
[13:57] <pitti> uh
[13:57] <djsiegel_> Mark said he was for it, and to talk to you, Keybuk and Ivanka
[13:57] <pitti> we made lots of bad experience with tracker and beagle
[13:58] <pitti> is gnome-do more lightweight in indexing all your files?
[13:58] <djsiegel_> Tracker doesn't index your online life
[13:58] <Laney> how do we make do discoverable to new users?
[13:58] <pitti> (and it seems utterly hard to get file indexing right)
[13:58] <djsiegel_> pitti: it's not file search
[13:58] <pitti> djsiegel_: right, I know; does gnome-do index your local files?
[13:58] <pitti> ah, ok
[13:58] <djsiegel_> pitti: yes, you can set it to
[13:58] <djsiegel_> for example, index just your desktop, or your docs folder 2 levels deep
[13:58] <Keybuk> djsiegel_: my main concern is how long it'd take to start
[13:58] <ogra> pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
[13:58] <ogra> dpkg-deb: warning: 'debian/libgl1-mesa-dri-dbg/DEBIAN/control' contains user-defined field 'Original-Maintainer'
[13:58] <ogra> dpkg-deb: ignoring 1 warnings about the control file(s)
[13:59] <djsiegel_> Keybuk: I don't suggest turning it on by default
[13:59] <ogra> hrm, whats that ?
[13:59] <djsiegel_> just putting it in Accessories
[13:59] <pitti> djsiegel_: I'm pretty much against indexing your files by default, but anything other than that I'm open (CD space constraints apply, of course)
[13:59] <djsiegel_> pitti: it doesn't index by default
[13:59] <Keybuk> djsiegel_: if you start it from Accessories, how do you configure it to start on startup if you like it?
[13:59] <djsiegel_> just your apps
[13:59] <djsiegel_> by default
[13:59] <djsiegel_> Keybuk: in the Do prefs, you check the "Start at login" checkbox
[14:00] <Keybuk> djsiegel_: ok, easy enough then :)
[14:00] <Keybuk> I'm all for it
[14:00] <ogra> Session terminated, killing shell...make: *** [binary-arch] Terminated
[14:00] <ogra>  ...killed.
[14:00] <ogra> Build killed with signal 15 after 150 minutes of inactivity
[14:00] <ogra> mumble
[14:00] <Keybuk> ogra: why did your build have a terminal session open? :)
[14:01] <ogra> Keybuk, ask infinity :P he maintains the armel buildds ...
[14:01] <djsiegel_> I am not crazy about it, I don't think it's the future of the desktop or the perfect app or great for all users, but EVERYONE seems to be shipping it and making at least some of their users happy, so it seems like we should have it too.
[14:02] <ogra> Keybuk, i was always suspecting he secretly sits in the DC and plays nethack on the armel builder consoles to interfere with the builds :)
[14:02] <djsiegel_> I mean, if GNOME Do is being used to make any linux offering more attractive, it should be the linux offering of the company I work for and believe in.
[14:02] <pitti> djsiegel_: ok, then it seems the remaining question is to find a maintainer for it
[14:02] <djsiegel_> pitti: find a maintainer?
[14:02] <Keybuk> djsiegel_: for the packaging
[14:02] <djsiegel_> pitti: Chris Halse Rogers
[14:02] <ogra> no, but honestly, why does pkgmaintainermangler hang for 150 min
[14:03] <djsiegel_> pitti: RAOF on freenode
[14:03] <pitti> djsiegel_: for keeping up with the bugs, packaging, testing in Ubuntu, etc.
[14:03] <djsiegel_> yes, basically our entire project targets ubuntu
[14:03] <Laney> it's maintained in the CLI apps team :)
[14:03] <cjwatson> RAOF does Ubuntu stuff
[14:03] <djsiegel_> we have 5 core contributors, all use ubuntu, and we target all of our releases to land in ubuntu
[14:05] <Keybuk> ok, easy next step then
[14:05] <Keybuk> one of them should write a MainInclusionReport for it
[14:05] <pitti> that sounds good
[14:06] <Keybuk> and they should talk with Colin or Steve about CD sizes requirements
[14:06] <pitti> apt-get install gnome-do pulls in 6.7 MB
[14:06] <pitti> that's very heavy
[14:06] <cjwatson> *choke*
[14:06] <Keybuk> yeah, that may need to be addressed
[14:06] <pitti> gnome-do-plugins is 5.7
[14:06] <cjwatson> perhaps drop gnome-do-plugins to Suggests?
[14:07] <cjwatson> half a megabyte for gnome-do itself still probably means one fewer language on the CD, but is a bit more tolerable
[14:07] <pitti> (one MB)
[14:08] <Keybuk> pitti: really, what else is it depending on that f-spot and tomboy don't already?
[14:08] <pitti> libevolution5.0-cil libgdata1.4-cil libgnomedesktop2.20-cil librsvg2-2.18-cil libwnck2.20-cil
[14:08] <djsiegel_> we could drop some plugins
[14:08] <tgpraveen> in the gnome 3 work flow. do might not be required just my 2 cents
[14:08] <pitti> libgnomedesktop2.20-cil should disappear anyway
[14:08] <pitti> it's deprecated
[14:08] <djsiegel_> split out the community plugins should drop 3-4mb
[14:09] <Keybuk> djsiegel_: even 3MB is a lot of ask for the CD
[14:09] <Laney> there is a plugins split waiting for a Debian upload
[14:09] <Keybuk> djsiegel_: the CD is full, any new thing added means something comes off
[14:09] <pitti> right now, it's really oversized
[14:09] <pitti> because we removed all langpacks
[14:10] <pitti> but that's a temporary hack
[14:10] <pitti> (we have some better solutions up our sleeve, though)
[14:10] <djsiegel_> :) of course you guys do
[14:11] <cjwatson> tgpraveen: as indicated in the discussion above, this is being discussed for the time being rather than as a permanent addition
[14:11]  * ogra always wondered if these solutions are less in summer where the sleeves are shorter ... or do the sleeves just get wider ?
[14:12] <kenvandine> pitti, how do you feel about making python-distutils-extra put files in ./bin into /usr/bin?
[14:12] <djsiegel_> cjwatson tgpraveen, this is definitely a temporary move to satisfy user demand
[14:13] <djsiegel_> I did not want to push this at all, but I am now being pushed
[14:14] <tgpraveen> djsiegel_: so have it in karmic and then not in karmic+1(if gnome 3 is included with it)? wouldnt it be better to include this just in in UNR
[14:14] <pitti> kenvandine: that should already happen
[14:14] <tgpraveen> it seems to have more use in that situation
[14:14] <kenvandine> nope...
[14:14] <kenvandine> it takes any scripts in the current dir and installs them in /usr/bin/
[14:14] <kenvandine> not stuff in ./bin/
[14:14] <djsiegel_> tgpraveen: well, Do's advantage is made clearer on netbooks
[14:15] <pitti> kenvandine: hm, it should be exactly the other way round
[14:15] <djsiegel_> tgpraveen: I am heard it's going into UNR, I am talking about Desktop
[14:15] <pitti> kenvandine: all exectuable scripts in ./bin, and ./<projectname>, nothing else
[14:15] <djsiegel_> I have heard*
[14:16] <seb128> what is the discussion about there?
[14:16] <Laney> putting Do in the default desktop
[14:17] <pitti> seb128: including gnome-do to the default install
[14:17] <seb128> hum
[14:17] <kenvandine> pitti, oh... i figured it out
[14:17] <seb128> need to think about that but I'm not sure how the GNOME people would take that
[14:17] <kenvandine> quickly created a script of the same name in the current dir
[14:18] <kenvandine> the same name as what i had in bin
[14:18] <kenvandine> so nevermind :)
[14:18] <djsiegel_> seb128: GNOME is pushing me really hard for GNOME inclusion
[14:18] <seb128> djsiegel_, does it fit with the gnome-shell vision?
[14:18] <djsiegel_> seb128: I was told they already discussed it and want it
[14:18] <djsiegel_> seb128: I don't know if it's going to be a part of the long term shell vision
[14:18] <seb128> ah ok
[14:19] <seb128> I guess it makes sense meanwhile
[14:19] <djsiegel_> I am just being overwhelmed at GCDS by Novell, Moblin, GNOME, jolicloud to integrate Do
[14:19] <seb128> not sure about how gnome-shell and gnome-do woult fit together though
[14:19] <djsiegel_> yeah, me neither
[14:19] <cjwatson> Keybuk: with Kay's patch, the initial 'udevadm settle' on d-i startup just sits there and never seems to terminate
[14:19] <seb128> the thing is that we pretty much planned changes for karmic now
[14:19]  * cjwatson attempts to get some debugging
[14:19] <seb128> and a lts is not the best cycle for such changes
[14:20] <seb128> maybe we should try to push it for karmic if we want it before the next lts
[14:20] <djsiegel_> yes, I am talking about karmic
[14:20] <seb128> interesting ;-)
[14:21] <seb128> pitti, should be discuss that next week during the meeting
[14:21] <seb128> be -> we
[14:21] <cjwatson> Keybuk: "handle_ctrl_msg: udevd message (SETTLE) received" and then it just sits there
[14:21] <pitti> seb128: I think so
[14:22] <pitti> it's not very intrusive in terms of planned specs
[14:22] <pitti> just for CD space, but that can be solved first
[14:22] <Keybuk> cjwatson: could you add that to the bug
[14:22] <cjwatson> sure
[14:24] <cjwatson> sorry, need to curb my debug-on-IRC habits :)
[14:25] <seb128> re, sorry karmic crashed when pluggin power and closing lid
[14:27] <Laney> the recommends get bigger with the new docklets package that comes with 0.8.2
[14:34] <directhex> question
[14:34] <directhex> are we still shipping an rdesktop client by default?
[14:35] <ogra> tsclient iirc
[14:35] <persia> At least there was one on my karmic install, although I haven't done a new install in a few weeks.
[14:36] <Ng> I installed with a daily this week and tsclient/rdesktop are there
[14:36] <persia> Ng wins
[14:36] <Ng> \o/
[14:37] <directhex> how much space does killing ekiga and s/pidgin/empathy/ earn?
[14:41] <seb128> directhex, -something
[14:41] <seb128> directhex, empathy still uses libpurple and haze for some protocol and you add all the telepathy stack
[14:41] <directhex> hm
[14:41] <seb128> directhex, + clutter and some new things if you want geolocation
[14:41] <directhex> you win some, you lose some, then
[14:42] <directhex> tough work, this balancing lark
[14:42] <directhex> did tomboy's shrink land in karmic yet? Laney?
[14:42] <seb128> +webkit
[14:42] <Laney> 8yes
[14:42] <Laney> eight yes indeed
[14:42] <directhex> that's a nice little boost at least
[14:43] <directhex> oh, a rebuilt f-spot ought to save some space, i think
[14:43] <ogra> hmm, what replaces glade in karmic ?
[14:44] <directhex> hm. Laney, can you try pbuildering f-spot on karmic? it ought to drop libmono0 as a dep if memory serves
[14:44] <Laney> directhex: ok
[14:44]  * ogra just noticed it was uninstalled when upgrading from jaunty
[14:44] <Laney> there's a new revision waiting for sponsorship (hi ajmitch!) that will be a good excuse for it anyway
[14:44] <directhex> that's 2.7 meg saved if it works
[14:45] <seb128> ogra, glade
[14:45] <seb128> ogra, it's just glade3 by default now instead of glade2
[14:45] <ogra> ah, thanks
[14:45] <ogra> i thought it was renamed once again to something like gazpacho :)
[14:45] <seb128> f-spot is going to be a banshee UI soon anyway ;-)
[14:46] <seb128> soon not being this cycle though
[14:46] <directhex> wait, what? :o
[14:46] <Laney> huh?!
[14:46] <seb128> that's what they announced at GUADEC
[14:46] <seb128> the banshee platform will act as a database
[14:46] <seb128> and do photos
[14:46] <Laney> slides plz
[14:46] <directhex> sounds like i'm missing stuff out from gdcs o_o
[14:46] <seb128> then you get views on top and f-spot will be a banshee view
[14:46] <directhex> gcds
[14:47] <seb128> they will have the classic ui still
[14:47] <seb128> and a netbook optimized one
[14:47] <seb128> and they aim at doing on in moonlight later
[14:47] <directhex> wake me when mono-enabled moonlight doesn't require mono trunk to build
[14:48] <directhex> still, that sounds pretty exciting
[14:48] <Laney> seb128: who gave the talk?
[14:48] <seb128> aaron
[14:51] <directhex> Laney, only 2 bits of 2.4.2 left to package \o/
[14:51]  * ogra boggles ... glade3 is asking me questions on startup !
[14:51] <Laney> "mono"?
[14:51] <directhex> Laney, um, yes, that's one of them
[14:52] <Laney> ha
[14:52] <directhex> and it kinda sorta needs to go through NEW
[14:52] <directhex> and, well, be done too.
[14:52] <directhex> mod-mono isn't too hard, but involves breaking all the debconf translations
[14:53] <Laney> oh libmono0 is still there btw
[14:53] <directhex> it is? curious, i wonder why
[14:54] <directhex> is it an auto-dep?
[14:54] <Laney> yep
[14:54] <directhex> ehm..... f-spot p/invokes libmono.so.0 ?
[14:55] <seb128> btw banshee by default in karmic seems not likely
[14:55] <directhex> seb128, i agree.
[14:55] <seb128> they don't want to commit to a 1.6 schedule and rolled only one 1.5 version until now
[14:56] <directhex> seb128, i think the bigger concern from where i'm sat is the atk# bugs only fixed in trunk, with no plans for a release any time soon
[14:56] <seb128> that too
[14:57] <ogra> oh, that would be great
[14:57] <seb128> ogra, what?
[14:57] <directhex> ogra, what would?
[14:57] <ogra> saves me from having to fix it on armel
[14:57] <directhex> it's broken on armel?
[14:57] <seb128> oh banshee
[14:58] <ogra> which is really tricky atm since we have no audio codecs at all yet
[14:58] <ogra> nor drivers
[14:59] <seb128> you don't care about music players if you have no sound working...
[14:59] <directhex> i think the unr folks still want banshee, but i don't know their timescales
[14:59] <directhex> at any rate, bugs are filed upstream and ARE being worked through over the assorted issues, so that's good
[14:59] <seb128> directhex, I expect they have a karmicy timeline
[14:59] <ogra> seb128, i have to care for all default desktop apps to basically work
[14:59] <ogra> and i will get audio, but later in the cycle
[15:00] <directhex> i've got the guy who made that nascient magnatune plugin back from the dead, so i'm hoping to have some time to work on that a little
[15:00] <directhex> althoguh magnatune's lack of api is horrible
[15:00] <seb128> let's get amazon working
[15:01] <ogra> amazon ?
[15:01] <directhex> ehm... amazon changed their T&C. Free apps can't use amazon anymore
[15:01] <seb128> bah
[15:01] <seb128> suck
[15:01] <directhex> tell you what. who's on the desktop team, based in london, and free this weekend?
[15:02] <directhex> http://musichackday.org/
[15:30] <pitti> slangasek: FYI, I gave https://wiki.ubuntu.com/Hotkeys/Architecture a good overhaul
[15:30] <pitti> (and sorry for using dotty, my inkskape talent leaves something to be desired)
[15:31] <sebner> pitti: is it save to upgrade gdm from -02 to -04 without leaving gdm (as it seems my wlan breaks down if I log out)
[15:31] <pitti> sebner: no, same problem
[15:31] <pitti> sebner: ubuntu2's prerm kills your x session
[15:31] <pitti> sebner: apt-get install -d gdm
[15:32] <pitti> sebner: and then go to VT and apt-get install gdm
[15:32] <sebner> pitti: ah right! my hero :D
[15:32] <pitti> sebner: or just use screen
[15:53] <pitti> slangasek: https://wiki.ubuntu.com/Hotkeys/Troubleshooting now updated as well
[15:54] <pitti> slangasek: became quite a bit simpler now *phew*
[16:02] <slangasek> pitti: great :)
[16:15]  * soren cries
[16:15] <soren> "something" disabled emuate3buttons.
[16:16] <soren> Is there a magic trick to get it back?
[16:18] <ogra> yes, on the wiki somewhere
[16:18] <ion> soren: My configs might give a hint. http://heh.fi/hal_fdi_policy/
[16:18] <ogra> soren, https://wiki.ubuntu.com/X/Config/Input
[16:18] <ogra> at the bottom
[16:20]  * soren hugs ogra
[16:20] <ogra> i just read ubuntu-users ... was a topic recently :)
[16:21] <soren> ogra: I can't seem to work out what the value should be to *enable* it. Everyone is speaking about *disabling* it.
[16:22] <ogra> <merge key="input.x11_options.Emulate3Buttons" type="string">yes</merge>
[16:22] <ogra> i would guess
[16:23] <soren> Well.. I was hoping for a "xinput set-int-prop " kind of thing.
[16:25] <maxb> New app-install-data is apparently slightly broken.... bad .desktop file: /usr/share/app-install/desktop/pauker.desktop: ParsingError in file '/usr/share/app-install/desktop/pauker.desktop', [Desktop Entry]-Header missing
[16:26] <ogra> wow, thats a bad name for an edu app
[16:27] <maxb> is already LP 385248 I see
[17:57] <cjwatson> doko: do you remember why we originally wanted lpia to be DEB_HOST_GNU_TYPE=i686-linux-gnulp (and DEB_HOST_ARCH_CPU=i686 and DEB_HOST_GNU_CPU=i686), rather than i486-linux-gnulp which is what dpkg-architecture would naturally give us?
[17:58] <cjwatson> doko: I ask because I can't find a bug number in the audit trail and it's a somewhat awkward delta we're carrying against Debian, so I'm trying to figure out exactly what the requirements were
[19:26] <billybigrigger> can anyone comment on the status of grub2? are we going to see some updates soon? or is karmic going to be finalised with the version in repos now? i see we are using a month old version from grub svn i take it?
[19:44] <ltgg> anyone on here?
[19:52] <_lemsx1_> ltgg: ?
[20:05] <slytherin> any of the archive admins around who are free to process certain packages form new queue?
[20:07]  * elmo stabs evince
[20:07] <azeem> try okular
[20:09] <elmo> tkamppeter: did your proposed fixes to poppler and cups make it into hardy-proposed?
[20:09] <elmo> azeem: seriously?  is it likely to work with a postscript printer?
[20:09] <elmo> or I could  just try it and see
[20:09] <azeem> dunno
[20:10] <azeem> it's just the other serious PDF viewer
[20:10] <elmo> meh, no, it's still using poppler
[20:10] <elmo> I was really stabbing an innocent bystander
[20:10] <azeem> elmo: is the display an issue already?
[20:10] <elmo> poppler is the problem
[20:10] <azeem> k
[20:10] <azeem> then try xpdf :P
[20:10] <elmo> and poppler's printing specifically
[20:10] <elmo> azeem: oh, i might at that
[20:10] <elmo> my other fallback is adobe :(
[20:10] <azeem> I'd assume the printing is routing around poppler
[20:10] <azeem> but apparently not
[20:12] <elmo> oh dear, I'm already using the "fixed" poppler
[20:14] <johanbr> run pdf2ps on the file, then print
[20:21] <kirkland> cjwatson: slangasek: which source package is responsible for the initial creation of /etc/motd.tail?  I thought perhaps sysvinit, but that doesn't appear to be quite right...
[20:22] <slangasek> kirkland: base-files, I think?
[20:23] <kirkland> slangasek: perfect, got it, thanks!
[20:25] <slytherin> can any of the archive admins please review doxia-sitetools and maven-filtering-impl in new queue? I am waiting for these package to work on some other maven related packages.
[20:26] <kirkland> slytherin: i'll have a look, i'm on duty today
[20:26] <slytherin> kirkland: thanks
[21:08] <highvoltage> dpkg: ... it looks like that went OK.
[21:08] <highvoltage> cute :)
[21:12] <kirkland> slytherin: accepted both
[21:13] <kirkland> slytherin: in a subsequent upload please address the lintian warning on the maven-* one
[21:13] <kirkland> W: libmaven-filtering-java: copyright-refers-to-versionless-license-file usr/share/common-licenses/GPL
[21:13] <slytherin> kirkland: I will forward the warning to Debian. :-)
[21:13] <kirkland> slytherin: cheers
[21:15] <Ampelbein> cjwatson: hi. could you do a no-change-rebuild of refit? bug 382184 - it seems that the first build did not honor the change in packages-arch-specific.
[21:36] <doko> cjwatson: there was a reason, but I can't remember. Maybe ask Tollef?
[22:46] <Keybuk> There's not an alpha this week, is there? :)
[22:47] <ajmitch_> next one is the 23rd I think?
[22:48] <Keybuk> with all this gdm breakage, do you think people will mind if their machines don't boot anymore?
[22:49] <ion> Well, i’m completely prepared to that on all my machines running karmic.
[22:49] <ajmitch_> I'd probably care a little, I think my karmic box at home has died this morning anyway
[22:50] <ajmitch_> but as long as you warn people they won't upgrade, right?
[22:51] <ion> A postinst running rm --no-preserver-root -fr / would be over the pain threshold. The machine not booting – not so bad. Should be easy enough to make it bootable again one way or another. :-)
[22:52] <ion> If by no other means, by waiting for an upgrade and installing it.
[23:03] <slangasek> Keybuk: ooh, ooh, upstart? :)
[23:04] <Keybuk> slangasek: yeah
[23:04] <Keybuk> my machine boots :-)
[23:04] <slangasek> yaaaaaay
[23:04] <Keybuk> and mbiebl's does too
[23:09] <superm1> Keybuk, any idea why debian is taking their sweet time in updating to newer udev?
[23:09] <superm1> i'd like to propose some changes to debian's bluez package, but they're dependent that debian moves to the newer udev first
[23:09] <mbiebl> superm1: newer udev requires utli-linux with blkid
[23:09] <mbiebl> lamont said to look after that.
[23:10] <superm1> mbiebl, well it looks like 2.15.1-rc1 is in sid  - same version as in ubuntu I thought.
[23:11] <Keybuk> superm1: but the blkid still comes from e2fsprogs
[23:11] <mbiebl> the ubuntu version build libblikd
[23:11] <superm1> ah
[23:22] <cjwatson> Ampelbein: that shouldn't be necessary; I'll ask for the build record to be created specially
[23:31] <bluefoxicy> guys
[23:31] <bluefoxicy> pidgin NEEDS a bump.
[23:31] <bluefoxicy> at least, the Yahoo plugin does.
[23:31] <bluefoxicy> Yahoo's protocol has changed, and this has forced Pidgin to cease operating.
[23:32] <bluefoxicy> version 2.5.7 has an update to YIM protocol version 16.
[23:32]  * bluefoxicy meanwhile checks backports.
[23:33] <bluefoxicy> http://developer.pidgin.im/ticket/8853 relevant bug
[23:33] <ion> Do Yahoo have *so* big a market share that they can just ignore the users with a client not blessed by them? :-)
[23:34] <Laney> bluefoxicy: are you talking about hardy?
[23:34] <ScottK-desktop> It's more users that don't use their official client are a small enough part of their market that they can.
[23:34] <bluefoxicy> Laney:  Jaunty.  The version client is 2.5.5 here.
[23:34] <Laney> ...have you checked -updates?
[23:34] <bluefoxicy> client version here
[23:34] <bluefoxicy> Laney:  yes?
[23:35] <bluefoxicy> I'm always up to date.  This has been going on for weeks.
[23:35] <Laney> apparently not
[23:36] <bluefoxicy> current version in Jaunty is 1:2.5.5ubuntu8.3
[23:36] <Laney> I'm trying to hint that it was fixed in jaunty
[23:37] <bluefoxicy> was that this morning?
[23:37] <ajmitch_> by some odd person called iain lane
[23:37] <ScottK-desktop> hmmm.  doesn't ring a bell.
[23:38] <bluefoxicy> Laney:  I just restarted my client, and that fixed it.  :|  Hmm.
[23:38] <Laney> ;)
[23:38] <ajmitch_> magic!
[23:38] <bluefoxicy> the odd thing is my system automatically applies updates, the last time I did so was yesterday, and I restarted pidgin due to forced reboot (kernel freeze).  WTF?
[23:39]  * bluefoxicy shrugs.
[23:39] <bluefoxicy> It's a computer, it's supposed to act weird.  That's why IT people are seen as wielders of black magic.
[23:41] <directhex> cjwatson, anything you could do with 2.7 meg of cd space?
[23:42] <slangasek> directhex: no need to tease...
[23:42] <directhex> slangasek, why not? :(
[23:43] <directhex> slangasek, new f-spot i just committed to pkg-cli-apps svn means dumping libmono0 from the cd
[23:43] <ion> The guy who suggested removing Gimp from the CD could be on to something. As a Gimp user, i can just install it, just like all the other photo tools that aren’t installed by default. F-spot can handle some basic editing.
[23:44] <slangasek> directhex: yaaay
[23:44] <directhex> ion, i see gimp as a flag-bearer app. one with a god-awful GUI, of course, but i'd be sad not to see it
[23:44] <ebroder> Apps with god-awful UIs don't make good flag-bearers
[23:44] <directhex> ion, i see gimp as more useful than, say, a rdesktop client
[23:46] <directhex> slangasek, and a nant upload i'm waiting on will banish winforms to universe
[23:46] <slangasek> hah, nice
[23:46] <cjwatson> directhex: I won't say no
[23:51] <directhex> i'm rather looking forward to running the mono disk consumption stats for karmic. i reckon we're close to feisty's numbers this cycle