[06:54] Amaranth: hi... why is the login/logout compiz plugin not enabled by default? [06:54] mac_v: hmm [06:55] mac_v: well, it was meant for KDE to replace kwin's logout effect [06:55] it works well in gnome too [06:55] since we now dont have that effect at all [06:56] Amaranth: > is this right > (class=X-session-manager & type=Dialog) | (class=Gtk-logout-helper & type=Dialog) [06:56] that works for me [06:56] I'm thinking of confirming this Bug 429132 ... [06:57] eep [06:57] Launchpad bug 429132 in hundredpapercuts "Compiz logout effekt" [Undecided,New] https://launchpad.net/bugs/429132 [06:57] it made everything gray [06:57] and it didn't go back when I canceled the shutdown [06:57] hmm... works fine here , no probs [06:57] oh, I had a broken rule [06:58] it was doing it whenever a gnome-session window was around [06:58] which is...always [06:58] ;p [06:58] mac_v: that rule doesn't seem to match anything [06:59] hrm... [06:59] * mac_v wonders why it works here [06:59] mac_v: karmic? [06:59] yup [06:59] mac_v: GNOME? [06:59] yup [07:00] weird [07:00] ok, ,just this alone works too> (class=Gtk-logout-helper & type=Dialog) [07:01] nope, class for the logout and shutdown windows are Gnome-session [07:02] Amaranth: hrm , i grabbed the class from compiz [07:02] so did I [07:02] from ccsm [07:02] yeah, me too , weird [07:03] did you switch to upstream dialogs? [07:03] i dont understand ^ [07:03] hmm, that option is gone [07:04] we must be using upstream dialogs now [07:04] indicator-applet-session 0.1 [07:04] oh , let me check for updates [07:07] (class=X-session-manager & type=Dialog) [07:07] this works too! , :( [07:14] Amaranth: nope , i only have PA updates... ok , shall i confirm the bug and we can figure it out in due course ? [07:14] I guess so [07:14] ok. [07:14] if we get it working we'll want to modify the decoration plugin to not show decorations for those windows too [07:14] we also need to disable unredirect fullscreen windows [07:16] Amaranth: hrm.... why no decorations for those windows? but sounds good :) [07:18] Amaranth: yup , looks sexy without decorations [07:46] Good morning [07:51] hello pitti [07:52] morning [07:53] hey MenZa [07:54] * MenZa sips his coffee, checks his morning IRC. [08:47] robert_ancell: new compiz uploaded! [08:47] mvo, yay! [08:49] crack! [08:49] * pitti hugs mvo [08:49] hey robert_ancell, good morning [08:50] pitti, hey [08:54] pitti: haha - good crack! [08:54] loads of fixes :) [08:54] * mvo ticks off another item from his todo list [08:56] hello desktopers [08:57] lut seb128 [08:57] salut didrocks [08:59] hey seb128 [08:59] hello pitti [09:01] hey seb128 [09:01] hello chrisccoulson [09:02] did you have a good weekend? [09:03] yes, too short but very good otherwise [09:03] you? [09:04] yeah, same really ;) had some friends round yesterday but spent most of saturday trying to get karmic to work on my desktop [09:05] oh, did you manage to get it working? [09:05] what was the issue you had? [09:06] 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] hey chrisccoulson [09:07] i made some changes in the BIOS to turn off the onboard raid before i started the reinstall [09:07] hey pitti [09:07] 318 unread bug emails during the weekend [09:07] seb128: good luck ;) [09:07] weekend email backlogs are not fun nowadays [09:08] didrocks, thanks ;-) [09:08] chrisccoulson, oh ok [09:08] hey chrisccoulson [09:08] hey didrocks!" [09:10] 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] Launchpad bug 424511 in gnome-session "gnome-panel and window manager do not start on login" [Medium,In progress] https://launchpad.net/bugs/424511 [09:10] what was the issue? upgrade broken in the middle of unpacking? [09:11] 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] that's a question for mvo I guess [09:12] yeah, possibly [09:12] i wasn't sure how else to fix it [09:13] because it is the old prerm script that unregisters the schema, it is difficult to stop that from happening [09:14] I'm not sure in which order maintainer scripts are ran [09:14] I need to open the documentation [09:14] but I'm trying to fight some thousand emails from the weekend right now [09:14] so it will be a bit later ;-) [09:14] using a conflicts or break seems to make sense [09:15] though apt tends to be stupid on breaks and that leads to removing things [09:16] seb128 - that's ok, i'll let you check your e-mails ;) [09:16] and get some coffee! [09:16] coffee!! [09:16] good idea ;-) [09:17] coffee is always a good idea :-) (or tea as well for the minority here ;)) [09:18] heh, yeah, i don't drink tea;) [09:18] 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] tea! [09:19] launched* [09:19] didrocks - yeah, i find that quite useful also [09:19] mvo: the end of my sentence about tea was dedicated to you :-) [09:19] thanks:) [09:19] didrocks: I know ;) [09:19] didrocks: nice page - I always used the reference manual, but the diagrams are neat [09:20] 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:20] Launchpad bug 426501 in devicekit-power "gnome-session crashed with SIGSEGV in g_str_hash()" [High,Fix committed] https://launchpad.net/bugs/426501 [09:29] chrisccoulson: nice! thanks for following this [09:29] chrisccoulson: are there many dupes? [09:29] but no prob to cherrypick it, they don't do releases often [09:30] 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] chrisccoulson: looks like http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=a09005a0a3a61537e8f34a0db2fec990a5333bd4 [09:31] chrisccoulson: seems there are other worthwhile fixes there, I might just do a git snapshot [09:32] pitti - yeah, that probably makes sense [09:33] pitti - it looks like it is http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=8cb468ce64b0e1b21198744977d8a14e17ff5efe which fixes the crash [09:33] + /* finalise the object */ [09:33] + g_object_unref (device); [10:22] mvo: can we access the "Sources" or "Packages" files on a buildd? or is it not-defined? [10:27] asac: I think that is possible (but a bit hacky) [10:28] mvo - did you see the earlier conversation i had with seb128 about gnome-session upgrade issues? (sorry, I have no scrollback now) [10:29] chrisccoulson: yes, but I did not look closely - it looked complicated ;) [10:30] heh, yeah, it's a bit wierd [10:30] 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] 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] mvo: ok so rather not? [10:42] asac: well, depends on how important that is and what other options there are [10:42] ok, took me the morning to go through weekend emails [10:42] asac: something about automatically adding something, right? [10:42] asac: :) [10:43] asac: maybe it could be done a "dpkg-buildpackage -S" time? [10:43] asac: the buildds for for main will e.g. not have universe Packages lists available [10:45] hmm ok [10:45] feels like something we cannot rely on ;) [10:47] mvo: yes. i am thinking about "-S" ... feels ugly too [10:47] hmm for some reason i can't get ubuntuone to load the webpage for adding my computer [10:47] why is that, i wonder? [10:47] asac: well, some packages (like ubiquity, update-manager) use something like that, they create a private apt sources.list and get data [10:48] asac: what was the problem again that this solves? [10:48] mvo: are those used in debian too? [10:48] asac: (sorry, I think you told me, but I forgot) [10:48] asac: I see no reason why it could not work for debian as well :) [10:48] its basically because we have firefox etc. and debian has iceweasel etc. [10:49] 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] i think that might be doable [10:49] not sure how to best check that though [10:50] asac: we can have a quick phonecall after lunch and I might be able to help? [10:50] why not ... ;) [10:51] * soren is fascinated by this discussion.. [10:51] asac: What are you trying to do? [10:51] magic! its asac ;) [10:51] asac: I've tried looking at scrollback, but I can't find it. [10:51] soren: we have supermagic ${xpi:depends} in mozilla-devscripts [10:51] asac: Ok. [10:51] (oh, even supermagic!) [10:51] and want to assemble the right depends ... [10:51] currently we maintain a list in the sources ... but thats suboptimal and would prefer to assemble that on the fly [10:52] I see. [10:53] Are they the same for all extensions, but still dynamic somehow, or are they completely different for all extensions? [10:54] soren: extensions ship a install.rdf that refers to the applications (with min/max version) they work on. [10:54] so completely different (in theory) [10:54] most will have firefox of course [10:54] Right. [10:54] Oh, so it's based on that? [10:55] yes. [10:55] And that info is in Packages? [10:55] not yet. [10:55] but could be added [10:55] Ah. [10:55] That would make sense. [10:55] for now we maintain a superset of applications [10:56] but would like to add two meta fields: ApplicationId, ApplicationVersion: [10:56] in that way we could make this 100% accurate [10:56] the other option would be to require developers to install _all_ dependencies during build [10:56] but thats bad [10:56] ;) [10:56] and not needed i hope [10:59] * soren ponders [11:03] so anyone found where the "retry" button is hiding in new edge launchpad? [11:03] oh [11:03] its that tiny recycle icon [11:05] seb128: can you NEW those https://edge.launchpad.net/ubuntu/+source/network-manager/0.8~a~git.20090911t130220.4c77fa0-0ubuntu1 ? [11:06] thx [11:22] asac, newed [11:22] asac: oh, new N-M? another polkit-1 migration thing done then \o/ [11:23] mvo, newed compiz too [11:24] asac: curious, the applet still needs to b-dep on libpolkit? [11:24] seb128: rock. [11:24] pitti: i will check that. might be an oversight or will land soonish i would hope [11:25] asac: usually you shouldn't need to have any polkit code client-side any more [11:25] in configure.ac it now uses polkit-gobject-1 [11:25] so at least the packaging can be adjusted [11:26] pitti: i thikn its a bit different because the applet provides a user settings service on its own [11:26] but i will check with dan [11:31] 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] asac: the applet runs as user, though? [11:32] asac: anyway, it's not a blocker, I just wondered [11:32] pitti: just saw that we properly depend on polkit-1 ... at least. i will check if that can be dropped [11:32] but i think we want the user settings to be controllable by certain other users [11:32] ah === al-maisan_ is now known as al-maisan [12:06] seb128: cool, many thanks [12:06] mvo, np, I'm eager to try the update ;-) [12:09] seb128: it rocks :) [12:10] seb128: and puts the policykit dialogs on top [12:10] seb128: and needs new libcompizconfig and new plugins that are not build yet and apparently have a low build-score :( [12:10] would it be possible to get a private ppa so that I can ask for ppa->archive copies? [12:10] you can maybe bribe pitti to bump build score ;-) [12:11] * mvo offers green tea to pitti as a bribe [12:13] mvo: which source packages? [12:13] mvo: libcompizconfig is in depwait [12:15] it's waiting for compiz publishing apparently [12:15] yeah, same for the plugins- packages, waiting for compiz-core-dev [12:16] the changelog is impressive [12:16] lot of issues and crashes fixed ;-) [12:16] yeah, the compiz upstream guys are just great [12:16] lots of valgrind and gcc -Wall [12:17] ;-) [12:17] and sparse I think [12:23] tseliot: do you have a idea how much space dkms (roughly) needs? [12:23] tseliot: for building I mean in /tmp ? [12:24] mvo: for building a module? [12:25] tseliot: yes [12:25] wb chrisccoulson [12:25] 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] mvo: I don't know but wouldn't it depend on the module? [12:26] mvo, did you read the gnome-session question earlier? [12:26] chrisccoulson, did you work on making totem use libgdata? [12:26] * tseliot -> lunch [12:26] hey chrisccoulson - I had a quick look at your question and I think break is ok [12:26] chrisccoulson: what does the prerm do btw? [12:26] tseliot: I guess it would, I just need a number :) I can then use it as a lower bound [12:27] mvo: ok, I'll give you a number when I'm back [12:27] thanks tseliot [12:27] mvo, it's standard dh_gconf calls [12:28] mvo, old schemas unregistered and new one registered [12:28] to make sure you don't have deprecated keys in the config and get the new ones too [12:28] * mvo nods [12:28] 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] chrisccoulson, no need to wait on the mir, that's a chicken egg issue ;-) [12:29] mvo - thanks for looking at that issue. the prerm script contains a hook generated by dh_gconf to unregister the schema [12:29] chrisccoulson, the eariler we ger the change the better if we want it for alpha [12:29] 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] seb128 - ok, i'll work on that later then:) [12:30] 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] seb128: right, it it's definitively an issue [12:30] chrisccoulson, ok thanks [12:30] seb128: but Kmos' patch is wrong [12:31] mvo, i just saw seb128 already answered your question ;) [12:31] * chrisccoulson should look at scrollback more often [12:31] pitti, right, that was a reply to " or don't collect information from the Apport notification which opens automatically " [12:31] seb128: I figured; thanks for confirming [12:31] 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] seb128: I think you should just add it to your ~/.bashrc or so [12:32] sorry, ~/.profile [12:32] the one that's read by GNOME [12:32] pitti, well I do want to be told about outdated versions [12:32] so I can decided according to what is outdated [12:33] seb128: if that's really hurting you, I can spend some 20 minutes to fix it properly [12:33] ie if the software is outdated no point to report the bug, if that's some stupid lib ... [12:33] pitti, no that's ok, I understand the issue now, thanks ;-) [12:34] pitti, can I gedit the .crash by hand to drop the UnreportableReason? [12:34] seb128: yes [12:34] ok, that's good enough for me [12:34] thanks: [12:34] ! [12:34] * seb128 hugs pitti [12:34] * pitti hugs seb128 [12:41] seb128: FYI, current retracer crash is again a "AssertionError: Could not find package for ExecutablePath" [12:42] it's looking for /usr/lib/firefox-3.5.2/firefox which doesn't exist any more [12:42] I'll just fix it to close them as obsolete [12:42] pitti, ok thanks [12:43] 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] the currentl version of glom in karmic is completely busted now though... [12:43] chrisccoulson: I remember [12:44] 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] eww [12:44] (that used to come from gnome-python2-extras) [12:44] so, i'm not sure what to do ;) [12:44] I assume it neither builds with the new 4 API, nor is there a newer upstream version which does? [12:45] pitti - it won't build with pygda4 either, as the API has changed a fair bit [12:45] the newer upstream version will do though [12:45] oh, brilliant [12:45] is that enough justification for a FFe? ;) [12:46] absolutely [12:46] it can hardly get any worse, after all [12:46] so updating it is a no-brainer [12:46] (I mean -release wise) [12:47] yeah, that's what i thought. we still need to get libgda4 in main though, so that we can build pygda4 [12:47] but i can work on a MIR for that [13:00] * asac lunch [13:09] mvo, libcompizconfig built now [13:10] mvo, the new version sort of fix the focus issue with seahorse gpg agent dialogs [13:10] they get on the first plan now which is good [13:11] but they still look unfocussed, ie decorations not colored [13:13] seb128: hm, it seems that it gets it right for software-store - is that the same polkit1 dialog? [13:14] mvo, no, I'm speaking about the gpg agent dialog [13:14] mvo, design *.changes, esc, debsign *.changes [13:14] 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] seb128: oh, ok. I have a look [13:17] mvo, no idea, maybe james_w` or pitti know [13:18] no idea, sorry [13:18] you could mail polkit-devel [13:30] 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] ie the top bar is transparent and only displayed when clicking on it === james_w` is now known as james_w [13:48] seb128: I need to test this on my other machine, with nvidia the guest session does not work for me with compiz :( [13:50] mvo, could be the same with a normal session start but I didn't want to close mine ;-) [14:07] seb128: what app would be a good candidate to test gio modules? [14:07] /usr/lib/gio/modules/libgvfsdbus.so [14:07] /usr/lib/gio/modules/libgioremote-volume-monitor.so [14:07] /usr/lib/gio/modules/libgiogconf.so [14:08] the gtk fileselector in gedit for example? [14:08] try browsing a ssh or smb share from there [14:08] what does the giogconf thing do? [14:08] thx [14:08] it allows gio to use gconf [14:08] gio is under gconf in the stack [14:08] seb128: how can i trigger that code path? [14:09] so it can't use libgconf, they have to trick [14:09] ah [14:09] same for gvfs [14:09] would gedit file selector trigger it? [14:09] yes [14:09] browse a share with nautilus [14:09] ok ... why are all those modules separate? [14:09] ssh, smb, ftp, anything non local [14:09] and open the gedit fileselector [14:09] e.g. can one use gvfsdbus without giogconf? [14:09] and see if you can browse those [14:09] felt like thats not possible [14:10] thanks. i think thats enough for our purpose [14:10] you can probably use giogconf to access gconf settings from gio [14:10] but I doubt we have anything doing that [14:10] the real "customer" for those is to make gio be able to use gvfs backends [14:10] seb128, i saw some chatter about compiz earlier, is there a known issue with it not starting? [14:10] kenvandine, no but you might have caught a partial upgrade [14:11] ok [14:11] kenvandine, ie upgraded the core while the plugins were not update [14:11] what error do you get? [14:11] Couldn't find a perfect decorator match; trying all decorators [14:11] Found no decorator to start [14:11] mvo is well known to screw those every time ;-) [14:11] hum [14:11] did you get any package remove? [14:11] yes [14:11] ie did you validate a dist-upgrade without reading or something? [14:12] it removed some plugins and the compiz package [14:12] hum [14:12] but upgrade compiz-core [14:12] the goal is to make you wait [14:12] not to make you remove [14:12] mvo: sorry, closed IRC over lunch; what was your PK question? [14:12] it's basically your fault [14:12] :) [14:12] ie don't confirm package removal [14:13] 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] and you went for the new crack ;-) [14:13] hehe... ok [14:13] wait for the next publisher run now and reinstall those [14:13] * kenvandine thought it would have held those back [14:13] upgrade would so [14:14] upgrade would do [14:14] dist-upgrade go the other way and remove to get you new cracks if you really want [14:14] certainly not important... just glad there isn't a bug :) [14:14] you should be using upgrade rather than dist-upgrade [14:14] hummm.. someone told me it would be better to test dist-upgrade regularly [14:14] hey rickspencer3* [14:14] :) [14:15] hey rickspencer3 [14:15] kenvandine, well read what dist-upgrade do in any case, conflicts often lead to removal during transitions [14:15] ie it's fine to remove old lib sonames [14:15] but you usually don't want to remove your decorator [14:15] i read it, just tested that upgrade path [14:16] i have the decorator... not sure why it isn't finding it [14:16] ok [14:16] what did get uninstalled exactly? [14:16] rickspencer3: fyi... you shouldn't dist-upgrade this morning :) [14:17] compizconfig-backend-gconf might be the culprit [14:17] that was removed [14:17] ups, wrong focus [14:17] it removed compiz and compizconfig-backend-gconf [14:18] try reinstalling those? [14:18] the decorator is in compiz-core, so i suspect compizconfig-backend-gconf [14:18] yeah [14:18] doing that now [14:19] dep errors [14:19] * kenvandine just waits [14:19] i know rickspencer3 does dist-upgrades every morning.. so i want to stop him :) [14:20] let's see if he does read what dist-upgrade do before acking ;-) [14:20] hehe [14:20] I usually use update-manager which does the right thing [14:20] i was suspicious of the upgrade... but knew it wouldn't completely hose me :) [14:20] hey kenvandine [14:20] aptitude did the right thing on compiz for me, FWIW [14:21] compiz | 1:0.8.3+git20090914-0ubuntu1 | karmic | source [14:21] * kenvandine waits for binaries [14:21] "Keep the following packages at their current version: [14:21] compiz [1:0.8.2-0ubuntu16 (now)] [14:21] and so on [14:22] * rickspencer3_ reads up [14:22] rickspencer3: summary; don't ack compiz removal if you dist-upgrade [14:23] kenvandine, are you getting an issue where you window frames kind of dissapear? [14:23] no [14:23] oops, my other computer is on [14:23] (did that happen in the middle of publish run? - on my test machine compiz wants to upgrade complettly)? [14:24] the goal is to make people wait to get all the binaries but dist-upgrade junkies might have issues ;-) [14:24] rmadison says it isn't published yet [14:24] compiz is published for 2 hours [14:24] humm [14:24] but other things were waiting for it to build [14:24] ie libcompizsettings [14:25] libcompizconfig [14:25]