[00:00] <rickspencer3> but I can hit the highlights for you guys right now
[00:00] <rickspencer3> robert_ancell, TheMuso anything to add to the agenda?
[00:00] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-09-01
[00:00] <TheMuso> No
[00:00] <robert_ancell> no
[00:01] <rickspencer3> ok
[00:01] <rickspencer3> so there were no actions from last week, as last week just focused on FF revue
[00:01] <rickspencer3> ken added the partner update to the wiki
[00:01] <rickspencer3> so you can see that there
[00:01] <TheMuso> ok
[00:02] <rickspencer3> looks like the dekstopcouch fix is available
[00:02] <rickspencer3> also, I was pushing to have xsplash latest and greatest uploaded for tomorrow, but there's a bug holding that up
[00:02] <rickspencer3> so in terms of X
[00:03] <rickspencer3> robert_ancell, this is the 100% bug
[00:03] <robert_ancell> k
[00:03] <rickspencer3> it is believed to be fixed, and a patch added to the kernel today
[00:03] <rickspencer3> and also upstream in the kernel
[00:03] <rickspencer3> bryce believes this will resolve some other bugs as well
[00:04] <rickspencer3> bryce recommends proceeding with mesa 7.6
[00:04] <rickspencer3> TheMuso, we discussed pulseaudio as well
[00:04] <rickspencer3> last week, my audio went all to heck
[00:04] <TheMuso> rickspencer3: How so?
[00:04] <rickspencer3> this was bad news for me, as it seemed to be getting better and better
[00:05] <rickspencer3> TheMuso, it was crashing in a loop every 30 seconds or so
[00:05] <rickspencer3> did not work with Firefox
[00:05] <rickspencer3> pedro went through the bugs and did *not* see an increase in incoming reports last week
[00:05] <TheMuso> right
[00:05] <rickspencer3> furthermore, I did an dist-upgrade today, and audio works perfectly for me again
[00:05] <TheMuso> Maybe due to new packages from the PPA, that is if you tested them.
[00:06] <rickspencer3> TheMuso, nope
[00:06] <rickspencer3> just stock dist-upgrade
[00:06] <rickspencer3> which came with a new kernel
[00:06] <rickspencer3> so, who knows
[00:06] <TheMuso> ok
[00:06] <TheMuso> anyway users are reporting crasher bugs, and Daniel is updating the PPA with snapshots, and also looking into those crashes.
[00:07] <rickspencer3> TheMuso, is there an increase, do you think?
[00:07]  * TheMuso is really starting to get pissed off that he can't currently use pulse day to day, and hopes to resolve that in the next couple of weeks with speech and audio debugging.
[00:07] <rickspencer3> ah
[00:07] <TheMuso> No, I don't think so.
[00:07] <rickspencer3> ok, pedro mentioned that were some specific crashers
[00:07] <TheMuso> Yeah and I wouldn't be surprised if its to do with some CPU SSE optimization code that pulse now has in it.
[00:08] <TheMuso> I need to talk to Daniel, but I have half a mind to turn those off for now.
[00:09] <rickspencer3> TheMuso, we should do that in an organized manner .. to work with users to specifically test if that fixes their crashes
[00:09] <TheMuso> Right.
[00:10] <rickspencer3> ok
[00:10] <rickspencer3> so Kubuntu has some good stuff to report
[00:10] <rickspencer3> I'd have to scroll up to get it, though
[00:10] <rickspencer3> most importantly, note that the Kubuntu netbook version is getting quite mature
[00:10] <rickspencer3> if you have a netbook, please test it out
[00:11] <rickspencer3> finally, note that our burn down chart is looking quite good
[00:11] <TheMuso> If KDE had deacent accessibility, I'd check it out anyway. :)
[00:11] <rickspencer3> we are close to the trend line, and perhaps asac will set some items to "DONE"
[00:11] <rickspencer3> TheMuso, ok
[00:11] <rickspencer3> even 4.3 is not accessible?
[00:12] <TheMuso> No
[00:12] <rickspencer3> :(
[00:12] <rickspencer3> this concerns me greatly
[00:12] <TheMuso> Still requires at-spi/dbus integration from KDE side.
[00:12] <rickspencer3> oh my
[00:12] <TheMuso> It will be a good 12 months at least.
[00:13] <rickspencer3> mm
[00:13] <rickspencer3> ok, so that was the meeting in a nutshell
[00:13] <TheMuso> Can't do much about it at a distro level atm
[00:13] <TheMuso> ok cool
[00:13] <rickspencer3> robert_ancell, TheMuso any questions, thoughts?
[00:14] <TheMuso> no, other than what I mentioned re pulse.
[00:14] <robert_ancell> bring on the release :)
[00:14] <rickspencer3> TheMuso, ok
[00:14] <rickspencer3> robert_ancell, it'll be here before you know it
[00:14] <rickspencer3> alpha 5 should be built tomorrow
[00:14] <TheMuso> Damn right.
[00:14] <rickspencer3> then UI freeze is just next week
[00:15] <rickspencer3> ok guys
[00:15] <rickspencer3> I need to go take a call, then another call :)
[00:15] <rickspencer3> I'll strive to get the meeting documented on the wiki tonight, but no promises ;)
[00:16] <rickspencer3> ya' know where to find me
[00:16]  * bryce waves
[00:16] <TheMuso> yep
[00:16]  * TheMuso has plenty more debugging to do. :)
[00:40]  * Amaranth can't wait for the 0.8.3 compiz snapshots to get uploaded to karmic
[00:40] <Amaranth> the 3 bugs marked as High against compiz are all fixed by it
[00:53] <rickspencer3> Amaranth, sweet
[00:56] <james_w> has anyone else seen a hang while running "xulrunner-1.9.1 --gre-version"?
[00:56] <james_w> in xulrunner's postinst
[01:03] <james_w> reproducible in my build chroot
[01:05] <Amaranth> so, based on these meeting notes, is it safe to say pitti is a machine and/or does not sleep? :)
[01:05] <james_w> too late to debug now though
[01:05] <Amaranth> james_w: doesn't hang here and I've not seen it do so during upgrades
[01:09] <rickspencer3> Amaranth, yes, pitti worked about 14 hours a day last week, for each day!
[01:14] <statik> hey james_w, I haven't seen that hang myself, though I have seen hangs when the couchdb js driver links against the wrong version of xulrunner
[06:46] <didrocks> good morning o/
[07:10] <pitti> Good morning
[07:10] <pitti> statik: good morning
[07:11] <pitti> statik: seems the merge was done, the proposal is closed
[07:11] <pitti> statik: I'll sponsor this
[07:11] <pitti> rickspencer3-afk, Amaranth: don't expect me to sustain that :)
[07:19] <pitti> statik: ah, james_w already sponsored
[07:28] <rugby471> mvo:  good morning
[07:33] <mvo> hey rugby471
[07:34] <rugby471> mvo: I will be away from 11:30 till 5, however after that I am sure I could do some work on software-store :-)
[07:37] <mvo> rugby471: cool, I will be there at 5pm :)
[07:38] <rugby471> hehe
[07:38] <rugby471> mvo: I am also doing a little bit of work making tuxpaint pretty
[07:38] <rugby471> it is a great little program
[07:39] <rugby471> but the butttons for it are very ugly :-(
[07:42] <rugby471> Laney: thanks for uploading the new f-spot :-)
[08:04] <lool> robert_ancell: You about?
[08:04] <robert_ancell> lool, yup
[08:04] <lool> robert_ancell: We're trying to get rid of brasero in UNR
[08:04] <lool> rhythmbox recommends it
[08:05] <lool> sorry rhythmbox depends on libbrasero-media0 which recommends it
[08:05] <robert_ancell> lool, ah, so it should be suggests then?
[08:05] <lool> StevenK and I were looking into either splitting the rhythmbox plugin out (/usr/lib/rhythmbox/plugins/cd-recorder/libcd-recorder.so) or dropping the dep
[08:05] <lool> robert_ancell: Yeah but I'm not sure
[08:05] <lool> robert_ancell: Does it break anything if you have rhythmbox without brasero?
[08:05] <lool> Should we rather split the plugin out?
[08:06] <lool> robert_ancell: Also there's a conflicts on nautilus-cd-burner in libbrasero which I dont quite understand
[08:06] <lool> It was added when brasero was made the default but I'm not sure it was needed
[08:07] <lool> robert_ancell: I checked in Debian and there's no recommends/conflicts there
[08:07] <robert_ancell> lool, I don't know for sure but I expect it can would be OK.
[08:07] <lool> robert_ancell: Ok
[08:07] <robert_ancell> seb128 will know it better than I do
[08:07] <lool> robert_ancell: What's with sound-juicer?  Should we ensure it pulls brasero afterwards or is it ok if we allow installation without brasero?  (just libbrasero-media0 installed)
[08:07] <robert_ancell> I don't see why a library needs to recommend an application though - that doesn't seem to make sense
[08:08] <lool> robert_ancell: ok will check with seb128 thanks
[08:08] <lool> Joss added a conflict on n-c-b too, but on the brasero package which makes more sense to me
[08:22] <seb128> hello there
[08:22] <pitti> hey seb128, bonjour!
[08:22] <seb128> hey pitti
[08:22] <seb128> guten tag!
[08:24] <rugby471> seb128: thanks for uploading the new f-spot, just fixed two papercuts :-)
[08:24] <seb128> rugby471, you're welcome, good
[08:27] <lool> Hey seb128, would love to grab you once you've processed your morning pings   :)
[08:27] <lool> I'd like to discuss the libbrasero-media0 recommends on brasero
[08:28] <seb128> I don't think I ever touched that package and I've no strong opinion about that
[08:28] <seb128> ie feel free to change it to suggests or drop it
[08:28] <lool> seb128: Ok there are two ways to change it
[08:28] <lool> seb128: Currently one RB plugin links to libbraseromedia and sound-juicer too
[08:29] <seb128> which means those applications should recommends the software?
[08:29] <lool> I wonder whether brasero is really needed when you call into libbraseromedia or whether it's ok if it's not installed
[08:29] <seb128> I don't know that requires testing
[08:29] <lool> seb128: Exactly so either I split the RB out in a new package which desktop pulls but not unr
[08:29] <seb128> I guess upstream didn't consider the case where distro where splitting the binaries
[08:29] <lool> Or I just make brasero a suggests
[08:29] <seb128> ie it's likely listing the feature if built with the lib
[08:30] <seb128> I would do a suggests
[08:30] <seb128> and rely on ubuntu-desktop installing it
[08:30] <lool> Ok; the reason I ask is mostly for sound-juicer since it's not seeded I wanted to make sure it pulls proper deps
[08:31] <lool> seb128: Is it ok to push brasero nowish?  (freeze etc.)
[08:31] <seb128> ask slangasek I would say ;-)
[08:31] <lool> Eh ok  :)
[08:32] <seb128> I expect it will be better to wait after freeze if that's not something you need on alpha builds
[08:32] <lool> I'll check whether we're oversize
[08:33] <lool> No it's ok
[08:44] <lool> seb128: on f-spot:   * debian/control, debian/rules: - use a gnome-screensaver build-depends rather than a rules workaround
[08:44] <lool> seb128: Is there a way I could help avoid this bdep?
[08:45] <lool> (gnome-screensaver is a bit heavy to pull here and a build just failed because it wasnt installable; I'd love to avoid the bdep if that's possible)
[08:50] <lool> Hmm it seems f-spot isnt in git for Ubuntu
[08:53] <seb128> lool, no, it's in sync usually I don't bother creating a vcs for a fake sync
[08:54] <lool> I think update-maintainer should strip Vcs stuff
[08:54] <seb128> lool, yes, you can undo the build depends on add the rules hack which is in debian back
[08:54] <seb128> and build-conflicts on gnome-screensaver
[08:54] <seb128> or work on a proper configure patch to have a configure option
[08:55] <lool> that's what I had in mind
[08:55] <seb128> it's just that it uses gnome-screensaver.pc right now to get the dir
[08:55] <rugby471> lool: I am surprised brasero has been on UNR for this long, since I haven't seen a netbook with a DVD/RW drive yet :-)
[08:55] <lool> seb128: so the issue is libexec verus lib?
[08:55] <lool> rugby471: Some people run UNR on laptops though
[08:55] <lool> rugby471: And you might have an USB burner
[08:55] <seb128> the issue is to know where gnome-screensaver is installed
[08:56] <lool> But my opinion was overruled a long time ago on keeping brasero  :)
[08:56] <rugby471> lool: oh really? I didn't realise it was that popular on non-netbooks..
[08:56] <lool> seb128: Ok
[08:56] <seb128> the easiest way is to use gnome-screensaver.pc for that
[08:56] <rugby471> lool: anyway I'll let you continue :-)
[08:56] <pitti> I'm off for some two hours for some errands
[08:56] <seb128> pitti, see you!
[08:57] <lool> seb128: there's a --with-gnome-screensaver=PREFIX though
[08:57] <seb128> lool, oh, it's possible, I didn't look at that, the build broke there because the debian hack was moving things from libexec to lib but it was already in lib there
[08:58] <lool> Ok
[08:58] <lool> I'll pbuild this stuff and see if it changes the contents
[08:58] <seb128> the reason is that the debian hack assumed that the wrong dir was used because it didn't build-depends on gnome-screensaver
[08:58] <seb128> I'm fine using the configure flag too
[08:58] <lool> Yeah will prepare a debdiff doing that for after A5
[08:58] <seb128> lool, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544204 for the record
[09:00] <lool> thanks
[09:08] <Laney> it's only a build-depends isn't it?
[09:09] <lool> It's a heavy one
[09:11] <Laney> you mean it takes a long time on the buildds?
[09:11] <lool> It increases the risk that the build-deps break the build and is more painful to build too
[09:12] <lool> inter apps build-deps are just causing trouble, they raise the requirements a lot
[09:12] <lool> It makes the build-deps graph much heavier than pure libs bdeps
[09:13] <mac_v> rugby471: are the bugs really fixed! did you check?
[09:13] <Laney> alright I don't really mind
[09:13] <Laney> but if you want to sort out a patch
[09:14] <lool> Laney: I started looking into it because f-spot failed to build on armel due to g-s being uninstallable; it raised my eyebrows that g-s was used as a bdep
[09:14] <lool> Laney: Oh sure
[09:14] <rugby471> mac_v: yup, the f-spot ones are
[09:14] <lool> Laney: I'm still updating my pbuilder right now to give it a try
[09:14] <Laney> ok
[09:14] <mac_v> rugby471: the app icons? i dont see it fixed
[09:14] <Laney> you can apply it straight in git
[09:14] <seb128> mvo, hey
[09:14] <Laney> if you have access
[09:15] <rugby471> mac_v: the app icons?
[09:15] <seb128> mvo, do you think we could try to filter bug #423024 out
[09:15] <seb128> mvo, the "corrupted filesystem tarfile - corrupted package archive" ones are usually not packages errrors
[09:15] <seb128> errors
[09:15] <mac_v> rugby471: yes , the icons dont show up for the first context menu item.
[09:16] <lool> Laney: You want a patch against Debian's git or against the Ubuntu package?
[09:16] <Laney> Debian please
[09:16] <lool> k
[09:16] <Laney> we havent uploaded it there yet
[09:16] <rugby471> mac_v: ah that one, I was going through the paper cuts this morning and launchpad said it has been fixed in the package so I simply marked it fixed in the papercuts project
[09:16] <Laney> can you put it on the bug report?
[09:16] <lool> Yeha I saw it was the last commit and tagged pending
[09:17] <lool> Laney: sure
[09:17] <Laney> thanks
[09:17] <rugby471> mac_v: this may have something to do with gnome not allowing icons in buttons/menu items etc.
[09:17] <mac_v> rugby471: pls dont do that! , check and then change :(
[09:17] <rugby471> sorry :-(
[09:18] <rugby471> mac_v: if it hasn't been fixed, then it should have been unmarked in the package
[09:18] <rugby471> mac_v: I was simply copying over that status to the parcuts project, however next time I shall test :-)
[09:19] <mac_v> rugby471: ;)
[09:25] <mac_v> rugby471: are you on karmic?
[09:26] <rugby471> mac_v: nope but I have a karmic virtual machine
[09:27] <mac_v> rugby471: could you check this on the VM? the first option does not show the icon... or maybe it is a bug in my etup
[09:27] <mac_v> setup*
[09:27] <rugby471> mac_v: sure
[09:31] <rugby471> mac_v: when you say the first option, could you do a screenshot?
[09:32] <mac_v> rugby471: you can take a screenshot of a context menu in an install ;)
[09:32] <mac_v> in vm you can ;p
[09:32] <rugby471> fine :-)
[09:33] <mvo> seb128: let me have a look (sorry, busy, busy, busy with app-center)
[09:33] <seb128> mvo, no problem ;-)
[09:33] <mac_v> rugby471: first option i mean the > Open with APPNAME ,the default option which opens the item on double click, above the separator
[09:35] <rugby471> mac_v: http://imagebin.org/62106
[09:36] <rugby471> yup I think the first application not having an icon is becuase of the gnome thing
[09:36] <mac_v> so its not fixed properly!
[09:37] <rugby471> mac_v: about the ~/Downloads papercut I appreciate what you are saying, however the original papercut was to fix the downloads location, that has been fixed, that is why I closed the bug. I think it is best to consult with David Siegel
[09:37] <rugby471> mac_v: yup it is a regression
[09:37] <rugby471> mac_v: wait what is the bug number of the menu item one?
[09:38] <mac_v> rugby471: i'm part of the papercuts team ;p
[09:38] <seb128> what are the discussions about there?
[09:38] <rugby471> yup but I was talking to him and he mentioned about bugs like that, where we need to fix the original request and then mark as fixed
[09:38] <seb128> seems you guy list several issues in one bug
[09:38] <mac_v> seb128: > Bug #387796
[09:38] <seb128> that leads to such issues
[09:39] <seb128> mac_v, that bug is fixed
[09:39] <mac_v> seb128: i got confused, wait
[09:39] <rugby471> seb128: the first issue, about XDG Downloads needing to be mapped to ~/Downloads is done
[09:39] <rugby471> seb128: the concern is now, that the Downloads directory needs ot be bookmarked in gnome
[09:40] <seb128> "bookmarked"?
[09:40] <rugby471> however that pushes the bookmarks in the Gnome panel menu into a seperate menu
[09:40] <rugby471> (XDG bookmarks in the nautilus sidebar)
[09:40] <rugby471> so there are really 3 issues
[09:40] <rugby471> XDG Downloads needs to be ~/Downloads - done
[09:41] <rugby471> should ~/Downloads be bookmarked?
[09:41] <seb128> bookmarked in the gtk sense?
[09:41] <seb128> ie added to .gtk-bookmarks?
[09:41] <rugby471> the gnome-panel bookmarks list limit needs to be bumped up/other bookmarks such as Ubuntu One need to be deleted
[09:42] <rugby471> yup
[09:42] <rugby471> seb128: sorry not xdg, gtk bookmarks :-)
[09:42] <mac_v> rugby471: seb128: when a bug get filed , the OP does not realize the seideffects of what he is proposing , so the bug affects other projects also , hence it spans over 2/3 projects
[09:43] <rugby471> yup
[09:43] <seb128> mac_v, that's fine so you should have 2-3 taks
[09:43] <seb128> tasks
[09:43] <rugby471> however the bug is crowded with three seperate discussins
[09:43] <rugby471> yup
[09:43] <mac_v> seb128: pitti had the panel bookmark bug assined it to you
[09:43] <mac_v> assigned
[09:44] <seb128> mac_v, well I did sponsor the xdg-user-dirs change to make Download be the desktop by default
[09:44] <seb128> which was what the bug was about
[09:44] <mac_v> If the downloads are simply sent to the downloads folder , this makes it harder ,than earlier, to access the downoads. , hence needs a bookmark
[09:44] <mac_v> downloads*
[09:45] <seb128> mac_v, well, step 1 would be to a have clear bug summaries
[09:45] <rugby471> seb128: you guys are both correct, mac_v is concerned about a regression becuase of the original bug however seb128 is correct in that they should be filed as seperate bugs
[09:45] <chrisccoulson> rugby471 - i was going to work on a change for the places menu that dynamically adjusted the maximum number of items based on vertical screen size, and only collapsed the least used entries in to a submenu when there are too many items, but i never got round to starting it :(
[09:45] <mac_v> seb128: i agree , on the summaries part :)
[09:45] <chrisccoulson> (i assume that's what you were talking about)
[09:46] <seb128> mac_v, the summary says
[09:46] <seb128> "This folder should be the default download location for firefox and this folder should be bookmarked in nautilus by xdg-user-dirs-gtk (like Music,Videos,Pictures and Documents)."
[09:46] <rugby471> chrisccoulson: yup, that sounds cool, however if you don't get round to it don't worry, we can just do an arbitary limit
[09:46] <seb128> and it's the default now
[09:46] <seb128> and in the xdg folders list
[09:47] <mac_v> seb128: the OP did not realize the sideffects of what he is proposing , so should th summary be changed?
[09:47] <chrisccoulson> rugby471 - yeah, it would be nice to get round to doing it but i don't have much time at the moment. i should book some more time off work to work on it really ;)
[09:47] <seb128> mac_v, I would expect your teams to figure that sort of things and set a clear summary of changes required before setting it as hundredpapercut to fix for us
[09:47] <rugby471> chrisccoulson: not enough time, that is always the problem :-)
[09:47] <seb128> mac_v, I would expect your teams to figure that sort of things and set a clear summary of changes required before setting it as hundredpapercut to fix for us otherwise you get such issues
[09:47] <mac_v> seb128: actually we were discussing about the bug status *only* in papercuts , not the xdg
[09:48] <seb128> mac_v, ok, I will stay away from this discussion then ;-)
[09:48] <rugby471> seb128: hehe
[09:48] <seb128> mac_v, but for the record I would have closed it too because what the summary requires has been changed
[09:48] <mac_v> seb128: you are true. about the goals :)
[09:49] <rugby471> seb128: what is the status on the icons in buttons etc. in gnome in ubuntu?
[09:49] <chrisccoulson> seb128 - any ideas what we can do about bug 422568? the original issue reported by c_korn was due to version skew between gnome-panel and gnome-panel-data, but it seems like there is a real issue after upgrading too
[09:49] <rugby471> seb128: some papercuts have been fixed but then regressed becuase of this, are we going to have icons or not?
[09:49] <seb128> rugby471, we changed that as GNOME did a month ago to not display icons by default
[09:49] <rugby471> ok
[09:49] <mac_v> seb128: > Bug #387796 the nautilus app icon bug has a side effect , the first option[the default choice ] is not showing an icon
[09:49] <rugby471> seb128: so what do we do with those bugs?
[09:49] <rugby471> mark them won't fix?
[09:50] <seb128> mac_v, that's a new bug, open a nautilus bug about this
[09:50] <mac_v> seb128: oh ok
[09:50] <rugby471> kl
[09:50] <seb128> rugby471, that's still an user setting, the bugs are still true for those enabling icons no?
[09:50] <rugby471> sorry I don't know
[09:50] <rugby471> for example
[09:50] <rugby471> there was papaercut saying that the close icon in firefox looked weird
[09:51] <rugby471> it was fixed
[09:51] <rugby471> but then the icons thing form gnome came in
[09:51] <rugby471> so what do we do with the bug becuase now there is no icon
[09:52] <rugby471> form > from, becuase > because
[09:53] <mac_v> seb128: the xdg bug , shouldnt the ~/Downloads be listed in the side pane?
[09:53] <mac_v> or is it just creation of a ~/Downloads folder?
[09:53] <seb128> I need to check
[09:53] <seb128> bookmarks are only created on the first login
[09:53] <seb128> ie need to try with a stock user
[09:54] <seb128> they are not going to change for users who customized their settings
[09:54] <seb128> because there is no way to know if the user deleted the bookmark or never got it
[09:54] <mac_v> oh! , then again a separate bug!
[09:54] <seb128> and you don't want to keep adding a bookmark the user deleted
[09:54] <rugby471> hehe
[09:54] <seb128> no, a feature
[09:55] <mac_v> the ~/Downloads wont be show for users upgrading :(
[09:55] <mac_v> shown*
[09:55] <rugby471> mac_v: yup that is how we have to do it
[09:55] <rugby471> mac_v: same with the f-spot XDG_PICTURE_DIR/Photos bug
[09:56] <mac_v> how do we fix it? a single bug for both?
[09:56] <rugby471> otherwise you get loads of breakages/annoyance from users that have ahd their settings changed
[09:56] <mac_v> seb128: cant it be done like the indicator applet? only add folders on first run?
[09:56] <seb128> mac_v, I would say it's not really a bug
[09:56] <rugby471> anyway I need to do some work after that discussion :-)
[09:56] <seb128> mac_v, I guess we could try something like that
[09:57] <seb128> I'm not a big fan to keep adding such wrapper to the session
[09:57] <seb128> for one thing we have no way to drop it
[09:57] <seb128> so this code has to run at every login until end of time
[09:57] <seb128> just to check that there is nothing to do and exit
[09:57] <seb128> but still it's an useless application listed in the startup list
[09:57] <seb128> it takes login time
[09:57] <seb128> etc
[09:57] <mac_v> oh :( , cant it be removed? after first run?
[09:58] <seb128> we could probably figure something
[09:58] <seb128> but you keep asking for thing we don't do now
[09:58] <seb128> and everybody is already overworked
[09:58] <mac_v> hehe ;)
[09:58] <mac_v> rugby471|hmwork: wanna do that^?
[09:59] <seb128> I would rather us to try to address this issue for good as some point
[09:59] <seb128> it making the upgrade tool do such changes or something
[09:59] <mac_v> oh ok
[09:59] <seb128> it -> ie
[09:59] <rugby471|hmwork> hehe I'll let someone else :-)
[10:00] <mac_v> seb128: upgrade tool would be nice
[10:00] <mac_v> :)
[10:00] <seb128> mac_v, we have some hundred thousand items of would be nice things to do ;-)
[10:00] <mac_v> true ;)
[10:02] <seb128> didrocks, hey
[10:02] <seb128> didrocks, did you start on the gobject-introspection update?
[10:02] <didrocks> hey seb128
[10:02] <didrocks> seb128: yes, it should be ok this evening
[10:02] <rugby471|hmwork> didrocks: great session yesterday, I didn't realise it was e
[10:02] <rugby471|hmwork> easier to update a package that I though
[10:02] <rugby471|hmwork> t
[10:02] <didrocks> rugby471|hmwork: thanks :)
[10:03]  * rugby471|hmwork "Stupid enter key.."
[10:03] <seb128> didrocks, hum ok
[10:03] <seb128> I have to find something else to do then
[10:03] <seb128> I started on upgrading gnome-shell but it's blocked on that
[10:03] <seb128> didrocks, how was your udw session yesterday?
[10:03] <didrocks> seb128: sorry to remove your work :)
[10:03] <seb128> heh
[10:04] <didrocks> seb128: great thanks, a lot of questions and interested people :)
[10:04] <seb128> didrocks, it doesn't remove my work, it blocks my work, that's different ;-)
[10:04] <seb128> ie I want to update gnome-shell but I need the new gobject first
[10:04] <seb128> nice
[10:04] <debfx> seb128: what symbols did I wrongly add to the libpurple symbols file?
[10:05] <didrocks> seb128: if you want, I can finish the job now, but not sure that I can test it extensively before this evening
[10:05] <seb128> debfx, let me look again, but wc -l says about 300 of those
[10:05] <seb128> didrocks, who cares about testing? ;-)
[10:05] <seb128> nothing uses it out of gnome-shell and I will test it there
[10:05] <debfx> seb128: compared to what?
[10:06] <seb128> debfx, compared to 2.6.1-2 from debian
[10:06] <didrocks> seb128: ok, I'll finish during lunch so :-)
[10:06] <debfx> that's because ubuntu also includes the libgnt symbols
[10:08] <Laney> bah
[10:08] <Laney> LP no longer shows changelogs up front on package pages
[10:08] <seb128> debfx, is there any reason why it does?
[10:08] <seb128> Laney, what do you mean?
[10:09] <Laney> I have to expand some stuff now to see changelogs
[10:09] <Laney> eg https://edge.launchpad.net/ubuntu/+source/f-spot
[10:09] <seb128> debfx, your .symbols has " g_hash_table_duplicate@Base 1:2.6.1" for example
[10:09] <seb128> debfx, and that's not a libpurple symbol
[10:10] <seb128> Laney, use "view full changelog" in the sidebar
[10:11] <Laney> right
[10:12] <debfx> seb128: g_hash_table_duplicate is a libgnt symbol http://developer.pidgin.im/doxygen/dev/html/gntutils_8h.html#1a59e8b19bfca4c11339aaa672adc256
[10:13] <seb128> debfx, right, not a libpurple one
[10:14] <seb128> debfx, I think we should follow debian and just list libpurple symbols there
[10:14] <debfx> seb128: yeah I'm not really sure why libgnt has been added to the libpurple symbols file
[10:14] <seb128> that's the same version than debian
[10:14] <seb128> let's just follow their lead and add the epoch
[10:15] <seb128> that should be good enough
[10:15] <seb128> do you want to do the change or should I do it?
[10:15] <seb128> otherwise your update is good to upload I think
[10:15] <seb128> good work!
[10:16] <debfx> i'll change it, thanks
[10:17] <debfx> the libgnt in libpurple symbols file change originally comes from debian (2.5.4-1)
[10:18] <debfx> looks like debian reverted it later, but ubuntu didn't
[10:18] <seb128> right
[10:18] <seb128> oh, you can also drop the replaces changes if you want btw
[10:18] <seb128> ie adding the epoch there
[10:18] <seb128> the version was before hardy
[10:18] <seb128> that would lower the delta a bit
[10:23] <debfx> seb128: ok, what do you think about the pidgin-encryption breakage?
[10:24] <seb128> debfx, that somebody should look at it but that it should not stop the pidgin upgrade for it
[10:29] <mat_t> seb128: hey
[10:29] <mat_t> seb128: is pitti around today?
[10:31] <seb128> mat_t, hello, yes but he ran away for some errand
[10:31] <seb128> mat_t, he should be back within an hour I think
[10:31] <mat_t> seb128: ok, thx!
[10:32] <seb128> you're welcome
[10:34] <didrocks> seb128: we still don't want to ship libgirepository-everything-1.0.so.1 (library for testing bindings for completeness)?
[10:35] <seb128> didrocks, what is debian doing?
[10:35] <seb128> didrocks, I would say sync on what debian is doing
[10:35] <didrocks> seb128: last time I checked, they didn't ship it, checking again now
[10:37] <didrocks> no, they still don't ship it. I'm looking now if we can sync
[10:37] <seb128> thanks
[10:41] <didrocks> seb128: we have additional conflicts/replaces (all "internals" to karmic cycle). What's the policy on that, do we drop it considering everyone has the former package version upgraded, do we want for the release to remove it, do we always keep this diff?
[10:42] <seb128> didrocks, we can drop those we only keep those for a few days in a unstable cycle usually
[10:42] <seb128> ie people tracking unstable version should update regularly
[10:42] <didrocks> ok, perfect so, I'll add for a sync request :)
[10:43] <seb128> don't bother
[10:43] <seb128> just tell me I can do the sync now
[10:43] <didrocks> seb128: final double checking :)
[10:44] <didrocks> (I just need to clarify one conflict)
[10:44] <mac_v> chrisccoulson: the dynamic panel bookmarks? will there be any chance of you working on it before karmic release?
[10:46] <didrocks> seb128: that's ok, you can sync :)
[10:46] <seb128> didrocks, gobject-introspection?
[10:47] <didrocks> seb128: yes, sorry, I was speaking about gobject-introspection
[10:47] <seb128> didrocks, thanks
[10:48] <chrisccoulson> mac_v - not sure yet. i would need to have a look at the existing code again to get a feel for how long it would take to do, but i can't guarantee that i would get it finished in time for karmic
[10:50] <mac_v> chrisccoulson: ok , if you are not able to fix it properly as you described? there is a papercut bug, it just needs the bookmarks limit to be raised. shall i assign the papercut bug to you, actually it also has a patch , just needs to be pushed
[10:50] <mac_v> ?
[10:51] <seb128> mac_v, I had the impression that the changes were still under discussion
[10:52] <mac_v> seb128: huh? discussion where?
[10:52] <seb128> about changing the limit
[10:52] <seb128> because it would create issues on small screens
[10:53] <mac_v> seb128: actually , the limit as described by Conn , doesnt seem to affect the netbooks.
[10:53] <lool> Laney, seb128: http://bugzilla.gnome.org/show_bug.cgi?id=593888
[10:53] <lool> Laney: I'm not sure you want to carry that in Debian in the mean time
[10:53] <chrisccoulson> mac_v - i don't mind, you can assign the papercut bug to me, and i will have a look at it. if i don't think i can finish it for karmic, then we could always go with the option of raising the limit
[10:54] <lool> Laney: (The existing --with-gnomescreensaver was only for the screensaver prefix but default to the libexec subdir so wasn't enough, hence these upstream patches)
[10:54] <mac_v> chrisccoulson: ok
[10:56] <Laney> lool: thanks for the work
[10:56] <Laney> I'll have a look and see if we want to apply or wait for the next release
[10:57] <rodrigo_> * notify-osd 0.9.19
[10:57] <rodrigo_>    * moved notifications to near the center on the right, this is not a bug.
[10:58] <rodrigo_> hmm, it looks weird to me though, will need to get used I guess
[10:58]  * Laney dislikes it
[10:58] <Laney> but I see that they put in a gconf key to configure it
[10:58] <rodrigo_> ah, cool
[10:59] <rodrigo_> where is that key?
[11:00] <rodrigo_> I guess /apps/notification-daemon/popup_location right?
[11:00] <Laney> dunno
[11:00] <rodrigo_> although it just says allowed values are: "top_left","top_right","bottom_left" and "bottom_right"
[11:01] <seb128> rodrigo_, upgrade, it has been changed again yesterday
[11:01] <rodrigo_> seb128: to top right again?
[11:01] <seb128> yes
[11:01] <rodrigo_> ah, ok
[11:01] <Laney> oh really
[11:01] <seb128> there is a gconf key now
[11:01] <Laney> what's the default?
[11:01] <seb128> default is the corner again
[11:01] <seb128> read changelog for the details
[11:01] <Laney> oh cool
[11:01] <rodrigo_> is it /apps/notification-daemon/popup_location ?
[11:02] <cdE|Woozy> https://launchpad.net/ubuntu/+source/notify-osd/0.9.20-0ubuntu1/+changelog
[11:05] <rodrigo_> ah, ok, because /apps/notification-daemon/popup_location had other allowed values, I guess I have that key from old notification-daemon
[11:06]  * rodrigo_ needs to clean up his $HOME one of these years :)
[11:07] <mac_v> rodrigo_: the gconf needs to be added
[11:07] <rodrigo_> mac_v: oh, it was not added? the changelog says so, right?
[11:07] <mac_v> only the *support* for the gconf has been added , so the gconf setting has  to be added manually
[11:08] <rodrigo_> ah, ok
[11:08] <rodrigo_> well, if it defaults to NorthEast, I'm ok :)
[11:09] <seb128> chrisccoulson, you said you would work on bug #419645?
[11:09] <seb128> chrisccoulson, should the bug be assigned to you?
[11:09] <chrisccoulson> seb128 - yeah, you can assign that to me too
[11:10] <seb128> thanks
[11:10] <chrisccoulson> sorry, i didn't get a chance to look at it last night
[11:10] <chrisccoulson> recovering from my first day bacm at work ;)
[11:11] <seb128> chrisccoulson, no problem we are frozen for alpha anyway
[11:36] <didrocks> seb128: gir-repository is in main as well, care to sponsor it?
[11:39] <seb128> didrocks, where is the update to sponsor?
[11:41] <didrocks> seb128: http://www.didrocks.fr/temp/gir-repository_0.6.4-0ubuntu1.dsc
[11:43] <seb128> didrocks, thanks
[11:43] <didrocks> seb128: thanks to you :)
[12:00] <maxb> Is this an appropriate channel to be on to discuss human-theme?
[12:01] <maxb> Specifically, to ask if there is any background info to the decision about changing menu_button to a simple circle?
[12:05] <pitti> mat_t: back now; sorry, took a little longer
[12:10] <asac> mvo: update manager said it has "installed all updated" and dpkg -i still says database is locked ... is that a bug?
[12:11] <mvo> asac: you have not closed the window yet? yeah, its a bug
[12:12] <asac> mvo: i have closed the window
[12:12] <asac> mvo: only thing on desktop related is the tray icon
[12:12] <mvo> asac: oh?
[12:12] <asac> and something is scratching my disk ... so maybe thats update-manager still doing something
[12:12] <mvo> asac: what does ps afx show?
[12:12] <asac> mvo: apt-check is still running
[12:12] <asac> mvo: now it finished
[12:12] <mvo> that sounds like the daily cron job for apt-get up
[12:13] <asac> took about 3 minutes after closing window
[12:13] <asac> hmm
[12:13] <mvo> 3min ? that is a long time
[12:13] <asac> mvo: maybe thats retriggered after upgrades got installed?
[12:13] <mvo> I assume this is a fast machine?
[12:13] <asac> not slow at least
[12:13] <asac> but apt/dpkg is pretty slow
[12:13] <asac> guess the database is too big or something
[12:13] <asac> i ran the cleanup commands you gave me once after berlin sprint
[12:14]  * mvo nods
[12:14] <chrisccoulson> seb128 - re bug 423058 - i'm not sure if DK-disks supports specifying a mount path anyway
[12:14] <asac> hmm
[12:14] <chrisccoulson> pitti might know for sure though
[12:14] <asac> mvo: so this upgrade left a bunch of stuff in unconfigured state too
[12:15] <mvo> asac: *wehhh*
[12:15] <mvo> asac: what?
[12:15] <mvo> asac: was it a normal upgrade? or a partial upgrade?
[12:15] <asac> http://paste.ubuntu.com/263708/
[12:15] <asac> mvo: i dont know. the new UI didnt tell me about partial upgrade or not
[12:16] <pitti> chrisccoulson, seb128: no, dk-disks doesn't allow arbitrary mount points
[12:16] <pitti> they are mostly useful for internal disks, and then fstab is more flexible
[12:16] <asac> mvo: i dont want to rule out that the iU stuff predates this update
[12:16] <chrisccoulson> pitti - thanks. is it likely too? or should that bug be WONTFIX against DK-disks?
[12:16] <asac> mvo: but it feels like it does because i was able to install stuff before using my favorite command line tools
[12:17] <asac> mvo: the tray thing is still there and seems to suggest that i should update now still
[12:17] <pitti> chrisccoulson: I don't know for sure, of course, but from what I understood of the approach, the systme should get simpler and more robust, and specifying mount points is a geek luxury problem which will probably not make it in
[12:17] <asac> mvo: you want anything before? should i just try that button?
[12:18] <chrisccoulson> pitti - thanks. i'll assign the bug to dk-disks for now, and chat with davidz when i get some time
[12:18] <pitti> chrisccoulson: especially since it's now quite easy to label your partitions
[12:18] <pitti> that's a better method than burying stuff in gconf keys IMHO
[12:18] <mvo> asac: hm, there is no new gui - do you have packagekit installed on accident?
[12:18] <mvo> asac: by accident I mean
[12:18] <asac> mvo: yes
[12:18] <asac> its there
[12:19] <asac> but i think i installed it intentionally at some point ;)
[12:19] <asac> to test it
[12:19] <mvo> asac: well, I guess this shows that its not that great ;)
[12:19] <asac> ii  packagekit                                    0.4.9+20090825-0ubuntu2                                        provides a software installation daemon
[12:19] <asac> ii  packagekit-backend-apt                        0.4.9+20090825-0ubuntu2                                        APT backend for packagekit
[12:19] <asac> ii  packagekit-gnome                              2.27.2-0ubuntu3                                                graphical distribution neutral software mana
[12:19] <mvo> asac: we don't do PK because it does not support debconf or any of this
[12:19] <mvo> asac: (intentionally)
[12:19] <asac> mvo: well. but why does it interfere
[12:19] <asac> i have it installed for ages
[12:20] <asac> like since hardy or intrepid or something i think ... never caused problems that i know of
[12:20] <mvo> oh? so this is the first time it did that?
[12:20] <asac> yes
[12:20] <asac> i dont use update-manager on daily basis
[12:20] <mvo> and the first time that you used the PK gui to upgrade?
[12:20] <asac> but try to do use it from time to time to catch issues
[12:20] <asac> mvo: PK gui?
[12:20] <asac> i use the tray thign ... which i thought was update-manager ;)
[12:21] <mvo> what you see is all packagekit, the gui of PK looks like a clone to u-m
[12:21] <asac> hmm
[12:21] <asac> its really update-applet
[12:21] <asac> e.g. packagekit
[12:21] <mvo> it installs itself as a tray icon (just like update-notifier)
[12:21]  * asac confused
[12:21] <mvo> etc
[12:21] <seb128> mvo, btw about the corruption bug, do you want an apt bug for that?
[12:21] <seb128> mvo, btw about the corruption bug, do you want an apt bug for that? to filter those out before sending
[12:21] <asac> mvo: ok so i guess that the gui was somewhat pulled in rfecently by some recommends promotion?
[12:21] <mvo> yeah, if you install packagekit-gnome then its all going to be confusing because the UI looks like a clone of our stuff
[12:22] <asac> hmm
[12:22] <asac> i actually dented that i liked the new update-manager ;)
[12:22] <mvo> asac: you can check in your dpkg.log or in /var/log/apt/term.log when it came to your system
[12:22] <mvo> seb128: please
[12:22] <asac> UI wise
[12:22] <seb128> mvo, apt is the right component?
[12:22] <asac> mvo: packagekit-gnome is nowhere in term.log
[12:22] <mvo> seb128: yes
[12:23] <asac> packagekit neither
[12:23] <asac> lets see if there are backup logs
[12:23] <mvo> asac: and not in the older term.* ?
[12:23] <mvo> asac: the only dependency on packagekit-gnome is paprefs (pulseaudio preferences)
[12:24] <seb128> mvo, thanks
[12:24] <asac> mvo: sudo zgrep packagekit-gnome /var/log/apt/term.log* | wc -l
[12:24] <asac> 0
[12:25] <asac> it didnt come recently
[12:25] <asac> odd
[12:25] <mvo> asac: same in dpkg.log ?
[12:25] <mvo> asac: indeed
[12:25] <asac> oldest term log is from april
[12:25] <mvo> seb128: sorry that I'm so busy, I hope to get software-store 0.2 out of the door today
[12:25] <asac> mvo: dpkg.log says it came on aug 31 ;)
[12:26] <asac> sudo zgrep packagekit-gnome /var/log/dpkg.log* | pastebinit
[12:26] <asac> http://paste.ubuntu.com/263714/
[12:26] <asac> so i magically installed it? not through apt?
[12:26] <asac> odd
[12:26] <seb128> mvo, oh no problem, you don't have to tell me about being busy ;-)
[12:26]  * seb128 hugs mvo
[12:26] <mvo> asac: is the something in /var/log/dist-upgrade about it?
[12:26] <asac> i only use apt-get or dpkg usually
[12:26] <asac> /var/log/dist-upgrade/apt.log:Installing packagekit-gnome as dep of paprefs
[12:26] <asac> yes
[12:26] <asac> so paprefs brought it
[12:27] <asac> why is it not in term.log?
[12:27] <mvo> thanks asac
[12:27] <mvo> asac: I have a look
[12:27] <asac> please fix it
[12:27] <asac> i would prefer to have one log ;)
[12:27] <asac> thanks
[12:27] <asac> so i remove packagekit now?
[12:27] <mvo> asac: yeah, I agree, there should be one central place that also logs what triggered installing of what
[12:28] <mvo> asac: yeah, remove it
[12:28] <asac> good by packagekit ;)
[12:29] <asac> mvo: paprefs and padevchooser ... why do those depend on it
[12:29] <asac> i think that should be fixed if possible
[12:32] <mvo> asac: paprefs tries to install stuff based on a filename, that is AFAIK not supported by the apt backend (and certainly not without aptfile installed)
[12:34] <seb128> hum, apturl doesn't install
[12:34] <mvo> seb128: what is the error?
[12:34] <seb128> mvo, btw apparently update-manager has still an id conflict when it needs to display the dist-upgrade dialog
[12:34] <mvo> seb128: hm, thanks. I have a look
[12:35] <seb128> mvo, I think it's on vbox2
[12:35] <seb128> mvo,
[12:35] <seb128> dpkg: error processing /var/cache/apt/archives/apturl_0.4.0ubuntu3_all.deb (--unpack):
[12:35] <seb128>  error creating directory `./usr/lib/python2.6/dist-packages/AptUrl/gtk': No such file or directory
[12:35] <mvo> TheMuso: why does paprefs have a packagekit-gnome dependency now? it seems to be using installprovidefiles, I don't think this work with the apt backend
[12:36] <mvo> seb128: *grumpf* I'm pretty sure that is python
[12:36] <c_korn> bug 422825
[12:36] <seb128> c_korn, thanks
[12:36] <seb128> waouh, impressive list of duplicates
[12:37] <c_korn> comment #8 has a fix
[12:37] <seb128> I guess it's failing for everybody
[12:37] <seb128> c_korn, that's not a fix but a workaround
[12:37] <c_korn> eh yes, meant that
[12:41] <seb128> mvo, bug #422665 is the update-manager issue
[12:41] <mvo> seb128: I have a look now, thanks
[12:42] <seb128> mvo, bug #420209 has a trivial patch you might want to consider too
[12:42] <mvo> seb128: thanks, doing that now
[12:42] <seb128> mvo, thanks a lot and sorry to keep you away from you daily app center goal ;-)
[13:09] <lool> Laney: Commits just went through on f-spot.git
[13:09] <lool> seb128: ^
[13:09] <seb128> thanks
[13:10] <lool> Laney, seb128: Could you please use --with-gnome-screensaver-privlibexecdir=/usr/lib/gnome-screensaver/gnome-screensaver and drop the bdep on next upstream release?
[13:10] <gnomefreak> pitti: is it intended that cupsddk-drivers will be removed?
[13:10] <lool> (this is awful  :)
[13:10] <seb128> Laney, ^ I will let you do the change in debian we will likely sync again after next upload
[13:10] <Ng> hey the dialog you get when you try to unmount a filesystem that has open files on it is kinda cute
[13:10] <Ng> but the "Unmount anyway" button doesn't seem to actually do what it claims
[13:11] <Amaranth> Always so picky :P
[13:13] <Ng> I was impressed that it figured out which terminal the bash process was in and showed the right app icon for it
[13:14] <pitti> gnomefreak: it's a transitional package, yes
[13:14] <gnomefreak> pitti: ok thanks
[13:15] <mac_v> pitti: regarding the gvfs not having a gui for setting the mount/unmount authorizations ? would that be an upstream bug?
[13:15] <pitti> mac_v: you mean policykit? yes, it wasn't ported yet
[13:16] <mac_v> oh oops , yeah policykit
[13:18] <mclasen> its not going to come back
[13:18] <mclasen> at least not in the same form
[13:19] <mac_v> mclasen: you mean mount will always require passwords ?
[13:19] <Amaranth> seb128: Did you get a chance to look at my merge requests?
[13:20] <mclasen> mac_v: no, I mean polkit-gnome-authorization will not come back
[13:21] <seb128> Amaranth, I looked quickly at the g-c-c one which seems ok but we are frozen for alpha
[13:21]  * mac_v hmm... reading man pklocalauthority
[13:21] <Amaranth> seb128: alright
[13:21] <Amaranth> seb128: although the main one I'm interested in is the gnome-panel one :)
[13:22] <seb128> Amaranth, I've not seen this one
[13:22] <Amaranth> seb128: it adds "scrollview over switcher changes viewports" support like how the switcher works with workspaces
[13:22]  * seb128 likes better using bug report than the merge request thingy
[13:23] <seb128> Amaranth, do you have a bug number corresponding to that?
[13:23] <Amaranth> hmm
[13:23] <seb128> I just don't think I got the email for that one
[13:23] <seb128> or a bzr url?
[13:24] <Amaranth> seb128: bzr branch lp:~amaranth/gnome-panel/scroll_with_viewports
[13:24] <seb128> Amaranth, thanks
[13:25] <seb128> Amaranth, is there an upstream bug about that?
[13:25] <Amaranth> the patch has been in upstream bugzilla for a year or so
[13:25] <seb128> Amaranth, would be nice to add the bug reference in such cases
[13:26] <seb128> in the changelog or as patch description directly
[13:26] <seb128> maybe we can nudge vuntz to review it ;-)
[13:27] <Amaranth> seb128: it's gnome bug 520779
[13:28] <Amaranth> I've tried nudging him off and on for a year :P
[13:28] <seb128> thanks
[13:28] <seb128> bug #520779
[13:28] <seb128> ups
[13:28] <seb128> bug #150443
[13:29] <Amaranth> hmm, wonder why I couldn't find that when I made up the branch
[13:30] <seb128> you can use bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/nnnnnn
[13:30] <seb128> it will give you the lp bugs which have a watch on nnnnnn
[13:31] <seb128> it's handy
[13:32] <debfx> seb128: I uploaded a new diff to the pidgin merge bug
[13:32] <seb128> debfx, I will look in a minute, thanks!
[13:58] <seb128> pitti, that's not because the stacktrace lands in some gtk function that the bug is a gtk one ;-)
[13:58] <seb128> not sure what to do about this apport crash bug, seems to happen at session closing
[13:58] <pitti> hard to say whether pygtk or gtk
[13:59] <pitti> but ISTR that there were quite a few duplicates in that icon loading function
[13:59] <seb128> pitti, or wrong gtk use in your software... ;-)
[13:59] <seb128> could be a ref counting issue
[13:59] <pitti> well, if a python statement causes a segfault instead of an exception, that would be a pygtk bug
[13:59] <seb128> or apport still trying to do thing where there is no display
[14:00] <seb128> that's arguable, I think pygtk upstream also said they don't want to convert some issues to exceptions
[14:01] <seb128> anyway I will just ignore the bug for now I think since I've no clue about the issue and there is no easy way to trigger the bug
[14:03] <pitti> seb128: what was the # again? I'll set it to incomplete then and ask for a reproduction recipe
[14:04] <pitti> but I had the feeling that we got a few of those icon loading crashes
[14:04] <seb128> pitti, don't bother
[14:05] <seb128> pitti, I went through the duplicate it seems to happen on logout, at least they get notification at next login
[14:06] <pitti> seb128: hm, I wonder whether we can detect the "currently shutting down session" situation and suppress crash reports
[14:06] <pitti> they are mostly useless anyway
[14:06] <seb128> quite some random bugs in that function
[14:06] <pitti> can you think of a way to tell?
[14:07] <seb128> pitti, clean /var/crash at login? ;-)
[14:07] <seb128> I'm half jocking
[14:07] <seb128> old crashes and logout crashes would be cleaned this way
[14:07] <seb128> otherwise we can compare .xsession-errors and crash timestamps I guess
[14:08] <seb128> or try to get logout time from some log
[14:08] <pitti> I'm actually serious, I guess a lot of crashes happen on logout
[14:08] <seb128> pitti, bug #204134 seems similar btw
[14:09] <pitti> I don't think that we can reliably detect it while the core dump happesn
[14:09] <seb128> pitti, right, would be nice to filter those out, the "clean at login" one might be a bit agressive though
[14:09] <pitti> but indeed it would be nice to clean up .crash files which were written during shutdown
[14:09] <pitti> seb128: also, we do want to get crashes of e. g. gnome-session which *cause* the session to terminate
[14:10] <seb128> right
[14:10] <pitti> hmmm
[14:10] <geser> is it normal that pkg-config also expects the .pc files listed in Require.private to be there when doing a pkg-config --exists?
[14:22] <kenvandine> hey rickspencer3
[14:22] <kenvandine> thanks for your branch :)
[14:22] <dobey> hey all
[14:22] <rickspencer3> hey KenEdwards
[14:22] <rickspencer3> oop kenvandine too :)
[14:23] <kenvandine> :)
[14:23] <dobey> pitti, seb128: how long do i have to get an update in for the alpha?
[14:23] <seb128> dobey, -1 day
[14:23] <pitti> dobey: about minus half a day, I think
[14:23] <dobey> :(
[14:24] <seb128> pitti, I'm wondering if the apport issue is similar to bug #86698
[14:24] <seb128> pitti, ie basically unset DISPLAY; apport-gtk -> crash
[14:24] <pitti> dobey: does it break the live system severely?
[14:24] <pitti> seb128: $ DISPLAY= /usr/share/apport/apport-gtk
[14:25] <pitti> seb128: that gives me lots of GtkWarnings, but no crash
[14:25] <seb128> pitti, well DISPLAY= /usr/share/apport/apport-gtk -c crash
[14:25] <dobey> pitti: does what break the live system severely?
[14:25] <pitti> dobey: the thing you want to fix
[14:25] <seb128> Program received signal SIGSEGV, Segmentation fault.
[14:25] <seb128> 0x010c8368 in render_icon_name_pixbuf (icon_set=0x84b2cd0, style=0x8ab0158,
[14:25] <seb128> bingo
[14:25] <pitti> seb128: indeed
[14:25] <pitti> confirmed here
[14:26] <pitti> seb128: so should each program do that on its own, or coudl it become a check/exit in pygtk or gtk itself?
[14:26] <pitti> I'm happy to add it to apport, but I figure that similar crashes will happen for other programs as well
[14:27] <c_korn> tedg: hello
[14:27] <tedg> c_korn: Morning!
[14:27] <seb128> tedg, hey, got your laptop back now? ;-)
[14:27] <tedg> c_korn: I have a bug number for you, just a sec.
[14:28] <tedg> seb128: No just gave up on posting to identi.ca using Gwibber :-/
[14:28] <seb128> pitti, see http://bugzilla.gnome.org/show_bug.cgi?id=411652
[14:28] <dobey> pitti: there's a branch about to land in the client which i want to get into alpha5, as it very likely fixes the issue that's causing us to have a metric infinium of duplicate reports currently
[14:28] <seb128> pitti, we did discuss it on IRC back then with upstream and I discussed it with mvo too I think
[14:28] <pitti> dobey: we can upload it in any case, of course
[14:28] <tedg> c_korn: bug 422025
[14:28] <seb128> pitti, upstream thinks it's up to applications to handle that correctly
[14:29] <pitti> dobey: if we need to re-roll the CDs for a critical flaw, then it'll get in, otherwise people just have to upgrade
[14:29] <dobey> pitti: ok
[14:29] <pitti> seb128: okay, noted
[14:31] <Laney> lool, seb128: Very good work, thanks to you both.
[14:31] <Laney> I might not be able to change anything until the weekend
[14:32] <c_korn> tedg: oh, I filed my bugs against the ubuntu version
[14:32] <c_korn> bug 421693 and bug 419472
[14:32] <c_korn> tedg: I have done some patching. you might want to review the debdiff
[14:33] <c_korn> I had to introduce the po/ directory and intltool.m4 .
[14:33] <tedg> c_korn: Could you use bzr and do it as a merge request?
[14:34] <tedg> c_korn: The trunk is lp:indicator-session.
[14:34] <tedg> Debdiffs aren't really useful, and they don't track credit either.
[14:35] <pitti> seb128: http://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/revision/1542
[14:35] <c_korn> so I propably have to merge the debdiff first to apply on the current trunk
[14:35] <bratsche> bryce around?
[14:35] <seb128> pitti, cool, thanks
[14:35] <seb128> pitti, I found http://live.gnome.org/PyGTK/WhatsNew210 too about that
[14:36] <tedg> bratsche: Probably a bit early.  He's on PST.
[14:36] <seb128> pitti, not sure if their way is better
[14:36] <bratsche> Oh yeah.  I'll check later. :)
[14:36] <seb128> pitti, ie it could be that display is still set but xorg closing or something?
[14:36] <pitti> seb128: right, it's not bulletproof
[14:36] <c_korn> unfortunately the lesson about using bazaar is on friday. so it will take me some time to read me in.
[14:36] <pitti> if X shuts down while the program is running, there's nothing we can do
[14:37] <pitti> seb128: right, I noticed the warning, but it doesn't cause a crash
[14:37] <tedg> c_korn: You should just be able to do: "bzr branch lp:indicator-session ; < do work > ; bzr commit ; bzr push lp:~c_korn/indicator-session/mywork"
[14:37] <pitti> seb128: while I'm at reducing assumptions on gtk, I may just as well do it all by myself :)
[14:37] <seb128> right
[14:38] <seb128> pitti, should I split the bug again?
[14:38] <seb128> or add an apport task?
[14:38] <pitti> seb128: or reassign it back to apport
[14:38] <c_korn> tedg: thanks. but I first have to switch to karmic due to: bzr: ERROR: exceptions.KeyError: 'Bazaar repository format 2a (needs bzr 1.16 or later)
[14:38] <tedg> c_korn: I'd be happier to help you with bazaar rather than trying to read a debdiff :)
[14:38] <pitti> seb128: which bug# was it again?
[14:38] <c_korn> tedg: :)
[14:38] <seb128> pitti, it's not only apport there, let me unsplit things
[14:38] <tedg> c_korn: Yes, sorry.  2a virus.  You can grab bazaar from their PPA.  They keep updated versions there.
[14:39] <pitti> seb128: right, please let me know, then I can link the LP number to the commit
[14:39] <tedg> c_korn: https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa
[14:40] <tedg> The Jaunty ones there are very old... looks like 48 minutes now :)
[14:40] <seb128> pitti, using bug #411276
[14:41] <c_korn> tedg: :) thanks. should I do something about the bug reports ? actually they are dups
[14:42] <tedg> c_korn: Sure.  I don't care which one gets dup'd which way.
[14:42] <tedg> c_korn: We should make sure the final ones have both a distro and an upstream task.
[14:45] <seb128> pitti, bug #204134 is the same issue for jockey
[14:45] <pitti> seb128: meh, that's what I meant with "shouldn't this check get into pygtk or gtk itself", but *shrug*, I'll add it there, too
[14:46] <pitti> seb128: thanks for fishing it out, committing fix
[14:46] <seb128> pitti, as said bug #86698 is the pygtk bug for that basically
[14:46] <seb128> pitti, but upstream was sort of bouncing it back on applications when we discussed it some time ago
[14:47] <seb128> bounced
[14:47] <seb128> I renamed the bug now for clarity
[14:49] <pitti> seb128: thanks; applied to jockey trunk
[14:49] <seb128> pitti, danke
[14:52] <kagou> hi seb128, I'v reported my bug (talk yesterday) at #423176
[14:52] <seb128> bug #423176
[14:52] <kagou> If you want more test I'm here for 1 hour
[14:53] <kagou> do you want a snif log ?
[14:53] <seb128> pitti, could bug #423160 be a media-player-id issue?
[14:53] <seb128> pitti, would you mind if I assign the bug to you?
[14:54] <seb128> doing so feel free to bounce back if that's not your bug
[14:54] <pitti> seb128: please assign to me, yes
[14:54] <pitti> I don't have an ipod, but I'll ask some triaging questions and have a look
[14:54] <seb128> done
[14:56] <seb128> pitti, in fact I get the issue there if you need details
[14:56] <pitti> seb128: ok, please subscribe then
[14:57] <seb128> pitti, I'm subscribed to rhythmbox will read comments
[14:58] <c_korn> tedg: there is no m4 directory on trunk. will it be added in the release ?
[15:02] <tedg> c_korn: I'm not 100% sure how that works.  If "make dist" builds it, then it will :)  Try a make dist.
[15:02] <dobey> 'make' doesn't build m4 directories
[15:02] <dobey> if anything it would be created by aclocal
[15:03] <dobey> generally because one adds the macro to tell it to do so, to configure.ac
[15:03] <c_korn> AC_CONFIG_MACRO_DIR([m4])
[15:04] <dobey> yes that
[15:04] <c_korn> so if I add a dependency on intltool in configure.ac the intltool.m4 should also be copied into the m4 directory
[15:04] <dobey> yes
[15:04] <dobey> when aclocal runs
[15:04] <dobey> well
[15:04] <dobey> depending on what you mean by dependency
[15:04] <dobey> if you add IT_PROG_INTLTOOL() to it
[15:09] <dobey> james_w: ni hao
[15:11] <james_w> hi dobey
[15:11] <dobey> james_w: i'm guessing at this point it's a bit too late to get poauth in to replace python-oauth?
[15:12] <james_w> not sure
[15:12] <james_w> I'm not on the release team
[15:13] <c_korn> dobey: yes, I meant that. thanks
[15:14] <dobey> james_w: well there's some work to the server api which needs to be done first i guess...
[15:15] <seb128> kagou, do you have a bugzilla account?
[15:15] <james_w> both oauth and poauth are incomplete for the server as I see it
[15:15] <james_w> they have similar code for the client
[15:15] <james_w> the client is all that is used
[15:16] <james_w> so what would switching buy us?
[15:16] <james_w> as the code will be frozen the responsiveness of upstream doesn't make a large practical difference
[15:17] <james_w> it should allow you to maintain fewer changes between branches of ubuntuone
[15:17] <james_w> but you said that you think those changes would only be import changes
[15:17] <dobey> 4 months to land a halfway broken "security fix" doesn't make a difference?
[15:17] <kagou> seb128, yes for gnome
[15:17] <seb128> kagou, want to open the bug upstream too?
[15:17] <kagou> if yu want ok
[15:18] <james_w> dobey: yes, but at this point I would be somewhat concerned about the poauth server code
[15:18] <kagou> i do that
[15:18] <james_w> dobey: it's not known-broken, but still
[15:18] <dobey> it's known broken
[15:18] <james_w> known-insecure I meant
[15:18] <seb128> kagou, it could also be useful to get a GVFS_SMB_DEBUG=1 gvfsd -r log
[15:18] <james_w> or is that the case as well?
[15:18] <seb128> kagou, or a higher number
[15:18] <seb128> kagou, that prints the libsmbclient debug logs
[15:19] <kagou> seb128, noted
[15:19] <dobey> james_w: well i guess that's currently the case, as i just realized it isn't validating the signatures (but i've a branch to do that)
[15:20] <james_w> umm, ok
[15:20] <seb128> kagou, thanks
[15:20] <kagou> your welcome
[15:21] <dobey> as i concentrated on the client bits for 0.1
[15:21] <c_korn> tedg: here it is: https://code.launchpad.net/~c-korn/indicator-session/mywork
[15:22] <james_w> dobey: the packaging is fine fwiw, so that's not an issue
[15:22] <tedg> c_korn: Cool, you didn't have to call it "mywork" that was just an example ;)
[15:22] <dobey> ok
[15:22] <james_w> dobey: we could get this in and transitions done in less than a day with release team approval
[15:22] <james_w> concerns with doing so
[15:22] <c_korn> oh, I apologize. didn't read carefully. can this be undone ?
[15:23] <james_w> are being out on our own with this code which carries some risk, shipping brand-new security-sensitive code
[15:24] <c_korn> tedg: better ? https://code.launchpad.net/~c-korn/indicator-session/gconf-key
[15:24] <james_w> dobey: what do you think about shipping just client code in karmic?
[15:25] <james_w> dobey: nothing uses the server code, we are under no obligation to ship server code just because it exists, there are fewer security worries, and the divergence in the fork is smaller
[15:25] <james_w> it would allow you to use one dependency for karmic and later in the client
[15:25] <james_w> just running a server on karmic would be harder
[15:26] <dobey> we could do that i guess
[15:27] <james_w> would it satisfy your needs?
[15:27] <debfx> could someone please unsubscribe ubuntu-main-sponsors from #310769 (package has been moved to universe)
[15:28] <debfx> bug #310769
[15:29] <dobey> james_w: not really. it satisfies the client needs, but not our server.
[15:29] <james_w> but why does that matter for what karmic ships with?
[15:30] <dobey> because maintaining patches to our own code in the packages is dumb.
[15:31] <james_w> what patch would be needed?
[15:31] <james_w> I still don't really know what all your requirements are
[15:31] <dobey> server is using the embedded ouath.py from ubuntuone-storage-protocol
[15:32] <james_w> once I do then we can fix this, I'm just bumping around in the dark at the moment
[15:32] <c_korn> brb, 24h disconnection
[15:32] <james_w> but you don't run your servers on karmic?
[15:33] <james_w> and you could have a local package of python-poauth that did ship the server code to run on your servers
[15:33] <dobey> let me finish doing this release of the client first
[15:33] <james_w> ok
[15:44] <kagou> seb128, done
[15:45] <seb128> kagou, thanks
[15:47] <seb128> kagou, do you have some time for debugging now?
[15:48] <kagou> errr no sorry. tomorrow
[15:48] <seb128> kagou, ok
[15:48] <seb128> kagou, would be interesting to see if /usr/lib/gvfs/gvfsd-network crashes
[15:48] <seb128> when you do gvfs-ls network:
[15:48] <kagou> yes with a dbus error i remember
[15:49] <seb128> well you get the error
[15:49] <seb128> would be interesting to see if that's the backend crashing
[15:49] <seb128> ie to run gdb /usr/lib/gvfs/gvfsd-network
[15:49] <kagou> noted
[15:49] <seb128> could be because it's crashing or because it's too slow
[15:49] <seb128> the debug log would be useful too
[15:49] <seb128> it would give infos on this ip you listed
[15:58] <tedg> c_korn: Sorry, I was on a call.  I was just joking about changing the name.
[15:58] <dobey> pitti: bug #423226
[15:58] <tedg> It doesn't really matter what the name is.
[15:59] <c_korn> ok :)
[15:59] <tedg> c_korn: I proposed it as a merge so that LP will generate the diff: https://code.edge.launchpad.net/~c-korn/indicator-session/gconf-key/+merge/11058
[15:59] <pitti> seb128: do you have a minute to sponsor the new ubuntuone-client? I just got pulled into another OMGalpha5 thing
[15:59] <pitti> dobey: thanks; cjwatson just said we're going to need a respin, so let's be fast
[15:59] <seb128> pitti, isn't karmic frozen for alpha right now?
[16:00] <pitti> seb128: well, soft freeze, as usual
[16:00] <pitti> seb128: this was said to fix an alpha-5 bug
[16:00] <seb128> pitti, well I got people complaining that I upload too much during those
[16:00] <seb128> ah ok
[16:00] <seb128> can do that ;-)
[16:00]  * pitti hugs seb128
[16:00]  * seb128 hugs pitti
[16:01] <dobey> it should fix a bug for which we've probably gotten > 100 dups for
[16:02] <dobey> so uh, yeah :)
[16:07] <tedg> c_korn: Okay, I forgot a command :)
[16:07] <seb128> dobey, pitti: uploaded
[16:07] <tedg> c_korn: You need to do a "bzr add" for the gconf_helper.[ch] files.  Then "bzr commit" and "bzr push" again.
[16:07] <tedg> c_korn: If you do a "bzr status" that will list the files as "unknown" which may mean they need to be added.
[16:08] <c_korn> tedg: ok, sorry. never used bzr before. but looks similar to git.
[16:09] <dobey> seb128: thanks!
[16:09] <c_korn> tedg: then "bzr commit; bzr push lp:~c_korn/indicator-session/gconf-key" ?
[16:10] <tedg> c_korn: You shouldn't need the path again, it should remember it (assuming that's the last place you pushed)
[16:11] <c_korn> damn it.
[16:12] <c_korn> tedg: sorry, I seem to mess up your code a bit :/ no this commit got pushed into the mywork branch.
[16:12] <c_korn> s/no/now/
[16:13] <tedg> c_korn: No worries, you can't mess up the code.  It just takes a touch of extra space on LP, but it only keeps the diffs so it's a trivial amount.
[16:14] <tedg> c_korn: Which branch name would you like to stick with?  We can mark the other as abandoned.
[16:15] <c_korn> gconf-key should be fine. but the mywork branch currently has my latest commit
[16:18] <tedg> c_korn: Okay, so I'll reject the merge request on gconf-key and generate one for mywork.
[16:19] <seb128> pitti, I've a one line change in nautilus to fix preference dialog crashing, can that be uploaded too?
[16:20] <pitti> seb128: sure; you can upload anything you like which doesn't break anything
[16:20] <pitti> so, no library transitions, major changes, etc.; bug fixes always welcome
[16:20] <seb128> pitti, well, I prefer to ask in case it would get in the way of cd respins
[16:20] <pitti> right, thanks
[16:20] <seb128> thanks
[16:46] <SiDi> Keybuk: hello, do you have a spare minute ?
[16:50] <Keybuk> I have several
[16:51] <SiDi> Okey, i wanted to ask you about the new boot process in karmic
[16:51] <SiDi> What role does GDM play, exactly ?
[16:51] <SiDi> And what happens if GDM isnt installed ? :)
[16:53] <seb128> SiDi, gdm is the login manager if you don't have it you get a text mode login
[16:53] <seb128> if you don't have another login manager installed
[16:54] <SiDi> seb128: the idea is to have another one, indeed :)
[16:54] <Keybuk> what other one do you have?
[16:54] <SiDi> but what i wanna know is when gdm is started, what role it takes in the new boot process, in order to understand what would happen if another was used
[16:54] <seb128> ?
[16:55] <seb128> the role is to let you type an username and password
[16:55] <SiDi> Keybuk: at the moment, gdm, but i want to get slim
[16:55] <seb128> so you can log in
[16:55] <SiDi> seb128: thats not what i meant :)
[16:55] <SiDi> if i understood well, gdm is started alongside all the gnome services in a gnome session, right ?
[16:55] <seb128> no
[16:56] <seb128> it's started by an init script
[16:56] <seb128> as any other system service
[16:56] <seb128> the new gdm itself is a gnome-session though
[16:56] <seb128> ie gdm starts gnome-session to render it's screen
[16:56]  * SiDi means the new gdm, not the old
[16:56] <seb128> yes
[16:57] <seb128> gdm is still started by an init script
[16:57] <SiDi> and then, when the user logins, the same session is used, right ?
[16:57] <seb128> gdm runs gnome-session though because the login screen is a custom session
[16:57] <seb128> no
[16:57] <Keybuk> SiDi: the same X server, different session
[16:57] <SiDi> Okey
[16:57] <seb128> the user session is started when you log in
[16:57] <seb128> which is different from the gdm session
[16:58] <seb128> gdm is only a login manager, you can use any other you want
[16:58] <SiDi> okey, so if i put kdm / slim instead, it will have no consequence on the rest of the boot ? (yeh, that question is very likely stupid :X))
[16:58] <seb128> the fact that it uses a gnome-session for it's banner is not revelant
[16:58] <seb128> no it will have no consequence
[16:58] <SiDi> okey, i thought it was using it as a way to load some gnome stuff before the user login
[16:59] <seb128> it might just break the xsplash effect
[16:59] <seb128> no
[16:59] <SiDi> What do you mean by xsplash effect ?
[16:59] <seb128> you know about xsplash?
[16:59] <SiDi> Would it entirely run usplash instead, or do you mean xsplash -> dm transition ?
[17:00] <seb128> gdm sends a signal to xsplash to say that loading is done
[17:00] <seb128> otherwise the splash would stay until timeout
[17:00] <SiDi> i see
[17:01] <SiDi> Thanks, seb128, Keybuk
[17:01] <seb128> you're welcome
[17:02] <mac_v> Keybuk: got a min for another doubt? :)
[17:02] <Keybuk> sure
[17:03]  * seb128 wonders why people don't just ask their question
[17:04] <mac_v> regarding > Bug #409784 , how to know about the number of udevs that a system hardware will use?
[17:04] <mac_v> seb128: just trying not to be rude i guess ;p
[17:05] <Keybuk> mac_v: err, you want to know how to figure out the maximum number?
[17:05] <Keybuk> is it that interesting?
[17:05] <mac_v> yeah ,max
[17:05] <seb128> mac_v, well if you ask the question you let the person who ask to decide what to do based on that, where in the other case you don't let a real choice which is ruder ;-)
[17:05] <Keybuk> mac_v: at least 128, plus a further client for every 8MB of memory on your system
[17:06] <Keybuk> so 384 if you have 2GB
[17:06] <Keybuk> 640 if you have 4GB
[17:06] <Keybuk> etc.
[17:06] <mac_v> Keybuk: hm... 128 , the people on ubuntu+1 all reported 3 or 4 , thats what made me file the bug ,
[17:06] <Keybuk> sure
[17:06] <mac_v> so it all depends on the memory
[17:07] <Keybuk> do you _still_ have 102 after a day or two of being online?
[17:07] <Keybuk> not so much
[17:07] <Keybuk> depends on how fast the kernel events arrive on boot
[17:07] <Keybuk> if they arrive quite slowly, or can be processed really quickly, you'll end up with fewer workers as they can be reused quicker
[17:07] <Keybuk> if they arrive quite quickly, or are processed relatively slowly, you'll end up with more workers
[17:08] <mac_v> oh...
[17:08] <Keybuk> send udevd SIGHUP
[17:08] <Keybuk> that cleans them up
[17:09] <Keybuk> but other than the task_struct cost, they're really not important
[17:10] <mac_v> thats good to know,
[17:10] <mac_v> right now i'm online for 13hrs and have 61
[17:10] <mac_v> so only if they are still many after 1/2 days i need to worry
[17:11] <mac_v> Keybuk: thanks , for the info :)
[17:12] <mac_v> seb128: actually he had invalidated the bug report , hence i asked him , else , you are right about the topic ;)
[17:13] <Keybuk> no, shouldn't have to worry at all
[17:13] <Keybuk> if they're still there after SIGHUP then worry ;)
[17:13] <Keybuk> if theyr'e still there after weeks or months, it's still not a worry
[17:14] <Keybuk> unusual perhaps, but just means your system changes a lot
[17:14]  * mac_v nods
[17:20] <baptistemm> is anyone able to set upstream link for gnome-bluetooth (https://edge.launchpad.net/ubuntu/karmic/+source/gnome-bluetooth/+edit-packaging)? I don't understand what to put.
[17:26] <Amaranth> baptistemm: yeah, you probably don't want to mess with that
[17:26] <Amaranth> baptistemm: when gnome-bluetooth actually gets a bug in launchpad and you want to link it upstream it gives a spot for a URL for the upstream bug report
[17:26] <Amaranth> it uses gnome bugzilla, right?
[17:29] <seb128> baptistemm, ask to jcastro
[17:30] <baptistemm> Amaranth: yep
[17:30] <baptistemm> seb128: okay thanks
[17:48] <bratsche> Keybuk around still?
[17:49] <Keybuk> yup
[17:50] <bratsche> Keybuk: Hey, so we would like to find some way to add UNR's launcher to the list of applications that xsplash should listen to... but obviously, only if UNR launcher exists.  And so far I don't have any good ideas for how to implement this.
[17:50] <bratsche> https://bugs.launchpad.net/xsplash/+bug/418716  is the bug
[17:50] <bratsche> Keybuk: Just wanted to see if you have any suggestions.
[17:51] <Keybuk> how do you listen so far?
[17:51] <bratsche> Right now xsplash is unfortunately hard-coded to know which signals to listen for.
[17:52] <bratsche> We could add a directory with files that it can read to see what signals to listen for, and then netbook-launcher, nautilus, and gnome-panel could just drop a file in there that says "listen for this signal"
[17:52] <Keybuk> that would work
[17:52] <bratsche> Okay, cool enough.  I'll add that then.
[17:53] <bratsche> Thanks.
[18:22] <pitti> Taekwondo o'clock, CU tomorrow!
[18:57] <awe> asac: no response from kwii
[19:17] <dobey> pitti: still around?
[19:28] <rugby471> dobey: he is at taekwondo it seems
[19:28] <dobey> sure
[19:29] <dobey> it is 20:30 there after all :)
[19:29]  * dobey was just hoping, as he might be able to answer a problem
[19:45] <didrocks> rugby471: do you know for what webkit is used in software-store?
[19:45] <rugby471> didrocks: yup
[19:45] <rugby471> didrocks: it is for the various views that we use
[19:45] <rugby471> didrocks: ie. the lobby view
[19:46] <rugby471> didrocks: ie. the application details view
[19:46] <didrocks> rugby471: it's still using gtk widget as container?
[19:46] <rugby471> I think mvo is planning to put all the view stuff in webkit
[19:46] <rugby471> didrocks: wait a min
[19:47] <rugby471> didrocks: https://wiki.ubuntu.com/SoftwareStore?action=AttachFile&do=get&target=main-window-structure.jpg
[19:47] <rugby471> the main pane is a webkitView widget
[19:47] <rugby471> the rest is gtk
[19:48] <didrocks> rugby471: ok, so, everything that is in the pane is made of webkit widgets
[19:48] <rugby471> yup
[19:48] <rugby471> webkit widgets> hmtl and css
[19:48] <didrocks> hum, no goot for using clutter :/
[19:48] <rugby471> nope
[19:48] <rugby471> however we can use javascript
[19:48] <rugby471> it makes it a lot easier to do these effects
[19:48] <rugby471> as you don't have to have compositing
[19:49] <didrocks> rugby471: you can't do the same effects than those you have in clutter
[19:49] <rugby471> didrocks: correct
[19:49] <rugby471> didrocks: however you can have effects like this:
[19:50] <rugby471> didrocks : http://hungred.com/wp-content/demo/jQuery-closing-opening-door-effect/demo.html
[19:50] <rugby471> didrocks: it also allows us the tweak the appearance a lot easier
[19:50] <didrocks> rugby471: that's nice, who will do that in software-store?
[19:51] <rugby471> well most of the webkit stuff is integrated
[19:51] <rugby471> the different HTML and css for the views is nearly done
[19:51] <rugby471> I created a lot fo it
[19:51] <rugby471> but mvo and mpt are also working on it
[19:52] <rugby471> mvo has gone from being the master of python to the student of javascript :-) (no offence mvo)
[19:52] <didrocks> ok, I'm quite disappointed as I worked hard with upstream to setup proper bindings…
[19:52] <rugby471> didrocks: : oh sorry :-(
[19:52] <didrocks> no pb, I will see what I can still do
[19:52] <rugby471> didrocks: you can talk with mpt/mvo  to see if there is anything else need with clutter
[19:53] <didrocks> rugby471: icons on top are still gtk icons?
[19:53] <rugby471> didrocks: on top?
[19:53] <didrocks> (in the pane)
[19:53] <rugby471> yup, the paths of the gtk icons are found by software-store and then put in the view in an img tag
[19:54] <didrocks> so, it's an html img, not a gtk icon?
[19:54] <rugby471> didrocks: trust me though, the move to html/css will make software-store rock even more :-)
[19:54] <rugby471> didrocks: pseudo code:
[19:54] <rugby471> in python we do icons.get_icon_path('category-games')
[19:55] <rugby471> and then substitue that into the hmtl:
[19:55] <rugby471> <img src="file:/$iconpath"
[19:55] <rugby471> so it is a html image, with the source from the gtk icon
[19:55] <didrocks> yes, that's what I feared :)
[19:55] <rugby471> (ie. $iconpath might be in this case /usr/share/icons/gnome/48x48/apps/gedit.png)
[19:55] <rugby471> ah?
[19:55] <rugby471> why is that?
[19:56] <didrocks> I had some ideas on effects on the icons
[19:56] <didrocks> but it's only feasable if the widget is a gtk one
[19:56] <dobey> what is it using to render the html?
[19:56] <rugby471> dobey: : webkit
[19:56] <dobey> oh
[19:56] <rugby471> didrocks: again I am sorry :-)
[19:56] <dobey> nevermind then :(
[19:56] <rugby471> dobey: what was it?
[19:57] <rugby471> you have me interested now :-)
[19:57] <dobey> well firefox has a special uri thing to load gtk+ icons from the theme
[19:57] <rugby471> ah yes
[19:57] <rugby471> dobey: however it is only the arbitary set of stock icons that they want
[19:58] <rugby471> I tried to do something similiar with songbird, but found that limitation :-)
[19:58] <dobey> i think that's changed now
[19:58] <dobey> (in 3.5)
[19:58] <rugby471> didrocks: I would still speak to mvo or mpt as I am sure there is still stuff you could do, hopefully not all your time will have been in vain :-)
[19:58] <rugby471> dobey: oh really? I would be interested to know
[19:59] <didrocks> rugby471: I will still make my ideas reals with a previous version not using webkit. Do you have any idea on the revision number before webkit switch?
[19:59] <rugby471> sure, give me a sec
[20:00] <rugby471> didrocks: before you do I would still talk to mpt & mvo though :-)
[20:00] <rugby471> didrocks: https://code.launchpad.net/~software-store-developers/software-store/trunk
[20:00] <didrocks> rugby471: nevermind, it's just to do some tests :)
[20:00] <rugby471> rev 157 - merge the webkit branch
[20:00] <rugby471> didrocks: oh okay :-)
[20:00] <didrocks> ok, taking 156 so :)
[20:00] <rugby471> yup
[20:28] <mvo> didrocks: yeah, testing trunk is great
[20:28] <mvo> didrocks: there is a TODO file that I keep up-to-date in the source :)
[20:29] <mvo> didrocks: bzr-buildpackage in trunk should work fine, if you find no issues, let me know and I upload tomorrow :)
[20:29] <mvo> I merged the webkit branch into trunk/ now (yeah!)
[20:42] <mac_v> aw , just missed mvo :(
[20:52] <rugby471> see ya
[22:32] <davmor2> pitti: the new empathy is missing irc account management yet telepathy-idle seems to be installed
[22:35] <davmor2> pitti: okay that's weird.  It's an option that is only missing from the new greeter account setup window
[23:52] <rickspencer3> hi robert_ancell
[23:52] <robert_ancell> rickspencer3, hi rick