[06:54] <mac_v> Amaranth: hi... why is the login/logout compiz plugin not enabled by default?
[06:54] <Amaranth> mac_v: hmm
[06:55] <Amaranth> mac_v: well, it was meant for KDE to replace kwin's logout effect
[06:55] <mac_v> it works well in gnome too
[06:55] <mac_v> since we now dont have that effect at all
[06:56] <mac_v> Amaranth: >  is this right >   (class=X-session-manager & type=Dialog) | (class=Gtk-logout-helper & type=Dialog)
[06:56] <mac_v> that works for me
[06:56] <mac_v> I'm thinking of confirming this Bug 429132 ...
[06:57] <Amaranth> eep
[06:57] <Amaranth> it made everything gray
[06:57] <Amaranth> and it didn't go back when I canceled the shutdown
[06:57] <mac_v> hmm... works fine here , no probs
[06:57] <Amaranth> oh, I had a broken rule
[06:58] <Amaranth> it was doing it whenever a gnome-session window was around
[06:58] <Amaranth> which is...always
[06:58] <mac_v> ;p
[06:58] <Amaranth> mac_v: that rule doesn't seem to match anything
[06:59] <mac_v> hrm...
[06:59]  * mac_v wonders why it works here
[06:59] <Amaranth> mac_v: karmic?
[06:59] <mac_v> yup
[06:59] <Amaranth> mac_v: GNOME?
[06:59] <mac_v> yup
[07:00] <Amaranth> weird
[07:00] <mac_v> ok, ,just this alone works too> (class=Gtk-logout-helper & type=Dialog)
[07:01] <Amaranth> nope, class for the logout and shutdown windows are Gnome-session
[07:02] <mac_v> Amaranth: hrm , i grabbed the class from compiz
[07:02] <Amaranth> so did I
[07:02] <Amaranth> from ccsm
[07:02] <mac_v> yeah, me too , weird
[07:03] <Amaranth> did you switch to upstream dialogs?
[07:03] <mac_v> i dont understand ^
[07:03] <Amaranth> hmm, that option is gone
[07:04] <Amaranth> we must be using upstream dialogs now
[07:04] <mac_v> indicator-applet-session 0.1
[07:04] <mac_v> oh , let me check for updates
[07:07] <mac_v> (class=X-session-manager & type=Dialog)
[07:07] <mac_v> this works too! , :(
[07:14] <mac_v> Amaranth: nope , i only have PA updates... ok , shall i confirm the bug and we can figure it out in  due course ?
[07:14] <Amaranth> I guess so
[07:14] <mac_v> ok.
[07:14] <Amaranth> if we get it working we'll want to modify the decoration plugin to not show decorations for those windows too
[07:14] <Amaranth> we also need to disable unredirect fullscreen windows
[07:16] <mac_v> Amaranth: hrm.... why no decorations for those windows? but sounds good  :)
[07:18] <mac_v> Amaranth: yup , looks sexy without decorations
[07:46] <pitti> Good morning
[07:51] <didrocks> hello pitti
[07:52] <MenZa> morning
[07:53] <didrocks> hey MenZa
[07:54]  * MenZa sips his coffee, checks his morning IRC.
[08:47] <mvo> robert_ancell: new compiz uploaded!
[08:47] <robert_ancell> mvo, yay!
[08:49] <pitti> crack!
[08:49]  * pitti hugs mvo
[08:49] <pitti> hey robert_ancell, good morning
[08:50] <robert_ancell> pitti, hey
[08:54] <mvo> pitti: haha - good crack!
[08:54] <mvo> loads of fixes :)
[08:54]  * mvo ticks off another item from his todo list
[08:56] <seb128> hello desktopers
[08:57] <didrocks> lut seb128
[08:57] <seb128> salut didrocks
[08:59] <pitti> hey seb128
[08:59] <seb128> hello pitti
[09:01] <chrisccoulson> hey seb128
[09:01] <seb128> hello chrisccoulson
[09:02] <chrisccoulson> did you have a good weekend?
[09:03] <seb128> yes, too short but very good otherwise
[09:03] <seb128> you?
[09:04] <chrisccoulson> yeah, same really ;) had some friends round yesterday but spent most of saturday trying to get karmic to work on my desktop
[09:05] <seb128> oh, did you manage to get it working?
[09:05] <seb128> what was the issue you had?
[09:06] <chrisccoulson> i made a silly error with my BIOS - it was trying to boot from the wrong disk. i only realised when i couldn't get jaunty to boot again too
[09:06] <pitti> hey chrisccoulson
[09:07] <chrisccoulson> i made some changes in the BIOS to turn off the onboard raid before i started the reinstall
[09:07] <chrisccoulson> hey pitti
[09:07] <seb128> 318 unread bug emails during the weekend
[09:07] <didrocks> seb128: good luck ;)
[09:07] <seb128> weekend email backlogs are not fun nowadays
[09:08] <seb128> didrocks, thanks ;-)
[09:08] <seb128> chrisccoulson, oh ok
[09:08] <didrocks> hey chrisccoulson
[09:08] <chrisccoulson> hey didrocks!"
[09:10] <chrisccoulson> seb128 - about bug 424511 - does gnome-session-bin need a Breaks on the earlier version of gnome-session (to force it to de-configure first)?
[09:10] <seb128> what was the issue? upgrade broken in the middle of unpacking?
[09:11] <chrisccoulson> seb128 - the issue is because the schema moves between packages. gnome-session-bin gets fully configured before gnome-session is deconfigured. when that happens, gnome-session unregisters the schema that gnome-session-bin just registered
[09:12] <seb128> that's a question for mvo I guess
[09:12] <chrisccoulson> yeah, possibly
[09:12] <chrisccoulson> i wasn't sure how else to fix it
[09:13] <chrisccoulson> because it is the old prerm script that unregisters the schema, it is difficult to stop that from happening
[09:14] <seb128> I'm not sure in which order maintainer scripts are ran
[09:14] <seb128> I need to open the documentation
[09:14] <seb128> but I'm trying to fight some thousand emails from the weekend right now
[09:14] <seb128> so it will be a bit later ;-)
[09:14] <seb128> using a conflicts or break seems to make sense
[09:15] <seb128> though apt tends to be stupid on breaks and that leads to removing things
[09:16] <chrisccoulson> seb128 - that's ok, i'll let you check your e-mails ;)
[09:16] <chrisccoulson> and get some coffee!
[09:16] <seb128> coffee!!
[09:16] <seb128> good idea ;-)
[09:17] <didrocks> coffee is always a good idea :-) (or tea as well for the minority here ;))
[09:18] <chrisccoulson> heh, yeah, i don't drink tea;)
[09:18] <didrocks> chrisccoulson: everytime you need to know in which order scripts are launch, just give a shot at http://women.debian.org/wiki/English/MaintainerScripts
[09:18] <mvo> tea!
[09:19] <didrocks> launched*
[09:19] <chrisccoulson> didrocks - yeah, i find that quite useful also
[09:19] <didrocks> mvo: the end of my sentence about tea was dedicated to you :-)
[09:19] <chrisccoulson> thanks:)
[09:19] <mvo> didrocks: I know ;)
[09:19] <mvo> didrocks: nice page - I always used the reference manual, but the diagrams are neat
[09:20] <chrisccoulson> pitti - bug 426501 is fixed upstream now. i'm not sure when upstream plan to do a tarball, but it might be worth cherrypicking the patch if it's going to be a while
[09:29] <pitti> chrisccoulson: nice! thanks for following this
[09:29] <pitti> chrisccoulson: are there many dupes?
[09:29] <pitti> but no prob to cherrypick it, they don't do releases often
[09:30] <chrisccoulson> pitti - i'm not sure if there are many dupes. some bugs might get reported against Xorg, as the symptoms are fairly similar, and I'm not subscribed to the g-p-m bugs
[09:30] <pitti> chrisccoulson: looks like http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=a09005a0a3a61537e8f34a0db2fec990a5333bd4
[09:31] <pitti> chrisccoulson: seems there are other worthwhile fixes there, I might just do a git snapshot
[09:32] <chrisccoulson> pitti - yeah, that probably makes sense
[09:33] <chrisccoulson> pitti - it looks like it is http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=8cb468ce64b0e1b21198744977d8a14e17ff5efe which fixes the crash
[09:33] <chrisccoulson> + /* finalise the object */
[09:33] <chrisccoulson> + g_object_unref (device);
[10:22] <asac> mvo: can we access the "Sources" or "Packages" files on a buildd? or is it not-defined?
[10:27] <mvo> asac: I think that is possible (but a bit hacky)
[10:28] <chrisccoulson> mvo - did you see the earlier conversation i had with seb128 about gnome-session upgrade issues? (sorry, I have no scrollback now)
[10:29] <mvo> chrisccoulson: yes, but I did not look closely - it looked complicated ;)
[10:30] <chrisccoulson> heh, yeah, it's a bit wierd
[10:30] <mvo> chrisccoulson: if its still relevant I can have a closer look when I'm finished with my current round of update-manager fixes
[10:33] <chrisccoulson> mvo - if you don't mind please:) i was going to propose adding a "Breaks: gnome-session (<< 2.27)" on gnome-session-bin, or something like that. We just need to make sure that the old (Jaunty) version of gnome-session is deconfigured (ie, its prerm script already ran) before the new gnome-session-bin is configured
[10:39] <asac> mvo: ok so rather not?
[10:42] <mvo> asac: well, depends on how important that is and what other options there are
[10:42] <seb128> ok, took me the morning to go through weekend emails
[10:42] <mvo> asac: something about automatically adding something, right?
[10:42] <mvo> asac: :)
[10:43] <mvo> asac: maybe it could be done a "dpkg-buildpackage -S" time?
[10:43] <mvo> asac: the buildds for for main will e.g. not have universe Packages lists available
[10:45] <asac> hmm ok
[10:45] <asac> feels like something we cannot rely on ;)
[10:47] <asac> mvo: yes. i am thinking about "-S" ... feels ugly too
[10:47] <hyperair> hmm for some reason i can't get ubuntuone to load the webpage for adding my computer
[10:47] <hyperair> why is that, i wonder?
[10:47] <mvo> asac: well, some packages (like ubiquity, update-manager) use something like that, they create a private apt sources.list and get data
[10:48] <mvo> asac: what was the problem again that this solves?
[10:48] <asac> mvo: are those used in debian too?
[10:48] <mvo> asac: (sorry, I think you told me, but I forgot)
[10:48] <mvo> asac: I see no reason why it could not work for debian as well :)
[10:48] <asac> its basically because we have firefox etc. and debian has iceweasel etc.
[10:49] <asac> ok. seems we would neeed to check if the developer has main/contrib/non-free in debian and in ubuntu all four components
[10:49] <asac> i think that might be doable
[10:49] <asac> not sure how to best check that though
[10:50] <mvo> asac: we can have a quick phonecall after lunch and I might be able to help?
[10:50] <asac> why not ... ;)
[10:51]  * soren is fascinated by this discussion..
[10:51] <soren> asac: What are you trying to do?
[10:51] <mvo> magic! its asac ;)
[10:51] <soren> asac: I've tried looking at scrollback, but I can't find it.
[10:51] <asac> soren: we have supermagic ${xpi:depends} in mozilla-devscripts
[10:51] <soren> asac: Ok.
[10:51] <mvo> (oh, even supermagic!)
[10:51] <asac> and want to assemble the right depends ...
[10:51] <asac> currently we maintain a list in the sources ... but thats suboptimal and would prefer to assemble that on the fly
[10:52] <soren> I see.
[10:53] <soren> Are they the same for all extensions, but still dynamic somehow, or are they completely different for all extensions?
[10:54] <asac> soren: extensions ship a install.rdf that refers to the applications (with min/max version) they work on.
[10:54] <asac> so completely different (in theory)
[10:54] <asac> most will have firefox of course
[10:54] <soren> Right.
[10:54] <soren> Oh, so it's based on that?
[10:55] <asac> yes.
[10:55] <soren> And that info is in Packages?
[10:55] <asac> not yet.
[10:55] <asac> but could be added
[10:55] <soren> Ah.
[10:55] <soren> That would make sense.
[10:55] <asac> for now we maintain a superset of applications
[10:56] <asac> but would like to add two meta fields: ApplicationId, ApplicationVersion:
[10:56] <asac> in that way we could make this 100% accurate
[10:56] <asac> the other option would be to require developers to install _all_ dependencies during build
[10:56] <asac> but thats bad
[10:56] <asac> ;)
[10:56] <asac> and not needed i hope
[10:59]  * soren ponders
[11:03] <asac> so anyone found where the "retry" button is hiding in new edge launchpad?
[11:03] <asac> oh
[11:03] <asac> its that tiny recycle icon
[11:05] <asac> seb128: can you NEW those https://edge.launchpad.net/ubuntu/+source/network-manager/0.8~a~git.20090911t130220.4c77fa0-0ubuntu1 ?
[11:06] <asac> thx
[11:22] <seb128> asac, newed
[11:22] <pitti> asac: oh, new N-M? another polkit-1 migration thing done then \o/
[11:23] <seb128> mvo, newed compiz too
[11:24] <pitti> asac: curious, the applet still needs to b-dep on libpolkit?
[11:24] <asac> seb128: rock.
[11:24] <asac> pitti: i will check that. might be an oversight or will land soonish i would hope
[11:25] <pitti> asac: usually you shouldn't need to have any polkit code client-side any more
[11:25] <asac> in configure.ac it now uses polkit-gobject-1
[11:25] <asac> so at least the packaging can be adjusted
[11:26] <asac> pitti: i thikn  its a bit different because the applet provides a user settings service on its own
[11:26] <asac> but i will check with dan
[11:31] <soren> asac: From what I can tell, debian-installer build-depends on apt, and grabs Package lists from the same place as the buildd and uses the information from there to do its magic. If debian-installer uses it, I'd say it's likely to not stop working anytime soon. You can look at debian-installer/build/util/get-packages to see how it calls apt-get (look for APT_GET).
[11:32] <pitti> asac: the applet runs as user, though?
[11:32] <pitti> asac: anyway, it's not a blocker, I just wondered
[11:32] <asac> pitti: just saw that we properly depend on polkit-1 ... at least. i will check if that can be dropped
[11:32] <asac> but i think we want the user settings to be controllable by certain other users
[11:32] <pitti> ah
[12:06] <mvo> seb128: cool, many thanks
[12:06] <seb128> mvo, np, I'm eager to try the update ;-)
[12:09] <mvo> seb128: it rocks :)
[12:10] <mvo> seb128: and puts the policykit dialogs on top
[12:10] <mvo> seb128: and needs new libcompizconfig and new plugins that are not build yet and apparently have a low build-score :(
[12:10] <mvo> would it be possible to get a private ppa so that I can ask for ppa->archive copies?
[12:10] <seb128> you can maybe bribe pitti to bump build score ;-)
[12:11]  * mvo offers green tea to pitti as a bribe
[12:13] <pitti> mvo: which source packages?
[12:13] <pitti> mvo: libcompizconfig is in depwait
[12:15] <seb128> it's waiting for compiz publishing apparently
[12:15] <mvo> yeah, same for the plugins- packages, waiting for compiz-core-dev
[12:16] <seb128> the changelog is impressive
[12:16] <seb128> lot of issues and crashes fixed ;-)
[12:16] <mvo> yeah, the compiz upstream guys are just great
[12:16] <mvo> lots of valgrind and gcc -Wall
[12:17] <seb128> ;-)
[12:17] <mvo> and sparse I think
[12:23] <mvo> tseliot: do you have a idea how much space dkms (roughly) needs?
[12:23] <mvo> tseliot: for building I mean in /tmp ?
[12:24] <tseliot> mvo: for building a module?
[12:25] <mvo> tseliot: yes
[12:25] <seb128> wb chrisccoulson
[12:25] <mvo> tseliot: a rough estimate is good enough, I want to add code a update-manager to ensure there is enough space in /tmp for building and that it does not fail because of this
[12:26] <tseliot> mvo: I don't know but wouldn't it depend on the module?
[12:26] <seb128> mvo, did you read the gnome-session question earlier?
[12:26] <seb128> chrisccoulson, did you work on making totem use libgdata?
[12:26]  * tseliot -> lunch
[12:26] <mvo> hey chrisccoulson - I had a quick look at your question and I think break is ok
[12:26] <mvo> chrisccoulson: what does the prerm do btw?
[12:26] <mvo> tseliot: I guess it would, I just need a number :) I can then use it as a lower bound
[12:27] <tseliot> mvo: ok, I'll give you a number when I'm back
[12:27] <mvo> thanks tseliot
[12:27] <seb128> mvo, it's standard dh_gconf calls
[12:28] <seb128> mvo, old schemas unregistered and new one registered
[12:28] <seb128> to make sure you don't have deprecated keys in the config and get the new ones too
[12:28]  * mvo nods
[12:28] <chrisccoulson> hi seb128 - no, i didn't work on that, as the MIR has not been approved yet. should i wait for that though?
[12:29] <seb128> chrisccoulson, no need to wait on the mir, that's a chicken egg issue ;-)
[12:29] <chrisccoulson> mvo - thanks for looking at that issue. the prerm script contains a hook generated by dh_gconf to unregister the schema
[12:29] <seb128> chrisccoulson, the eariler we ger the change the better if we want it for alpha
[12:29] <chrisccoulson> and the schema is registered in the postinst script. so there appears to be a race if you move the schema between packages
[12:30] <chrisccoulson> seb128 - ok, i'll work on that later then:)
[12:30] <seb128> pitti, sorry about the apport bug, I got confused I think yes, the thing is "get a crash, click to report it, get the error about whatever being deprecated you don't care about"
[12:30] <pitti> seb128: right, it it's definitively an issue
[12:30] <seb128> chrisccoulson, ok thanks
[12:30] <pitti> seb128: but Kmos' patch is wrong
[12:31] <chrisccoulson> mvo, i just saw seb128 already answered your question ;)
[12:31]  * chrisccoulson should look at scrollback more often
[12:31] <seb128> pitti, right, that was a reply to " or don't collect information from the Apport notification which opens automatically "
[12:31] <pitti> seb128: I figured; thanks for confirming
[12:31] <seb128> pitti, I do click on it because I want to report the bug and I don't know that have pulseaudio not uptodate will prevent me reporting a bug on nautilus for example
[12:32] <pitti> seb128: I think you should just add it to your ~/.bashrc or so
[12:32] <pitti> sorry, ~/.profile
[12:32] <pitti> the one that's read by GNOME
[12:32] <seb128> pitti, well I do want to be told about outdated versions
[12:32] <seb128> so I can decided according to what is outdated
[12:33] <pitti> seb128: if that's really hurting you, I can spend some 20 minutes to fix it properly
[12:33] <seb128> ie if the software is outdated no point to report the bug, if that's some stupid lib ...
[12:33] <seb128> pitti, no that's ok, I understand the issue now, thanks ;-)
[12:34] <seb128> pitti, can I gedit the .crash by hand to drop the UnreportableReason?
[12:34] <pitti> seb128: yes
[12:34] <seb128> ok, that's good enough for me
[12:34] <seb128> thanks:
[12:34] <seb128> !
[12:34]  * seb128 hugs pitti
[12:34]  * pitti hugs seb128
[12:41] <pitti> seb128: FYI, current retracer crash is again a "AssertionError: Could not find package for ExecutablePath"
[12:42] <pitti> it's looking for /usr/lib/firefox-3.5.2/firefox which doesn't exist any more
[12:42] <pitti> I'll just fix it to close them as obsolete
[12:42] <seb128> pitti, ok thanks
[12:43] <chrisccoulson> pitti - do you remember that i spoke to you just before feature-freeze about getting libgda4 in to main, but then i put it off because the package that requires it (glom) was not going to be ready for FF?
[12:43] <chrisccoulson> the currentl version of glom in karmic is completely busted now though...
[12:43] <pitti> chrisccoulson: I remember
[12:44] <chrisccoulson> it's not installable due to missing dependencies, and I can't rebuild it because it requires pygda3, which no longer exists in the archive either
[12:44] <pitti> eww
[12:44] <chrisccoulson> (that used to come from gnome-python2-extras)
[12:44] <chrisccoulson> so, i'm not sure what to do ;)
[12:44] <pitti> I assume it neither builds with the new 4 API, nor is there a newer upstream version which does?
[12:45] <chrisccoulson> pitti - it won't build with pygda4 either, as the API has changed a fair bit
[12:45] <chrisccoulson> the newer upstream version will do though
[12:45] <pitti> oh, brilliant
[12:45] <chrisccoulson> is that enough justification for a FFe? ;)
[12:46] <pitti> absolutely
[12:46] <pitti> it can hardly get any worse, after all
[12:46] <pitti> so updating it is a no-brainer
[12:46] <pitti> (I mean -release wise)
[12:47] <chrisccoulson> yeah, that's what i thought. we still need to get libgda4 in main though, so that we can build pygda4
[12:47] <chrisccoulson> but i can work on a MIR for that
[13:00]  * asac lunch
[13:09] <seb128> mvo, libcompizconfig built now
[13:10] <seb128> mvo, the new version sort of fix the focus issue with seahorse gpg agent dialogs
[13:10] <seb128> they get on the first plan now which is good
[13:11] <seb128> but they still look unfocussed, ie decorations not colored
[13:13] <mvo> seb128: hm, it seems that it gets it right for software-store - is that the same polkit1 dialog?
[13:14] <seb128> mvo, no, I'm speaking about the gpg agent dialog
[13:14] <seb128> mvo, design *.changes, esc, debsign *.changes
[13:14] <mvo> seb128: btw, do you happen to know if there is a way to avoid the blocking when the polkit1 dialog comes up? in the past I brought up the dialog, so I had a (addtional) gtk main loop running, but now its the doing of polkit
[13:14] <mvo> seb128: oh, ok. I have a look
[13:17] <seb128> mvo, no idea, maybe james_w` or pitti know
[13:18] <james_w`> no idea, sorry
[13:18] <james_w`> you could mail polkit-devel
[13:30] <seb128> mvo, when starting a guest session I always get gnome-panel opacity not correct with the new compiz, did you notice that too?
[13:30] <seb128> ie the top bar is transparent and only displayed when clicking on it
[13:48] <mvo> seb128: I need to test this on my other machine, with nvidia the guest session does not work for me with compiz :(
[13:50] <seb128> mvo, could be the same with a normal session start but I didn't want to close mine ;-)
[14:07] <asac> seb128: what app would be a good candidate to test gio modules?
[14:07] <asac>  /usr/lib/gio/modules/libgvfsdbus.so
[14:07] <asac>  /usr/lib/gio/modules/libgioremote-volume-monitor.so
[14:07] <asac>  /usr/lib/gio/modules/libgiogconf.so
[14:08] <seb128> the gtk fileselector in gedit for example?
[14:08] <seb128> try browsing a ssh or smb share from there
[14:08] <asac> what does the giogconf thing do?
[14:08] <asac> thx
[14:08] <seb128> it allows gio to use gconf
[14:08] <seb128> gio is under gconf in the stack
[14:08] <asac> seb128: how can i trigger that code path?
[14:09] <seb128> so it can't use libgconf, they have to trick
[14:09] <asac> ah
[14:09] <seb128> same for gvfs
[14:09] <asac> would gedit file selector trigger it?
[14:09] <seb128> yes
[14:09] <seb128> browse a share with nautilus
[14:09] <asac> ok ... why are all those modules separate?
[14:09] <seb128> ssh, smb, ftp, anything non local
[14:09] <seb128> and open the gedit fileselector
[14:09] <asac> e.g. can one use gvfsdbus without giogconf?
[14:09] <seb128> and see if you can browse those
[14:09] <asac> felt like thats not possible
[14:10] <asac> thanks. i think thats enough for our purpose
[14:10] <seb128> you can probably use giogconf to access gconf settings from gio
[14:10] <seb128> but I doubt we have anything doing that
[14:10] <seb128> the real "customer" for those is to make gio be able to use gvfs backends
[14:10] <kenvandine> seb128, i saw some chatter about compiz earlier, is there a known issue with it not starting?
[14:10] <seb128> kenvandine, no but you might have caught a partial upgrade
[14:11] <kenvandine> ok
[14:11] <seb128> kenvandine, ie upgraded the core while the plugins were not update
[14:11] <seb128> what error do you get?
[14:11] <kenvandine> Couldn't find a perfect decorator match; trying all decorators
[14:11] <kenvandine> Found no decorator to start
[14:11] <seb128> mvo is well known to screw those every time ;-)
[14:11] <seb128> hum
[14:11] <seb128> did you get any package remove?
[14:11] <kenvandine> yes
[14:11] <seb128> ie did you validate a dist-upgrade without reading or something?
[14:12] <kenvandine> it removed some plugins and the compiz package
[14:12] <seb128> hum
[14:12] <kenvandine> but upgrade compiz-core
[14:12] <seb128> the goal is to make you wait
[14:12] <seb128> not to make you remove
[14:12] <pitti> mvo: sorry, closed IRC over lunch; what was your PK question?
[14:12] <seb128> it's basically your fault
[14:12] <kenvandine> :)
[14:12] <seb128> ie don't confirm package removal
[14:13] <seb128> what it said is "you are in the middle of a transition, do you want to wait or screw your system to get new crack"
[14:13] <seb128> and you went for the new crack ;-)
[14:13] <kenvandine> hehe... ok
[14:13] <seb128> wait for the next publisher run now and reinstall those
[14:13]  * kenvandine thought it would have held those back
[14:13] <seb128> upgrade would so
[14:14] <seb128> upgrade would do
[14:14] <seb128> dist-upgrade go the other way and remove to get you new cracks if you really want
[14:14] <kenvandine> certainly not important... just glad there isn't  a bug :)
[14:14] <seb128> you should be using upgrade rather than dist-upgrade
[14:14] <kenvandine> hummm.. someone told me it would be better to test dist-upgrade regularly
[14:14] <kenvandine> hey rickspencer3*
[14:14] <kenvandine> :)
[14:15] <seb128> hey rickspencer3
[14:15] <seb128> kenvandine, well read what dist-upgrade do in any case, conflicts often lead to removal during transitions
[14:15] <seb128> ie it's fine to remove old lib sonames
[14:15] <seb128> but you usually don't want to remove your decorator
[14:15] <kenvandine> i read it, just tested that upgrade path
[14:16] <kenvandine> i have the decorator... not sure why it isn't finding it
[14:16] <seb128> ok
[14:16] <seb128> what did get uninstalled exactly?
[14:16] <kenvandine> rickspencer3: fyi... you shouldn't dist-upgrade this morning :)
[14:17] <kenvandine> compizconfig-backend-gconf might be the culprit
[14:17] <kenvandine> that was removed
[14:17] <seb128> ups, wrong focus
[14:17] <kenvandine> it removed compiz and compizconfig-backend-gconf
[14:18] <seb128> try reinstalling those?
[14:18] <kenvandine> the decorator is in compiz-core, so i suspect compizconfig-backend-gconf
[14:18] <kenvandine> yeah
[14:18] <kenvandine> doing that now
[14:19] <kenvandine> dep errors
[14:19]  * kenvandine just waits
[14:19] <kenvandine> i know rickspencer3 does dist-upgrades every morning.. so i want to stop him :)
[14:20] <seb128> let's see if he does read what dist-upgrade do before acking ;-)
[14:20] <kenvandine> hehe
[14:20] <seb128> I usually use update-manager which does the right thing
[14:20] <kenvandine> i was suspicious of the upgrade... but knew it wouldn't completely hose me :)
[14:20] <pitti> hey kenvandine
[14:20] <Laney> aptitude did the right thing on compiz for me, FWIW
[14:21] <kenvandine>     compiz | 1:0.8.3+git20090914-0ubuntu1 |        karmic | source
[14:21]  * kenvandine waits for binaries
[14:21] <Laney> "Keep the following packages at their current version:
[14:21] <Laney> compiz [1:0.8.2-0ubuntu16 (now)]
[14:21] <Laney> and so on
[14:22]  * rickspencer3_ reads up
[14:22] <seb128> rickspencer3: summary; don't ack compiz removal if you dist-upgrade
[14:23] <rickspencer3_> kenvandine, are you getting an issue where you window frames kind of dissapear?
[14:23] <kenvandine> no
[14:23] <rickspencer3> oops, my other computer is on
[14:23] <mvo> (did that happen in the middle of publish run? - on my test machine compiz wants to upgrade complettly)?
[14:24] <seb128> the goal is to make people wait to get all the binaries but dist-upgrade junkies might have issues ;-)
[14:24] <kenvandine> rmadison says it isn't published yet
[14:24] <seb128> compiz is published for 2 hours
[14:24] <kenvandine> humm
[14:24] <seb128> but other things were waiting for it to build
[14:24] <seb128> ie libcompizsettings
[14:25] <seb128> libcompizconfig
[14:25] <seb128> so those might still be pending publishing now
[14:48] <seb128> mvo, should bug #414170 be closed too?
[14:49]  * popey wonders if anyone is aware of bug 412125, and that it makes flash unusable (comments about flash being unusable by default to /dev/null) on karmic..
[14:51] <mvo> seb128: yes, I merged that one
[14:51] <mvo> seb128: thanks :)
[14:51] <popey> it may well not be an nspluginwrapper issue, but given it only seems to affect 64-bit ubuntu..
[14:51] <seb128> mvo, np ;-)
[14:52] <seb128> popey, no clue about that, maybe try #ubuntu-mozilla rather?
[14:52] <popey> ok
[14:52] <popey> that channel is empty
[14:52] <seb128> I've no clue about that and I use only i386 installs
[14:53] <seb128> asac, what is the channel for ubuntu mozilla?
[14:53] <james_w> #ubuntu-mozillateam
[14:53] <asac> yep
[14:53] <popey> thanks!
[15:02] <mvo> so seriously, what would it take to get ppa->archive copy for compiz so that we can ensure the thing goes in in one go?
[15:03] <seb128> mvo, wrong channel, would rather be a soyuz question I guess
[16:16] <pitti> kenvandine: bug 412601 is marked fixed upstream, but open in karmic; is there a new release we can package which drops the old policykit bits and incorporates lool's fixes?
[16:17]  * kenvandine will look
[16:18] <pitti> kenvandine: btw, I uploaded all the farsight/upnp stuff on Saturday, should be all set now
[16:18] <kenvandine> yeah thx!
[16:18] <Keybuk> after today's updates, all my window manager keybindings have been lost
[16:18] <kenvandine> rickspencer3 and i did our weekly 1:1 with it today :)
[16:20] <pitti> kenvandine: rock
[16:21] <james_w> Keybuk: compiz?
[16:22] <Keybuk> james_w: yes
[16:22] <james_w> Keybuk: did you upgrade compiz and remove a compiz related package?
[16:22] <james_w> -gconf or something?
[16:23] <Keybuk> james_w: I did a dist-upgrade
[16:23] <james_w> yeah, it probably forced the removal of some plugin packages due to skew
[16:23] <Keybuk> james_w: compizconfig-backend-gconf is installed
[16:23] <Keybuk> though it's a different version
[16:23] <Keybuk> 0.8.2 vs. 1:0.8.3+git...
[16:24] <james_w> maybe it's just broken
[16:27] <lool> Keybuk: For the other packages there are ABI depends to prevent this from happening; compiz-core-abiversion-2009xxxx
[16:27] <lool> But I was told by upstream that this wasn't needed for these
[16:28] <Keybuk> I don't have any -abiversion- packages installed
[16:28] <lool> Keybuk: it's a virtual provide
[16:28] <Keybuk> lool: ah ok
[16:28] <lool> apt-cache show compiz-fusion-plugins-extra |grep compiz-core-abiversion
[16:28] <Keybuk> two such packages show up in "dpkg -l" as uninstalled
[16:28] <lool> But this system is not used for the compizconfig backend; perhaps it should; upstream told me not in the past
[16:28] <lool> mvo: ^  do you know?
[16:30] <mvo> Keybuk, lool: do you have the "compiz" metapkg still installed?
[16:30]  * asac out for 2-3h
[16:30] <mvo> or did apt helpfully remove that for you?
[16:30] <Keybuk> mvo: no
[16:30] <Keybuk> mvo: apparently
[16:30] <Keybuk>   compiz: Depends: compiz-fusion-plugins-extra (>= 0.8.3) but it is not going to be installed
[16:31] <mvo> its currently building
[16:31] <mvo> sorry, for the trouble
[16:34] <cassidy> seb128, kenvandine: would be good to ship farsight2 0.0.15, that's a bug fix release
[16:34] <seb128> cassidy, what about telepathy-gabble 0.8.3?
[16:34] <cassidy> yep, that one too
[16:35] <seb128> ok
[16:35] <cassidy> I opened https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/429378
[16:35] <cassidy> but didn't for fs2 as there is an ubuntu delta
[16:35] <seb128> ok thanks
[16:35] <cassidy> not sure if we should drop it or not
[16:35] <cassidy> bigon, ^
[16:35] <seb128> we can't
[16:36] <seb128> debian doesn't have farsight in gst-good I think
[16:36] <cassidy> oh right
[16:37] <cassidy> papyon would be good to but has been refused : https://bugs.launchpad.net/bugs/428779
[16:37] <rugby471> hello
[16:44] <seb128> cassidy, seems this one has not been refused but pitti has valid concern on code copy
[16:44] <rugby471> mvo: hi
[16:44] <seb128> cassidy, do you know why upstream moved to use a private copy rather than the system version?
[16:44] <seb128> hey rugby471
[16:45] <pitti> seb128: the code copy can be easily reverted, as it seems, so when that's done (as a package patch or upstream), it looks fine indeed
[16:45] <cassidy> seb128, not sure; I'll ask. I guess that's because it's not pkged
[16:46] <seb128> cassidy, the usual way is to have both, use the system version if available otherwise use the copy as fallback
[16:46] <mvo> hey rugby471!
[16:46] <mvo> rugby471: I saw your branch, many thanks! what did change in the status icons?
[16:46] <cassidy> seb128, I'll ask him
[16:46] <rugby471> mvo: you mean the progres icons?
[16:46] <mvo> rugby471: yeah
[16:47] <cassidy> seb128, we just release tp-butterfly with audio/video support btw :)
[16:47] <rugby471> mvo: just changed them to be 24x24
[16:47] <mvo> rugby471: aha, cool
[16:47] <seb128> cassidy, how well is that working?
[16:47] <rugby471> and the names of them to be softwarestore-progress-n.png
[16:47] <mvo> rugby471: I have not merged yet, but I will today (I think)
[16:47] <rugby471> mvo: rather than software-store ...
[16:47] <rugby471> mvo: kl
[16:47] <cassidy> seb128, surprisingly well when I tested it
[16:47] <rugby471> mvo: I would also have a look at the other branches (like stuart landridges)
[16:47] <cassidy> not sure if it should be shipped in Karmic though
[16:48] <rugby471> mvo: he has a useful feature that is implemented in my branch, but not as well :-)
[16:48] <cassidy> oth, I expect most people will use pkg from the PPA if it's not
[16:48] <seb128> I expect most user don't know what a ppa is
[16:49] <seb128> your userbase vision seems to be a technical users corner ;-)
[16:50] <cassidy> good point. I still think that most Empathy users are people with some technical experience but that's not true any more
[16:50] <seb128> at least it will not be in karmic if it's default
[16:50] <cassidy> you are using haze for MSN ?
[16:51] <pitti> cassidy: not any more
[16:51] <pitti> we recently switched to install butterfly by default
[16:51] <cassidy> cool
[16:52] <mac_v> rugby471: mvo: In software store... when an install is in progress  , i switch to that section , now once the install has completed the window just becomes empty :( , the "In progress" section disappears and nothing is shown in the right display window.... wouldnt it be better if the view automatically switched to the last completed install/remove?
[16:52] <Zdra> Karmic should definitely ship with MSN a/v !
[16:52] <mvo> mac_v: yeah it would - I think there is even a open bug about that
[16:53] <mac_v> oh.. ok.. good to know :)
[16:53] <rugby471> mac_v: that is a question to ask mpt who is not here right now :-)
[16:53] <cassidy> Zdra, you didn't even test it yet :p
[16:53] <mac_v> rugby471: yeah lucky him ;p
[16:53] <mvo> rugby471: yeah, I saw it, today I was pretty occupied with other stuff
[16:53] <mvo> rugby471: but its on my merge agenda :)
[16:53] <Zdra> cassidy: ... and I won't use it... but that's a really good sell argument
[16:53] <rugby471> mvo: hehe
[16:53] <rugby471> mvo: would it help if I summarise what I did in my branch , here?
[16:54] <seb128> Zdra, if it's working
[16:54] <mvo> rugby471: if you would write debian/changelog entires, that would help me
[16:54] <rugby471> sure
[16:54] <mvo> many thanks!
[16:54] <seb128> Zdra, upstream tends to be enthousiastic about new features without always noticing the stability issues
[16:56] <cassidy> yeah
[16:57] <Zdra> bah, stable software is not something important, all that we care is the buzz of announcement
[16:57] <Zdra> see google's business plan
[16:57] <Zdra> add a little "beta" next to ubuntu and that's it
[16:57] <mac_v> rugby471: mpt has already answered ; > Bug #426278
[16:58] <Zdra> seb128: more seriously, we shipped a/v for jabber even if doesn't work that well... and no other client does msn a/v, so it can't be a regression
[17:00] <seb128> Zdra, the issue is not only that, it's also the stability of your im client
[17:00] <seb128> Zdra, and shipping broken things or things not working correctly usually give a bad image of the product, better to not enable a feature that giving the impression it's a working one if it will create frustration for most users for example
[17:01] <Zdra> seb128: seems you are the last sane people in IT :p
[17:02] <Zdra> usually it is "works for me, so ship it"
[17:02] <seb128> ;-)
[17:04] <pitti> mat_t: hey, welcome back!
[17:10] <seb128> pitti, hum so I've some gettext for desktop files wondering
[17:10] <seb128> pitti, I noticed that the message indicator applet launchers are not translated
[17:10] <seb128> seems to be due to the fact that we strip translations from the desktop file
[17:11] <rugby471> mvo: I have pushed the debian changelog
[17:11] <seb128> pitti, how are applications supposed to get translated desktop names nowadays?
[17:12] <kenvandine> pitti, about bug 412601
[17:12] <kenvandine> i think the upstream bug got marked as released because it was moved to main
[17:12] <kenvandine> the PK bug is 418643
[17:12] <mvo> rugby471: thanks, I have a look once I'm finished with some update-manager work
[17:12] <kenvandine> which i think is on deck to be completed this week
[17:13] <rugby471> mvo: cool
[17:17] <rugby471> mvo: oh by the way here is a very easy to fix bug :-) https://bugs.launchpad.net/ubuntu/+source/software-store/+bug/428324
[17:19] <mvo> rugby471: :)
[17:20] <mvo> rugby471: I check it out after lunch
[17:20] <mvo> eh
[17:20] <mvo> dinner
[17:27] <MenZa> !lasmen
[17:27] <MenZa> er.
[17:28] <MenZa> hmm.
[17:28] <MenZa> I was wondering why I'd been highlighted in here. Turns out I had 'help' on highlight.
[17:28]  * MenZa grumbles.
[17:29] <seb128> pitti, ok, it's bug #371399
[17:30] <seb128> pitti, I've added a karmic task, that's very visible for the message launchers
[17:32] <Amaranth> mvo: yay compiz upload :)
[17:32] <mat_t> hey pitti :)
[17:42] <chrisccoulson> it is very thoughtful of gdu-notification-daemon to tell me that my disk is failing, every time i log in
[17:44] <mac_v> chrisccoulson: just turn it off from start up list ;)
[17:44] <chrisccoulson> mac_v - yeah, i might do that. but it needs fixing properly really ;)
[17:45] <mac_v> yup , there is a bug about it already :)
[17:48] <mvo> Amaranth: yay, the changelog is impressive too :)
[17:48] <mvo> rugby471: meh, I don't think I manage the merge today, I do it tmorrow (sorry for that)
[17:48] <rugby471> mvo: no problem
[17:49] <rugby471> mvo: there is no rush :-)
[17:49] <pitti> seb128: hi (sorry, was at dinner)
[17:49] <pitti> seb128: they should have X-GNOME-Gettext-Domain: in the .desktop file and the translations in the .po/.mo files
[17:49] <seb128> pitti, cf my most recent messages
[17:49] <pitti> kenvandine: ah, and Loic's changes?
[17:49] <pitti> seb128: looking
[17:50] <pitti> seb128: right, thanks; will look into that
[17:50] <kenvandine> pitti, don't know about that
[17:50] <dpm> pitti: seb128, there's some information I collected here on .desktop files as well, you can also tell me if you spot any errors -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Desktop%20Entries
[17:51] <dpm> (re: seb128's question earlier)
[17:52] <pitti> dpm: nice, thanks! edited to use X-GNOME-... (the preferred name now)
[17:53] <dpm> ok, cool, thanks
[17:55] <dpm> pitti: out of interest, howcome has that changed to X-GNOME-...? Has the functionality been accepted at freedesktop.org upstream?
[17:56] <pitti> dpm: it's used in OpenSUSE as well now, and proposed upstream
[17:56] <pitti> dpm: X-Ubuntu- still works, of course, but we shouldn't perpetuate it
[17:56] <pitti> I hope that one day it just becomes Gettext-Domain:
[17:57] <dpm> right, ok
[17:58] <rugby471> sorry guys I know this is off-topic but could anyone tell me whether the SM_CLIENT_ID of a window needs ot be specific to the process (ie. main_window) or to the session manager (ie. softwarestore_main_window) ?
[17:58] <rugby471> ot > to
[18:00] <seb128> vuntz, hey, did you update your langpack patch for gdesktopapp apis too?
[18:01] <chrisccoulson> rugby471- i'm not sure i completely understand the question. the sm_client_id should be unique to the main window, and is allocated by the session manager
[18:01] <rugby471> chrisccoulson: hi chris
[18:01] <chrisccoulson> hi:)
[18:02] <rugby471> chrisccoulson: basically does the ID need to be main_window
[18:02] <rugby471> or softwarestore_main_window
[18:02] <rugby471> I am trying to solve bug 426294
[18:02] <chrisccoulson> i'm still a bit confused - what are you doing with it?
[18:03] <chrisccoulson> ah
[18:03] <rugby471> chrisccoulson: so I need to use .set_role() to fix this
[18:03] <rugby471> chrisccoulson: or am I wrong?
[18:04]  * rugby471 is clueless about session manager/application interaction
[18:04] <chrisccoulson> oh yeah. right, software-store needs to connect to the session manager (using something like eggsmclient or gnomeclient). the session manager will allocate the client ID, which you would then set as a property on the leader window with gdk_set_sm_client_id (in C)
[18:04] <chrisccoulson> but i don't know if you need to do the second step really
[18:05] <chrisccoulson> i don't see other applications do that, and they work fine
[18:05] <rugby471> chrisccoulson: ok, so I need to connect to the session manager first, and then (maybe) set the role
[18:05] <rugby471> chrisccoulson: know of the python module to connect to the session manager?
[18:06] <chrisccoulson> rugby471 - i'm not sure of how to do it in python. i will try to find an example
[18:06] <rugby471> chrisccoulson: thanks
[18:06] <chrisccoulson> my python knowledge isnt that great;)
[18:06] <rugby471> hehe
[18:07] <chrisccoulson> you can just use raw dbus calls if you're in gnome, but that wouldn't work with other session managers
[18:09] <rugby471> chrisccoulson: I shall ask mvo if you cannot find anything as he will be more intouch with it than I am :-)
[18:12] <rugby471> mvo: I am looking at bug 428417, should I just open this with eog?
[18:13] <rugby471> chrisccoulson: don't worry about it, I thought it was just a simple thign but it seems like it is something that needs some more thought. Thanks for your help :-)
[18:13] <chrisccoulson> rugby471 - that warning shouldn't be presented normally now btw, due to a recent metacity update. are you still seeing it?
[18:13] <vuntz> seb128: no. Did something change?
[18:13] <rugby471> chrisccoulson: no I am not
[18:13] <chrisccoulson> it should only appear at the moment if you try to log out and you've got session saving enabled
[18:13] <chrisccoulson> which is not the default
[18:13] <rugby471> on a fresh karmic it did not happen for me
[18:13] <seb128> vuntz, the original patches we have are for gnome-menus and g_key I think
[18:14] <chrisccoulson> but i disagree that a warning should be shown at all anyway - there are lots of clients that don't do session saving
[18:14] <seb128> vuntz, g_app_* was added after those and is not using gettext
[18:14] <rugby471> chrisccoulson: I agree and it looks like upstream as well, however they have got to get around to doing it first :-)
[18:14] <seb128> vuntz, I was just wondering if you worked on that before we dup efforts ;-)
[18:14] <rugby471> upstream > upstream do
[18:14] <vuntz> seb128: nope
[18:14] <vuntz> seb128: but I'll be happy to use your patch ;-)
[18:15] <vuntz> seb128: (else, I'll do it... hrm... in a few days)
[18:18] <seb128> vuntz, ok, let's see who is slower ;-)
[18:19] <vuntz> seb128: I would expect g_app* to use gkeyfile, though
[18:19] <seb128> vuntz, it doesn't work
[18:19] <seb128> vuntz, python -c "import gio; print gio.app_info_get_default_for_type('image/jpg', 0).get_name()"
[18:19] <seb128> try that for example
[18:19] <seb128> for some reason it doesn't use translations
[18:19] <seb128> I didn't look at the code yet
[18:30] <seb128> asac, there?
[18:34] <pitti> good night everyone, Taekwondo o'clock
[18:37] <seb128> pitti, have fun
[18:42] <chrisccoulson> i'm pleasantly surprised at the boot speed of my desktop with karmic
[18:47] <seb128> lucky you
[18:47] <seb128> I'm not impressed at the one on both my laptop and desktop configs
[18:48] <seb128> it takes some 35 seconds to go to gdm
[18:49] <chrisccoulson> 35 seconds is just slightly longer than my desktop took with jaunty
[18:49] <chrisccoulson> i get 22 seconds now
[18:50] <jcastro> seb128: you need an ssd
[18:50] <jcastro> :)
[18:51] <chrisccoulson> jcastro - my 22 seconds is just on a standard 7200rpm hard drive ;)
[18:51] <Amaranth> jcastro: still getting 8 second boots?
[18:51] <seb128> I've a ssd on my mini config
[18:51] <chrisccoulson> 8 seconds?
[18:51] <jcastro> Amaranth: no, down to 4
[18:51] <chrisccoulson> nice:)
[18:51] <chrisccoulson> i must invest in one!
[18:51] <Amaranth> I'm getting 30 seconds even with ubuntu-boot staging
[18:51] <Amaranth> jcastro: holy crap
[18:51] <seb128> jcastro, but I like to have medium configs so I know what the average user experience is
[18:51] <Amaranth> jcastro: that means login time is at least 4x boot time now
[18:51] <jcastro> dude you'd be surprised how many annoying things get fixed with a fast disk, heh
[18:51]  * Amaranth has a 5400rpm drive
[18:51] <seb128> jcastro, you can't require everybody to have a ssd to have a decent user experience
[18:51] <jcastro> seb128: I have an older laptop with a 4200rpm drive that I keep just to keep me honest
[18:52] <chrisccoulson> jcastro - i could save 18 seconds of my life every day by investing in a SSD;)
[18:52] <Amaranth> no but the 10 second boot/login is meant for SSDs
[18:52] <jcastro> well, it's a slow ssd
[18:52] <Amaranth> jcastro: thought you had the X25
[18:52] <jcastro> I do
[18:52] <jcastro> no, I meant the "10 second boot" machine has a slow ssd
[18:52] <Amaranth> oh, right
[18:53] <Amaranth> jcastro: So if a slow SSD and a slow CPU get a 10 second boot you should get a 5 second boot :P
[18:53] <jcastro> seb128: even on the slow laptop it's been improving for me
[18:53] <Amaranth> at that point suspend is kind of pointless unless you have something you want to keep open :P
[18:53] <jcastro> Amaranth: I was getting 5 counting couch launching xulrunner(!) so it should get faster
[18:54] <Amaranth> my boot time has more than doubled since a clean install of jaunty :/
[18:54] <Amaranth> and I even did a clean install of alpha 4 recently
[18:54] <seb128> jcastro,right, I'm a bit concerned about the "xorg will start so fast that we will not need a splash to not be true on normal non-ssd config"
[18:56] <jcastro> well, I always keep old machines around for testing
[18:58] <jcastro> seb128: one day we should all boot up with 256mb of ram or something and see how much pain we endure
[18:58] <seb128> there is no point to do
[18:58] <seb128> but using normal machines to do testing makes sense
[18:59] <seb128> ie your ssd doesn't reflect the average user configuration I think
[19:26] <ccheney> cool someone just fixed the OOo icon theme fallback code to not display not installed themes and to not fallback to ones that don't exist :)
[19:39] <NCommander> ccheney, please do not upload OOo
[19:40] <ccheney> everything except arm builds in time and arm is totally broken for OOo atm (going to fix a debug issue for arm with the next upload as well)
[19:40] <ccheney> or is the some other reason not to upload?
[19:40] <NCommander> ccheney, you upload OOo and you cause the buildds to spin out, and you break the arch all packages on armel
[19:40] <NCommander> livefs's will then fail to build
[19:40] <NCommander> and completely break images
[19:40] <NCommander> on armel
[19:41] <NCommander> We *need* an arm release for A6
[19:43] <asac> seb128: pong
[19:45] <ccheney> NCommander: oh ok, i thought OOo was currently not installed on arm at all since its broken, no problem, won't do the upload
[19:45] <NCommander> ccheney, thanks. The OOo-less arch code broke a few alphas ago, but its been a moot point since its building on ia64, and sparc's d-i is very broken ATM
[19:45]  * NCommander has to fix the later at some point
[19:52] <chrisccoulson> seb128 - it seems that gnome-session-bin is actually just missing a conflicts on gnome-session
[19:52] <chrisccoulson> i'm just testing the upgrade path now
[19:56] <ccheney> NCommander: oh cool, ia64 isn't dead anymore :)
[19:56] <NCommander> ccheney, my desktop is an ia64
[19:57] <NCommander> :-)
[20:01] <ccheney> NCommander: yea, ia64 buildd was out of space for a while though, heh
[20:01] <NCommander> ccheney, yeah, I had prodded lamont on that
[20:02] <ccheney> ok
[20:04] <Amaranth> NCommander: does compiz work on there?
[20:11] <seb128> asac, hey, libnm-glib breaks build but I didn't investigate
[20:11] <seb128> did the .pc changes name or something (in which case renaming the package would have be nice)
[20:13] <asac> seb128: hmm. what build did it break?
[20:13] <asac> we bumped soname in binary package, but not d-ev
[20:14] <NCommander> Amaranth, I'm stuck on the framebuffer, its got a ATI video card w/ no graphics
[20:15] <Amaranth> NCommander: oh, dang
[20:15] <NCommander> Amaranth, wanting to see if compiz works on obscure architectures? :-)
[20:17] <Amaranth> NCommander: yeah, I know it works on x86, x86-64, and powerpc but it'd be cool to know it works on space and ia64 too :P
[20:17] <Amaranth> dunno about arm
[20:18] <NCommander> Amaranth, I'll tell you on ARM once I have a SoC with 2D/3D accelaration ;-)
[20:18] <NCommander> Amaranth, I have SPARC hardware ... :-)
[20:18] <NCommander> Amaranth, give me a good recommendation on a PCI video card that has no binary blobs, and I'll look into it
[20:19] <Amaranth> NCommander: I guess anything ati older than Radeon HD cards
[20:20] <Amaranth> NCommander: perhaps http://www.newegg.com/Product/Product.aspx?Item=N82E16814161010
[20:20] <seb128> asac, empathy
[20:21] <seb128> asac, I didn't build try but if the pc name changes I expect that's normal
[20:22] <NCommander> Amaranth, hrm, maybe my ia64's card is supported
[20:22] <NCommander> Amaranth, its c. 2002-ish
[20:27] <asac> seb128: its a bug. the pc files changed, but instead of a new packagename we should just ship compatibility .pc files
[20:28] <seb128> asac, the name probably changed for a reason? ie the api is not compatible?
[20:28] <Amaranth> NCommander: as long as it a Radeon 7000 or newer and not a Radeon HD it should work
[20:28] <seb128> in which case it doesn't make sense to have compatibility
[20:28] <seb128> Amaranth, the new compiz makes some gnome-panel bars to be transparent until clicked, known issue?
[20:28] <asac> seb128: its a soname transition yes. but the .pc file was just changed because dan wanted to finally shift from _ to -
[20:28] <Amaranth> seb128: Haven't seen that, no
[20:29] <seb128> asac, ah ok, bug then
[20:29] <Amaranth> oh man, that's probably because of my patch too :/
[20:29] <seb128> Amaranth, I get it every time in a guest session
[20:29] <NCommander> Amaranth, where's the idiots guide to setting up the free driver ;-)
[20:30] <Amaranth> seb128: don't suppose you can try building it without 015_draw_dock_shadows_on_desktop.patch?
[20:30] <Amaranth> seb128: you'll only have to install 3/4 of KDE to do so :)
[20:30] <Amaranth> NCommander: should be as simple as installing the ati driver package
[20:30] <Amaranth> brb, going to test guest session
[20:32] <Amaranth> seb128: hrm, I don't have a guest session
[20:32] <Amaranth> and I think I remember something about a bug right before jaunty where this happened but only with the guest session
[20:32] <seb128> Amaranth, install gdm-guest-session?
[20:33] <Amaranth> it is installed, or at least it was
[20:33] <Amaranth> although I just saw the problem with my bottom panel on my regular session
[20:33] <Amaranth> yeah, gdm-guest-session is installed
[20:34] <seb128> and you don't have "Guest session" in the fusa menu?
[20:34] <Amaranth> building without my patch now, it's the only one that touches any code that should have an effect on drawing docks
[20:34] <Amaranth> seb128: oh, I don't use fusa
[20:34] <seb128> Amaranth, I'm doing that too
[20:34] <Amaranth> isn't it supposed to show up in gdm?
[20:34] <seb128> Amaranth, well add it it you want to try guest session
[20:35] <Amaranth> that seems silly but ok
[20:35] <seb128> Amaranth, no, for security reason only logged-in users can give you access
[20:35] <seb128> that's a design decision
[20:35] <seb128> no open login for anybody want to try to crack your box
[20:35] <Amaranth> are there two user switcher applets?
[20:36] <seb128> yes
[20:36] <Amaranth> because the one I added just opens the gnome-control-center shell
[20:36] <seb128> the upstream one and the ubuntu one
[20:36] <Amaranth> what is the name of that one?
[20:36] <seb128> session notification
[20:37] <seb128> or something similar
[20:37] <seb128> the icons is "i" with a circle
[20:37] <Amaranth> indicator applet session
[20:37] <seb128> right
[20:37]  * mac_v thinks canonical ran out of labels ;p and is naming everything indicator-*
[20:37] <Amaranth> ok, installed my rebuilt compiz-plugins
[20:38] <Amaranth> still happening
[20:38] <Amaranth> going back to my laptop, I can test with guess session now
[20:39] <Amaranth> hrm, when you go back from a guest session compiz messes up just like resume from suspend
[20:40] <Amaranth> that'll make it easier to debug that problem
[20:40] <Amaranth> the panel thing also happens when you restart compiz
[20:40] <Amaranth> hrm, panel isn't coming back...
[20:41] <Keybuk> bratsche: +        /usr/bin/xsplash --gdm-session &
[20:41] <Keybuk> urgh, could you not add a --daemon flag instead/
[20:42] <bratsche> Keybuk: Sure.. and then the user session just tells it to display again?
[20:42]  * Amaranth blames all of this on intel
[20:42] <Keybuk> bratsche: no, I mean instead of the "&"
[20:42] <Keybuk> "&" means that xsplash will begin spawning in the background while Init carries on
[20:43] <bratsche> Keybuk: Oh I see.
[20:43] <Keybuk> a --daemon flag would mean Init waits for xsplash to actually be spawned and enter its main loop
[20:43] <bratsche> Keybuk: Sure.
[20:43] <Keybuk> part of the reason xsplash doesn't quite appear so quickly is the kernel /tends/ to give a little more priority to the parent rather than the child in these situations
[20:45] <seb128> Amaranth, it was working before the update though ;-)
[20:45] <bratsche> Keybuk: https://bugs.launchpad.net/xsplash/+bug/429602  <-- I'll let you know when I get a branch ready.  Would you be able to review it for me?
[20:45] <seb128> Amaranth, 1:0.8.3+git20090825-0ubuntu1 didn't have the issue if that's useful
[20:46] <Amaranth> seb128: just the last update even
[20:46] <seb128> Amaranth, and I updated only compiz binaries
[20:46] <Amaranth> yeah, even the 0907 package didn't do it
[20:46] <Keybuk> bratsche: sure
[20:46] <Keybuk> no urgency, but it's a would be nice :)
[20:46] <Amaranth> so we've got 7 days of commits to compiz or one of the plugin packs
[20:48] <seb128> Amaranth, I updated only compiz
[20:48] <seb128> Amaranth, ie none of the other sources
[20:48] <Amaranth> ok
[20:48] <Amaranth> in that case http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=4477f537c43a3abc75aebc8af8ff1f28b8cf36a5
[20:49] <Amaranth> *shrug*
[20:49] <Amaranth> it's the only commit that seems to even get close
[20:50] <seb128> can you try or do you want me to try?
[20:50] <Amaranth> I can try
[20:50] <seb128> ok thanks
[20:50] <Amaranth> everything else is plugin changes
[20:54] <Amaranth> no luck, trying http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=85ba708cb894658c9bf9862a311010a9b79ec6f2
[20:54] <Amaranth> if that isn't it I'm going to start tearing hair out
[20:54] <Amaranth> wait, that can't be it
[20:58] <Amaranth> holy crap I think that was it
[20:58] <Amaranth> yep, that was it
[20:59] <Amaranth> seb128: if you back out http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=fc83fcd8b9866c19416323e17e82e4e4e9fb14d2 and http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=85ba708cb894658c9bf9862a311010a9b79ec6f2 (in that order) it should start working correctly again
[20:59] <Amaranth> just snag the patch files for them from cgit and patch -R
[20:59] <seb128> Amaranth, is that useful if I do testing?
[21:00] <Amaranth> seb128: yeah, just to make sure that is the problem commit
[21:00] <seb128> ok
[21:00] <Amaranth> I just tried guest session 3 times and didn't get invisible panels while before I was getting one every time
[21:00] <Amaranth> but confirmation would be nice
[21:03] <bratsche> Keybuk: https://code.launchpad.net/~bratsche/xsplash/daemon/+merge/11731
[21:03] <seb128> Amaranth, the second one fails to apply
[21:03] <Amaranth> seb128: you applied the other one first?
[21:03] <seb128> yes
[21:04] <Amaranth> oh, whoops, I left one out
[21:04] <Amaranth> http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=4477f537c43a3abc75aebc8af8ff1f28b8cf36a5
[21:04] <Amaranth> that needs to go before the 85ba one as well
[21:04] <Amaranth> the 85ba one is the cause, the other two are cleanups of the code added in that commit
[21:04] <seb128> Amaranth, ok, applied now
[21:04] <seb128> building
[21:05] <Amaranth> I think gcc 4.4 must be a lot faster than 4.2 because I remember compiz taking forever to build and it flies now

[21:10] <seb128> Amaranth, that fixes the issue indeed
[21:10] <Amaranth> alright, will let danny know and try to find a fix
[21:10] <seb128> thanks
[21:10] <Amaranth> if I can't figure anything out I'll see if mvo or robert-ancell can upload a package with those pulled out
[21:12] <seb128> Amaranth, other issue, when triggering the gpg agent twice you get the focus but the decoration is not colored
[21:12] <Amaranth> hrm
[21:12] <Amaranth> you mean with bzr builddeb?
[21:12] <seb128> ie it comes to frontend but looks like it would not get focus
[21:12] <seb128> start a session
[21:12] <seb128> debsign .changes
[21:12] <seb128> esc
[21:12] <seb128> debsign .changes
[21:13] <seb128> the second call displays the dialog to front
[21:13] <Keybuk> bratsche: that looks fine to me
[21:13] <seb128> (it used to be in background, good job to fix that)
[21:13] <Keybuk> bratsche: though I'd put the fork() after all the _init () functions
[21:13] <seb128> but the decoration indicates it's not colored
[21:13] <seb128> not sure if that's a clear description
[21:13] <bratsche> Keybuk: Okay cool.
[21:14] <Keybuk> usually you put it at the "if we get this far, everything's ok" point
[21:14] <Keybuk> personally I'd put it after you've actually loaded the logo and stuff
[21:14] <Keybuk> since that way, "xsplash is ready and has painted the screen"
[21:14] <Keybuk> (and thus the next line in the gdm script is run under xsplash
[21:15] <bratsche> But wouldn't it be blocking gdm from continuing if I do it that way?
[21:15] <Keybuk>  which happens to be an Upstart notification in the ubuntu-boot PPA :p)
[21:15] <Keybuk> yes
[21:15] <Amaranth> seb128: I think I understand
[21:15] <Keybuk> but that's not a bad thing
[21:15] <Keybuk> for a start, it'd encourage you to make sure it doesn't take you very long at all to display the screen ;)
[21:15] <bratsche> I'm trying to keep it quick :)
[21:16] <Keybuk> ironically, sometimes it's faster to do things in series than in parallel
[21:16] <bratsche> Okay.. I'll shift the fork() stuff until later.
[21:17] <Amaranth> the moblin 5 second boot was more focused on making sure things didn't interfere with each other than anything else, from what I could see
[21:17] <Keybuk> exactly
[21:17] <Keybuk> it so happens that the very next line in that script is "initctl emit ..."
[21:17] <Keybuk> which is a signal to upstart that it's ok to start some things now, because gdm is up
[21:18] <Amaranth> Keybuk: btw, was there a reason you needed the .tgz of my boot chart or were you asking everyone?
[21:18] <Keybuk> Amaranth: I still haven't figured out what the strange "exe" process is at the end of the initramfs
[21:18] <Amaranth> ah
[21:19] <Amaranth> Keybuk: also, it seems like sreadahead isn't actually doing anything
[21:19] <Keybuk> we've been debugging that
[21:20] <Amaranth> ah, alright
[21:20] <mac_v> Amaranth: wrong , it does something for me , ;) it eats my cpu for 1min after session start :(
[21:20] <Amaranth> heh
[21:21] <mac_v> Keybuk: is the boot Mailing list an open ML or a canonical one?
[21:22] <Keybuk> a Launchpad one
[21:22] <mac_v> oh , lp , i'v been searching in the wiki ...
[21:24] <chrisccoulson> seb128 - i've just pushed a change to fix the gnome-session upgrade issue
[21:24] <Keybuk> mac_v: https://launchpad.net/~ubuntu-boot
[21:25] <chrisccoulson> it's difficult to test properly though without doing a full jaunty-> karmic upgrade
[21:25] <mac_v> Keybuk: lol , nice boot ;)
[21:26] <bratsche> Keybuk: Okay, resubmitting the merge request.. I moved the fork fu until after the resources are loaded.
[21:28] <Keybuk> bratsche: looks ok to me
[21:29] <mac_v> kenvandine: hi... is this empathy bug fixed> Bug #409828 , or does it need a patch? looking into it it seems that a new image define needs to be created
[21:29] <bratsche> Keybuk: If you don't mind, could you mark it approved on https://code.launchpad.net/~bratsche/xsplash/daemon/+merge/11734 ?  David is really into doing the review/merge request procedure.
[21:29] <mac_v> s/fixed/commited upstream
[21:30] <seb128> chrisccoulson, thanks
[21:30] <seb128> chrisccoulson, we will see what user testing will do
[21:31] <bratsche> Keybuk: Thanks!
[22:00] <chrisccoulson> seb128 - is gnome-system-monitor usable for you?
[22:01] <seb128> chrisccoulson, define usable
[22:01] <chrisccoulson> it hammers the session bus here causing dbus-daemon to hog the CPU
[22:01] <chrisccoulson> and it won't exit
[22:01] <chrisccoulson> other than that, it seems to function ok
[22:02] <seb128> chrisccoulson, no such issue there
[22:03] <chrisccoulson> hmmm, that's odd
[22:05] <seb128> I didn't upgrade that afternoon though
[22:05] <seb128> what signal do you get on the session bus?
[22:07] <chrisccoulson> it seems to be repeated calls to org.gtk.Private.RemoteVolumeMonitor.List and org.gtk.vfs.MountTracker.listMounts
[22:08] <seb128> could be due to your disks
[22:08] <seb128> or something similar
[22:08] <chrisccoulson> i'll run it in GDB and see if i can figure out whats happening
[22:24] <chrisccoulson> ccheney - i only just noticed from my bugmail that dianewalker980 messed up a lot of tasks again on bug 345189
[22:24] <chrisccoulson> i've just requested their account is suspended now
[22:27] <chrisccoulson> seb128 - gnome-system-monitor here is continuously creating and finalizing volume monitors, although i havent figured out why yet. explains all the dbus spam though ;)
[22:38] <ccheney> chrisccoulson: ok
[22:38]  * ccheney thinks it should be changed so only bugsquad can change the status
[23:02] <chrisccoulson> seb128 - just building the youtube plugin in totem now
[23:02] <chrisccoulson> the BBC iplayer plugin doesn't work though, as it's missing some dependencies
[23:02] <chrisccoulson> python-feedparser, which is in universe
[23:03] <chrisccoulson> and also python-beautifulsoup
[23:03] <Laney> beautifulsoup? it does screen scraping?
[23:03] <chrisccoulson> Laney - no idea. but the plugin wouldn't load until i installed it ;)
[23:04] <chrisccoulson> Laney - "error-tolerant HTML parser for Python"
[23:04]  * Laney gets suspishus
[23:05] <Laney> there's no proper iPlayer API?
[23:05] <chrisccoulson> i'm not sure really, i haven't had a proper look at it yet
[23:06] <Laney> anyway if it relies on something as brittle as that, i'd be a bit dubious
[23:06] <Laney> this is all without looking though ;)
[23:06] <chrisccoulson> yeah, i think it's best to just disable it for now. it doesn't work without those dependencies anyway
[23:09] <chrisccoulson> i suppose i could move it to totem-plugins-extra
[23:10] <seb128> chrisccoulson, right, I was going to suggest that too
[23:10] <chrisccoulson> i'll do that then - it's working ok with the extra dependencies
[23:10] <seb128> thanks
[23:36] <davmor2> asac: bug 411476 is still in place and also so is bug 423438 on iso 20090914.2 (just to let you know)