[00:05] <seb128> enough for today, next uploads tomorrow
[09:14] <huats> morning everyone
[09:16] <seb128> hey huats
[09:46] <mvo> hey glatzor!
[09:46] <glatzor> morning mvo!
[09:46] <glatzor> mvo, you have been quite bussy lately?
[09:47] <mvo> glatzor: yeah :(
[09:47] <glatzor> mvo, thanks a lot for the upload
[09:48] <glatzor> of packagekit
[09:48] <glatzor> mvo, do you come to ubucon october?
[09:48] <mvo> glatzor: cheers, thanks a lot for all the work you put into it!
[09:48] <mvo> glatzor: I have no definite plans about it yet - do you plan to come?
[09:48] <mvo> glatzor: I was there last year and it was pretty good
[09:52] <mvo> asac: you have a moment to talk about xul-extensions ?
[09:53] <glatzor> mvo, I plan to. But I have to care about the tickets and a hotel :)
[09:53] <mvo> asac: is there a way (or a good heuristic) to detect what package provides a extension? I checked firefox-sage. should I just dump out "extension && depends-on: firefox-3" ?
[09:54] <glatzor> mvo, furthermore I want to turn over my translation coordinator work to somebody else there.
[09:54] <mvo> glatzor: you have a candidate already?
[09:55] <asac> mvo: hmm
[09:56] <mvo> asac: firefox-beagle for exmaple does not depend on ff-3, only ff
[09:56] <mvo> (and abrowser)
[09:56] <asac> yeah
[09:56] <mvo> or should I use abrowser as the key for ff-3 (xul-extension-3) ?
[09:56] <asac> mvo: so from what i understand you want to detect extensions without looking in the package?
[09:58] <asac> mvo: ?
[09:58] <mvo> asac: basicly I want to fix the bug that g-a-i does not show xul extensions currently for ff-3. and I don't care how :)
[09:59] <asac> mvo: cool
[09:59] <asac> mvo: so its reawlly a bug?
[09:59] <mvo> asac: if I look at the package itself, what information do I have to watch out for? is there a dir or registry file?
[09:59] <asac> thought that the data pieces were dropped :)
[09:59] <mvo> asac: not as such I think, its more like the branch was never ported to ff-3
[10:01] <asac> mvo: unfortunately there is nothing that is a real accurate indication that its an extension
[10:01] <asac> mvo: we can raise the bar though and introduce a policy
[10:01] <mvo> asac: that would be nice. if I get it 95% right with using the dependency information and the string "extenstion" and do some manual checking then that should be fine for now
[10:02] <mvo> asac: its not that many extenstions, right?
[10:02] <asac> mvo: is that just a one time thing now? or do you want to detect that on the fly?
[10:03] <asac> https://wiki.ubuntu.com/MozillaTeam/Extensions/List
[10:03] <mvo> asac: on the fly would be best of course, but for now a heuristic and manual review should be neough
[10:03] <mvo> asac: aha, thanks
[10:04] <mvo> asac: if you run gnome-app-install --xul-extensions=firefox-2 that stll works, so its just a matter of updating the list. I guess ff-3 calls g-a-i with "firefox-3"
[10:04] <mvo> ?
[10:04] <asac> mvo: actually we updated the list in hardy afaict
[10:04] <asac> its wierd that we didnt notice that it doesnt work for ffox 3
[10:06] <asac> mvo: yeah. just checked on my hardy laptop. at least the dialog that open from the firefox extensions dialog has a bunch of extensions in it
[10:06] <asac> mvo: it uses --xul-extensions=firefox
[10:06] <asac> thats ok imo
[10:07] <mvo> asac: interessting, let me check
[10:07] <asac> mvo: thats a regression
[10:07] <asac> there is nothing different
[10:07] <asac> in intrepid. except that the dialog shows up nothing
[10:07] <mvo> asac: so the string in ff-3 did not change? how strange
[10:07] <asac>  /usr/bin/python /usr/bin/gnome-app-install --xul-extensions=firefox
[10:07] <asac> that is broken in intrepid
[10:07] <asac> and works on hardy
[10:08] <asac> mvo: i am quite sure that jazzva took care to update all the data in the hardy cycle for all our ffox 3 extensions
[10:08] <asac> thats why i find it strange
[10:09] <asac> mvo: did you change the format of the data branch?
[10:09] <mvo> asac: hm, there goes my theory :) I look into it, its strange, I can reproduce the failure here on my laptop, but on my desktop it gives me output.
[10:10] <asac> mvo: hmm. i think it was reported multiple times to moziiolateam
[10:10]  * mvo scratches his head
[10:10] <asac> i always assumed that glatzor or you just abandoned some old data branch
[10:10] <asac> and we would have to add everything ;)
[10:10] <asac> somewhere else
[10:11] <mvo> asac: no, the data is still there
[10:11] <mvo> must be something else then
[10:11]  * mvo digs a bit deeper
[10:14] <mvo> asac: aha! I think its because most of them are in universe now and g-a-i blacklists universe in the mime-search (this is a subset of the mime search code)
[10:16] <mvo> asac: how is security handled for those extensions? is it safe to assume they get propper security support and updates?
[10:25] <asac> mvo: err. no official policy, but if we get to know that there is a security issue, we will update it
[10:26] <mvo> asac: could you comment on this in #267382 ? then I fix the code
[10:26] <asac> bug #267382
[10:32] <asac> mvo: done
[10:34] <mvo> asac: thanks
[10:51] <glatzor> mvo, I hope so havng a candidate
[10:51] <glatzor> mvo, see you later
[12:07] <asac> mvo: one question. folks say that this notification bubble to "restart firefox" never disappears ... is there anything we could do about it?
[12:07] <mvo> asac: can you reproduce that?
[12:08] <asac> mvo: i think i am currently in that state ;)
[12:09] <asac> mvo: e.g. information light is in tray even though firefox was restarted
[12:09] <asac> mvo: is there any info i could get?
[12:09] <mvo> asac: could you please give me the file ~/.update-notifier/hooks_seen
[12:10] <mvo> asac: and ls -l /var/lib/update-notifier/user.d/
[12:10] <asac> mvo: http://paste.ubuntu.com/50444/
[12:10] <mvo> and stat /var/lib/update-notifier/user.d/firefox-3.0-restart-required
[12:11] <asac> http://paste.ubuntu.com/50445/ (ls -l)
[12:11] <asac> http://paste.ubuntu.com/50446/ (stat)
[12:15] <mvo> asac: what are your mount options (noatime, relatime)?
[12:16] <asac> mvo: /dev/sda9 on /var type ext3 (rw)
[12:19] <mvo> hmmm
[12:20] <mvo> asac: so you click on the bubble and then when you close the dialog its still there?
[12:21] <asac> mvo: no. i restart firefox and its still there :)
[12:22] <asac> mvo: most likely not a feature, but now that we display a "restart" button within firefox it would be beneficial if we could find a way to make that thing disappear when ffox was properly restarted
[12:22] <asac> mvo: e.g. we have http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
[12:22] <mvo> asac: after the next login?
[12:23] <asac> mvo: unfortunately its in ubufox so we still need this "old" notitification mechanism
[12:23] <asac> mvo: no. after restarting firefox
[12:23] <asac> not sure about next login
[12:23] <mvo> aha, so you click on this, ff restarts and now the bubles does not disappera
[12:23] <mvo> r
[12:23] <asac> yeah
[12:23] <asac> mvo: also if someone just closes firefox and starts it again it would make sense that it disappears as well
[12:24] <asac> but currently i am more concerned about the case where they restart firefox using that panel in firefox
[12:24] <mvo> right, I see the problem now. that is a tricky. how does the restart work currently? is there some sort of script I could hook into?
[12:25] <mvo> basicly it would have to update .update-notifier/hooks_seen and notify update-notifier to re-read the notification stuff
[12:25] <mvo> asac: is there a open bug about this particular one?
[12:27] <seb128> mvo: btw I'm running the new compiz and didn't notice any issue
[12:27] <asac> mvo: well. restarting using that button we could do something (like running a hook), but it would be better if it worked without any hook
[12:27] <asac> because otherwise people just closing firefox and starting it wont work
[12:28] <asac> mvo: couldnt update-notifier look for the PID and if that PID is gone remove the notification?
[12:28] <asac> (sounds simple for an outsider ;))
[12:30] <mvo> asac: it could, but this hook stuff is pretty generic currently and that makes it difficult. adding some special purpose handling just for FF would allow that, but its not ideal I think. is there a open bug about this already on your side? if not, I will create one
[12:30] <mvo> thanks for testing seb128
[12:31] <asac> mvo: hmm. dont we provide a "ps" command?
[12:31] <asac> couldnt that command be run regularly to see if its still returning the right thing?
[12:31] <mvo> yes, I was thinking about this, but then we would have to store the old pid and the new pid and compare
[12:32] <seb128> mvo: you're welcome
[12:32]  * pochu waves
[12:32] <asac> mvo: yeah. but sounds a bit like this is a general feature missing ;)
[12:32] <asac> not really specia
[12:32] <asac> l
[12:32] <mvo> no problem with special purpose handling, but a bit more difficult without. if the restart could write some sort of stamp file that it got restarted, that might help
[12:33] <mvo> I'm not arguing that :)
[12:33] <mvo> just trying to think what can be done in a way that is least intrusive at this point
[12:33] <asac> okay. maybe think about it ... not urgent. just some polishing that would be nice to get
[12:33] <mvo> maybe "MontiorApp=firefox" would be the right now and handling that detects restarts of the given program
[12:33]  * mvo ponders about it a bit
[12:34] <pochu> seb128: hi, if you're not busy can you sync gdl from unstable?
[12:37] <mvo> asac: bug 274359
[12:38] <asac> mvo: cool. subscribed :)
[12:38] <asac> thanks
[12:38] <mvo> cheers
[13:00] <seb128> pochu: I tried to sync gdl and gnome-build before lunch already but they were not yet on the mirror we use for syncs
[13:02] <seb128> hey pedro_
[13:02] <pedro_> bonjour seb128!
[13:11] <pochu> seb128: ok, thanks :)
[13:11] <pochu> hello pedro_ :)
[13:11] <pedro_> hey hey pochu
[13:16] <mpt> Keybuk, why did you mark bug 269502 as a duplicate of bug 269500?
[13:16] <Keybuk> because it's the same bug - lack of icons?
[13:17] <Keybuk> just a lack of a different icon
[13:18] <Keybuk> the real bug is that we need kwwii to do a bunch of icons for those dialogs of a set size
[13:19] <Keybuk> (modulo any discussion about the fact the dialog code shouldn't care :p)
[13:19] <mpt> There are plenty of other bug reports about missing icons in various places
[13:19] <seb128> but those are in the same application for the same dialogs
[13:19] <mpt> anyhoo, just as long as they both get fixed :-)
[13:20] <Keybuk> sure, I was just collating particular missing icons for the same patch, in the same package, into the same RC bug ;)
[13:20] <seb128> it's better to have all icons required for gnome-session power manager actions in the same bug
[13:20] <seb128> easier to track it this way
[13:21] <Keybuk> depends
[13:21] <Keybuk> I think it's better for them to be filed as separate bugs
[13:21] <Keybuk> that way people filing don't have to care
[13:21] <Keybuk> and we can just collate them when we hand them to artists
[13:22] <Keybuk> one day we might have multiple pen-pushers, and might give them a set each, etc.
[13:22] <seb128> right that's what I meant
[13:22] <seb128> we just need to keep once in this case
[13:22] <seb128> but that's not something the submitter should know or care about
[13:53] <seb128> lool: do you think you could sponsor the debian pkg-gnome uploads waiting today? the intrepid beta freeze is today and I'll have to do ubuntu changes if we can't sync those
[13:54] <seb128> (and yeah I should really get a current debian unstable environment again to do that too)
[13:56] <james_w> hey tedg
[13:56] <tedg> Morning james_w
[13:57] <james_w> tedg: in bug 267331 I've been investigating why I don't get offered a suspend option
[13:58] <james_w> tedg: it seems as though it's because pm-utils decides it should use uswsusp, but uswsusp doesn't allow for suspend
[13:58] <james_w> is using uswsusp generally the right thing to do?
[13:59] <tedg> james_w: Unfortunately you've gone beyond my understanding.  pitti is probably a good person to ask.
[13:59] <tedg> james_w: I'm more at the level of "if HAL says so, I believe it"
[13:59] <james_w> ok, thanks.
[14:00] <lapo> hi
[14:01] <lool> seb128: I could, so much to do today, will try hard
[14:01] <lool> james_w: i'm not forgetting you
[14:02] <james_w> thanks lool
[15:08] <pitti> Keybuk, seb128: *evil idea*
[15:08]  * seb128 runs
[15:08] <pitti> Keybuk, seb128: the only thing we need that fuse group for is to run /bin/fusermount, right?
[15:09] <pitti> hm, on second thought that's in fact too evil
[15:09] <pitti> (using the existing hal device permissions engine to set an x acl to /bin/fusermount, but that is (1) a bad hack, and (2) wouldn't work on non-ext3)
[15:10] <pitti> so nevermind me
[15:10] <seb128> k
[15:10] <seb128> brb, just restarting session and I've some topics for you
[15:12] <james_w> pitti: hey, I'd like your response to the uswsusp mail on ubuntu-devel@ when you see it/have a minute
[15:14] <seb128> re
[15:14] <mpt> pitti, for bug 202267, what would "Additional" mean?
[15:14] <mpt> Additional to what?
[15:14] <seb128> pitti: let me know when you have a minute
[15:15] <fta2> seb128, i have cairo ready, is it too late?
[15:15] <seb128> fta2: no it's not, where is it? ;-)
[15:15] <pitti> james_w: not this week, I'm afraid, but I've got it in my inbox (it's nto relevant for intrepid anyway)
[15:15] <pitti> seb128: sure
[15:16] <james_w> pitti: it's not relevant for Intrepid?
[15:16] <fta2> seb128, diff.gz or debdiff ?
[15:16] <pitti> mpt: well, if you say that the current wording is fine, I'm all for it :)
[15:16] <pitti> james_w: we are way beyond FF, and today is beta freeze...
[15:16] <seb128> fta2: whatever
[15:17] <mpt> pitti, that's not what I'm saying
[15:17] <james_w> pitti: yeah, but my analysis suggests that users aren't offered suspend in GNOME in Intrepid.
[15:17] <mpt> pitti, the problem seems to be that sometimes drivers don't appear in the window, and I'd like to know why that is
[15:17] <pitti> seb128: maybe you can give me a quick intro about how f-spot is called now, in the new gnome world? (my knowledge got stuck with g-v-m)
[15:18] <pitti> james_w: oh? I use it every day
[15:18] <seb128> pitti: nautilus does the hotplugging nowadays, see the nautilus preferences tab which list the actions
[15:18] <james_w> pitti: I'l dig a bit more
[15:18] <seb128> pitti: it relies on special mimetypes
[15:18] <pitti> mpt: "sometimes" -> different days on the same machine, or for different users? it will only show drivers which actually work on your machine
[15:18] <pitti> seb128: there are .desktop files which connect the mimetype to an app, and which have the arguments in their Exec=, something like that?
[15:19] <seb128> pitti: f-spot-import.desktop for example has MimeType=x-content/image-dcf;x-content/image-picturecd
[15:19] <seb128> pitti: image-dcf is the one used for cameras I think
[15:19] <mpt> pitti, quoting the forum thread, "no card ever shows on harware drivers window!!!!!!!!!!!"
[15:20] <pitti> mpt: well, "cards" aren't supposed to show up there :) it's a "driver" list, not a "hardware" list
[15:20] <seb128> pitti: right, that's similar to normal mimetype associations, the .desktop claim mimetype, nautilus lists all the desktop which claim the concerned mimetype and the default can be specific in the defaults.list
[15:20] <pitti> seb128: ah, and %u means what?
[15:20] <mpt> pitti, am I correct in assuming that all graphic cards require a driver?
[15:21] <pitti> mpt: that's true, but many work with the ones which we already ship, so you don't see any in jockey on those systems
[15:21] <pitti> mpt: like intel, many ATIs, and older ones such as S3, via, etc.
[15:21] <pitti> same with printer drivers, you only see a driver if there is one which doesn't get installed by default
[15:22] <seb128> pitti: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
[15:22] <seb128> pitti: %u is one url
[15:22] <mpt> pitti, so is it true that {all available drivers} = {drivers we ship} + {drivers that appear in the Hardware Drivers window}?
[15:22] <pitti> mpt: by and large yes
[15:22] <seb128> pitti: if you change to %f it'll accepted filename, it nautilus will give the fuse mount path rather than a gphoto uri
[15:22] <seb128> s/it/ie
[15:23] <pitti> seb128: ah, I see; but %f would break for people which aren't in fuse
[15:23] <seb128> right
[15:23] <pitti> seb128: ah, I remember that discussion; I think once we discussed whether %u should get the %f value if fuse is used
[15:23] <mpt> pitti, I don't think there's any name we could use that would explain that.
[15:23] <pitti> but that might be too general
[15:23] <seb128> pitti: the easier might be to do what we did in hardy again, disable the gvfs gphoto automounting
[15:24] <seb128> pitti: right, but that has sideeffects, it'll break "recently open" for example since there is no automount when accessing the fuse path but there is if you try to access the gvfs url
[15:24] <pitti> mpt: "Third-party device drivers"?
[15:24] <seb128> pitti: ie, smb:://server/filename works but .gvfs/server/filename will not after a session restart
[15:24] <pitti> seb128: exactly
[15:25] <wst> mpt: Somebody just put an idea on brainstorm today regarding that: http://brainstorm.ubuntu.com/idea/13644/
[15:25] <mpt> pitti, but we ship some third-party drivers, right?
[15:25] <wst> "Hardware Driver Manager worth it's name "
[15:25] <mpt> i.e. the proprietary ones
[15:25] <pitti> mpt: we don't ship them on CDs, but I think we have them on the DVD
[15:26] <pitti> mpt: so we packaged them, but it's still nvidia's/ATI's driver
[15:26] <mpt> wst, yeah, I agree
[15:27] <didrocks> seb128: hi again, if you want to give me some more work for this evening, you're really welcome. I will ask to vuntz who is just next to me :) (FYI, swfdec0.8 is still in debian NEW)
[15:27]  * vuntz slaps didrocks in real life
[15:28] <pitti> seb128: so to me, the "correct" solution would be to (1) use %f, and (2) ensure that fuse works for everyone on the local console, just like USB device access; or any better idea?
[15:28] <didrocks> ouch
[15:28] <seb128> pitti: either that, or teach f-spot to unmount the gvfs location before importing
[15:28] <pitti> seb128: that might actually fail, though, if the device is busy?
[15:29] <pitti> (well, that would be quite a corner case admittedly)
[15:29] <seb128> didrocks: intrepid will be frozen for beta today, I don't think there will be a lot of updates to do tonight
[15:29] <seb128> pitti: if the device is busy any other way will fail too
[15:29] <didrocks> seb128: yes, I know. it was just in case :)
[15:29] <pitti> seb128: reading files from the fuse fs should work?
[15:30] <seb128> pitti: gvfs gphoto only uses libgphoto and that will not allow concurrentiel access either
[15:30] <seb128> pitti: I didn't try to access the same camera twice using gvfs either, not sure if libgphoto will allow that
[15:30] <seb128> pitti: but that's really a corner case if you ask me
[15:30] <pitti> seb128: I mean, I can work with f-spot and at the same time copy files in nautilus
[15:31] <pitti> seb128: corner case> I agree
[15:31] <pitti> phone, brb
[15:31] <fta2> seb128, http://www.sofaraway.org/ubuntu/tmp/cairo_1.7.6-0ubuntu1.diff.gz http://www.sofaraway.org/ubuntu/tmp/cairo_1.7.6-0ubuntu1.dsc
[15:31] <seb128> fta2: thanks
[15:32] <seb128> pitti: I'm fine with using the fuse mount or unmount, just pick one ;-)
[15:32] <pitti> seb128: aesthetically I find the "reduce libgphoto to mass storage" solution much more elegant, TBH; and it also gets rid of that silly "use which device" dialog in f-spot
[15:33] <pitti> which shows some "usb:" and "usb:001:005" weirdness, and you never know which one is right
[15:33] <seb128> pitti: I know some people got scared by the 10 lines warning about "you are going to be added to the fuse group" before hardy and I'm wondering how many are not in this group
[15:34] <pitti> seb128: TBH, screw the group
[15:34] <seb128> pitti: ok, so let's use the fuse mount then
[15:34] <pitti> seb128: my current idea is to change /bin/fusermount from 4754 to 4755 and use hal to add ACLs to /dev/fuse
[15:35] <pitti> seb128: fusermount can then bail out if the user doesn't have access to the device
[15:35] <pitti> so that fuse permissions entirely depend on /dev/fuse, and not that silly fusermount binary
[15:35] <seb128> ok
[15:38] <Hobbsee> mmm, new shiny backgrounds fro gnome
[15:38] <Hobbsee> makes it look like kde.
[15:44] <pitti> seb128: oh, crap, it's actually more complicated
[15:44] <pitti> seb128: I just tried that with an user which isn't in 'fuse'
[15:44] <pitti> seb128: nautilus actually uses gvfs/gphoto direclty, not the fuse mountpoint
[15:45] <seb128> pitti: you will get no fuse mount and it'll not open anything
[15:45] <pitti> seb128: so I still get the conflict for that user
[15:45] <pitti> seb128: right, I won't get a fuse mount, but I will get a nautilus window, and f-spot
[15:45] <pitti> seb128: wel, ignore me, I might just be confused about how things work
[15:45] <pitti> let me poke some more, and ignore me for now
[15:46] <seb128> pitti: what did you do? just plugged the camera? the default action should be to ask what you want to do
[15:46] <pitti> yes, it did that
[15:47] <seb128> and what did you pick?
[15:47] <pitti> f-spot
[15:47] <pitti> seb128: anyway, I changed it to %f in /usr/share/applications/f-spot-import.desktop
[15:48] <pitti> but f-spot still asks me for the usb device and gets the access error
[15:48] <pitti> do I need to run some magic update-mime-types-cache script or so?
[15:48] <pitti> or restart my session?
[15:50] <pitti> seb128: ^
[15:50] <seb128> pitti: does f-spot-import .gvfs/blablabla does the same?
[15:51] <seb128> pitti: it seems that f-spot-import doesn't like being given a directory
[15:51] <pitti> seb128: yes, it does
[15:51] <pitti> and neither --help
[15:51] <seb128> pitti: try using f-spot --import .gvfs/blabla
[15:51] <pitti> ah, it's a shell script, /me reads
[15:52] <pitti> ah, silly one
[15:52] <pitti> I wonder why it does it that way; a mere [ -d "$1" ] is certainly sufficient?
[15:52] <pitti> f-spot --import .gvfs/gphoto2-Medium\ auf\ usb%3A005\,008/
[15:53] <pitti> doesn't work either, bwah
[15:55] <pitti> seb128: hm, I can't get it to work with a dir path
[15:58] <seb128> pitti: I think there is a bug about that, but I though that was working when using f-spot --import rather than f-spot-import
[15:59] <pitti> james_w: oh, do you mean that the fusa applet just offers "suspend" and not "hibernate"?
[15:59] <pitti> james_w: that's a bug indeed; I am just used to the system menu thing (or the power button)
[16:00] <james_w> pitti: no, fusa offers neither, gnome-session offers hibernate and not suspend, and asking g-p-m says you can't suspend when asked over dbus
[16:00] <james_w> and hal reports that the computer can't suspend
[16:00] <james_w> though I haven't rebooted in to the latest updates yet, so fusa may change
[16:01] <seb128> james_w: ted knows about this issue
[16:01] <pitti> james_w: hm, for me g-p-m offers both, and fusa just offers suspend
[16:02] <james_w> pitti: do you have uswsusp installed?
[16:02] <seb128> pitti: arg, bug #260242, apport compatibility breakage! ;-)
[16:02] <pitti> seb128: ok, so I successfully tested it now, I'll change fuse to not require that fuse group any more for local consoles
[16:02] <seb128> "apport-gtk: error: no such option: --package synaptic --pid <pid>"
[16:02] <pitti> uh?
[16:02] <pitti> seb128: willfixsorrykthx
[16:03] <seb128> pitti: or tell me what to change in launchpad integration
[16:03] <pitti> seb128: it's *meant* to still work
[16:04] <pitti> I didn't deliberately break the command line, I probably just accidentally broke it when adding the convenience short forms
[16:04] <seb128> ok
[16:04] <pitti> seb128: so shall I go ahead with the un-fuse-groupification?
[16:04] <james_w> could that be a quoting issue?
[16:05] <james_w> apport "--package synaptic --pid <pid>" instead of apport "--package" "synaptic" "--pid" "<pid>"?
[16:05] <seb128> pitti: I've no objection but I might not be the best person to ask an opinion about this fuse group and why it's there
[16:05] <pitti> seb128: no, I didn't mean that (I'm pretty convinced about that part)
[16:05] <seb128> pitti: oh, so yes
[16:05] <pitti> seb128: I meant it in the sense of "will it make sense at this point, i. e. will we change f-spot to use the fuse mount point"
[16:06] <seb128> yes  I agree on that
[16:06] <pitti> great
[16:06]  * pitti hugs seb128
[16:06]  * seb128 hugs pitti
[16:07] <seb128> ok, there is something wrong there
[16:07] <seb128> several time I close a tab in xchat-gnome accidentally today, something changed
[16:08] <seb128> james_w: yeah, seems to be a quoting issue, at least the command line interface works correctly
[16:09] <seb128> bah, and I dropped the backlog too
[16:10] <seb128> fta2: what was the url for the cairo update again?
[16:10] <seb128> or something who has the chan backlog for the arfternoon?
[16:10] <seb128> somebody
[16:14] <seb128> nobody?
 seb128, http://www.sofaraway.org/ubuntu/tmp/cairo_1.7.6-0ubuntu1.diff.gz http://www.sofaraway.org/ubuntu/tmp/cairo_1.7.6-0ubuntu1.dsc
