[00:48] <asac> slangasek: http://pastebin.com/psqA6BAL ... thats the rebuild list for thumb2 + main ...
[00:53] <asac> slangasek: you want me those chunks to stage in an empty native PPA or rather directly in archive?
[00:54] <asac> for me native PPA would feel safer, but its your say
[01:24] <DaemonFC> Why is the terminal now purple? Who could have thought that was cute?
[01:24] <DaemonFC> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/532355
[03:03] <slangasek> asac: I don't see any benefit to staging it in a PPA
[03:04] <persia> Excellent.  320 packages to keep the buildds humming over the weekend.
[03:22] <Sarvatt> was mesa-utils recently demoted to universe or something? I was just trying out a kubuntu livecd from today and it looks like kwin desktop effects need glxinfo installed which is in universe and not on the cd
[03:23] <persia> glxinfo is in universe, but it doesn't show at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[03:23] <Sarvatt> was just thinking maybe it got demoted after compiz stopped needing it in early lucid
[03:23] <Sarvatt> its part of the mesa source package
[03:24] <persia> Potentially.  I suspect the kwin desktop effects need to recommend or depend on it if they don't.
[03:24] <persia> Do you know which package is breaking without it?
[03:25] <Sarvatt> it's not really breaking, its just that you cant enable opengl compositing in KDE without mesa-utils installed and it's not on the cd and it doesn't seem like that was intentional
[03:26] <persia> OK.  I'll go see if I can find someone who knows, and maybe it can be sorted.
[03:46] <ejat> anyone here know the issue networkmanager in lucid alpha3 ? which is its keep connecting ... either wired @ wireless ?
[03:48] <persia> ejat: You probably wanted to ask that question in #ubuntu+1 or #ubuntu-bugs
[03:49] <ejat> persia: owh ok .. going there ..
[03:53] <jayvee> Anyone here that has a vague idea of how Wubi works? I’m “remastering” a 9.10 live CD, which works beautifully with Ubiquity. But when I launch Wubi from my remastered disc, the “Install inside Windows” button is gone from the splash screen, whereas it shows up on the 9.10 “gold” image.
[03:54] <jayvee> So there is some logic in Wubi that makes it check for whether to enable the “Install inside Windows” button or not. I’d like help trying to find out where and what that logic is. :)
[03:55] <persia> jayvee: Your best contact is xivulon, who can sometimes be found in #ubuntu-installer
[03:55] <jayvee> will ping him
[03:55] <jayvee> cheers
[03:55] <persia> (which is generally a good place to ask installer questions, but not so much at this time of day: tends to be on a UTC+0 schedule)
[03:56] <jayvee> UTC+10 here
[03:56] <jayvee> +11 actually — daylight savings.
[03:57] <persia> Yep.  Your IP gives you away (even though you're using the good kind of network)
[03:58] <StevenK> Ahhh, another SLUG person :-)
[03:58] <jayvee> xivulon isn't on at the moment, but I'll try asking anyways.
[05:10] <crimsun> slangasek: are you still experiencing #382440?
[05:29] <MindVirus> Where can I find the code for the logout dialog box?
[05:29] <MindVirus> Would Alpha 3 accept a patch for a checkbox on the logout box to save settings?
[05:30] <MindVirus> I'm sorry, Alpha 4..
[05:30] <micahg> MindVirus: no alpha 4, patches always welcome, no guarantee when they'll land :)
[05:31] <micahg> MindVirus: beta 1 is the next release
[05:32] <MindVirus> OK.
[05:32] <MindVirus> Where can I find the code?
[05:32] <micahg> MindVirus: might want to file a bug first to make sure it's accepted before putting a lot of time into it
[05:32] <MindVirus> micahg: OK.
[05:35] <micahg> MindVirus: bug 44010
[05:38] <MindVirus> micahg: Should I send a patch even though it's been 4 years?
[05:38] <micahg> MindVirus: yes!  those are great bugs to be able to close if it's not resolved :)
[05:39] <micahg> MindVirus: actually, I spoke too soon
[05:39] <lamalex> Is there a way to apply debian/patches so that new patches that need generated are relative to the patched source?
[05:39] <micahg> MindVirus: check with seb128 to make sure it's still wanted :)
[05:39] <lamalex> other than just running a loop with patch <
[05:39] <micahg> MindVirus: you could actually just ask in the bug
[05:39] <RAOF> lamalex: Depends on the patch system.
[05:39] <RAOF> lamalex: Generally, “debian/rules patch” will do the right thing
[05:39] <lamalex> i know there's a command to see what patch system is in use..
[05:40] <RAOF> what-patch, yeah.
[05:40] <lamalex> thanks
[05:40] <lamalex> cdbs
[05:45] <lamalex> RAOF, ^
[05:45] <RAOF> Oh, sorry.  “debian/rules patch” should work, I think.
[05:45] <persia> It does.
[05:45] <RAOF> I'm also pretty sure you can pass a patch to apply first to cdbs-edit-patch.
[05:46] <lamalex> and it will modify the patch based on the other patches?
[05:46] <lamalex> oh, nevermind
[05:47] <persia> for cdbs it's generally best to just use cdbs-edit-patch, do stuff, and edit.
[05:47] <persia> (at least for cdbs+simple-patchsys)
[07:03] <persia> I'm getting a FTBFS of python-apt on i386, using the source in the archive.  That source was uploaded on 1st February (and build successfully).  The errors are mostly of the class "error: 'string' was not declared in this scope" (where 'string' is replaced by other things).  Does anyone happen to know what toolchain changes may have caused this, or a strategy to work around it?
[07:05] <DaemonFC> Is there a way to restore proper minimize/maximize behavior?
[07:10] <persia> DaemonFC: That's really a question for #ubuntu or #ubuntu+1 (yes, I know)
[07:11] <DaemonFC> how can they step in and change the maximize/minimize order to be different from not only every GUI since the mid 1980's to every other GUI that currently exists?
[07:11] <DaemonFC> this is not going to be popular
[07:12] <DaemonFC> why do they want to make people re-learn basic GUI manipulation that they've known for 25 years or more?
[07:12] <DaemonFC> what does this gain Ubuntu other than frustrated users?
[07:12] <mtx_init> to be honest you are not being very clear.
[07:12] <DaemonFC> it's not like this is a cure cancer patch, it's shift stuff around for no reason
[07:13] <DaemonFC> mtx_init, They changed it from minimize,maximize,close to maximize,minimize,close
[07:13] <RAOF> mtx_init: I assume that the complaint is that the new Metacity theme switches the order of the minimise and maximise buttons.
[07:13] <mtx_init> i use clearlooks
[07:13] <DaemonFC> this is stupid, actually stupid is too mild a word but I'll leave it at stupid
[07:14] <persia> DaemonFC: You could always select a different theme, but really, this isn't the best channel.
[07:14] <DaemonFC> persia, It puts them in the wrong order regardless of theme
[07:14]  * persia was fairly certain the order was determined by the theme
[07:15] <DaemonFC> that was actually the first thing I tried before poking around in gconf-editor and changing it back
[07:15] <mtx_init> DaemonFC: if you are so very dissatisfied, why not just write a patch
[07:15] <mtx_init> DaemonFC: can you change the setting easily ?
[07:15] <DaemonFC> a restore sane and conventional GUI behavior of the last two decades patch
[07:15] <RAOF> persia: It's actually in /apps/metacity/general/button_order, for some reason.  You'd think it'd be in the theme, though.
[07:15] <DaemonFC> yeah, flip a gconf key
[07:16] <persia> RAOF: Odd.
[07:16] <RAOF> +1 metacity theme format weirdness.
[07:16] <DaemonFC> reboot and find yourself in the mirror universe
[07:16] <mtx_init> is this a theme change or a overall change to gnome?
[07:16] <DaemonFC> they should render fonts backwards too to enhancereadability
[07:16] <DaemonFC> change to GNOME :P
[07:18] <mtx_init> To be honest if somebody is minimizing their app, they are implying at the time being they dont need it.  So if they accidentily hid the close button, it would be less troublesome.  Compared to if they were maximizing and accidentally hit close.
[07:18] <mtx_init> hit
[07:19] <mtx_init> thats likely the reason.
[07:19] <Mirv> if someone happens to be in search of a challenge, find out how on earth to compile git://git.debian.org/collab-maint/ffmpeg2theora.git (0.26) on Ubuntu... would be welcome for the tool to be useful (two-pass), but might be too hard
[07:19] <DaemonFC> mtx_init, No, it's not like that. You'll minimize when you want to maximize and maximize when you mean to minimize it
[07:19] <Mirv> (and yes it doesn't compile on Debian either)
[07:19] <DaemonFC> there's no reason for this behavior and it's a practical joke I hope
[07:20] <DaemonFC> this is the kind of thing you do to a co-worker while they're out to lunch to be mean
[07:20] <mtx_init> DaemonFC: what I mean is that it makes more sense the new way.  It is mess up prone.
[07:20] <mtx_init> less
[07:20] <mtx_init> less mess up prone.
[07:20] <persia> Um, really.  This isn't the best place.
[07:20] <DaemonFC> in that case, why not do close,minimize,maximize?
[07:20] <persia> If you want to talk about a theme, and you don't want to use support or social channels, try -artwork.
[07:22] <mtx_init> DaemonFC: start writing some emails I guess, get a petition going if you are so concerned.
[07:24] <persia> Bother.  It's not even arch-specific.  I can get the same build-failure for powerpc :(
[07:40] <bigon> how can I resent a bug with apport? I still have the .crash file but the upload failed the first time?
[07:45] <pitti> Good morning
[07:45] <superm1> bigon, apport-bug /var/crash/file
[07:50] <bigon> superm1: thx
[07:54] <dholbach> good morning
[07:56] <GheRivero> morning
[07:58] <mtx_init> will dump(8) work on ext4?
[08:05] <GheRivero> offcial release of dump from june has ext4 support included
[08:07] <mtx_init> GheRivero: should the man page be updated?
[08:08] <GheRivero> i think so, anyway is still experimental, like ext3 support :!
[08:08] <mtx_init> lol, ok.
[08:13] <mtx_init> as of now though have tests shown it is moderately safe?
[08:20] <GheRivero> not any real test so far, anyway all the hard work is done by e2fsprogs
[08:21] <mtx_init> ok, seems like many people dont use dump anymore.  I think its great.
[08:24] <GheRivero> i doubt anybody rely on it already
[08:24] <mtx_init> what do they use instead?
[08:26] <GheRivero> some backup system, tar, rsync... who knows
[08:32] <GheRivero> for personal use i will stay with rsync
[08:32] <mtx_init> yeah, but its not really incremental like dump.
[08:34] <GheRivero> it can be done incremental with rsync
[08:34] <mtx_init> i thought the delta algo needed to see the files.
[08:34] <mtx_init> il have to look that up
[08:35] <ev> bdmurray: thanks for the apport hook in usb-creator!
[08:36] <ion> I’m using rsnapshot.
[08:36] <mtx_init> how is that working out ion
[08:37] <ion> I’m very happy with it. It does need to see the older snapshots, though. But this is offtopic. :-)
[08:40] <GheRivero> it's an rsync with steroids :)
[08:40] <mtx_init> GheRivero: is that what you use as well?
[08:40] <mtx_init> there is also rdiff
[08:41] <GheRivero> i use privative backup software on the servers (enterprise policy) an rsync-scripts at home
[09:06] <kees> cjwatson: was removing the Ubuntu version number from the generated menu when moving to grub-pc intentional?
[09:14] <\sh> mvo: why does python-apt recommends a javascript lib (libjs-jquery)?
[09:17] <mvo> \sh: for the html documentation
[09:17] <mvo> \sh: if that is a problem I can move it to suggests
[09:22] <cjwatson> kees: somewhat.  in part it was just that nobody implemented that bit, but (as I wrote in a bug report on the subject recently) the Ubuntu version numbers were often wrong in edge cases anyway and I think there's an argument that no version numbers are better than wrong ones
[09:23] <cjwatson> so it's kind of "I never really liked the old way anyway"
[09:23] <\sh> mvo: it installs by default during a server install...I wonder if this is necessary...
[09:23] <mvo> \sh: no, I guess best is to move the html to python-apt-docs - could you file a debian bug about this please?
[09:23] <\sh> mvo: sure will do :)
[09:24] <mvo> thanks
[09:24] <\sh> mvo: after my meeting there will be a bug
[09:58] <dpm> Hey pitti, good morning. Thanks for coming back to me on the apport symptom and ubuntu-translations last night. There seemed to be bug 448335 already for that, so I added a comment and opened a task for apport-symptoms
[09:58] <pitti> dpm: ah, good
[09:58] <pitti> I'll answer to that asap
[09:59] <dpm> pitti, thanks!
[10:03] <dpm> pitti, as a general thought, would it be possible to make langpack-o-matic build the translated xml files from PO files for documentation exposed for translation in LP? I know it might be difficult to find out which PO files actually correspond to translation and thus need xml output instead of mo output, but now that ubuntu-docs are in language packs, would perhaps not be a good compromise to build (well, convert) the xml files from the ubuntu-docs pac
[10:03] <dpm> kage only?
[10:04] <dpm> (which PO files actually correspond to documentation, I meant)
[10:04] <didrocks> cjwatson: hey, about the ubiquity merge for wallpaper caching on install, I've uploaded the new proposal some days ago (https://code.edge.launchpad.net/~didrocks/ubiquity/copy_wallpaper_cache/+merge/20527). I don't know the workflow, do you want me to push it or make a new review first?
[10:07] <cjwatson> didrocks: no that's fine, it's in my queue, I've just been buried in kernel work for the last two days
[10:08] <didrocks> cjwatson: perfect, I just wanted to ensure you didn't wait for anything on my side. Thanks :)
[10:24] <slangasek> crimsun: 382440> nope
[10:29] <\sh> mvo: BTS -> Bug#572617: Acknowledgement (python-apt recommends libjs-jquery)
[10:30] <pitti> dpm: langpack-o-matic doesn't process anything in those right now (just shuffles the files around), but in principle I guess it could do it
[10:32] <dpm> pitti, I think it would make a lot easier the work of the docs team, and would allow docs translations to be updated regularly. Do you think it would make sense to open a bug in langpack-o-matic for that?
[10:33] <mvo> \sh: thanks
[10:33] <pitti> dpm: sure, you can do that; I'm just afraid I won't have time to actually work on it
[10:34] <dpm> pitti, sure, I don't want to load you with more work :) I just want to make sure it's recorded and we can at least discuss it if it makes sense
[10:37] <pitti> dpm: I think it would (either in LP itself or in langpack-o-matic); it's a step closer to seamless intregration of translations
[10:39] <dpm> Yeah, I think we can start with langpack-o-matic and ubuntu-docs only, which would already offer a great benefit. Thanks pitti
[10:53] <ogra> hmm, my gnome-terminal profiles were trashed with the recent theme upgrade ... thats not nice
[10:58] <pitti> ogra: bug 532511
[11:02] <ogra> ah, thanks pitti
[11:02] <pitti> I'm glad I'm not the only one
[11:02] <pitti> ogra: please confirm/affects me too/etc
[11:35] <asac> what is up with cdrdao and cdrkit ... do we use those by default?
[11:47] <directhex> asac, yes, cdrikit is afaik. not that anything promped that question, of course
[11:47] <ogra> asac, cdrdao is a direct dep of kubuntu-desktop
[11:47] <ogra> cdrkit should be a virtual package iirc wodim should replace it, no ?
[11:47] <directhex> ogra, wodim is the binary package from cdrkit
[11:48] <ogra> oh, right
[11:48] <ogra> i looked at binaries
[11:48] <directhex> and it's a depends for xubuntu-desktop and brasero, for non-kubuntu users
[11:49] <directhex> and ubuntu-desktop and you get the idea
[11:49] <directhex> lots and lots of cdrkit and cdrdao
[12:03] <asac> directhex: cdrkit fails to build on all archs in lucid ;)
[12:03] <asac> same for cdrdao
[12:03] <asac> Richie: ^^
[12:03] <asac> err Riddell ^
[12:51] <mok0> jdong: ping
[12:53] <ogra> The following packages have unmet dependencies:
[12:53] <ogra> libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.19.6-1ubuntu4) but 2.19.6-1ubuntu3 is to be installed
[12:53] <ogra> hrm
[12:53] <ogra> couldnt the publisher be changed to hold back "Arch: all" packages until all arhes have built
[12:54] <ogra> i think that would be saner than having stuff randomly fail until the "Arch: any" packages are published
[12:57] <seb128> ogra: so if powerpc takes one month to build gtk or gtk fails there we will get no update until it's fixed?
[12:57] <seb128> just taking powerpc as $randomarch
[12:57] <ogra> seb128, well, one could special case it for ports
[12:57] <seb128> well same difference
[12:57] <seb128> gtk build did segfault a zillion times on armel
[12:57] <ogra> i dont really care for i386 and amd64 ...
[12:57] <seb128> it would block i386 and amd64 for days
[12:57] <ogra> i mean for the ports.ubuntu-com archive
[12:58] <ogra> i assume there is special casing in the publisher code already given its a different server etc
[12:58] <ogra> so holding back _all.deb from publishing until the arch dependednt packages are there shouldnt be to hard imho ...
[12:59] <ogra> and we'd never have broken images due to all/any differences
[13:04] <cjwatson> ogra: no, ports.u.c is split out at mirroring time.  holding back architectures would create all sorts of new problems though.  the proper fix is to publish different versions of _all.deb on different architectures, based on what version of the architecture-dependent binaries are current
[13:05] <ogra> but that would increase the disk needs massively i suspect
[13:06] <ogra> since you would multiply the _all.deb packages ...
[13:06] <cjwatson> ogra: no
[13:06] <cjwatson> no, you don't store multiple copies when they're all identical
[13:06] <ogra> ah, you link them ?
[13:07] <cjwatson> I'm talking about the references in Packages
[13:07] <ogra> ah, k
[13:07] <cjwatson> no file name changes
[13:07] <ogra> yup, i understand now
[13:22] <geser> cjwatson: but wouldn't publishing several _all.deb increase the chance of packages being build against different versions on different archs?
[13:26] <cjwatson> geser: it's silly to try to defend against that only for packages with both any and all components, imo.  if it matters, use strict build-deps
[13:26] <geser> true
[13:27] <cjwatson> and the current situation isn't explicitly a defence against that or anything
[13:49] <pitti> kirkland: muhaha! http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
[13:49]  * pitti is reminded of the Go-Kart race in Berlin
[13:50] <pitti> kirkland: quick, fix 4 bugs!
[13:50] <kirkland> pitti: i'm sitting on two big bugfix uploads :-)
[13:50] <kirkland> pitti: just waiting for you to go to sleep :-D
[13:50] <pitti> ah, darn, and I have to prepare the release meeting
[13:50] <kirkland> pitti: hehe
[13:50] <pitti> but it didn't count my 10 fixes from yesterday yet
[13:50] <kirkland> pitti: yeah, it's kinda funny when and how it counts
[13:51]  * pitti ^5s kirkland
[13:51] <kirkland> pitti: i need to look at that source code :-)
[13:51]  * kirkland high fives pitti back
[13:51] <pitti> kirkland: probably it's just lagging a bit; I think it updates once a day, and parses the -chagnes ML archive
[13:52]  * pitti gets a telescope to watch seb128 at the pole position
[13:52] <kirkland> :-)
[13:52] <pitti> go, seb128, go!
[13:53] <kirkland> pitti: http://www.youtube.com/watch?v=71e_TxmCaxk
[13:53] <seb128> pitti, oh, stats fixed!
[13:54] <seb128> pitti, I've a good margin apparently ;-)
[13:54] <pitti> kirkland: ouch!
[13:54] <kirkland> pitti: hehe!
[14:25] <ttx> pedro_: around ?
[14:26] <pedro_> ttx, hello!
[14:26] <ttx> pedro_: hey !
[14:26] <ttx> pedro_: zul and I are planning a bugzapping session on samba next week
[14:27] <ttx> https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-bug-zapping
[14:27] <ttx> pedro_: given that samba work is mostly triaging...
[14:27] <ttx> pedro_: I was wondering if we could plug a samba bugday to start it.
[14:27] <ttx> like Wednesday we do the bug day
[14:28] <ttx> and Thursday we work on bugfixes
[14:28] <ttx> pedro_: would that bugday slot be free ?
[14:31] <pedro_> ttx, we were planning a bug day on gwibber on Thursday so Wednesdays is still free
[14:31] <pedro_> ttx, i'll coordinate with hggdh and set up everything
[14:31] <pedro_> hggdh, ^
[14:31] <ttx> pedro_: we could do tuesday... but I fugured some lead time to announce it would be better ?
[14:33]  * hggdh sees...
[14:33] <pedro_> ttx, I'd prefer Wednesday to announce on a week day (Monday) and don't lost the announcement during the weekend
[14:33] <ttx> pedro_: ack.
[14:33] <ttx> pedro_: we are mostly after people confirming issues with weird software like Windows 7 :)
[14:36] <pedro_> ttx, ok noted ;-)
[15:18] <cjwatson> Keybuk: I've been working on the console-setup upstart conversion, having got as far as I want to get with the kernel for now (and I don't think I'm going to get that kernel change into lucid, I just want to get the ball rolling on it).  Things sort of work, but the font gets reset to the default somewhere around the point where plymouth-splash starts
[15:19] <cjwatson> Keybuk: do I need to have console-setup start on graphics-device-added or drm-device-added, or something?
[15:19] <cjwatson> I think part of the problem may be that, while fbcon will copy the font from a previous fbcon, it won't copy from a previous vgacon
[15:20] <cjwatson> so the font gets set up (I can see it) and then gets reset as the console driver switches over
[15:22] <Keybuk> cjwatson: that could be possible
[15:22] <Keybuk> there's a "graphics-device-added fbcon" event
[15:22] <Keybuk> I'd be concerned about a boot time impact of repeatedly setting a console font, of course
[15:23] <cjwatson> me too
[15:23] <cjwatson> I was just about to say the same thing
[15:23] <cjwatson> I think it's rather fewer syscalls than setting the keymap
[15:24] <Keybuk> yeah, that's my understanding
[15:24] <Keybuk> what does "time" say? :)
[15:24] <cjwatson> keymap seems to be one ioctl per key :-(
[15:25] <cjwatson> 0.03s for font, 0.11s for keymap
[15:25] <Keybuk> setupcon -f is 0.03s user 0.04s system
[15:25] <Keybuk> right
[15:25] <cjwatson> once the cache is hot
[15:25] <cjwatson> which it will be the second time
[15:25] <Keybuk> I guess you only need to set the keyboard once?
[15:25] <cjwatson> yeah, I believe so
[15:25] <cjwatson> keymap is working for me now
[15:26] <cjwatson> you have to set the keymap while not in raw mode, and the font while not in graphics mode
[15:26] <Keybuk> so the font is per-vc then?
[15:26] <Keybuk> which doesn't make a huge amount of sense given there's only one font ;-)
[15:26] <cjwatson> on fbcon yes, on vgacon no
[15:27] <cjwatson> the patch I sent to kernel-team makes it per-vc in the process of fixing the other problems
[15:27] <Keybuk> if you set the vgacon font for tty1 when that's in KD_TEXT, but the fg_console is tty7 in KD_GRAPHICS ...
[15:27] <Keybuk> what happens then?
[15:27] <cjwatson> but doesn't quite work properly yet
[15:27] <cjwatson> boom
[15:27] <cjwatson> almost certainly
[15:27] <Keybuk> biiiig bada boom
[15:27] <Keybuk> 'cause obviously what I really don't want to introduce into the boot is VT switches
[15:27] <cjwatson> console-setup currently checks fgconsole; it's racy, but not much to be done about it right now
[15:28] <cjwatson> if we can set the font strictly between fbcon loading and plymouth-splash switching mode ...
[15:28] <Keybuk> I think plymouth leaves the vt in K_XLATE but KD_GRAPHICS
[15:28] <cjwatson> plymouth sets raw mode
[15:29] <Keybuk> cjwatson: that doesn't work if fbcon is built-in to the kernel
[15:29] <cjwatson> or at least calls cfmakeraw
[15:29] <Keybuk> cjwatson: oh, I stand corrected then
[15:29] <cjwatson> but setting the keymap 'on starting plymouth-splash' (and other bits to cope if plymouth never runs) appears sufficient
[15:30] <Keybuk> you'd have to do it on starting plymouthd too :-/
[15:30] <cjwatson> plymouthd?  I don't have that ...
[15:30] <Keybuk> err, plymouth.conf
[15:30] <cjwatson> how come?  it doesn't set raw mode until the splash comes up, AFAICS
[15:30] <cjwatson> nor does it switch to graphics mode until then
[15:30] <Keybuk> that will bring the splash up if fbcon is already loaded
[15:31] <cjwatson> oh
[15:32] <cjwatson> actually it looks like I just did 'on starting plymouth'; if plymouth is started in the initramfs, then the initramfs scripts already take care of setting up the console
[15:33] <Keybuk> right
[15:33]  * cjwatson goes to check the KD_TEXT/KD_GRAPHICS question above in the kernel
[15:34] <Keybuk> hmm
[15:35] <Keybuk> do you need /dev/tty stuff to set the keymap or font?
[15:36] <cjwatson> confirmed; AFAICS, KDFONTOP on a non-foreground VC will cause vgacon to write to video memory and explode if the fgconsole is in fact (say) X
[15:36] <Keybuk> *cry*
[15:36] <cjwatson> yes, need /dev/tty*
[15:36] <Keybuk> argh!
[15:36] <cjwatson> well, [1-6]
[15:36] <Keybuk> that makes things even more complicated
[15:36] <Keybuk> if you need /dev/tty* then you have to also wait for virtual-filesystems
[15:36] <Keybuk> but plymouth will be started before that
[15:37] <cjwatson> *blink*
[15:37] <cjwatson> oh, I was unclear above: we can set the keymap at any time, as long as the console we're actually setting the keymap on isn't in raw mode
[15:38] <cjwatson> font is the one that depends on the state of the foreground console as well
[15:38] <cjwatson> it's very tempting to just mknod /dev/tty[1-6] if they don't exist yet
[15:38] <Keybuk> argh!
[15:38] <Keybuk> please don't
[15:39] <cjwatson> boot time?
[15:39] <Keybuk> partly, plus conflict with udev, devtmpfs, etc.
[15:39] <cjwatson> mm.
[15:40] <cjwatson> I guess there's no way to pull tty device creation earlier?
[15:40] <Keybuk> if using devtmpfs, they'll always be there
[15:40] <Keybuk> but there's the following case:
[15:40] <Keybuk>  - older kernel (no devtmpfs)
[15:40] <Keybuk>  - no ramdisk (so nothing mounted on /dev early)
[15:41] <Keybuk> so you might have /dev/tty1-6 there as you start, but /dev gets mounted as an empty tmpfs by mountall as you're setting things up, so the device nodes vanish on you
[15:41] <cjwatson> as long as it doesn't actually explode, I could live with that not managing to set console keymap and font, if that's the price
[15:42] <cjwatson> until such time as we fix the kernel to not have these painful limitations
[15:42] <Keybuk> ok, how about this then
[15:42] <Keybuk> you need the foreground console in KD_TEXT, and most consoles in K_XLATE
[15:42] <Keybuk> assume we're using fbcon
[15:43] <Keybuk> so when the fbcon driver is loaded, set up the consoles keymap and font
[15:43] <Keybuk> that'll cover the majority of cases
[15:44] <cjwatson> what hardware's going to end up in vgacon for lucid?
[15:44] <Keybuk> none
[15:44] <Keybuk> the only way to get that I suspect is using video= on the command-line
[15:44] <cjwatson> oh, because we use vga16fb and fbcon on top
[15:45] <Keybuk> exactly
[15:46] <cjwatson> (hm, I'm not actually entirely sure I'm correct about my assertion regarding the keymap.  we appear to set it on /dev/tty0)
[15:46] <Keybuk> haha :)
[15:46] <Keybuk> wonder what happens if you VT switch while doing that :D
[15:48] <cjwatson> that said, you can do loadkeys --console=/dev/tty1,/dev/tty2,/dev/tty3,/dev/tty4,/dev/tty5,/dev/tty6 and time says it takes no longer here, despite all those ioctls
[15:48] <cjwatson> I guess the time might just be parsing the cache keymap
[15:48] <cjwatson> *cached
[15:50] <cjwatson> Keybuk: so, if I just do this 'on graphics-device-added fbcon', and make sure it guards against the tty being in raw mode or the vc being in graphics mode, that should be enough even if fbcon is built-in?
[15:50] <Keybuk> I think so
[15:52] <cjwatson> I have a feeling that there's in fact just one keymap to rule them all
[15:53] <cjwatson> I'm not seeing much in the way of VC-dependency in here
[15:53] <Keybuk> probably
[15:53] <Keybuk> easy well to tell
[15:53] <Keybuk> set funky keymap
[15:53] <Keybuk> switch VT :)
[15:53] <soren> Is there a klingon keymap?
[15:54] <cjwatson> confirmed, just the one
[15:54] <soren> If there is, is it just like an English one, but with needle and acid and stuff on the keys?
[15:54] <Keybuk> cjwatson: so for both you just need tty0 ?
[15:54] <ion> http://www.slashgear.com/wp-content/uploads/2009/01/klingon_keyboard1.jpg
[15:54] <Keybuk> or do you need to set font-per-vc ?
[15:55] <cjwatson> you do need to set font-per-vc
[15:55] <Keybuk> when VCs are created, does it copy the font from an existing one?
[15:55] <soren> ion: I thought klingon used an English^WEarth character set?
[15:56] <soren> Perhaps it's just usually transliterated.
[15:56] <cjwatson> fbcon at least doesn't seem to
[15:56] <cjwatson> it copies from a previous fb on the same console if it can, but that's all
[15:56] <cjwatson> keymap: a hack occurs to me
[15:56] <cjwatson> it matters if the tty you happen to pick is in raw mode
[15:57] <cjwatson> therefore, iterate through ttys until you find one in unicode mode, and use that
[15:57] <Keybuk> that'd work ;)
[15:57] <cjwatson> they almost certainly won't *all* be raw
[15:57] <Keybuk> just wondering what happens then
[15:57] <qense> I've got a project of which multiple binaries are compiled, including a shared library. I would like to link to that library inside those other binaries, but the only working solution I found was adding the source files of the library to the SOURCES of the other binaries in the Makefile.am. Using #include "path/to/file.h" doesn't work, the compiler keeps complaining about non-defined/existing functions.
[15:57] <Keybuk> you start with VT1
[15:57] <Keybuk> plymouth creates VT7
[15:58] <Keybuk> does that mean that VT2-6 exist or not?
[15:58] <cjwatson> what does it do to create vt7?  openvt?
[15:58] <Keybuk> cjwatson: VT_SETACTIVE
[15:59] <cjwatson> YM VT_ACTIVATE?  ok.
[15:59] <Keybuk> no, VT_SETACTIVE ;)
[15:59] <cjwatson> no such ioctl
[15:59] <Keybuk> it's VM_ACTIVATE combined with VT_SETMODE in one ioctl
[15:59] <Keybuk> err, VT_SETACTIVATE sorry
[15:59] <cjwatson> ah.  no match for that in plymouth source though
[16:00] <Keybuk> cjwatson: you're looking at the unfixed plymouth source remember
[16:00] <Keybuk> the plymouth source with lots and lots of issues around VTs :)
[16:00] <cjwatson> anyway, no matter, both call vc_allocate
[16:00] <Keybuk> like doing all the ioctl()s on /dev/console instead of the right VT
[16:00] <Keybuk> yeah
[16:00] <Keybuk> does that allocate the intermediate ones?
[16:00] <cjwatson> I'm just looking
[16:00] <Keybuk> because that would mean only VT1 exists at the point your stuff gets run
[16:00] <cjwatson> it doesn't appear to
[16:01] <Keybuk> then plymouth would make either VT7 only or VT2-7
[16:01] <Keybuk> so would that not mean that getty 2-6 don't have a font
[16:02] <cjwatson> hmm.  so what *does* allocate those vts?
[16:02] <Keybuk> getty I suspect
[16:04] <cjwatson> I *think* that the act of opening the tty device allocates the VC on it
[16:17] <Keybuk> cjwatson: the act of observing them calls them into existance?
[16:17] <Keybuk> how quantum
[16:46] <gadeynebram> Hoi! Excuse me if i'm in the wrong channel. I'm looking for some information to start contributing with ubuntu as a developer. Can anyone point me in the right direction?
[16:59] <pitti> gadeynebram: https://wiki.ubuntu.com/ContributeToUbuntu has quite a lot of pointers and is a good "signpost" page
[17:01] <gadeynebram> tnx pitti
[17:10] <pitti> cjwatson, ev: hm, what's the magic key to select keyboard/language in the gfxboot screen now? would it be possible/prudent to add a "press F1 to select keyboard" or so?
[17:10] <ev> any key
[17:11] <ev> you just have to be quick
[17:11] <pitti> ah, that gets me back to the old gfxboot
[17:11] <ev> right
[17:11] <pitti> yes, not much time
[17:11] <ev> is that not what you're after?
[17:11] <pitti> I was trying to make sense of the "keyboard equals human" equation :)
[17:11] <ev> hahaha
[17:11] <ev> I think it was the best of a long list of bad options
[17:12] <\sh> kwwii: dude, how can someone change the window border buttons from left to right, and when do we get the window menu button back? ;)
[17:12]  * sebner waves at \sh :)
[17:12] <pitti> ev: hm, maybe I'm just dense, but I find it a bit confusing
[17:13] <didrocks> cjwatson: thanks for the merge :)
[17:14] <\sh> hey sebner :)
[17:15] <cjwatson> pitti: the timeout is five seconds; we couldn't put any text there because it's pre-language-selection
[17:15] <cjwatson> so the best we could do was hope that people would grok the keyboard icon
[17:16] <cjwatson> the rebus is supposed to be "press a key for accessibility options", since that's the primary thing left that you can't do any other way
[17:16] <pitti> ah
[17:16] <cjwatson> (though not by any means the only thing left and I think the design team over-focus on that part, but ...)
[17:16] <pitti> would "F1 = <keyboard> <human>" be too evil?
[17:16] <cjwatson> the idea was to cause fewer people to see the full boot screen
[17:16] <pitti> I know that it's "any key", but F1 is F1 in many languages at least
[17:17] <cjwatson> well, talk with Michael Forrest maybe?
[17:17] <pitti> ah, sure
[17:22] <pitti> bryceh, tjaalton: can I just upload -vmmouse with a working udev rule, or should I send you a patch, for review/git commit/sponsoring?
[17:22] <pitti> (I'll send a patch to Debian, too)
[17:38] <ogra> kirkland, is there any way to create a qemu image that automatically grows without having to specify the imagesize at creation time ?
[17:39] <kirkland> ogra: sort of
[17:39]  * ogra thought qcow2 would do it but i'm apparently wrong
[17:39] <kirkland> ogra: kvm-img create -f qcow2 foo.img 10000G
[17:39] <kirkland> ogra: that's a 10TB backing disk
[17:40] <kirkland> ogra: though it shouldn't take that much space
[17:40] <ogra> indeed
[17:40] <kirkland> ogra: pick your size
[17:40] <kirkland> ogra: you have to give it *some* size
[17:40] <kirkland> ogra: but qcow2 shouldn't use it all
[17:40] <ogra> well, if i give it 1G and install ubuntu-desktop in it i run out of space
[17:40] <ogra> at least in qemu-system-arm
[17:41] <kirkland> ogra: how big is a desktop install now?
[17:41] <kirkland> ogra: i thought it was 4+G ?
[17:41] <pitti> nah
[17:41] <pitti> in two releases ago we were at 2.3 GB
[17:41] <ogra> should be below 3
[17:41] <pitti> perhaps 2.5 now
[17:42] <ogra> i like to keep some buffer space for package cache etc thats why i usually pick 4
[17:42] <ogra> but for my qcow2 tests i just defined 1 and expected it to auto-grow
[17:42] <pitti> mdeslaur: thanks for fixing vmmouse_detect!
[17:43] <pitti> mdeslaur: I have an udevified package now, currently testing in kvm
[17:43] <ogra> though my prob is that i need to mount the image and converted it back and forth from/to raw ... i only just discovered qemu-nbd ...
[17:43] <ogra> kirkland, could converting it be my issue ?
[17:43] <kirkland> ogra: what are you converting it to/from?
[17:44] <ogra> kirkland, i create it raw, run debootsrap in it in qemu-user ... then convert it to qcow2 and use it as disk for the rest of the install in qemu-system
[17:44] <mdeslaur> pitti: cool! can't wait to try it out!
[17:44] <tjaalton> pitti: just upload
[17:44] <tjaalton> pitti: and thanks!
[17:45] <pitti> tjaalton: ok, I'll send the debdiff to debian and the rule to an upstream bug
[17:45] <pitti> thanks
[17:46] <kirkland> ogra: oh, yeah, DFDT
[17:46] <kirkland> ogra: :-)  create it qcow2 to start with
[17:47] <ogra> yeah, i only did find qemu-nbd now ... i need to mount it somehow for the debootstrap run :)
[17:47]  * ogra is trying to find a proper workaround for bug 532733
[17:47] <ogra> qcow2 sadly isnt loop mountable
[17:50] <slangasek> geser: if you use LP: instead of lp: in your changelog, there's no need to update bugs by hand to say you've committed :)
[17:50] <slangasek> geser: this appears to be a bug in bzr's changelog regexp, which curiously doesn't match the dpkg-dev one
[17:50] <pitti> tjaalton: meh, the first time I blamed my stupidity, but the second time I really triple-checked: building the -vmmouse source kills the .postinst I just wrote.. WTH?
[17:51] <geser> slangasek: so "lp: #xxx" only works for Launchpad-Bugs-Fixed in .changes files but not for LP itself?
[17:51] <pitti> argh, "cleanscripts" in xsfbs.mk
[17:51] <ogra> pitti, eaten by the virtual mouse :)
[17:51] <tjaalton> pitti: hmm, heh
[17:51]  * pitti rewrites it a third time, and tries with .in
[17:51] <geser> slangasek: thanks, will remember that. is there a bug about this filed in LP itself?
[17:53] <slangasek> geser: probably not filed yet, getting there
[17:55] <dpm> bryceh, thanks for integrating the patch to load translations from failsafeXinit!
[17:56] <Keybuk> slangasek: http://pastebin.ubuntu.com/389103/ - was that you?
[17:58] <slangasek> Keybuk: looks familiar; I'm perfectly willing to believe it's wrong
[17:58] <Keybuk> it could well be right
[17:59] <Keybuk> it just wasn't sent upstream
[17:59] <Keybuk> *spanks*
[17:59] <slangasek> yes, sorry
[17:59] <slangasek> tseliot told me he usually interacts with upstream via IRC; so I joined the channel and have seen no activity there since
[17:59] <slangasek> so the submission got backburnered until I could figure out what I'm supposed to do
[18:00] <Keybuk> the channel is mostly "bug halfline about things" ;-)
[18:00] <Keybuk> s'ok, I shall commit for you
[18:00] <bryceh> dpm, thanks for making it :-)
[18:01] <Keybuk> grr @ bzr
[18:01] <Keybuk> I wish the colon would stay put
[18:01] <Keybuk> bzr diff --old :submit SOME-FILE
[18:01] <slangasek> sounds like a medical problem
[18:01] <Keybuk> "ah yes, I need the upstream version"
[18:01] <Keybuk> bzr diff -r submit: SOME-FILE
[18:01] <Keybuk> why does the colon dance like that?
[18:01] <Keybuk> *fumes*
[18:01] <slangasek> irritable colon syndrome
[18:01] <Keybuk> lifeless: I blame you
[18:02] <Keybuk> at least GIT is consistent
[18:02] <Keybuk> consistent unbearable torture
[18:04] <jdong> wait when did the colon dislocate like that??
[18:05] <ion> At least the rectum is still where it’s supposed to be.
[18:05] <ScottK> You've checked?
[18:06] <ion> Yeah, i have, your rectum is fine.
[18:07] <ScottK> That's a compliment I don't often hear.
[18:07] <Keybuk> http://www.youtube.com/watch?v=xHKTE75dgE4
[18:07] <ion> keybuk: :-)
[18:13] <Keybuk> oh, wow
[18:13] <Keybuk> bzr revert -r submit: FILE
[18:13] <Keybuk> and
[18:13] <Keybuk> bzr revert -r :submit FILE
[18:13] <Keybuk> DO DIFFERENT THINGS
[18:13]  * Keybuk weeps
[18:16] <jdong> Keybuk: eeek, is one of the colons acting as a revno separator?
[18:16] <Keybuk> no, I think one of them means
[18:16] <Keybuk> "the branch you merged from RIGHT NOW"
[18:16] <Keybuk> and the other means
[18:16] <Keybuk> "the branch you merged from AT SOME ARBITRARY POINT IN THE PAST THAT YOU DON'T WANT"
[18:17] <jdong> what???
[18:17] <jdong> sheesh
[18:17] <ScottK> bzr revert -r :submit: FILE probably ends the Universe.
[18:18] <ion> Whenever someone does that, the universe simply reboots and repeats in an infinite loop.
[18:19] <ScottK> Cool.  Resolves the open/closed question then.
[18:20] <Keybuk> bzr: ERROR: ":submit:" is not a valid location alias.
[18:20] <ScottK> I knew someone would try it ....
[18:20] <kirkland> ogra: oh, right, qcow2 isn't loop mountable
[18:21] <jibel> any cups maintainer could have a look at bug 532053 ?
[18:21] <jibel> It appears 3 times today. The latest jaunty upload seems to be broken.
[18:22] <ScottK> tkamppeter: ^^^
[18:45] <jmdault> A quick question for the gurus: how do you deal with a FTBFS for lpia?
[18:45] <jmdault> Is there a way to tell launchpad *not* to build a package for this arch?
[18:46] <slangasek> jmdault: um... at this point, you generally don't, as lpia is not a supported arch in lucid :)
[18:46] <jmdault> slacker_nl: I'm backporting to hardy
[18:47] <slangasek> well, if the only way you were planning to deal with it was by telling Launchpad not to build it, then I think you can ignore it anyway
[18:47] <jmdault> I thought by having "Architecture: i386 amd64" in debian/control, that it would not build for lpia, but it stubbornly tries to
[18:48] <Keybuk> that's more of a guideline
[18:48] <jmdault> I guess I can ignore idt, but it leaves a red X in my PPA and it looks bad ;-)
[18:49] <Keybuk> I'm not entirely sure whether PPAs even know P-a-s
[18:58] <lifeless> Keybuk: I don't like that they are different
[18:58] <lifeless> Keybuk: one means 'the branch you submit to'
[18:59] <lifeless> Keybuk: the other means 'the common ancestor of the branch you submit to'
[19:02] <kees> cjwatson: I couldn't even figure out how it was done before.  ucf, I think?  since the os-prober actually examines root filesystems, maybe we can do something similar.
[19:02] <cjwatson> kees: I'd rather leave it out
[19:02] <cjwatson> it was a source of trouble, and I don't have time to fix it up
[19:03] <cjwatson> one problem was that it had no way to spot that some other OS on the disk had been upgraded unless you reran update-grub
[19:03] <cjwatson> and I think there may have been other problems too
[19:05] <kees> cjwatson: fair enough.  I'll shed quiet tears.  :)
[19:21] <kwwii> \sh: gconf and never. :P
[19:22] <ScottK> \sh: There's a post on planet.ubuntu.com about it.
[19:25] <cjwatson> Riddell: I'm more than a little bit lost with this ubiquity KDE startup thing
[19:26] <cjwatson> Riddell: I've been trying to find my way around mazes of KDE startup code for an hour or two now, and it may be time for me to admit defeat
[19:26] <cjwatson> Riddell: I imagine we just need to start up a couple more bits of KDE ... I could try guesswork
[19:27] <cjwatson> Riddell: something is getting confused about not being able to talk to the session bus, because I can see in strace that the session bus is running
[19:28] <cjwatson> hmm, I wonder if it's just kdesudo eating environment variables or something?
[19:30] <cjwatson> no, can't be that, we're already running as root here
[19:34] <cjwatson> and ubiquity definitely has DBUS_SESSION_BUS_ADDRESS in its environment
[19:44] <tkamppeter> ScottK, this is strange, package installation is done as root, so chown should work. In addition, I did not do the latest Jaunty upload. I think it was pitti, but I am not sure. Check Launchpad for who uploaded and see the debian/changelog for what bug got fixed by the SRU and/or security update.
[19:49] <ScottK> tkamppeter: I just know you have a general interest in the package.
[20:29] <mdeslaur> jcastro: is anyone working on application indicator support for liferea?
[20:30] <jcastro> not afaik
[21:17] <Riddell> cjwatson: what's the best way to play with the stand alone ubiquity startup?
[21:28] <cjwatson> Riddell: I've been booting with break=casper-bottom and playing with it there
[21:28] <cjwatson> it's a bit time-consuming, but at least fairly reliable
[21:28] <cjwatson> Riddell: my current thought is that I could use setresuid() to confuse KApplication into thinking that we aren't running setuid
[21:29] <cjwatson> but without confusing dbus into thinking the euid is root
[21:29] <cjwatson> however, this involves writing osextras.setresuid, since python itself doesn't have that until 2.7
[21:32] <Riddell> cjwatson: it's weird because nothing much has changed in that area since karmic
[21:32] <Riddell> might be worth trying with an old kdesudo to see if that's it
[21:32] <Riddell> or even kdesu
[21:33] <cjwatson> we're not using either
[21:34] <cjwatson> the install-only mode starts ubiquity up directly as root
[21:34] <cjwatson> I'm wondering if the change might have been in something like dbus
[21:35] <cjwatson> I agree not a lot has changed; OTOH if I can fix it with setresuid that might be a win all round :)
[21:35] <cjwatson> I'm speculating slightly - the strace was hard to make out
[21:35] <cjwatson> actually I'm speculating a lot
[21:36] <cjwatson> might be reproducible by starting an arbitrary KDE application as real-root (setuid not seteuid, so su not sudo) though, making sure that DBUS_SESSION_BUS_ADDRESS is passed through
[21:36] <cjwatson> with any luck it would crash in the same way
[21:53] <gtlz> any work being done on the "encrypted home directory" stuff to allow users to pick from the different algos? i'd love to be able to pick twofish with a 32 keybit for example...
[21:54] <gtlz> without having to do it manually
[21:57] <Caesar> So I have this theory that autofs5-ldap isn't behaving because it's being started prior to the network coming up (it has no upstart job)
[21:57] <Caesar> Is that possibly what's happening?
[21:59] <sebner> jdstrand: it makes me pretty sad to say this but please don't sync supertux today (FFe, just subscribed ubuntu-archive) as it's still in incomming *hahah* xD
[22:00] <jdstrand> sebner: heh, ok
[22:01] <sebner> jdstrand: thanks :)
[22:12] <slangasek> Caesar: sysvinit scripts will not be run before localhost is up, but other network interfaces aren't guaranteed to be up
[22:13] <Caesar> Hmm, so that may well be the problem then
[22:13] <Caesar> I shall try to write an upstart job for autofs5
[22:13] <Caesar> How do I specify "when a non-lo interface has started"?
[22:14] <slangasek> Caesar: cf. /etc/init/nmbd.conf in samba
[22:14] <Caesar> Very good
[22:46] <cjwatson> Riddell: I've confirmed that the same thing happens under su
[22:47] <cjwatson> (admittedly with konqueror rather than ubiquity, but the failure is in the same place)
[22:51] <Caesar> Hmm, with either expect fork or expect daemon I end up with two automount processes, whereas with start-stop-daemon, I only had one
[22:52] <cjwatson> Riddell: also confirmed that using setres[ug]id fixes it for launching konqueror in a suitably configured environment
[22:53] <cjwatson> so I think I'll go ahead with this approach
[23:13] <kees> tedg: so, I have indicator-applet on my panel.  it has a little envelope thing that implies it's related to pidgin.  how do I get rid of that?
[23:13] <tedg> kees: Pidgin or the applet?
[23:14] <tedg> kees: There is xchat messaging menu integration now...
[23:14]  * tedg hugs kenvandine
[23:14] <kees> tedg: then envelope itself.  it's an icon on my desktop that is meaningless for me, so I don't want it showing up.
[23:14] <kees> tedg: also, the volume control icons are busted; how do I fix that?
[23:14] <tedg> kees: If you really want it gone you can apt-get remove indicator-messages
[23:15] <tedg> kees: But if you just want the icon to leave you can copy /usr/share/indicators/messages/applications/* to ~/.config/indicators/messages/application-blacklist
[23:15] <tedg> Hell you could probably sym link it... but I haven't tried that.
[23:16] <kees> tedg: so, just having a file there causes an icon to appear?  I'm running neither pidgin nor evolution, so I wouldn't expect an indicator for it.
[23:17] <tedg> kees: The idea is that you don't need to know if the program is running or not to find the messaging menu useful.
[23:17] <persia> kees: The trick is that it's not trivial to tell what might send DBus messages.
[23:17] <superm1> but if you close pidgin buddy list it doesn't stay running?
[23:18]  * persia is gleefully removing indicator-messages and indicator-me
[23:18] <kees> how about having it only show up if pidgin or evolution sends a message?
[23:18] <tedg> persia: That's actually not an issue, we do lots of crazy things to make it so we can discover that :)
[23:18] <persia> tedg: Can you do more crazy things, because I'd like my panel space back :)
[23:18] <tedg> kees: We do, only if they're installed.  By installing them you're sending a message :)
[23:19] <persia> tedg: Except I've gone through and purged all of evolution and pidgin, and I still have it.
[23:19] <tedg> persia: That is probably because you were on devel release for karmic.
[23:19] <persia> tedg: No, this is in lucid.
[23:19] <tedg> persia: There's probably a file in /etc/indicators/* that was installed.
[23:19] <kees> tedg: no, i mean, it's fine that the files are there and installed, but why show the icon before the application has sent a notification?
[23:19] <tedg> persia: We couldn't remove them in /etc, so that's why it's /usr/share now.
[23:20] <persia> ls: cannot access /etc/indi*: No such file or directory
[23:20] <kees> tedg: to confirm, ~/.config/indicators/messages/application-blacklist  (singular, not plural "application") should be a directory contiains the files from  /usr/share/indicators/messages/applications/ ?
[23:20] <tedg> kees: I realize what you're saying.  And I'm saying that we can't really figure out whether you're using an application or not.  We want to have an entry there whether it's running or not.
[23:21] <kees> tedg: so far, symlinks, copying, plural and singular, has not worked
[23:21] <kees> tedg: can you explain why?  (i.e. it's never sent a message, so why is there an icon?)
[23:21] <tedg> kees: ~/.config/indicators/messages/applications-blacklist/
[23:21] <tedg> kees: Sorry, I think that was wrong before
[23:22] <persia> tedg: blacklisting is great, but the complaint is that it shows by default even if clients aren't installed.
[23:22] <kees> tedg: blacklist doesn't work.  can you confirm it works for you?
[23:22] <tedg> kees: You could say that the same about the Applications menu :)
[23:22] <tedg> kees: Yeah, I have Empathy blacklisted
[23:22] <kees> tedg: no, that's for applications I want to start.  the notification area is for messages that are waiting for my attention.
[23:22] <tedg> persia: If it's not installed, that's a bug.
[23:23] <kees> tedg: do I need to restart something for it to notice?
[23:23] <tedg> kees: Your clock wants your attention?
[23:23] <tedg> kees: No they're all watches.
[23:23] <kees> tedg: my clock is running.  it's a separate applet completely.
[23:23] <kees> tedg: update manager sends a notification, an icon appears.
[23:24] <persia> tedg: Just to confirm, I should be able to have indicator-messages installed and not see an icon if I have neither of pidgin or evolution installed, right?
[23:25] <tedg> kees: Think of the messaging menu more like your clock.  It's a place for messages to go, and a place for you to find messaging applications.
[23:25] <kees> tedg: can you pastebin this for me: find ~/.config/indicators/messages/applications-blacklist | xargs grep -H .
[23:25] <tedg> persia: Yes.
[23:25] <tedg> persia: Do you have anything in /usr/share/indicators/messages/applications ?
[23:25] <persia> tedg: Thanks.  I'll reconfirm with a fresh lucid install, and file a bug from there.
[23:26] <kees> tedg: but how do I configure (GUI) what I want for messaging?  not everyone uses evolution and pidgin
[23:26] <cjwatson> Riddell: I've committed what should be a fix for this
[23:26] <kees> tedg: for example, rhythmbox doesn't show up there until I run it.
[23:27] <tedg> kees: I don't get anything from that command...
[23:27] <Riddell> cjwatson: I owe you beer
[23:27] <kees> tedg: then I don't understand how you're blacklisting.  can you walk me through it?
[23:28] <tedg> kees: $ cp /usr/share/indicators/messages/applications/empathy /home/ted/.config/indicators/messages/applications-blacklist/
[23:28] <kees> cp: cannot stat `/usr/share/indicators/messages/applications/empathy': No such file or directory
[23:28] <tedg> kees: Okay, replace with pidgin or what ever you want to blacklist
[23:28] <kees> cp /usr/share/indicators/messages/applications/* ~/.config/indicators/messages/applications-blacklist/
[23:28] <persia> tedg: "ls: cannot access /usr/share/indicators/mes*: No such file or directory" (indicator-messages is installed)
[23:29] <cjwatson> Riddell: wait until it provably works :) I only tested it out of context ...
[23:29] <kees> tedg: after the above cp, I still have the icon
[23:29] <tedg> persia: Hmm, ls ~/.config/indicators/messages/applications ?
[23:29] <tedg> kees: Is it in the menu?
[23:29] <tedg> kees: Are there entries in the menu?
[23:29] <kees> tedg: yes.
[23:29] <cjwatson> Riddell: would have been a hell of a lot less work if we were using python 2.7 :-/
[23:29] <kees> $ ls ~/.config/indicators/messages/applications-blacklist
[23:29] <kees> evolution  pidgin
[23:30] <kees> and I still have the envelope icon and when clicking the icon, it has pidgin and evolution stuff listed
[23:30] <persia> tedg: ls: cannot access .config/indicators/mess*: No such file or directory
[23:30] <kees> persia: I had to create the directory
[23:30] <persia> kees: Right, which makes the contents of the directory unlikely to affect the issue :)
[23:31] <tedg> kees: Hmm, Oh, I guess it couldn't create a watch because the dir didn't exist.  You'll have to restart your session.
[23:31] <kees> _session_!?
[23:31] <tedg> kees: Or killall indicator-messages-service indicator-applet
[23:31] <kees> I've restarted the applet a few times, but yeah, I'll try messages-service instead
[23:32] <kees> tedg: still there.
[23:32] <tedg> persia: I have no idea where your entries are coming from then.  That's very odd.  There's no hardcoded entries.
[23:32] <tedg> kees: Entries in the menus?
[23:32] <persia> tedg: OK.  Do you need a clean install for me to file a bug, or shall I just file from my workstation?
[23:32] <kees> tedg: oddly, evolution is gone, but pidgin remains.
[23:33] <tedg> persia: If you could start indicator-messages-service on the console and give the output that'd be best.
[23:33] <tedg> persia: It's very chatty
[23:33] <tedg> kees: Heh, Pidgins, can't get rid of them.
[23:33] <kees> :P
[23:34] <tedg> kees: Do you have any entries in ~/.config/indicators/messages/applications ?
[23:34] <persia> tedg: I get a coredump :)
[23:34] <Riddell> cjwatson: I'll give it a test on the CDs tomorrow, many thanks for looking into it
[23:34] <kees> tedg: nope
[23:34] <tedg> persia: After you killed the running one?
[23:34] <persia> tedg: do I need to start it in a special way, or shall I just send an apport report with the coredump?
[23:34] <tedg> persia: So special way, but it might not handle not getting it's name gracefully (which should be a bug also)
[23:35] <tedg> kees: Hmm, interesting.  Are you sure Pidgin isn't running?
[23:36] <kees> $ pidof pidgin | wc -l
[23:36] <kees> 0
[23:36] <kees> other notes: symlink doesn't work.
[23:36] <tedg> kees: I guess file a bug, I'm unsure why that'd be.
[23:36] <kees> tedg: also, watches don't seem to work.
[23:36] <tedg> Okay guys, I need to run to make dinner.
[23:36] <kees> tedg: thanks!
[23:36] <tedg> Please file bugs, it should go away too :)
[23:38] <cjwatson> Riddell: guess I'd better upload then :)
[23:38] <persia> kees: You're filing the bug?
[23:39] <kees> persia: yup
[23:39] <kees> persia: 3 actually
[23:41] <persia> kees: Excellent, then I'll refrain.
[23:42] <kees> persia: bug 533021 if you want to confirm/subscribe
[23:43] <kees> and bug 533023
[23:47] <persia> purging indicator-messages also seems to work, but that seems a less ideal solution (as I *do* want it to suddenly magically pop up if I happen to use a supported client)