[00:05] <arand> robert_ancell: Regarding chromium-bsu in featured... It seems (test on noveau vs nvdidia) to run unbearably slow if no 3D accel is available, so maybe one should look otherwise for a simple 2D game?
[00:07] <robert_ancell> arand, could you note that on https://wiki.ubuntu.com/DesktopTeam/Lucid/FeaturedApps.
[00:07] <arand> robert_ancell: will do.
[00:08] <robert_ancell> arand, I'll also update that with the current choices so it's easier to comment on
[00:10] <robert_ancell> arand, I suspect that supertuxkart has the same problem.  Perhaps a solution is to update the package description with "This game requires 3D support"
[00:14] <arand> robert_ancell: Definitely a good idea. Regading chr-bsu I figured one of it's raison-de-etre might be that it is a simple 2D game, which is kind of spoiled if it needs 3D support.
[00:14] <robert_ancell> arand, is there a good candidate for replacement?
[00:15] <arand> robert_ancell: hmm, not really that I know off the top of my head..
[00:16] <robert_ancell> arand, the policy for the list is once a package is on the list it remains there until it is replaced by a better package
[00:17] <arand> robert_ancell: ah, right, and the ratio games/other is set for now?
[00:18] <robert_ancell> arand, no ratio is set,  it just has to be argued that the new list is better than the old one
[00:19] <robert_ancell> (so a new list might get rejected on the grounds "too many games" or "not enough games")
[00:21] <arand> robert_ancell: right, time to go wild in the software centre..
[00:22] <robert_ancell> arand,  :)
[01:24] <thewilbob> hello, my mail notification alert popup for thunderbird 2.xx24 and Ubuntu 9.10 using Gnome is huge.  How to control the size?
[06:19] <pitti> Good morning
[06:20] <pitti> rickspencer3: I've seen those as well -- you mean popup help which stays around until you click it away?
[06:22] <pitti> rickspencer3: ah, no, I have something different then
[06:24] <RAOF> Good morning.
[06:31] <pitti> hey RAOF, how are you?
[06:32] <RAOF> Good.
[06:32] <TheMuso> Hey pitti.
[06:32] <RAOF> I'm seeing if I can write a patch to prevent VESA from loading when kms is active faster than pbuilder can build gjs on armel. :)
[06:32] <pitti> heh
[06:32] <pitti> good luck!
[06:32] <TheMuso> lol
[08:14] <didrocks> good morning
[08:23] <pitti> bonjour didrocks
[08:23] <didrocks> pitti: hey pitti, how are you?
[08:24] <pitti> I'm splendid; how are you? back from the conference?
[08:24] <pitti> didrocks: I solved your Popen() mystery
[08:24] <didrocks> pitti: oh nice, I didn't look at my email yet. I have a huge backog :)
[08:25] <didrocks> right, back from the conference/canonical booth. We had a lot of people, it was nice
[08:25] <didrocks> of course, my voice is totally out of order today :)
[08:25] <didrocks> (3 days is a little bit hard when you're not used to speak in a noisy environment)
[08:25] <pitti> yes, your IRC sounds raw today :-P
[08:25] <didrocks> but it was fun :)
[08:25] <didrocks> heh
[08:25] <pitti> great to hear!
[08:26] <didrocks> how was the beta going? Not too much "last minute changes to be done now NOW NOW!" ? :)
[08:30] <didrocks> pitti: nice catch (just read your email) about the buffering and the option to fix that but I don't understand how the shell (when you execute python-mkdebian directly), ask to print what you currently have in the buffer before python deciding that the buffer is full enough to print it
[08:30] <pitti> kwwii: do you know how/where the theme previews are generated/stored? I wondered about bug 540907
[08:30] <pitti> didrocks: I can't parse your sentence, I'm afraid
[08:31] <didrocks> hum, let me rephrase :)
[08:31] <pitti> didrocks: the shell isn't involved at all with this
[08:31] <pitti> it just connects pipes
[08:31] <didrocks> pitti: right, but as you said, the issue is that python is buffering too much its stdout
[08:31] <pitti> didrocks: oh; I just know that shell programs are line buffered, so it's a nice comparison to check whether the problem is on the feeding or receiving side
[08:32] <pitti> didrocks: right; it's fully buffered when stdout is not a termial, and line-buffered if it is a terminal
[08:32] <pitti> (by default)
[08:32] <didrocks> ok, that was that part missing for me "fully buffered when stdout is not a termial, and line-buffered if it is a terminal" :)
[08:32] <didrocks> pitti: thanks a lot for looking at that and for the fix as well :)
[08:32] <pitti> de rien
[08:39] <seb128> good morning desktopers
[08:40] <Nafallo> morning seb128
[08:41] <didrocks> good morning seb128
[08:43] <seb128> hey Nafallo didrocks
[08:44] <seb128> didrocks, had good holidays?
[08:44] <didrocks> seb128: oh :p Not really holidays and more tired than working at home, TBH :)
[08:44] <seb128> lol
[08:44] <didrocks> seb128: yesterday, my voice was low. Today, it's totally broken!
[08:44] <seb128> so you are back to quiet work today? ;-)
[08:45] <didrocks> seb128: heh, I tried to minimize the backlog. Just put on the side, bugs I should triage/comment and delete the noise. But I think it'll be ok and a quiet day (well, at least, I hope it will :))
[08:46] <pitti> bonjour seb128
[08:46] <didrocks> seb128: and you, rushing once the freeze will be no more in practice? :)
[08:46] <seb128> hey pitti!
[08:46] <seb128> didrocks, no, I''ve been filling the queue
[08:46] <seb128> got a rhythmbox update with 5 bug closed yesterday
[08:46] <didrocks> nice :)
[08:47] <seb128> I had to do something, pitti throw some gauntlet at me yesterday ;-)
[08:47] <pitti> wow
[08:47] <pitti> seb128: oh, btw, wrt the Y3
[08:47] <pitti> seb128: I faintly remember that I had to enable the MTP plugin manually
[08:47] <didrocks> seb128: heh
[08:47] <seb128> pitti, works now since the mtp gconf key is fixed
[08:47] <pitti> so that might explain why it worked for me now
[08:48] <seb128> pitti, yeah, as I said yesterday evening it was missing the schemas keys to enable it :p
[08:48] <pitti> seb128: so that was the key for enabling the plugin?
[08:48] <seb128> yes
[08:48] <pitti> sweet
[08:48]  * pitti hugs seb128
[08:48] <seb128> it's in the queue now
[08:48]  * seb128 hugs pitti
[08:48] <seb128> I want lucid to unfreeze!
[08:48] <seb128> so much good things waiting ;-)
[08:48] <pitti> hah, 67 packages
[08:48] <seb128> + syncs pendings
[08:49] <seb128> I guess like new udisks is not there but you will sync from Debian?
[08:49] <pitti> "A total of 3077 bug tasks were fixed during Lucid!"
[08:49] <pitti> that will jump quite a bit after the flush
[08:49] <seb128> I'm pondering waiting for updates or do multimedia playing
[08:49] <pitti> it might get me very close to kirkland, depending on how many he piled up
[08:49] <seb128> testing rather
[08:50] <seb128> that was not clear
[08:50]  * seb128 wants to test all his players on lucid
[08:50] <seb128> like file them up from rhythmbox, play songs, etc
[08:50] <seb128> I've a U3 and some ipods there
[08:50] <pitti> with new gdu/udisks/mpi it will work much better
[08:50] <seb128> ok, so let's wait for those
[08:50] <seb128> I don't fancy doing all the testing twice
[08:50] <pitti> teuf also fixed libgpod yesterday
[08:50] <seb128> right
[08:50] <pitti> I hope he will release it soon
[08:51] <pitti> and we need to fix humanity-icon-theme
[08:51] <seb128> btw the DK_ rules comes from libgpod
[08:51] <seb128> not from my old devicekit-disks config
[08:51] <seb128> I've that pending too
[08:51] <pitti> h-i-t ships /usr/share/icons/Humanity/devices/24/multimedia-player-ipod.svg
[08:51] <pitti> but it tought to be m-p-apple-ipod.svg
[08:52] <seb128> pitti, http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/libgpod;a=commit;h=8b89229eb5ae88ed40438fa789b665817d71a786
[08:53] <seb128> pitti, http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/libgpod;a=commit;h=23db920dc865f208af176886228c5f67686248cf
[08:53] <pitti> seb128: right, I discussed all those with teuf yesterday
[08:53] <seb128> pitti, those 2 commits are interesting
[08:53] <seb128> the second one explain the DK lines in my udev log
[08:53] <pitti> I'll prod him to cut a new release (he was about to anyway), then we can package that
[08:53] <seb128> pitti, I was going to do the 0.7.1 update + those 2 commits today
[08:53] <seb128> 0.7.91 rather
[08:54] <seb128> but I will update when he does a new tarball
[08:54] <pitti> seb128: I pinged teuf
[08:54] <seb128> pitti, thanks
[08:55] <seb128> let me know if he plans to roll a new tarball today
[08:55] <seb128> otherwise I will do what I said
[08:55] <pitti> I will
[08:55] <seb128> it's easy enough to do another update next week
[08:55] <seb128> but I want to do ipod testing this afternoon so I will probably build the new version + git changes anyway
[08:55] <seb128> I can as well upload that if there is no tarball today
[08:57] <pitti> teuf | pitti: maybe tonight
[08:57] <pitti> teuf | pitti: you want one soon ?
[09:13] <seb128> pitti, thanks
[09:14] <pitti> I'm off to doctor for ~ 1 hour
[09:14] <seb128> pitti, see you
[09:32] <huats> morning !
[09:33] <didrocks> salut huats. How was your trip back to Toulouse?
[09:35] <huats> hello didrocks
[09:35] <huats> it was quite good : I slept till Bordeaux (which is more than half of the trip :))
[09:44] <thekorn> hi, if changing the keyboard layout using g-keyboard-properties is not working, the bugreport should be filed against g-settings-daemon, correct?
[09:56] <huats> didrocks, remember pessulus :)
[09:57] <didrocks> huats: I have an event in my calendar for it :)
[09:57] <didrocks> but not now ^^
[09:57] <huats> sure
[10:01] <pitti> re
[10:04] <mvo> seb128: you will not like this, but its needed (or something like this, does not have to be exactly this). bug #514879 has a patch now
[10:21] <kwwii> pitti: the problem with the theme preview has to do with the buttons in metacity
[10:21] <kwwii> pitti: it is a known problem which we are hopefully going to fix
[10:30] <pitti> kwwii: ah, great; thanks
[10:36] <didrocks> back in a little bit more than one hour, going to have a lunch with vuntz :)
[10:39]  * vuntz is kidnapping didrocks 
[11:03] <pitti> seb128: oh, btw
[11:03] <pitti> seb128: bug 539636
[11:04] <pitti> seb128: I've analyzed the main bug now (bug 438136) and summarized into https://bugs.freedesktop.org/show_bug.cgi?id=25772#c6
[11:04] <pitti> seb128: but your particular bug report is a more interesting case
[11:04] <pitti>  reallocated-sector-count     77|  1| 63 FAIL_PAST 1783 sectors Pre-fail Online
[11:04] <chrisccoulson> pitti - are you noticing any consolekit weirdness?
[11:04] <chrisccoulson> i'm getting this in my syslog:
[11:04] <chrisccoulson> chris-laptop console-kit-daemon[1200]: WARNING: Could not determine active console
[11:04] <pitti> seb128: this is not an issue of mis-parsing the raw sector count
[11:05] <pitti> seb128: the normalized count is also pretty low already (77), and in the past the drive's own firmware even detected it much worse (which might be a firmware bug)
[11:05] <pitti> seb128: but still, if I were you I'd replace that disk
[11:05] <pitti> hi chrisccoulson
[11:05] <chrisccoulson> hey pitti
[11:06] <pitti> chrisccoulson: I have one entry for that in auth.log
[11:06] <pitti> ah, no, haha
[11:06] <pitti> auth.log:Mar 19 12:05:55 tick sudo:   martin : TTY=pts/2 ; PWD=/var/log ; USER=root ; COMMAND=/bin/grep Could not determine active console
[11:06] <chrisccoulson> i'm also seeing lots of these:
[11:06] <chrisccoulson> chris-laptop console-kit-daemon[1200]: WARNING: Error waiting for native console 8 activation: Invalid argument
[11:06] <pitti> that was just the grep that I just did
[11:07] <chrisccoulson> basically, consolekit is totally broken here (it says i'm not on the active console)
[11:07] <chrisccoulson> and so not much is working now ;)
[11:08] <pitti> chrisccoulson: is the daemon running? ck-list-sessinos?
[11:08] <pitti> "sessions"
[11:08] <asac_> pitti: so how do you i18n .desktop files in upstream python build systems? where is a good example package?
[11:08] <chrisccoulson> pitti - it is. and this is what ck-list-sessions shows:
[11:08] <chrisccoulson> http://paste.ubuntu.com/397759/
[11:09] <pitti> chrisccoulson: this seems fine?
[11:09] <chrisccoulson> pitti - "active = FALSE"
[11:09] <chrisccoulson> that should be true
[11:09] <pitti> asac_: just the same as in C projects -- .desktop.in and use intltool-merge
[11:09] <pitti> asac_: jockey and apport do that (with distutils-extra)
[11:09] <asac_> ok. so distutils-extra
[11:10] <pitti> chrisccoulson: ah, indeed
[11:11] <pitti> asac_: but of course you can also copy the intltool logic from DistUtilsExtra/command/build_i18n.py
[11:11] <pitti> chrisccoulson: if you can reproduce that, running the CK daemon in the foreground (on a VT) might be interesting
[11:11] <asac_> pitti: i look at jockey ... the desktop.in files are nowhere referred to (not setup.py etc.)
[11:11] <pitti> (and then do some VT switching/X sessions, etc.)
[11:11] <chrisccoulson> pitti - the consolekit error message is triggered because this fails:
[11:11] <chrisccoulson> ioctl (console_fd, VT_WAITACTIVE, num);
[11:12] <pitti> asac_: distutils auto.py magic :)
[11:12] <chrisccoulson> so, i wonder who messed up the VT stuff ;)
[11:12] <pitti> asac_: it grabs all .desktop.in files automatically
[11:12] <asac_> oh
[11:12] <pitti> asac_: and adds them to POTFILES.in, etc.
[11:12] <asac_> pitti: and you create the .pot with intltool-merge ?
[11:12] <asac_> oh
[11:12] <asac_> right i wondered where the POTFILES.in is
[11:13] <pitti> asac_: .pot is intltool-update; intltool-merge takes a bunch of .po and a .desktop.in (or other .in files) and builds the merged .desktop
[11:13] <pitti> asac_: i-update extracts strings from sources (in POTFILES.in) and builds a pot; it can also merge the .po files against an updated .pot
[11:14] <asac_> let me try that ;)
[11:17] <asac_> pitti: so what do i run to bootstrap the po/ ? e.g. i make a distutils.auto setup.py ... and then i run that like what?
[11:18] <seb128> re
[11:18] <seb128> sorry I was out for some shopping
[11:18] <seb128> mvo, looking but yeah, I'm not sure we want to change gtk now
[11:19] <pitti> asac_: "bootstrap"? it can't automatically translate for you, sorry
[11:19] <pitti> asac_: that's for the next version, with babelfish integration :-P
[11:19] <seb128> pitti, rock on for libsmartata
[11:19] <seb128> pitti, what is the issue with my disk?
[11:20] <pitti> seb128: just replied in the bug (basically the same what I said above)
[11:20] <seb128> ok
[11:20] <seb128> will check in a bit
[11:20] <pitti> seb128: but your blob is a perfect test case
[11:21] <pitti> seb128: i. e. it is a state where it's actually justified to warn users, but it's not below the vendor threshold yet
[11:21] <asac_> pitti: i mean when i setup the upstream build system
[11:21] <asac_> i have no po/ directory
[11:21] <pitti> asac_: just build it once
[11:21] <asac_> ok
[11:21] <pitti> asac_: then you have po/myproject.pot
[11:21] <pitti> and can then copy that to e. g. de.po and start translating
[11:22] <seb128> pitti, maybe the warning could be lighter in such cases ;-)
[11:22] <pitti> seb128: how does it look like now?
[11:22] <pitti>       overall assessment:      Disk reports many bad sectors
[11:22] <pitti> that looks pretty correct
[11:23] <seb128> well the notification area icon has a red bold label
[11:23] <pitti> seb128: well, when I'm done with patching libatasmart it will say "bad sectors", but still say "okay"
[11:23] <seb128> it makes you feel like you should change the disk NOW
[11:23] <seb128> where this disk is working for years with this error
[11:24] <pitti> ah, I'll just load your blob into udisks and see
[11:24] <pitti> nice way of testing it both ways
[11:27] <asac_> pitti: yeah. that worked. so how do i get all the translations we already have in the .desktop in the po? or is that ok to keep them there?
[11:27] <pitti> asac_: the .desktop.in shouldn't have any
[11:27] <seb128> ups
[11:27] <pitti> seb128: FYI, $ sudo udisks --ata-smart-refresh /dev/sda --ata-smart-simulate /tmp/smart.blob
[11:27] <seb128> pitti, ok
[11:28] <seb128> ah, good to know
[11:28] <asac_> pitti: well. we had a .desktop with plenty of transltaions ;)
[11:28] <pitti> seb128: that's a great way of testing this stuff once you have a blob
[11:28] <asac_> i would prefer to not loose them
[11:28] <pitti> asac_: hm, you could write some seddery/small perl script to extract them and put them into a .po file, and then use intltool-update to merge them, so that they get a proper format?
[11:29] <pitti> seb128: ah, and now I also see the notification with an action
[11:29] <pitti> seb128: do we have a bug for that as well?
[11:29] <seb128> yes, it's milestoned
[11:29] <asac_> ok thanks
[11:29] <asac_> guess i will just drop them for now ... we can add that back later
[11:30] <pitti> asac_: how many are there?
[11:30] <pitti> asac_: if it's just 5, a manual copy&paste is certainly much faster :)
[11:35] <asac_> pitti: 80 ;)
[11:35] <asac_> but ok
[11:35] <asac_> i dropped them for now ... it was a copy from openoffice anyway
[11:39] <chrisccoulson_> pitti - i rebooted and consolekit is working again now
[11:39] <pitti> chrisccoulson_: strange
[11:39] <chrisccoulson_> but it's done that twice now since yesterday evening :-/
[11:39] <pitti> chrisccoulson_: perhaps it's stumbling over a bad console state sometimes, while plymouth does its magic
[11:39] <chrisccoulson_> pitti - i suspect that's probably what happens
[11:39] <pitti> chrisccoulson_: perhaps change the d-bus service file to launch it through /bin/sh -c and redirect output to /var/log/consolekit.log?
[11:40] <pitti> (unless it's already going to syslog, of course)
[11:40] <seb128> james_w`, hey
[11:40] <chrisccoulson_> the output already goes to syslog
[11:40] <seb128> james_w`, do you have a minute for a bzr question?
[11:40] <chrisccoulson_> pitti - but the error is that the ioctl returns EINVAL
[11:40] <pitti> chrisccoulson_: then merely add --debug to the .service?
[11:41] <chrisccoulson_> pitti - yeah, i added --debug to the service file
[11:41] <pitti> chrisccoulson_: ah, if you already tracked it down to that, perhaps open a bug and subscribe Keybuk? I think he knows the VT stuff inside out now
[11:41] <chrisccoulson_> pitti - yeah, will do
[12:05] <mvo> seb128: not now> fine with me, but something needs to happen soonish (next week?). without some patch like this the performance of the treeview is just too bad
[12:06] <seb128> mvo, "now" was lucid cycle there
[12:06] <seb128> mvo, "now" was lucid cycle there
[12:06] <seb128> ups
[12:06] <mvo> seb128: oh
[12:07] <seb128> mvo, well I commented before looking at the change
[12:07] <mvo> seb128: we need a solution for lucid
[12:07] <seb128> mvo, I don't like much having but I guess if it's needed
[12:07] <mvo> I don't like it either
[12:08] <mvo> if I had my will we would not do treeviews with changing height until the problem is properly fixed
[12:08] <mvo> but I did not get my will so we need to do something
[12:09] <seb128> do you think you could still email the upstream list to raise the issue?
[12:09] <mvo> I will try
[12:09] <seb128> mvo, speaking of which you got a reply from thos on g-c-c
[12:10] <seb128> mvo, I will upload your change, I've a fix from Cody to upload too
[12:10] <mvo> I had hoped for support for the treeview speed  from bratsche
[12:10] <seb128> but that might be on monday
[12:10] <mvo> seb128: yeah, this is what I was about to suggest, to wait until mondy
[12:10] <seb128> I don't want to queue gtk changes to go in when nobody is around
[12:10] <mvo> just in case
[12:10] <mvo> and I will push a updated patch to upstream to see if I can convince them, I think it could even be included in the general case because I can not (currently) measure any slowdown
[12:14] <seb128> mvo, thanks!
[12:14]  * seb128 lunch now
[12:14] <seb128> bbl
[12:26] <pitti> chrisccoulson_: hm, it seems that 5 of the 6 "triaged problems" on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus are your's.. do you need some help with those?
[12:26] <pitti> chrisccoulson_: we can probably discuss bug 532511 again, and I'm sure that seb128 or I can also help with bug 456468
[12:27] <chrisccoulson_> pitti - we're pretty screwed with bug 456468 after the investigation we did yesterday
[12:27] <chrisccoulson_> but i would appreciate some help on deciding a way forward for bug 532511
[12:28] <chrisccoulson_> pitti - did you follow what we did with bug 456468 yesterday?
[12:29] <pitti> chrisccoulson_: no, I didn't follow
[12:29] <pitti> the bug trail doesn't seem to have anything new?
[12:30] <chrisccoulson_> pitti - what happens is - glibc and gtk gets updated, then something triggers an icon reload in nm-applet
[12:30] <chrisccoulson_> and nm-applet tries to load the (new) libpixbufloader-png.so in to memory, which depends on the latest glibc library
[12:30] <chrisccoulson_> but the old glibc is still in memory, and it fails
[12:30] <pitti> oh, I think I saw that bit
[12:30] <chrisccoulson_> pitti - ** (nm-applet:1368): WARNING **: Icon nm-active-device missing: Unable to load image-loading module: /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so)
[12:31] <pitti> chrisccoulson_: so is that why nm-applet dies during dist-upgrade, but comes back just fine?
[12:31] <chrisccoulson_> i should probably update the bug really
[12:31] <chrisccoulson_> pitti - yeah, that's why it dies
[12:31] <chrisccoulson_> but it affects lots more stuff than nm-applet
[12:31] <pitti> I even restarted it during dist-upgrade
[12:31] <chrisccoulson_> pitti - have a look at my xsession-errors from the upgrade: http://paste.ubuntu.com/397262/
[12:31] <chrisccoulson_> (its not nice)
[12:31] <pitti> is that even something new? similar stuff seems to have happened during just about any dist-upgrade so far, AFAIR
[12:32] <chrisccoulson_> i'm not sure. i suppose most things just don't die like nm-applet does
[12:33] <pitti> it's not a big deal for ethernet anyway, but I guess you'd suddenly lose wifi during dist-upgrade
[12:33] <chrisccoulson_> yeah, that seems to be what happens
[12:33] <pitti> which is still not breaking the upgrade (since by that time all the .debs were downloaded), but a bit of a wart
[12:34] <seb128> pitti, I don't have any idea about the nm issue
[12:34] <pitti> chrisccoulson_: so ideally in this case nm-applet would ignore all the new icons etc. and just keep on running, right?
[12:34] <seb128> pitti, neither does has mvo
[12:34] <chrisccoulson_> pitti - yeah, probably
[12:34] <chrisccoulson_> that doesn't help for upgrades though
[12:34] <chrisccoulson_> (as it's the old version running)
[12:34] <pitti> seb128: right, just pondering, since as I said Chris currently owns 5 out of 6 RC bugs
[12:34] <seb128> pitti, we discussed it yesterday, we are basically screwed out of changing the code running before upgrade
[12:35] <pitti> well, I don't personally consider it a dealbreaker anyway
[12:35] <seb128> pitti, how do you build your rc list?
[12:35] <pitti> seb128: lucid targetted, priority high or critical
[12:36] <pitti> see https://wiki.ubuntu.com/RCBugTargetting
[12:36] <seb128> pitti, I'm sure we have other bugs matching those criterious
[12:36] <seb128> I've at least opened half a dozen of > high with lucid tasks
[12:36] <seb128> none being there
[12:36] <pitti> seb128: yes, I didn't update the list this week yet
[12:37] <mvo> could we detect it exiting and restarting it? I'm desperate but I wanted to throw the idea out
[12:37] <pitti> seb128: I'm about to :)
[12:37] <pitti> mvo: in new code, yes ..
[12:37] <mvo> in u-m I mean
[12:37] <chrisccoulson_> mvo - that should really be the responsibility of the session manager to do that
[12:37] <chrisccoulson_> but for some reason, we disable session manager integration in nm-applet
[12:37] <seb128> mvo, we could I guess, but would it behave correctly with the old nm still running?
[12:38]  * mvo has no idea 
[12:38] <seb128> or do we need to restart nm?
[12:38] <mvo> isn't the dbus API stable?
[12:38] <seb128> no clue
[12:38] <seb128> I think it changed since hardy
[12:38] <seb128> nm 0.6 to 0.8
[12:38] <seb128> but I'm not sure
[12:39]  * mvo looks for the NM expert
[12:39] <pitti> seb128: different question, should we go with poppler 0.13/0.14, or stay at 0.12?
[12:40] <pitti> seb128: (at this point I'd think stay at 0.12, but checking..)
[12:42] <seb128> pitti, how come you ask about that? just curious
[12:42] <seb128> pitti, stay with 0.12
[12:42] <pitti> seb128: bug 404214
[12:42] <pitti> seb128: ok, I'll grab that bug then and backport the patch
[12:42] <seb128> 0.13 will we stable after lucid
[12:42] <seb128> and requires cairo 1.9
[12:42] <seb128> and still no sign of cairo 1.10
[12:42] <seb128> which was due in january
[12:43] <seb128> I don't trust them for getting it on time and it's late for upgrading cairo to a new serie
[12:43] <seb128> pitti, thanks
[12:43] <seb128> pitti, urg http://qa.ubuntu.com/reports/team-assigned/canonical-desktop-team-assigned-bug-tasks.html
[12:43] <seb128> pitti, there is like 3 screens of rc bugs for our team
[12:43] <seb128> quite some fix commited though but still
[12:44] <pitti> yes
[12:45] <pitti> seb128: I don't add them all to the wiki page, mostly just the things that Steve asks about in the release meeting invitation, plus some extra which I think are tricky and hard to fix
[12:45] <seb128> ah ok
[12:45] <pitti> seb128: but a lot of the ones in above list are not targetted to lucid
[12:45] <seb128> I was just surprised by the "5 of the 6 rc bugs we have are assigned to chrisccoulson_"
[12:45] <pitti> and thus are not release critical
[12:45] <pitti> s/are/appear to/
[12:46] <seb128> pitti, well there is at least 25 bugs with lucid tasks > High there
[12:47] <pitti> seb128: so far I was using https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?batch=200, and grabbed the desktop-y bits out
[12:48] <pitti> seb128: I think above page is buggy
[12:48] <pitti> it has bug 474917 at the top, but that was closed long ago
[12:48] <seb128> pitti, it's not closed
[12:49] <seb128> see ubottu
[12:49] <pitti> see the bug :)
[12:49] <seb128> weird
[12:49] <seb128> wth?
[12:50] <mvo> seb128: I updated upstream gnome #607447
[12:50] <seb128> mvo, danke
[12:50] <mvo> with hard data and updated patch
[12:51] <seb128> mvo, you rock, thanks
[12:52] <mvo> thanks, I hope its considered upstream
[13:14] <pitti> Riddell, kenvandine: can you please update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus for Kubuntu/DX?
[13:14] <kenvandine> pitti, sure
[13:15] <pitti> seb128: http://sourceforge.net/projects/gtkpod/files/libgpod/libgpod-0.7.9x/libgpod-0.7.92.tar.gz/download :)
[13:18] <seb128> pitti, danke!
[13:54] <pitti> seb128: ok, got the atasmart patch ready; now it says Overall Status: BAD_SECTOR instead of BAD_SECTOR_MANY
[13:54] <seb128> pitti, oh, nice
[13:54] <seb128> I still need to look at how those smart status work
[13:55] <seb128> because the winxp utilities we tried seem to disagree about the bad sectors on this disk there
[13:55] <pitti> seb128: no notification any more, but palimpsest says "contains some bad blocks"
[13:55] <pitti> sounds about right to me
[13:57] <seb128> yes, definitively better ;-)
[13:57]  * seb128 hugs pitti, the bug killer
[13:58]  * pitti hugs back seb128
[14:17]  * pitti sings "another one bites the dust"
[14:20] <seb128> pitti, which one?
[14:20] <pitti> seb128: well, the libatasmart one
[14:20] <seb128> ah
[14:20] <pitti> patch sent upstream, applied to debian git, uploaded
[14:20] <pitti> I want to get my 40th. "fix committed" task today still, so now off to those jockey bugs
[14:21] <seb128> lol
[14:21] <nigelb> pitti, seb128: you folks rock :) (probably we need to appreciate the awesome work more ;) )
[14:22] <seb128> nigelb, thank you!
[14:22] <nigelb> :)
[14:22] <pitti> nigelb: believe it or not, the best appreciation in practical live is when hundreds of people discuss button ordering or the shade of violet on the background image; it can't be so bad if they do that :)
[14:22] <pitti> nigelb: but thank you!
[14:23] <nigelb> :)
[14:23] <pitti> seb128: just to avoid collisions, do you plan an evo upload after the freeze?
[14:23] <pitti> seb128: I have a pending change to fix .desktop translations (in bzr)
[14:24] <seb128> pitti, nothing scheduled yet but we will most likely upload it before beta2 yes
[14:24] <seb128> pitti, the change is a no change rebuild with new cdbs right?
[14:24] <pitti> right
[14:24] <pitti> well, I bumped the b-dep
[14:24] <seb128> I was pondering doing that or not
[14:25] <pitti> in case I'd upload now
[14:25] <seb128> I don't like having artificial requirements just to not wait a few hours between uploads
[14:25] <pitti> then I don't need to worry about watching the publication, etc.
[14:25] <pitti> well, it's not artificial
[14:25] <Laney> my terminal theme just got overwritten on a karmic->lucid update. I seem to recall a bug for this being there already, is that right?
[14:25] <pitti> it will be buggy with earlier cdbs
[14:25] <seb128> right
[14:25] <seb128> upload
[14:25] <seb128> thanks
[14:25] <seb128> I need to chase njpatel about evo-indicator too
[14:25] <pitti> Laney: bug 532511
[14:26] <Laney> pitti: thanks
[14:26]  * Laney subscribes
[14:26] <seb128> jcastro, if you read me, fix your code! ;-)
[14:27] <hyperair> pitti: re bug #540098, it's a kernel thing.
[14:27] <pitti> hyperair: oh?
[14:27] <hyperair> pitti: i still see it, but only when it takes exceptionally long to suspend/resume.
[14:27] <pitti> hyperair: I was pretty sure I saw it before, but I tried three or four times now, and it looks fine
[14:27] <hyperair> pitti: the chvt is not done in userspace. ask in #intel-gfx if you don't believe me =\
[14:28] <pitti> hyperair: I originally suspected a wrong chvt quirk in pm-utils, but that's not it
[14:28] <pitti> hyperair: I do believe you
[14:28] <jcastro> seb128: ?
[14:28] <hyperair> pitti: i965 chvts internally
[14:28] <pitti> hyperair: but it's not a bug in pm-utils either way then
[14:28] <pitti> hyperair: 945 too then, apparently
[14:28] <pitti> hyperair: but thanks for telling me, then I won't go crazy :)
[14:28] <seb128> jcastro, sorry that was supposed to be for njpatel, the n skipped and completion did its job :p
[14:28] <hyperair> pitti: hehehe =p
[14:29] <seb128> jcastro, hey btw, how are you? ;-)
[14:29] <njpatel> seb128, what's the issue?
[14:29] <seb128> jcastro, did I wake you up? ;-) did IRC ping make your phone ring too? ;-)
[14:29] <njpatel> seb128, I haven't touched evo-indicator for quite some time
[14:29] <jcastro> seb128: no I have sane highlighting in irssi for that.
[14:29] <seb128> njpatel, you flood .xsession-errors with useless g_debug calls
[14:30] <seb128> njpatel, I was looking at making .xsession-errors a bit cleaner so we can see actuals errors
[14:30] <njpatel> seb128, I see, is there a bug for it?
[14:30] <seb128> njpatel, not yet, do you want me to just drop all the g_debug in the ubuntu source as a distro change?
[14:31] <seb128> njpatel, or do you want to look at it and maybe set a g_log handler?
[14:31] <seb128> njpatel, the ping was actual to check with you what is easier and how busy you are, I can look at that myself next week
[14:31] <njpatel> seb128, just drop g_debug, it shouldn't be there for releases
[14:31] <njpatel> seb128, I'll make a note to merge the patch too when I get some downtime
[14:32] <njpatel> seb128, sorry, I thought it was broken for a second :)
[14:32] <seb128> njpatel, well could those be useful in some cases? I'm fine setting a g_log handler and write that to .cache or something
[14:33] <njpatel> seb128, truthfully, I can't remember what they are printing, but setting a log handler sounds fine
[14:33] <TeTeT> asac: do you happen to know where lockPrefs can be stored for Firefox 3.6? There is no more /etc/firefox-3.6/pref/firefox.js
[14:33] <seb128> njpatel, np, my ping was unclear sorry about that, lame attemp to be funny on friday but I'm too tired for that today :p
[14:33] <njpatel> seb128, heh :)
[14:33] <seb128> njpatel, ok, will do that and send you the patch, most likely next week though
[14:34] <njpatel> sounds good, thanks
[14:50] <vish> mvo: hi.. if you havent noticed this comment yet , > https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/536627/comments/18  the SC icons were renamed to be more generic to ensure they can be used in the main menu as well
[14:52] <asac> TeTeT: we have /etc/firefox/pref/firefox.js
[14:53] <asac> TeTeT: if lockPref doesnt work anymore we want a bug
[14:53] <asac> assign chrisccoulson_ to it
[14:53] <mvo> vish: yeah, I knew this was comming
[14:53] <TeTeT> asac: ok, I will give it a try
[15:01] <rickspencer3> chrisccoulson_, hi
[15:01] <TeTeT> asac: thanks
[15:01] <rickspencer3> chrisccoulson_, https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/526411
[15:24] <qense> aquarius: Apport adds log files to Ubuntu One bug reports that contain (request) tokens. Isn't that terribly unsafe?
[15:25] <aquarius> qense, yes. We mark bugs as private if that happens, or at least we try to
[15:26] <qense> They are automatically marked private already, iirc. However, members of Bug Control can view those bugs and we don't do a security check on applications.
[15:27] <seb128> well we should
[15:27] <seb128> the same people have access to crash stacktrace
[15:27] <seb128> which can have login, password, etc
[15:27] <qense> s/applications/applicants
[15:28] <qense> But anyone who wants to access that sensitive information just has to show some good work on a few bug reports and is in.
[15:29] <qense> And anyone who was already in can suddenly decide he or she can use the information of a certain log file for e.g. an act of revenge, or maybe to access the banking account of someone who's known to have a lot of money.
[15:32] <LaserJock> that's one reason I don't use apport, although I don't know that that's a good argument in general against it
[15:33] <LaserJock> it's hard to get good bugs if you don't have all the info to work with
[15:33] <qense> The information Apport provides is very valuable and it does make the life of the Bug Squad a lot easier, but it does have some security issues we should take into account.
[15:34] <LaserJock> they were taken into account when the permissions were set up
[15:34] <chrisccoulson_> seb128 - could you add a lucid task to bug 526411 please? :)
[15:36] <LaserJock> I believe ubuntu-bugcontrol was specifically created to address that security issue
[15:36] <qense> But gaining access to ubuntu-bugcontrol isn't that hard.
[15:36] <LaserJock> well, that's another issue :-)
[15:36] <qense> At least if you're willing to invest a little time in it.
[15:36] <LaserJock> how are you going to triage bugs you can't see, and if you can see them but not all the info you need ...
[15:37] <qense> That would indeed be problematic.
[15:37] <LaserJock> at some point you've got to trust that people are doing the right thing
[15:37] <LaserJock> we do that with ~ubuntu-dev
[15:38] <LaserJock> millions of users give them root access to their machines
[15:38] <LaserJock> and yet none of them have had a "security" check
[15:38] <LaserJock> they've contributed and are a part of the team, so we trust them
[15:39] <LaserJock> however, there is one difference in that in the case of ~ubuntu-dev there is an amount of code audit
[15:39] <LaserJock> whereas using somebody could use a login/password from a bug without anybody knowing it
[15:39] <qense> exactly
[15:40] <qense> Furthermore, I suspect that becoming a member of ubuntu-dev is harder than becoming a member of ubuntu-bug-control.
[15:40] <seb128> chrisccoulson_, done
[15:41] <chrisccoulson_> seb128 - thanks
[15:41] <LaserJock> qense: sure
[15:41] <thekorn> why do ubuntu one bugreports contain request token at all? shouldn't they be masked?
[15:41] <cassidy> seb128, I just released telepathy-gabble 0.8.12 fixing the crash we debugged yesterday and some other issues
[15:42] <thekorn> as any other potentially security risky data
[15:42] <qense> thekorn: Because the log file incluse the token.
[15:43] <seb128> cassidy, excellent, I will update
[15:43] <LaserJock> some apps are particularly bad about exposing user data in logs
[15:43] <LaserJock> perhaps there could be some review of apps/apport for such things
[15:44] <thekorn> qense: so it is either a bug in ubuntu one (masking them should happen there) or a bug in the package hook (masking before attaching this logfile)
[15:44] <qense> I'm not sure whether it's possible to reliably mask the value in the Apport hook, so I'll file a bug against Ubuntu One.
[15:45] <nigelb> qense: it is possible to mask in apport hooks
[15:45] <nigelb> I did do some masking for the rhythmbox hook.
[15:45] <nigelb> Only we need to find the actual info and get a regex to mask it
[15:45] <kklimonda> qense: it is - rhythmbox package hook masks passwords that are stored in plain text in gconf
[15:46] <qense> I know, but I'm not sure whether the key can be distinguished from regular words/names.
[15:46] <qense> bug #541968 contains such a log file if you want to see what I'm talking about
[15:47] <kklimonda> qense: you would have to subscribe me :)
[15:47] <thekorn> qense: and while you are on reporting this bug, filenames should also be masked in case of ubuntu one
[15:47] <thekorn> ;)
[15:47] <qense> thekorn: I'll mention that!
[15:47] <thekorn> thanks
[15:48] <nigelb> qense: I dont have access to that bug
[15:48] <qense> Ah
[15:48] <qense> I just remembered that Ubuntu One bugs get reported against the ubuntuone-client project, which isn't controlled by Bug Control.
[15:49] <nigelb> yep
[16:58] <pitti> ccheney`: when do you plan to do a new OO.o upload? there's a couple of RC bugs which are "fix committed now", amongst those the arm crash fix?
[17:15] <mvo> ccheney`: please include the binfilter too when you do the upload
[17:15] <mvo> the fix
[17:17]  * pitti waves, have to leave now
[17:17] <pitti> have a nice weekend everyone! great beta-1, let's get some rest
[17:17] <pitti> seb128: slangasek will flush the queue after meeting
[17:17] <pitti> he already requested thawing
[17:18] <didrocks> pitti: enjoy your week-end :)
[17:18] <seb128> pitti, have a nice weekend!
[17:20] <chrisccoulson> i didn't realise beta 1 was released now
[17:20] <chrisccoulson> i look forward to the flood of updates later ;)
[17:21] <seb128> yeah, me too
[17:21] <seb128> crossing finger to not have things breaking though
[17:21] <seb128> not the perfect timing to unfreeze
[17:32] <ccheney`> pitti: as soon as i get the clear to upload, only have one other bug to fix that i can think of at the moment, checked yesterday and they said it should be ok to do so late today
[17:32] <ccheney`> mvo: yea, should already have that in my merge from debian
[17:34]  * ccheney` bbia 30m
[17:36] <mvo> ccheney`: cool
[17:38] <seb128> ccheney`, you can upload
[17:39] <seb128> ccheney`, during freezes upload just get queued until after freeze and lucid is unfrozen now too
[17:46] <igoryonya> When i add repo dvds it only adds one entry, but when I did it on freshly installed system, it added several entries to the software sources. is it normal? does it mean that my dvds didn't get completley indexed, or is it because of some update?
[17:53] <huats> didrocks, did your remember for a sponsoring bug has already happened ? ;)
[17:54] <didrocks> huats: I'm not parsing your sentence, did you mean, did I sponsored your pessulus change already?
[17:55] <huats> I meant it exactly :D
[17:55] <huats> I was wondering if your calendar warned you that you had to sponsor something :)
[17:56] <didrocks> huats: right, I know still working on other things right now, but it's on my queue
[17:56] <huats> ok
[17:56] <huats> thanks
[17:56] <huats> (I was asking since I was about to work on another package)
[17:58] <chrisccoulson> didrocks - if you want to offload some sponsoring, then i could maybe do some for a bit ;)
[17:58] <chrisccoulson> (assuming i can upload those)
[17:59] <chrisccoulson> oh, i can't help you with pessulus anyway ;)
[18:06] <didrocks> chrisccoulson: wouldn't be take long, just order my priority, but thanks :)
[18:16]  * ccheney` back
[18:16] <ccheney`> seb128: ah i didn't know if it was a soft freeze or a real one
[18:17] <ccheney`> seb128: i'll upload the new OOo then as soon as I can manage to test the bug fix for themes
[18:52]  * ccheney` bets he knows what is wrong with his theme patch for OOo, it tries to do the smart fallback stuff which is now already done inside OOo
[19:03] <fta> what's the target version for gtk in lucid final?
[19:04] <desrt_> 2.20
[19:04] <desrt_> probably 2.20.1ish
[19:04] <fta> thanks
[19:04] <desrt_> we hope to have 2.20 out upstream to go with the gnome release on march 29
[19:05] <desrt_> so probably a few days before that
[19:20] <didrocks> urgh, power breakage, and consequently, my server got down :(
[19:25] <didrocks> well, time for dinner and then enjoying the week-end
[19:25]  * didrocks waves goodbye
[19:28] <seb128> didrocks, thank, you too!
[19:28] <didrocks> seb128: thanks :-)
[19:29] <seb128> that said time for weekend there too
[19:29] <chrisccoulson> have a good weekend seb128 / didrocs
[19:29] <chrisccoulson> **didrocks
[19:29] <seb128> chrisccoulson, thanks, you too ;-)
[19:35] <ccheney`> hmm after looking at this patch i'm not sure how it worked before unless they really redid a lot in 3.2, there are areas that need to be patched that aren't perhaps that is part of the problem with 3.2
[19:35] <ccheney`> in any case it shouldn't be too hard to make it work
[20:02] <asac> pitti: can you reset our burndown for beta-2?