[16:15] <seb128> james_w: thanks!
[16:47] <fta2> seb128, thanks for the upload
[16:47] <seb128> fta2: thank you for the update ;-)
[17:07] <seb128> didrocks: you can do http://download.gnome.org/sources/gnome-volume-manager/2.24/gnome-volume-manager-2.24.0.tar.gz if you want
[17:14] <seb128> pitti: could you have a look to bug #258421? do you think it's something we should push before beta?
[17:15] <pitti> seb128: I'd ask tkamppeter, it's his baby
[17:15] <pitti> if there's a working patch, sure
[17:15] <seb128> pitti: he attached the patch, I was just wondering if you are fine uploading that now or if you think it's late in the cycle for such change
[17:15] <pitti> it's an intrepid spec, so the more testing feedback we get, the better
[17:16] <seb128> pitti: the patch is simple and seems to make sense
[17:16] <pitti> oh, it's sitting there for a month, I wonder why he didn't prod us earlier *sigh*
[17:16] <pitti> seb128: yeah, I agree
[17:16] <seb128> pitti: he did ping me once on IRC but I was busy and he didn't subscribe the sponsor team either
[17:16] <seb128> pitti: ok, I'll upload that
[17:16] <pitti> seb128: did you give it a shallow test? if not, shall we test it now?
[17:16] <pitti> if it works for some example files, I'd upload it now
[17:17] <pitti> much better than post-beta
[17:17] <seb128> pitti: I've no configured printed I could try on
[17:17] <pitti> (just print to a file)
[17:17] <seb128> well, print to a file let you select the format so that will not makes a difference there
[17:17] <pitti> true
[17:17] <seb128> the patch change what is send to cups
[17:18] <pitti> I just wonder why the get_ppd_file was commented out
[17:18] <pitti> was that solely to detect the supported PS version?
[17:18] <pitti> if so, it's obvious that it can go
[17:18] <seb128> pitti: the chunk of code commented was to set ps options
[17:18] <seb128> yes
[17:19] <pitti> let's give it a try
[17:19] <pitti> I'll test it tomorrow
[17:19] <pitti> and if it's broken, we just revert it
[17:19] <pitti> (need to save some time, have a bunch of things to do for beta, too)
[17:19] <pitti> seb128: "cowboy approach"
[17:19] <seb128> pitti: give it a try in the "let's upload and revert if required" sense?
[17:20] <pitti> seb128: we have the corresponding change in KDE for a while, and nobody said OMGkittens!
[17:20] <seb128> alright
[17:20] <seb128> and that's only printing
[17:20] <pitti> paperless office FTW!
[17:20] <seb128> that will not break sessions
[17:20] <pitti> (nowadays I'm actually much more concerned about scanning working :) )
[17:21] <pitti> seb128: oh, evince doesn't use gtkprint?
[17:21] <pitti> (Till says that firefox and evince would need another patch)
[17:22] <seb128> pitti: it does, not sure why he wrote that
[17:22] <mvo> mpt: could you please review http://paste.ubuntu.com/50546/ ? its the message I want to show when the user has the "fglrx" (ati) driver installed and wants to go from hardy to intrepid. the fglrx driver does not work on intrepid
[17:23] <mpt> mvo, you're burying the lede :-)
[17:23] <pitti> mvo: you made a typo in "FR33 S0FTW4R3 RUL3Z!"
[17:23] <mpt> The most important stuff is the last sentence
[17:23] <mpt> The first two sentences are the explanation
[17:24] <mvo> mpt: fortunately wikipedia has a explaination what this means :)
[17:25] <mpt> mvo, does this alert appear only if anyone on the system has desktop effects turned on?
[17:26] <mvo> mpt: that is difficult to detect currently and desktop effects is one of the regressions people may see, another one would be games or 3d apps
[17:26] <mvo> but the desktop effects are certainly the biggest one
[17:26] <mpt> ok, that's useful info, thank you
[17:26] <seb128> pitti: gtk uploaded, let's wait for user comments
[17:26] <mpt> mvo, next question: Why does fglrx no longer work?
[17:26] <pitti> mvo: hm, I thought that at least radeonhd supported compiz and 3d, too?
[17:27] <NCommander> seb128, good morning
[17:27] <pitti> mpt: amd doesn't manage to provide a driver which works with the current X.org version
[17:27] <mvo> pitti: ati does support it to some extend (r500, bits of r600) - but its far from complete for the r600
[17:27] <seb128> NCommander: hello
[17:27] <NCommander> how goes it this morning seb128
[17:27] <mvo> pitti: randeonhd didn't have any 3d accelleration last I looked (~3 months ago granted)
[17:27] <NCommander> or afternoon, or :-)
[17:27] <seb128> NCommander: I'm having a really busy week but otherwise good, you?
[17:27] <mvo> pitti: it is pretty amazing, but radeon (without the hd) seem to be much faster developing
[17:28] <pitti> mvo: oh, I read bug reports which said not to propose fglrx automatically, since radeonhd worked fine with compiz and the like
[17:28] <NCommander> seb128, debating on applying for MOTUship
[17:28] <mvo> pitti: http://www.x.org/wiki/RadeonFeature
[17:28] <mvo> pitti: intressting, I will try radeonhd again
[17:28] <pitti> mvo: well, ICBW, might be radeon without hd as well
[17:28] <seb128> NCommander: I though you said after intrepid?
[17:28] <pitti> mvo: it was "free driver"
[17:28] <mvo> right
[17:29] <mpt> pitti, so why didn't you say that in the message to begin with? :-) "... because AMD has not supplied an up-to-date driver"
[17:29] <mvo> but I think for r700 there is no support at all for 3d currently and for parts of the r600 too. but the x guys will know better
[17:29] <NCommander> seb128, intrepid is almost gone, need to get my affairs in order ;-)
[17:29] <mvo> it works very well (radeon) with my r500
[17:29] <pitti> mpt: which message? the one mvo just wrote? I saw it the first time, too :)
[17:29] <mpt> sorry, mvo
[17:30] <mvo> mpt: ups, sorry
[17:30] <pitti> "We converted you to freedom, send kisses to ubuntu-devel@, have a nice day"
[17:30] <mvo> mpt: it didn't occured to me, it sounds to much like shifting the blame to someone else
[17:30] <mpt> Are we to blame?
[17:31] <mvo> no
[17:31]  * mpt continues rewriting
[17:31] <pitti> mvo: well, I wouldn't say "AMD suck", but maybe "The proprietary fglrx driver is unavailable for this Ubuntu version" maybe?
[17:31] <mvo> yes, that sounds better
[17:32] <seb128> Laney: hi
[17:32] <Laney> hi seb128
[17:33] <mvo> mpt: there is a old discussion in https://launchpad.net/bugs/189406 that I would like to have your opnion about. its not urgent, but it would be nice if you could have a look at it and comment at some point. its basicly about if update-manager should provide version number informaiton (from version to version) in the listview or not. it does not do that currently, but some users feel strongly that it should
[17:33] <seb128> Laney: going to sponsor your pidgin bug fix now
[17:33] <Laney> seb128: \o/
[17:33] <mpt> mvo, does this fglrx retirement happen only on a Hardy->Intrepid upgrade?
[17:33] <mvo> mpt: yes, only there
[17:33] <mpt> great
[17:34] <mvo> mpt: we may still want to be a bit generic becuase it might be displayed on guadelinex or someone else who base on us too
[17:34] <pedro_> seb128: is ekiga 3.0 going to be included in intrepid?
[17:34] <pitti> mvo, mpt: please keep in mind that this currently affects the two older nvidia drivers as well (71 and 96), and it might happen that we can't fix them in time
[17:34] <didrocks> seb128: ok. I get back home from PCL and work on it :)
[17:34] <seb128> pedro_: if somebody is wanting to do the update, I don't know the ekiga packaging and I'm too busy for that, maybe ask to lool, I think they were discussing some snapshot packages, etc
[17:35] <seb128> pedro_: that would be nice to have though
[17:35] <seb128> pedro_: why?
[17:35] <mvo> pitti: right, I have it in mind, but wanted to attack fglrx first
[17:35] <pedro_> seb128: alright, i was just looking to a wishlist bug about it, nothing in particular besides that
[17:35] <pedro_> seb128: thanks
[17:36] <pedro_> mvo: do you have any news regarding bug 219444 ? :-)
[17:36] <mvo> pedro_: it should be fixed, or at least I can not reproduce it anymore
[17:36] <lool> WARNING: Failed to parse default value `??????????? ?????? ;gtk-theme-selector.desktop,???????????? ??????????? ???;default-applications.desktop,??????????? ????;gnome-cups-manager.desktop]' for schema (/schemas/apps/control-center/cc_actions_list)
[17:36] <lool> blah
[17:37] <mvo> pedro_: do you still see it somewhere?
[17:37] <pedro_> mvo: ok i'm going to ask to the reporters for feedback, thanks
[17:37] <mpt> mvo, how's this? http://paste.ubuntu.com/50553/
[17:37] <pedro_> mvo: i haven't, just checking :-)
[17:38] <pitti> yay blame :)
[17:39] <lool> At least the cc.schema is valid XML and UTF-8 hmm
[17:40] <mvo> mpt: could we make it a bit more in the spirit of pittis suggestion? something like "The driver "fglrx" by AMD is not avialable for this version for ubuntu" or something? - I'm not a native speaker but it does sound a bit unfriendly
[17:40] <seb128> lool: likely a translation
[17:40] <mvo> (I'm not a native speaker so I could be wrong about the wording)
[17:40] <mvo> (eh, the tone I mean)
[17:40] <mpt> "we converted you to freedom"?
[17:40] <pitti> mvo: well, admittedly my initial proposal made *us* look bad (sorry, we failed to provide it)
[17:41] <mvo> hm, right
[17:41] <mpt> oh,  "The proprietary fglrx driver is unavailable for this Ubuntu version"
[17:41] <seb128> lool: btw since you are around, is anybody working on the ekiga ubuntu package? would be nice to have ekiga3 in intrepid, I know you were trying snapshot, would that be something we can upload to intrepid?
[17:42] <lool> seb128: I think it's a translation as well, but didn't find what the actual problem is
[17:43] <seb128> lool: could have been in the previous version
[17:43] <seb128> lool: since it unregister the previous one and then register the new version
[17:43] <lool> seb128: Concerning ekiga, my tests gave awful results, but many things were changed that were worthwhile
[17:44] <lool> seb128: However the UI freeze is problematic for the new ekiga, we should talk to doc team before pushing it
[17:44] <mpt> mvo, <http://paste.ubuntu.com/50556/>?
[17:44] <lool> seb128: The long discussion which started after my test report basically concluded that most of the bugs I saw were fixed in tip, and hence now 3.0
[17:44] <lool> and a couple ones I mentionned were fixed later on
[17:45] <mvo> mpt: thanks, I like that
[17:45] <lool> seb128: dpkg-reconfigure capplets-data gives me the error again
[17:45] <mpt> mvo, ok, looking at 189406 now
[17:45] <lool> (twice now)
[17:45] <seb128> lool: well, it's GNOME and has a standing exception
[17:45] <mvo> mpt: I can provide you with screenshots if you need them
[17:45] <mvo> thanks again mpt!
[17:46] <pitti> mvo: I like http://paste.ubuntu.com/50556/, thanks mpt
[17:46] <lool> seb128: Ok, didn't know we could skip the UI freeze; my understanding was that because of GNOME's freezes, we could push new GNOMEs in Ubuntu and that was compatible with our own freezes
[17:46] <lool> But in the case of ekiga, they might have honored the upstream freeze, but we didn't merge new upstreams with the new UI
[17:46] <lool> Anyway, yes it is worthwhile, and we should consider it, but I didn't actually retest it (I would like to but...)
[17:48] <NCommander> hey pitti
[17:48] <pitti> hi NCommander
[17:48] <NCommander> pitti, mind looking at a main-sru, that has three verifications?
[17:48] <pitti> NCommander: yes, tomorrow on my archive day
[17:49] <pitti> (beta freeze urgencies ATM, sorry)
[17:49] <mpt> mvo, wow, that's a bug report that could really benefit from the "Me Too" button
[17:49] <seb128> lool: right, wouldn't hurt to get an approval, or at least let the documentation team know about the change if we update
[17:49] <NCommander> ah
[17:49] <NCommander> Ok
[17:49] <NCommander> Did we enter beta freeze already?
[17:49] <seb128> lool: is there one of the upstream guys who is doing the snapshot and maybe would be wanting to maintain it directly in ubuntu?
[17:50] <mvo> mpt: ideed, this is why I wanted additional review. I personally think not having the version information is ok, but given how many people complain I'm reconsidering that
[17:51] <mpt> mvo, I don't think it matters much either way
[17:52] <mpt> so sure, go ahead and re-add it :-)
[17:52] <lool> seb128: Dunno, I know who's packaging the snapshots and had issues with the packaging itself which wasn't derived from the ubuntu one, but I don't know how competent he would be to update the debian/ubuntu packaging; I'd say he would likely be interested though
[17:52] <mpt> mvo, I do see a lot of waste with the words "From", "version", "to", and "Size" being repeated over and over
[17:52] <mvo> mpt: actually re-adding it is more effort at this point (because I need a exception for it etc)
[17:53] <mpt> That could be fixed by putting that information in columns
[17:53] <seb128> lool: ok thanks, could be interesting to try to bring it to motu or something ;-)
[17:54] <seb128> Laney: btw I was reading some of the bug you are working on, the testcase for stable bugfix updates is to make sure the update still works correctly
[17:54] <mpt> mvo, then it's up to you whether you think it's more or less important than other things you could do before the release
[17:55] <mvo> mpt: ok, thanks
[17:55] <mvo> mpt: there is plenty to do, I think I will make a compromise and add a gconf key for it so that the intressted people can just enable it easily
[17:56] <mpt> mvo, I don't understand. Just turning it on would require a freeze exception, but adding a gconf key would not?
[17:57] <mvo> mpt: changing it for everyone would break the UI freeze
[17:57] <mvo> mpt: changing it via gconf would not change the default UI, so its less problematic
[17:57] <mpt> huh, I didn't know UserInterfaceFreeze worked that way
[17:58] <mpt> You can do any crazy stuff you like, as long as it's not on by default? :-)
[17:58] <Laney> seb128: Oh? I thought sru verifiers had to test all of the supposed bugfixes. Is this not the caes?
[17:59] <seb128> Laney: that doesn't really apply to new versions
[17:59] <seb128> Laney: that's true when you fix a specific bug
[17:59] <Laney> Oh, I was just thinking of it as a special case of a bug fix upload which happens to come with a version number bump
[17:59] <seb128> Laney: when we trust upstream one a new version the test is to make sure there is no regression there
[17:59] <mvo> mpt: not quite, but you exaggerate a bit what I suggested, no ;) ?
[18:00] <Laney> seb128: Well in that case do you think I should ask for the SRU?
[18:01] <seb128> Laney: would be nice, murray who commented on the bug is upstream and was at uds to discuss the topic and we told him we would accept bug fixes updates when it makes sense
[18:02] <Laney> seb128: Excellent! I always knew there wouldn't be a problem with the SRU, just thought that we were blocked on test cases.
[18:02] <Laney> Thanks for your advice
[18:02] <seb128> you're welcome
[18:02] <crevette> hello
[18:02] <mpt> mvo, I have very little idea how long these things take. If adding a gconf key (which will be removed later) is quicker than requesting a freeze exception, then sure, go ahead.
[18:03] <seb128> lut crevette
[18:04] <crevette> salut seb128
[19:29] <didrocks> se
[19:37] <didrocks> pitti: has gnome-volume-manager been moved to universe for intrepid? (I saw that with rmadison)
[19:37] <pitti> didrocks: yes, we don't use it any more
[19:37] <didrocks> pitti: ok, so, I will change the Maintainer field for 2.24.0
[19:42] <didrocks> ok, bug #274515 ready :)
[20:06] <lool> james_w: acpid changes worked like a charm
[20:07] <lool> james_w: And sorry for pushing so late
[20:30] <james_w> lool: no problem for me, thanks for the upload
[21:27] <mvo> seb128: I just got bug-buddy on a epip crash, is that expected? or should I get apport instead?
[21:28] <seb128> mvo: that's a known bug
[21:28] <mvo> ok
[21:28]  * mvo is tired
[21:28]  * seb128 too
[21:28] <seb128> I should fix that before beta
[22:17] <huats> hey everyone
[22:17] <huats> seb128: are you around ?
[22:17] <seb128> re huats
[22:17] <huats> hello
[22:18] <huats> :)
[22:18] <huats> sorry I was in the train..
[22:18] <seb128> that's alright
[22:18] <huats> I have looked at gnome-build
[22:18] <seb128> intrepid is frozen for beta so there is no hurry
[22:18] <huats> ok
[22:19] <huats> I am wondering (but I might be wrong :)) if the debian update is not wrong
[22:19] <pochu> there's a problem with gdl & bug 274485
[22:19] <pochu> hmm, that title needs an update :)
[22:19] <huats> :)
[22:19] <huats> I'll have a look
[22:19] <huats> regarding gnome-build
[22:19] <huats> I am really surprised
[22:19] <pochu> huats: thanks
[22:20] <huats> pochu: no pb
[22:20] <seb128> huats: what?
[22:20] <huats> I have noticed that the DD have not change the lib numbr
[22:20] <huats> while upstream have change the LTVERSION
[22:21] <seb128> huats: that's the soname which counts there
[22:22] <huats> from 1:0:0 to 2:0:0 which means (according what I have understood) that the binary compatibility has been broken
[22:23] <seb128> right, they screwed it, great
[22:23] <seb128> huats: can you open a rc bug on gnome-build in debian saying the soname changes but the binary has not been renamed?
[22:23] <huats> seb128: if you want I have the right update here
[22:24] <huats> (well I think the right one)
[22:24] <huats> sure
[22:24] <huats> I'll do that now
[22:24] <huats> pochu: regarding the listen pb
[22:24] <seb128> huats: is anjuta still running using the current intrepid version?
[22:24] <huats> seb128: don't think
[22:24] <huats> I'll tell you that right now...
[22:25] <seb128> huats: we will need to update anjuta tomorrow, how is the update going?
[22:25] <huats> (I could not finish the build in the train, because of a lack of 1 package)
[22:25] <huats> seb128: almost finished...
[22:25] <seb128> ok good
[22:25] <huats> pochu: libgdl-gnome-1-0 does not exists anymore in the new upstream version
[22:25] <huats> they have removed that
[22:26] <huats> so the package either...
[22:26] <huats> seb128: the new anjuta requires the new gnome-build (in the configure)
[22:27] <seb128> that's ok, but better to have gnome-build correct first
[22:27] <huats> sure
[22:27] <huats> ...
[22:27] <huats> I am really sorry that I have found that pb, but on the other side I am to notice that I have understood it :)
[22:28] <seb128> nothing to be sorry about, but would be nice to open the bug on debian
[22:32] <huats> pochu: what do you want to do for gdl? (regarding the bug you mentioned) ?
[22:32] <pochu> huats: I don't know, I haven't investigated it yet
[22:32] <huats> pochu: ok
[22:32] <pochu> huats: would it be possible to get rid of those dependencies?
[22:33] <pochu> (of libgdl-gnome-1-0 dependencies)
[22:33] <huats> anjuta won't need it in the new version (the one to be uploaded tomorrow)
[22:34] <huats> pochu:  so it only remains python-gnome2-extras
[22:34] <huats> there is a need to investigate
[22:34] <huats> ...
[22:35] <huats> I'll have a look tomorrow (once I have finished anjuta) if you don't do it first, pochu
[22:35] <seb128> that's a trivial one
[22:35] <huats> ok
[22:36] <huats> seb128: I was sating that without giving a look at python-gnome2-extras
[22:36] <seb128> just rebuilding might be enough, let me try
[22:36] <huats> ok
[22:36] <pochu> It didn't
[22:36] <pochu> I tried it :-)
[22:36] <huats> :)
[22:36] <seb128> well just don't build the gdl option then, nothing use that anyway
[22:36] <pochu> brb
[22:37] <huats> seb128: it might be better if I provide a patch in the debian bug tracker....
[22:37] <seb128> huats: you can yes, doesn't stop us to patch the ubuntu package too
[22:37] <huats> of course
[22:48] <seb128> vuntz: there?
[22:49] <huats> seb128: I don't think
[22:50] <huats> he is still in Paris tonight
[22:50] <huats> and he have planned to met with soem friends...
[22:50] <huats> so not sure he'll be here
[22:50] <huats> ...
[22:51] <seb128> ok, I was asked in case
[22:51] <seb128> huats: <robster> seb128: oh, ouch. sorry about that. let me fix.
[22:51] <seb128> huats: debian maintainer about the gnome-build upload
[22:53] <huats> seb128: yep I know who robster is :)
[22:53] <huats> great !
[22:53] <huats> I have put the bug, and the fix
[22:54] <huats> (in the bug)
[22:54] <seb128> ok good
[22:58] <huats> seb128: I am sorry I have to go...
[22:58] <seb128> huats: that's alright, enough work for me for today anyway, see you tomorrow
[22:59] <huats> seb128: spending some time with my gf fter 3 days away...
[22:59] <huats> seb128: ok great
[22:59] <huats> tomorrow the anjuta update will be OK
[22:59] <huats> ...
[22:59] <huats> (I am building it right now)
[22:59] <huats> good night
[22:59] <huats> (and pochu too :))
[23:00] <seb128> huats: right, you should spent time with your gf and not packaging after some days away ;-)
[23:00] <huats> :)
[23:00] <seb128> huats: I'll refuse to sponsor any upload from you today ;-)
[23:00] <huats> (but I didn't want to miss the freeze )
[23:00] <seb128> have a nice end of evening
[23:00] <huats> thanks seb128
[23:00] <huats> you too
[23:00] <seb128> (you can freeze exceptions don't worry)
[23:00] <seb128> thanks
[23:01] <huats> (and there'll be nothing to sponsor from me tonight :))
[23:01] <huats> sure :)
[23:01] <huats> but anyway
[23:01] <huats> :)
[23:01] <seb128> bye
[23:01] <huats> bye
[23:02] <Ampelbein> seb128: what do you think about bug 204253 ? its about activating the cache notification icon by default. should i take the issue upstream or is this a change we could have in ubuntu?
[23:04] <seb128> Ampelbein: hum, could you mail the ubuntu-desktop list about that? I've to admit I don't see the point to have an icon sitting there the whole day, we want to avoid having a zillion useless icons as some other os do
[23:04] <seb128> Ampelbein: also you should reassign task, not close one as invalid to open a new one in such case
[23:04] <Ampelbein> ok, will do that, thanks.
[23:05] <seb128> Ampelbein: what you did means that the seahorse subscriber will get all the mails about the changes on this bug (somewhat a launchpad bug)
[23:05] <Ampelbein> oh. did not know that, thought if the task is invalid they would not get mail.
[23:07] <seb128> well there is no real point to list invalid task for all the packages which are not concerned ;-)
[23:07] <seb128> easier and cleaner to just change the component for the open task
[23:08] <seb128> anyway enough for me for today
[23:08]  * pochu didn't know nautilus had tabs support...
[23:08] <seb128> thanks for your work on those desktop bugs and updates ;-)
[23:08] <seb128> pochu: that's new in 2.24
[23:08] <seb128> 'night everybody, see you tomorrow