[00:06] <Ampelbein> seb128: i guess the build errors i just got for seahorse-plugins come from the broken fontconfig you mentioned earlier? (http://launchpadlibrarian.net/23958748/buildlog_ubuntu-jaunty-i386.seahorse-plugins_2.26.0-0ubuntu1_FAILEDTOBUILD.txt.gz)
[00:07] <seb128> Ampelbein: yes
[00:07] <Ampelbein> ok.
[00:10] <Ampelbein> seb128: bug #343976 ready for review.
[00:11] <seb128> Ampelbein: thanks
[00:19] <Ampelbein> seb128: any more updates to do?
[00:20] <seb128> Ampelbein: http://download.gnome.org/sources/gnome-icon-theme/2.26/gnome-icon-theme-2.26.0.tar.gz
[00:21] <Ampelbein> ok
[00:25] <Laney> when are we supposed to hear about uds sponsorship?
[00:25] <seb128> not yet I guess
[00:25] <Laney> i thought it was today
[00:25] <seb128> lists had to be made for some days ago and are reviewed now I think
[00:26] <seb128> will be soon I guess
[00:26] <Laney> scary
[00:26] <seb128> what?
[00:27] <Laney> waiting to hear
[00:27] <seb128> ah ;-)
[00:27] <Laney> it's like seeing if you have what you want on christmas day
[00:27] <seb128> hehe
[00:28] <dobey> well i finally upgraded my laptop to jaunty today
[00:28] <dobey> and thankfully suspend/resume and wireless and 3d all still work
[00:42] <Ampelbein> seb128: bug #343996 ready for review.
[00:43] <seb128> thanks
[00:43] <seb128> Ampelbein: http://download.gnome.org/sources/vino/2.26/vino-2.26.0.tar.gz if you want an another one
[00:43] <Ampelbein> seb128: ok.
[00:52] <Ampelbein> seb128: just one simple question about bzr. is there an easy way to build from the bzr-branch with pbuilder? for now i always copy the debian-directory to a source directory and build there, but this seems quite complicated.
[00:55] <asac> Ampelbein: try bzr builddeb --merge --dont-purge ;)
[00:55] <jColl> Anyone know what's going on with Hardy updates size mismatches?
[00:55] <asac> bzr-builddeb package
[00:55] <asac> Ampelbein: you just need to place the tarball at appropriate place
[00:57] <huats> seb128: bug  344006
[00:57] <Ampelbein> asac: i tried that but then dpkg-checkbuilddeps complains that build-depends are not satisfied.
[00:57] <seb128> huats: thanks
[00:57] <huats> your welcome seb128
[00:58] <asac> Ampelbein: install the builddepends then
[00:58] <asac> Ampelbein: otherwise just build sources and then put the .dsc to pbuilder
[00:58] <asac> like bzr bd --merge --builder='debuild -S'
[00:59] <Ampelbein> asac: ah, ok. that's what i was looking for.
[00:59] <asac> something is really slow with my network
[00:59] <asac> bummer
[00:59] <Ampelbein> asac: did not want to install all the build-deps myself since that's what pbuilder is there for was i thinking. thanks for the help.
[01:07] <asac> Ampelbein: sudo apt-get build-dep package ;)
[01:08]  * Ampelbein is banging my head to the desk. so obvious... thanks again.
[01:10] <Ampelbein> seb128: bug #344000 ready for review.
[01:12] <seb128> Ampelbein: thanks
[01:14] <seb128> asac: your fontconfig fix worked apparently ;-)
[01:14] <asac> seb128: really?
[01:15] <asac> seb128: which build succeeded?
[01:15] <seb128> asac: https://edge.launchpad.net/ubuntu/+source/gnome-utils/2.26.0-0ubuntu1/+build/906982
[01:15] <asac> argh. is launchpad slow on your side too?
[01:15] <seb128> asac: no
[01:15] <seb128> but I'm using edge
[01:15] <asac> me too
[01:16] <asac> seems my provider thinks during night they can do maintenance or something
[01:16] <seb128> try to not use edge maybe then ;-)
[01:16] <asac> its really slow
[01:17] <asac> seb128: that did the trick i think
[01:17] <asac> amazing
[01:17] <asac> how can librarian be so much faster?
[01:18] <asac> that must be coincident
[01:18] <asac> so cool
[01:18] <seb128> asac: what did you change? non-edge?
[01:19] <asac> seb128: yeah
[01:19] <asac> now it rocks the boat
[01:20] <asac> seems i could continue to work all night now ;)
[01:22] <seb128> asac: if you don't break the buildds again ;-)
[01:22] <asac> haha
[01:23] <asac> i usually try not to do that
[01:24]  * seb128 build retry everything uploaded tonight
[01:27] <asac> seb128: now that gcc is off the amd builder stuff hopefully gets moving quickly
[01:28] <asac> but i386 is mostly yours now ;)
[01:28] <asac> damn ... the edge boost was temporary only
[01:34] <seb128> asac: amd64 still fail to build
[01:34] <seb128> asac: but not on the bug now
[01:34] <seb128> just arch any-all mismatch for fontconfig packages leading to uninstallability
[01:34] <asac> seb128: log?
[01:34] <asac> ah
[01:35] <seb128> amd64 didn't catch the same published run for fontconfig
[01:35] <asac> seb128: well
[01:35] <seb128> publisher
[01:35] <asac> amd64 doesnt even have a free slot
[01:35] <asac> so when ati is done all stuff hopefully will be there
[01:36] <seb128> I guess now is a good time to go to bed ;-)
[01:36] <asac> yeah
[01:36] <asac> seb128: did you get failures from other arches too?
[01:36] <asac> they should have the same issue
[01:36] <seb128> some
[01:36] <asac> k
[01:37] <asac> gnome-utils seems to build on armel
[01:37] <seb128> https://edge.launchpad.net/ubuntu/+source/gnome-utils/2.26.0-0ubuntu1
[01:37] <seb128> in fact only i386 worked
[01:37] <asac> seb128: its building right now on armel .. isnt it?
[01:37] <seb128> yes
[01:37] <asac> k
[01:38] <asac> its definitly compiling so stuff should be there
[01:38] <asac> maybe ports is faster though
[01:38] <seb128> asac: I will remember to break builds next time you have a firefox you want to get pushed to your users ;-)
[01:39] <asac> seb128: do you know when publisher run is?
[01:39] <seb128> asac: :03 I think
[01:39] <seb128> hourly
[01:40] <seb128> asac: btw what did you change in fontconfig exactly?
[01:41] <seb128> asac: tried to clean all the ubuntu special rules there?
[01:41] <asac> seb128: i removed obsolete conffiles
[01:41] <asac> seb128: and links
[01:41] <asac> seb128: and disabled debconf
[01:42] <asac> also moved stuff that was in .diff.gz into a debian/patches/ patch ;)
[01:42] <asac> and split that up
[01:42] <asac> e.g. half of the changes where in diff.gz the rest in patches
[01:43] <seb128> good to some cleaning there
[01:44] <asac> seb128: do you know if you still use anymetric anywhere?
[01:44] <seb128> no idea
[01:44] <asac> from changelog it was just firefox that got patched to show some fonts in similar way as evince
[01:45] <asac> but i dropped that anymetrics patch quite some time ago ... so i would like to remove that patch from here too
[01:45] <asac> e.g. the the fontconfig part of it
[01:45] <asac> but i guess you are the wrong to ask ;)
[01:45] <seb128> I think it was only firefox
[01:45] <asac> i think it was ian who did that
[01:46] <seb128> drop it now and see if anybody complain ;-)
[01:46] <seb128> yes, ian did that
[01:46] <asac> yeah. i will drop it once the dust has settled
[01:46] <asac> dont want to give you another any/all conflict ;)
[01:46] <seb128> yeah, wait until tomorrow ;-)
[01:54] <asac> http://launchpadlibrarian.net/23960611/buildlog_ubuntu-jaunty-amd64.gnome-system-monitor_2.26.0.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:54] <asac> doesnt look directly fontconfig related
[02:04] <seb128> asac: I'm ready to bet it's fontconfig though
[02:07] <seb128> asac: http://launchpadlibrarian.net/23960698/buildlog_ubuntu-jaunty-amd64.libwnck_2.26.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[02:08] <seb128> asac: those apt summaries are confusing but it's basically libcairo not installable
[02:08] <asac> seb128: yes out of sync of libwnck and gtkmm and launchpad-integration? did that fail too?
[02:08] <seb128> and I guess that's due to fontconfig not being installable
[02:08] <seb128> asac: yes, I just retried libwnck and gtkmm
[02:09] <seb128> I will go to bed now and give an another retry round in the morning
[02:09] <asac> everything is published now i think
[02:09] <asac> fontconfig wise
[02:10] <asac> at least amd64 is finally DONE too
[02:10] <seb128> good, just need for the publisher to finish running then
[02:13] <asac> good night then
[07:04] <pitti> Good morning
[07:04] <pitti> dobey: hey
[07:04] <pitti> dobey: package  install trigger apt-get update> you can't
[07:04] <pitti> dobey: why would you want to do that?
[07:05] <tjaalton> sigh, many gnome packages fail to install atm
[07:05] <tjaalton> gnome-panel: Depends: gnome-panel-data (< 1:2.26) but 1:2.26.0-0ubuntu1 is to be installed
[07:06] <tjaalton> wonder why the depends looks like that
[07:09] <didrocks> morning :)
[07:09] <pitti> hey didrocks
[07:09] <didrocks> hey pitti o/
[07:27] <tjaalton> ok, so there seems to be some problems in amd64
[07:28] <tjaalton> that's why gnome-panel etc failed to build
[07:28] <tjaalton> huats: hey, how's the anjuta update doing?-)
[07:30] <huats> tjaalton: hey
[07:30] <huats> doing well
[07:30] <huats> there has been a new upstream yesterday
[07:30] <huats> with new bdeps
[07:31] <huats> I am waiting for all of them to be in jaunty (it will be done soon)
[07:31] <huats> and then I can upload it
[07:31] <tjaalton> huats: oh great, I didn't see that :)
[07:31] <tjaalton> ah, so not uploaded yet.. ok
[07:32] <huats> tjaalton: indeed...
[08:18] <seb128> hello
[08:19]  * seb128 yawns
[08:19] <didrocks> hey seb128 o/
[08:19] <seb128> hello didrocks
[08:20] <didrocks> seb128: I think you should take a big cup of coffee :)
[08:20] <seb128> didrocks: yeah, I just did
[08:21] <didrocks> seb128: you have some sponsoring stuff to do when you will be really awake :)
[08:21] <seb128> didrocks: yeah, looking at that now
[08:22] <didrocks> I'm finishing bug-buddy in the meanwhile. Is murrine a new package?
[08:22] <seb128> didrocks: no, it's gtk2-engine-murrine
[08:22] <seb128> didrocks: that the theme engine used by default on ubuntu
[08:23] <didrocks> didrocks: oh, ok. I'm on it once bug-buddy done :)
[08:23]  * mvo takes the vte and g-t sponsoring
[08:23]  * pitti hugs seb128
[08:23]  * pitti hugs mvo too, Guten Morgen
[08:23]  * seb128 hugs pitti mvo
[08:23] <mvo> guten morgen!
[08:24]  * mvo hugs seb128 and pitti and didrocks
[08:24] <seb128> mvo: guten tag!
[08:24]  * didrocks hugs seb128 & mvo (and pitti for the second time of the day ;))
[08:24]  * seb128 hugs didrocks
[08:24] <pitti> seb128: taking gimp and gnome-doc-utils
[08:25] <seb128> pitti: danke
[08:32] <crevette> good morning
[08:34] <seb128> lut crevette
[08:35] <seb128> pitti: did you clean the retracers issues? I don't see any problem right now but got emails from those
[08:35] <pitti> seb128: yes
[08:35] <seb128> pitti: ok thanks
[08:35]  * seb128 hugs pitti
[08:35]  * pitti hugs back seb128
[08:36] <pitti> seb128: FYI, I now have all the pieces together -- launchpadlib backports for hardy and intrepid, firewall rules on ronne fixed, launchpadlib branch test suite succeeding
[08:36] <seb128> excellent
[08:36] <pitti> seb128: I think I'll do the big switch on Thursday, when we're frozen anyway
[08:36] <pitti> but I need to switch all retracers at the same time
[08:38] <seb128> pitti: btw for bzr sponsoring with your workflow, dch -r will change the changelog entry owner to the sponsor is that what you expect?
[08:38] <pitti> seb128: taking gnome-games
[08:38] <seb128> pitti: I'm on it
[08:38] <pitti> seb128: ah, ok
[08:38] <pitti> seb128: no, I use dch -rm for that
[08:38] <pitti> -m preserves the maintainer
[08:38] <seb128> pitti: I've taken gnome-games and vinagre (set those to fix commited)
[08:39] <seb128> pitti: ok thanks
[08:39] <pitti> seb128: I think it's more polite to keep the original sponsoree in
[08:39] <seb128> yeah me too
[08:39] <pitti> seb128: taking tomboy then
[08:39] <seb128> I was just wondering since I've not used this workflow before and didrocks did the upgrade this way now
[08:40] <seb128> pitti: danke
[08:40] <pitti> seb128: for gnome-doc-tools, I just pulled his branch into the ~ubuntu-desktop one, checked diff, dch -rm, debcommit -r
[08:41] <seb128> didrocks: you have been added to the ubuntu-desktop team congrats
[08:41] <seb128> didrocks: you can push directly there now and ask for review ;-)
[08:41]  * pitti hugs didrocks
[08:41]  * seb128 hugs didrocks
[08:43] <seb128> ok
[08:43] <seb128> I'm looking to notify-osd now
[08:43] <dobey> pitti: to avoid requiring the user run apt-get update manually. the package installs a gpg key and sources.list for a ppa for example
[08:43] <seb128> the 0.9.3 broke for quite some users apparently
[08:43] <pitti> seb128: ugh, how?
[08:43] <seb128> the binary has been renamed to notify_osd instead of notify-osd or something
[08:43] <pitti> dobey: I'm afraid packages can't do that
[08:44] <pitti> dobey: and packages shouldn't ever ship an apt sources.list, too
[08:44] <dobey> yes, it rather sucks
[08:44] <dobey> why not?
[08:45] <pitti> dobey: the intended way is that the user adds an apt source in synaptics and then it'll DTRT
[08:45] <dobey> sure
[08:45] <pitti> dobey: how do you use mirrors or CD sources then? this would break for people who are offline, etc.
[08:45] <dobey> but requiring a user to do all that work, sucks
[08:45] <dobey> uhm
[08:45] <dobey> ppas are on cd sources? or mirrored?
[08:45] <pitti> dobey: mvo also has a rather clever system for simplifying that even more, with a kind of apt:// URL syntax
[08:46] <dobey> pitti: apt: urls only work if the package is available in a sources list. you can't use apt to install a package in your ppa if the user hasn't added the ppa
[08:46] <pitti> dobey: I think that's precisely what they are designed for
[08:46] <pitti> i. e. add an apt source
[08:46] <pitti> dobey: mvo knows more, though, ICBW
[08:46] <pitti> good morning sabdfl
[08:46] <seb128> hello sabdfl
[08:47] <pitti> ember: sponsoring tomboy... Trying patch debian/patches/01_dllmaps.patch at level 1 ... 0 ... 2 ... failure.
[08:47] <sabdfl> hey guys. seb, 2.26 seems to have landed very smoothly!
[08:47] <dobey> i don't see how. apt doesn't know where to find the package until you tell it
[08:47] <sabdfl> how are you, pitti?
[08:47] <pitti> sabdfl: pretty good, in the usual beta rush :) how are you?
[08:47] <sabdfl> all happy in cape town
[08:48] <pitti> dobey: it's not apt itself, it's a desktop-ish thing
[08:48] <dobey> pitti: well, it doesnt't really matter. apt:package doesn't work if package isn't already available via apt
[08:49] <pitti> mvo: ^ halp plz
[08:49] <pitti> mvo: isn't that the very use case we wanted to add? make it easy to add a new apt source?
[08:49] <seb128> sabdfl: indeed the day has been long yesterday but we landed almost everything and didn't have a real issue so it's good ;-)
[08:51]  * mvo keeps forgeting that the vte build takes forever
[08:52] <seb128> is there any way to push automatically to the vcs url which is used in the control?
[08:53]  * didrocks hugs seb128 & pitti: thanks a lot both of you :)
[08:53] <mvo> seb128: like using a checkout ?
[08:53] <mvo> seb128: hm, brasero conflicts with nautilus-cd-burner now in bzr - is this really needed?
[08:54] <seb128> mvo: they both provide the nautilus burn: location so you have duplicated buttons in nautilus, duplicated menu items, etc
[08:54] <pitti> seb128: no automatic one, I'm afraid; however, you should use "bzr info" and take that one, since Vcs-Bzr: usually points to http://
[08:55] <seb128> mvo: ideally the nautilus .so could be splitted and only this one conflict
[08:55] <pitti> seb128: for Vcs-Bzr: that makes sense IMO, since it's a clickable link to the browser
[08:55] <seb128> right
[08:55] <pitti> seb128: ideally debcheckout -a would automatically set the push address to the pull address
[08:55] <crevette> salut seb128
[08:55] <pitti> seb128: I think that's indeed a good idea, annoys me as well; I'll make a TODO item to look into this
[08:55] <mvo> seb128: if you think the conflict is appropriate I'm fine with it, it seems a bit strong if all that results is a worse UI than before :)
[08:55] <seb128> mvo: no, I bzr get lp:~didrocks, review and then push to lp:~ubuntu-desktop when uploading
[08:55] <pitti> ember: ignore me
[08:56] <seb128> mvo: it's annoying to have to copy the url for that ;-)
[08:56] <seb128> mvo: worse UI?
[08:56] <seb128> pitti: thanks
[08:56] <seb128> lut crevette
[08:56] <mvo> seb128: I tend to use checkouts with debcommit, that saves me from the push
[08:56] <crevette> sorry I was away :)
[08:57] <crevette> pitti, as I know you have bluetooth devices, may I ask if you have time if you can test https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/343859 ?
[08:57] <seb128> mvo: so you checkout twice, the didrocks and ubuntu-desktops one and bzr merge and then push to upload?
[08:57] <mvo> seb128: worse-ui> if the conflicts is there "just" because if both are installed the buttons are duplicated that seems a bit strong
[08:57] <seb128> mvo: can we make sure that people upgrading will get nautilus-cd-burner removed? because having duplicated functions is a bit ugly
[08:57] <pitti> seb128: no need to checkout oboth
[08:57] <seb128> mvo: right click on an iso or open burn:
[08:58] <pitti> seb128: debcheckout -a tomboy; bzr pull lp:~didrocks/tomboy/whatever
[08:58] <mvo> seb128: I have a checkout usually of the ~ubuntu-desktop one, then I do a bzr merge lp:~didrocks/foo/ubuntu; bzr diff and if its good (builds, test ok) I do a debcommit (or debcommit -r). if the ~ubuntu-desktpo branch was a checkout it will push automatically
[08:58] <seb128> ok, I see
[08:58] <seb128> thank you guys
[08:58] <mvo> seb128: aha, I see the problem now
[08:58] <seb128> I usually bzr get lp:~didrocks
[08:58] <seb128> review
[08:58] <seb128> and bzr push lp:~ubuntu-desktop etc
[08:59] <pitti> seb128: that usually works, too, just feels slightly odd :)
[08:59] <mvo> can you do bzr diff with that workflow too?
[08:59] <mvo> funny that three people have three (slightly) different workflows :)
[08:59] <pitti> sure, bzr diff -c -1
[08:59] <seb128> mvo: yes,  since he branches from ~ubuntu-desktop to do the update
[09:00] <pitti> the push will fail if the branches were diverged, so that should be alright
[09:00] <pitti> if it fails, you need to merge
[09:00] <pitti> I made a note to fix debcheckout -a
[09:00] <pitti> to automatically set the push addresss
[09:00] <pitti> so that you have debcheckout -a tomboy; bzr pull otherbranch; review; dch -rm; debcommit -r; bzr push
[09:01] <dobey> mvo: so can you elaborate on pitti's claims of apt-url magic?
[09:02] <mvo> dobey: maybe, what was the claim?
[09:02] <pitti> mvo: is that new apt-url system meant for adding apt sources, or just installing packages from existing apt sources?
[09:02] <pitti> mvo: (I thought the former)
[09:03] <mvo> pitti: the new one can add apt source *if* they come from app-install-data-partner(s)
[09:03] <mvo> so it can add e.g. the partner repository
[09:03] <pitti> mvo: ah, that was restricted for security reasons
[09:03] <mvo> but it can not add anything that is not already whitelisted
[09:03] <pitti> mvo: so it's not meant to work for PPAs?
[09:03] <mvo> yes, security and QA
[09:03] <mvo> it could work for PPAs if we add a explicit whitelist for a specific PPA
[09:03] <mvo> but it does not right now
[09:03] <pitti> mvo: I really don't think that packages should ship sources.list files (and try apt-get update in postinst)
[09:04] <dobey> you can't do apt-get update in postinst anyway
[09:04] <mvo> pitti: what package is doing that?
[09:04] <dobey> because the package install already has the lock
[09:04] <pitti> right, and it's entirely backwards
[09:04] <mvo> dobey: you could with -o Debug::NoLocking=True, but that would be cheating
[09:04] <dobey> pitti: but if packages aren't meant to install sources list files, why the hell is there an /etc/apt/sources.list.d/ ? :)
[09:05] <pitti> dobey: so that programs like synaptics or admins can use it :)
[09:05] <dobey> bah
[09:05] <mvo> I agree with pitti, pushing stuff there from a package is not the right thing
[09:06] <mvo> what use case do you have ?
[09:06] <pitti> seb128: I'll do the evo-indicator merge request
[09:06] <dobey> easy setup of ppas, for one
[09:06] <seb128> pitti: oh, I did the upload
[09:06] <pitti> oh, ok
[09:06] <seb128> pitti: I didn't push to bzr for several reasons though
[09:07] <seb128> 1- I don't understand why we don't have only the packaging there
[09:07] <pitti> seb128: I just pulled and I have 0.1.10-0ubuntu1 in the branch
[09:07] <seb128> 2- bzr-buildpackage in the ubuntu checkout doesn't work
[09:07] <seb128> 3- I don't understand how this launchpad feature works
[09:07] <seb128> pitti: cf what I just wrote ;-)
[09:07] <mvo> dobey:  its a tricky trade off, everything can be in a PPA, including stuff that breaks the system in bad ways, if we make it too easy, people will break their system (or worse, install random stuff and break it next time they try to upgrade and blame us)
[09:08] <pitti> seb128: (1) it's a branch from trunk, so with that we can directly merge fixes and new versions from trunk
[09:08] <mvo> we had this in the past with external repos, this is why its currently relatively difficult
[09:08] <dobey> mvo: uhm. if they're looking at something in a ppa, they're going to do that anyway
[09:08] <pitti> (2) it's not set up for bzr-buildpackage AFAICS (and not really necessary, but I'm fine with having it set up)
[09:08] <pitti> (3) which LP feature?
[09:08] <dobey> mvo: and you can already just click on specific .deb packages in a ppa and install them with gdebi
[09:08] <pitti> seb128: you wrote that you didn't push, but apparently you pushed, but didn't upload or so?
[09:09] <pitti> seb128: ah, ignore me; I pulled from their PPA branch, not from ubuntu
[09:10] <pitti> seb128: see https://edge.launchpad.net/ubuntu/+source/evolution-indicator, no upload
[09:10] <pitti> seb128: (you don't mix this up with indicator-applet, do you?
[09:11] <seb128> pitti: I do
[09:11] <seb128> pitti: (2), how do I build from the checkout then?
[09:12] <seb128> pitti: (3) the merge request page, are we supposed to edit something there?
[09:12] <pitti> seb128: (2) debuild -S
[09:12] <pitti> seb128: (2) nothing special really, you "just do"
[09:12] <pitti> seb128: (3) no need to, if you merge and push, it'll resolve itself (it notices that you did the merge)
[09:13] <seb128> pitti: debuild -S ... the checkout has autogen.sh and no configure that's not what I want, I used the upstream tarball
[09:13] <pitti> ah
[09:13] <seb128> maybe I'm not used to this workflow but I dislike packaging trunk and running autotools in the package build
[09:13] <pitti> seb128: I think the last time I just unpacked the orig.tar.gz
[09:13] <seb128> I like better using tarballs
[09:13] <pitti> seb128: right, I like pre-built autostuff, too
[09:14] <seb128> right, that's what I did and copied the debian directory over
[09:14] <seb128> but if that's to do that why not having the debian directory only in bzr?
[09:14] <pitti> seb128: we can do that (bzr-bd merge mode)
[09:15] <seb128> I don't really care either way I just don't understand the current way
[09:15] <seb128> it seems to be
[09:15] <seb128> bzr get
[09:15] <seb128> download tarball
[09:15] <seb128> untar
[09:15] <seb128> copy debian directory manually
[09:15] <seb128> build
[09:15] <seb128> which is not really efficient ;-)
[09:16] <pitti> seb128: this would work:
[09:16] <pitti> bzr get
[09:16] <pitti> download tarball
[09:16] <pitti> untar into checkout
[09:16] <pitti> debuild
[09:16] <pitti> but yeah, it's confusing
[09:16] <pitti> if we use bd for everythign else, we should use it for this, too
[09:16] <pitti> seb128: want me to change the branch accordingly?
[09:17] <pitti> seb128: we'd loose the ability to merge from their packaging branch, but we can ask them to use bd, too
[09:17] <pitti> or wait, maybe not
[09:17] <pitti> seb128: I don't see a reason why we can't keep teh branch as it is and just add merging
[09:17] <seb128> pitti: this package don't change often enough for me to be bothered do whatever is easier for dx and you
[09:17] <pitti> right
[09:17] <pitti> seb128: ok, I'll switch it to bd
[09:18] <seb128> pitti: thanks
[09:18] <seb128> want me to push my changes there?
[09:18] <pitti> seb128: what did you change, just pulled the PPA branch?
[09:18] <seb128> pitti: I added an shlibs update to the rules too
[09:18] <pitti> sure
[09:19]  * pitti writes a debian/watch for https://edge.launchpad.net/evolution-indicator/+download
[09:22] <seb128> mvo: do you need help on the gnome-panel message indicator migration script?
[09:22] <seb128> mvo: beta freeze is in 2 days ideally that should be landing today or tomorrow
[09:22] <mvo> seb128: its a bit myserious why its not working currently
[09:23] <mvo> seb128: if you could test run it and see what it prints in your xsession-errors, that would be cool
[09:23] <seb128> mvo: does it has any expectation on my user config?
[09:24] <mvo> seb128: not a lot, it will not add the applet if its already there and it needs a tray applet to find the position to put it onto
[09:24] <mvo> thats about it
[09:26] <seb128> mvo:    http://launchpadlibrarian.net/23754128/add-indicator-applet.py
[09:26] <seb128> mvo: that one worked right now for my ubuntu test user account
[09:27] <seb128> running python add-indicator-applet.py
[09:27] <seb128> doh, that's not the current version
[09:27]  * seb128 retries
[09:27] <mvo> seb128: the latest is in my ppa
[09:28] <seb128> mvo: let me try
[09:28] <mvo> seb128: it seems something is different when run from the session for some reason, the logs from kenvandine_wk indicate it runs, but for some reason stops
[09:29] <mvo> there is a exception handler in it, that seems to be not kicked too
[09:32] <seb128> pitti: hum, the new indicator-applet build-depends on gir-repository which is in universe
[09:32] <asac> hah
[09:32] <seb128> tedg: ^
[09:32] <seb128> hey asac
[09:32] <asac> i saw the merge request yesterday
[09:33] <asac> hey seb128; how is the catching up going?
[09:33] <asac> all back in line?
[09:33] <seb128> asac: yes all is good now thanks again for the quick fixing!
[09:34] <asac> cool. no problem.
[09:35]  * asac enjoys getting the first few 2.26 bts
[09:36] <pitti> seb128: where did you push your evo-indicator changes?
[09:36] <seb128> pitti:  seb128: (you don't mix this up with indicator-applet, do you?
 pitti: I do
[09:36] <seb128> pitti: I didn't touch this one, I did change indicator-applet
[09:36] <pitti> aah
[09:36] <pitti> seb128: ok, doing e-i now
[09:37] <seb128> thanks
[09:37] <seb128> pitti: did you read my gir-repository note?
[09:37] <pitti> seb128: I did
[09:37] <pitti> waiting for Ted
[09:37] <seb128> pitti: the new libindicator didn't build due to that dunno if you need it
[09:37] <seb128> ok
[09:37] <asac> gir-repository sounds like something optional imo
[09:38] <seb128> he added some api that other softwares might require now
[09:42] <pitti> seb128: ah, perfect; bd merge mode works with such "full upstream source" branches as well
[09:42] <pitti> seb128: thus we get the bd love and retain the possibility of cherrypicking fixes from trunk and merging with it \o/
[09:42] <pitti> schweet
[09:43] <asac> pitti: i did that for the whole nm 0.7 ... but then upstream moved to git and i had to go back to debian/ only
[09:43] <asac> so full upstream sources has some risk of loosing everything ;)
[09:43] <pitti> asac: well, hopefully not our upstream in this case :)
[09:43] <mvo> seb128: hm, looks like I need to update my gnome-panel patch for the new version
[09:43] <pitti> asac: (DX team)
[09:43] <asac> heh ;)
[09:44] <asac> i want git bzr
[09:44] <asac> when?
[09:44] <asac> ;)
[09:44] <asac> oh and don't forget bzr-hg
[09:46] <pitti> asac: /me 2
[09:46] <seb128> mvo: the autoadding worked for me right now
[09:46] <mvo> seb128: hm, cool
[09:46] <mvo> seb128: with the panel from the ppa?
[09:47] <seb128> mvo: yes
[09:48] <seb128> mvo: on a clean config though, will test with my user in a bit
[09:48] <pitti> seb128: ok, evo-indicator uploaded and pushed; it Just Works[tm] with bzr bd now
[09:48] <seb128> ie I tried with my test user
[09:48] <pitti> seb128: want me to fix indicator-applet branch, too?
[09:48] <mvo> seb128: I uploaded a new 2.26 based one into the ppa (just fyi)
[09:48] <seb128> pitti: excellent, I'm doing the notify-osd update, MacSlow just rolled a new tarball
[09:48] <seb128> pitti: yes please
[09:48] <seb128> mvo: cool thanks
[09:50] <mvo> so all is ready once we figured out what went wrong on the install from kenvandine_wk - I will ask him for a gconf dump when is is ready again
[09:50] <seb128> mvo: I had a case where it was placed at the left of the menus, took me a bit to figure that it was there
[09:51] <mvo> seb128: hm, it should be more careful about this now and not do the update if it gets a "0" position
[09:52] <seb128> mvo: might have been the .py on the bug which gave me that which was the old version
[09:52]  * mvo nods
[09:54] <pitti> seb128: ok, pushed; if you pull, you see that it's UNRELEASED, thus not uploaded yet; thus the next change shouldn't start a new changelog entry
[09:55] <pitti> doesn't build without gir, though
[09:56] <asac> pitti: have you tried to remove the gir bits?
[09:56] <seb128> pitti: ok
[09:56] <pitti> I don't know at all what that does
[09:56] <seb128> that does automatically bindings using gobject introspection
[09:57] <pitti> I think we should wait for tedg here
[09:57] <asac> pitti: its a repository for introspection wrappers
[09:57] <asac> probably for python?
[09:57] <asac> oops
[10:02] <seb128> notify-osd 0.9.4 is buggy
[10:02] <lool> it's not yet there for python, it's for js ATM
[10:02]  * seb128 sponsors bug-buggy
[10:02] <lool> bug-buggy :)
[10:03] <asac> lool: js?
[10:03] <lool> javascript -- I didn't expect to tell that to you   ;-)
[10:03] <asac> lool: i expanded that ... just wondered who uses dbus bindings with js
[10:04] <seb128> didrocks: around?
[10:05] <didrocks> seb128: yes
[10:05] <seb128> asac: any opinion on whether we should consider webkit 1.1.n for jaunty?
[10:05] <seb128> didrocks: for bug-buddy there is no need to dfsg the tarball in this new version?
[10:06] <asac> seb128: do we know how the rdepends will cope with that?
[10:06] <didrocks> seb128: you pointed a stable released not a vcs one. Or, I misunderstood the dfsg usage?
[10:06] <asac> seb128: afaik gwibber will break. we should certainly check with upstream for our rdepends first
[10:07] <seb128> didrocks: you misunderstood, that's debian redoing the tarball without google-breakpad/src/common/convert_UTF.* because of the license
[10:07] <seb128> asac: no idea about rdepends that's why I ask, debian did upgrade to experimental
[10:07] <seb128> asac: kov is working on it nowadays, he also did the epiphany-webkit trunk packaging as a new source
[10:08] <didrocks> seb128: oh, ok. So, we have to take the tarball from another version than the direct upstream tarball
[10:08] <asac> seb128: kov? glandium gone?
[10:08] <seb128> didrocks: we have to take the upstream tarball, clean those and repackage
[10:08] <seb128> didrocks: debian doesn't consider those files a free or there is a license issue to ship those apparently
[10:09] <seb128> asac: dunno about glandium but kov is focussed on webkit upstream and in debian
[10:09] <didrocks> seb128: ok, so, I will attach the new orig.tar.gz to the bug once done
[10:09] <asac> interesting
[10:09] <seb128> asac: he did the gtk 2.16, libsoup, libproxy, etc updates
[10:09] <seb128> asac: to be able to package epiphany-webkit trunk
[10:09] <didrocks> seeing what is possible to do with bzr to take it, if possible
[10:09] <seb128> asac: he did also update webkit to 1.1
[10:09] <asac> brave
[10:09] <seb128> didrocks: ok thanks
[10:09] <seb128> asac: indeed ;-)
[10:10] <seb128> asac: rdepends are pretty limited so might want to consider it, though it's not the focuss right now and can wait next cycle
[10:11] <seb128> asac: we would just be able to ship epiphany-webkit 2.27 in universe if we do the update
[10:11] <asac> seb128: i will check with gwibber folks. they asked me a few days if we will update
[10:11] <seb128> ok thanks
[10:11] <asac> i think the other rdepends is just devhelp
[10:11] <asac> and midory + kaze
[10:18]  * mvo reboots
[10:39] <huats> asac: ask them if they need python-webkit 1.1 or if we can stay to 1.0.2 for jaunty...
[10:43] <didrocks> seb128: bug-buddy fixed. All packages you listed me yesterday are ready for sponsoring. gtk2-engines-murrine is waiting for jcastro's LP project creation :)
[10:44] <dobey> pitti: if i want to make changes to python-distutils-extra, what branch should i develop against?
[10:44] <pitti> dobey: http://bazaar.launchpad.net/~python-distutils-extra-hackers/python-distutils-extra/debian ideally
[10:44] <seb128> didrocks: excellent, want other updates?
[10:45] <pitti> dobey: once you have fixex, I'm happy to merge them and upload to debian/ubuntu
[10:45] <pitti> seb128: taking eel2 and gtk2-engines, ok?
[10:45] <didrocks> seb128: with pleasure :)
[10:45] <dobey> pitti: is that 'upstream'?
[10:46] <pitti> dobey: yes; Sebastian Heinlein and I are upstream
[10:46] <seb128> pitti: gtk2-engines has already been uploaded yesterday that seems uncoordinated update and an invalid request, you can take the other one
[10:46] <dobey> pitti: ok, just wasn't sure if that or his branch was the upstream branch
[10:46] <pitti> didrocks: eel2> you didn't push that into the ~ubuntu-desktop branch yet, did you?
[10:46]  * seb128 looks at bug-buddy again
[10:47] <didrocks> pitti: no, I wasn't allowed to push it when I did the update
[10:47] <pitti> didrocks: n/p
[10:47] <didrocks> pitti: I can push it now if you wish
[10:48] <pitti> didrocks: don't worry, already pulling; just checking
[10:48] <didrocks> pitti: oki :)
[10:48] <seb128> didrocks:
[10:48] <seb128> http://download.gnome.org/sources/gnome-control-center/2.26/gnome-control-center-2.26.0.tar.gz
[10:48] <asac> huats: well. they need 1.0.2 ... i was about to ask whether they could make our gwibber move to 1.1 ;)
[10:48] <huats> :)
[10:48] <asac> actually asked
[10:48] <huats> ok
[10:48] <huats> let me know
[10:49] <didrocks> seb128: on it :)
[10:49] <huats> (python-webkit has a new release 1.1 for a few days so if they need it we can update it...)
[10:50] <dobey> pitti: btw, you might want to bzr upgrade --1.6 to lp:~python-distutils-extra-hackers/python-distutils-extra/debian branch :)
[10:51] <pitti> dobey: yeah, will do that the next time I touch it
[11:35] <Nafallo> my window borders are gone :-/
[11:35] <Nafallo> up to date jaunty
[11:37] <pitti> dobey: do you happen to know how I can fix the label truncation in http://launchpadlibrarian.net/23910777/gnome-mount-bug-1.png ?
[11:37] <pitti> dobey: it usually gets wrapped (I did gtk_label_set_line_wrap TRUE)
[11:38] <pitti> dobey: but this seems to happen for certain specific label lengths
[11:38] <dobey> pitti: hmm, no. i think it might be a bug in gtk+, perhaps from a patch?
[11:38] <dobey> i'ved noticed that in intrepid also
[11:39] <pitti> yeah, I guess it is
[11:39] <dobey> it happens in the evolution-webcal error dialog
[11:39] <pitti> dobey: ok, I file that separately then, and create a minimal test case
[11:39] <dobey> and i spent a lot of time making the evolution-webcal dialogs be super awesome wrt that
[11:40] <dobey> it could be an upstream change that broke it too
[11:40] <dobey> wouldn't be the first time upstream gtk+ broke api/abi with my code :-/
[12:11] <kenvandine_wk> mvo_: i can attach a gconf dump
[12:13]  * kenvandine_wk applies his morning updates :)
[12:17] <mvo_> kenvandine_wk: please do thanks
[12:34] <tjaalton> seb128: I can reproduce bug 224642 on jaunty, and it's driving me nuts :)
[12:34] <tjaalton> seb128: so if you have suggestions how to debug it, I'm all ears
[12:35] <pitti> seb128: wb
[12:35] <pitti> seb128: doing MacSlow's notify-osd update now
[12:35] <pitti> seb128: and I also builddeb-ified the branch
[12:35] <seb128> pitti: I had it ready but if you want ...
[12:36] <pitti> seb128: oh, I didn't see updates in the branch, sorry?
[12:36] <seb128> pitti: or rather I noticed some code issues and they said they would roll a new tarball, they did?
[12:36] <pitti> seb128: he just told me 30 mins ago
[12:36] <pitti> seb128: right, 0.9.5
[12:36] <seb128> ok
[12:36] <pitti> with the AC_INIT fix
[12:36] <seb128> I had 0.9.4 ready
[12:36] <seb128> but go for it
[12:36] <seb128> it was almost no work
[12:36] <pitti> okay
[12:36] <pitti> right
[12:36] <pitti> bzr merge trunk and changelog mainly
[12:37] <pitti> and the watch file/.bzr-builddeb
[12:37] <pitti> seb128: okay, verified that this fixes bug 338837
[12:39] <seb128> pitti: good ;-)
[12:39] <seb128> pitti: thanks
[12:40] <pitti> lunch o'clock
[12:44] <seb128> pitti: enjoy
[12:44]  * seb128 just back from lunch and wrote activity email
[13:01] <asac> seb128: nautilus-cd-burner supposed to go away or just transitional?
[13:01] <seb128> asac: none of those, it's a valid cd burning software just not the default one
[13:02] <asac> seb128: heh. just wondered because dist-upgrade suggested to remove it now ;)
[13:02] <asac> i confirmed that
[13:02] <seb128> asac: right
[13:02] <asac> good
[13:02] <asac> byebye
[13:02] <seb128> asac: that's because brasero and nautilus-cd-burner has the same options
[13:03] <asac> thats ok. last time i tried i liked brasero
[13:03] <seb128> asac: ie having both duplicate nautilus menu items etc
[13:03] <asac> if it has the same nautlius integration now thats good
[13:04] <kenvandine_wk> seb128: nautilus-cd-burner is on the deprecated list for 2.26
[13:05] <kenvandine_wk> not sure if it will still be maintained :)
[13:05] <seb128> bastien seems to not be 100% happy with brasero yet
[13:05] <seb128> but I'm not sure if he will keep working in n-c-b or just push them to fix issues
[13:06] <mvo_> kenvandine_wk: did you attach the gconf dump yet?
[13:07] <mvo_> kenvandine_wk: I pushed a new version, but the changes are just cosmetic (deal with tray applet in right_stick mode)
[13:07] <kenvandine_wk> no, my box has been busy updating
[13:08] <kenvandine_wk> should in just a few minutes
[13:09] <tedg> seb128: pitti: I think the gir bits could be dropped -- there's nothing really using them right now.
[13:09] <tedg> It's kinda sad really, I thought that was more mature than it really is.
[13:10] <kenvandine_wk> tedg: are the python  bindings packaged?
[13:10]  * mvo_ keeps wondering why we removed the logout action from the system menu
[13:10] <seb128> mvo_: because fusa is the true way ;-)
[13:11] <tedg> kenvandine_wk: No, it's on the todo list.  I haven't asked eeejay what state they're in recently.
[13:12] <tedg> mvo_: Basically so there isn't two ways to logout.  If FUSA isn't the answer, then we simply shouldn't have it there.
[13:13] <kenvandine_wk> tedg: cool, segphault said he is impressed with it :)
[13:13] <kenvandine_wk> but said the bindings aren't fully functional yet
[13:13] <mvo_> tedg: its just that it break my old habit to logout using the system menu, I have that habit since the dawn of time
[13:13] <mvo_> seb128: right, I know that :)
[13:13] <kenvandine_wk> mvo_: change is good, mkay
[13:13] <kenvandine_wk> :)
[13:13]  * tedg imagines mvo_ coming out of the womb and shutting down the computer in the hospital using the system menu :)
[13:14] <seb128> mvo_: remove fusa ;-)
[13:14] <kenvandine_wk> our vanilla session should really have the default menus and no fusa, imho
[13:14] <tedg> kenvandine_wk: Yeah, he sent me a screenshot of it working though, which was pretty cool.
[13:14] <mvo_> its fun when switching between intrepid and jaunty where its on a different location. or explaning it to my e.g. my parents
[13:15]  * kenvandine_wk is anxious to use it :)
[13:15] <kenvandine_wk> tedg: i can package it, when they are ready
[13:15]  * mvo_ looks up what "womb" means
[13:16] <kenvandine_wk> mvo_: i am building something in kvm... and i have to shutdown kvm to run virtualbox and get that gconf dump
[13:16] <kenvandine_wk> multiple virtualization technology fail :)
[13:16]  * mvo_ shuts up and goes back to sponsoring
[13:16] <mvo_> kenvandine_wk: no problem
[13:17] <tedg> kenvandine_wk: That'd be great, talk with eeejay, but I think it's in a good enough place to start putting something together.
[13:18] <kenvandine_wk> ok
[13:18] <tedg> mvo_: On the plus side, we don't plan on moving it again :)
[13:18] <kenvandine_wk> tedg: yet :)
[13:18] <kenvandine_wk> eeejay: is the indicator bindings ready to be packaged?
[13:18] <tedg> kenvandine_wk: It would be nice if the vanilla gnome could use the default panel.  Not sure how to do that though.  The panel config is so fubar.
[13:20] <MacSlow> mvo_, just looked at the latest compiz-fusion-plugins-main
[13:20] <kenvandine_wk> tedg: yeah, we would need to have a separate set of menus as well as vanilla gconf
[13:20] <mvo_> MacSlow: and its not there?
[13:21] <MacSlow> mvo_, /usr/share/compiz/animation.xml seems to be ok
[13:21] <MacSlow> mvo_, I wonder what people did report in bug https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331564
[13:21] <kenvandine_wk> tedg: but i have a hard time calling it a vanilla session as it is now :)
[13:22] <seb128> kenvandine_wk: new ekiga available if you still work on it
[13:22] <kenvandine_wk> seb128: yes... i started porting the patches last night
[13:22] <mvo_> MacSlow: I just checked the source, it should be there (the animation one), I double check if the one from compiz is also there, maybe they disabled animation or something?
[13:22] <kenvandine_wk> so will move to 3.2
[13:22] <kenvandine_wk> :)
[13:23] <tedg> kenvandine_wk: That's why it's Italian-vanilla-gnome ;)
[13:23] <kenvandine_wk> hehe
[13:23] <kenvandine_wk> better vanilla i guess :)
[13:23] <mvo_> MacSlow: I will ask in the bugreport for a gconf dump
[13:24] <MacSlow> mvo_, if the animation plugin would be disabled it would not introduce any issue there. One remaining bit to check is if the fade-plugin is enabled by default
[13:24] <MacSlow> mvo_, although that's not what our defaults look like
[13:25] <seb128> good
[13:25] <mvo_> MacSlow: I commented in the report
[13:28] <mvo_> MacSlow: I can not reporduce it here, no matter what (with animation, without, with fade, without)
[13:30] <MacSlow> mvo_, yeah ... there are exception rules for "title=notify-osd" in place for both so I don't know what people are running in there mentioned in the bug report
[13:30] <mvo_> MacSlow: lets wait for the gconf dump
[13:42] <MacSlow> mvo_, I'll commented a bit more on https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331564 so Nicolò can better tell us what's his/her system-settings look like
[13:42] <didrocks> seb128: g-c-c is ready but there is two missing dependencies (libgnome-window-seetings1 and capplets-data)
[13:43] <seb128> didrocks: missing dependencies? those a g-c-c binaries ...
[13:43] <didrocks> seb128: oupss, should review my dpkg -i, sorry ;)
[13:48] <mvo_> MacSlow: the fade plugin has also a hardcoded rule !type=desktop - does notify-osd set this one?
[13:48] <mvo_> MacSlow: we do enable fade by default, its used for some stuff, but animation disables (parts) of it
[13:49] <MacSlow> mvo_, no that rule does not apply to notify-osd
[13:50] <MacSlow> mvo_, to make sure the fade-plugin leaves notify-osd's windows alone, we just need to add the rule we added to animation to fade
[13:50] <MacSlow> mvo_, I can make a patch for that and send you the file
[13:53] <MacSlow> hey bothorsen
[13:55] <mvo_> MacSlow: I'm on a call right now, I do it afterwards
[13:55] <MacSlow> mvo_, ok np
[13:56] <bothorsen> MacSlow: hey
[13:58] <didrocks> seb128: g-c-c and gtk2-engine-murrine done
[13:59] <seb128> didrocks: you rock ;-)
[13:59]  * didrocks hugs seb128 :-)
[13:59]  * seb128 hugs didrocks
[14:06] <seb128> pitti: do you know where to reassign bug #342013?
[14:10] <kenvandine_wk> mvo_: gconf dump attached
[14:21] <seb128> didrocks: want some other updates?
[14:21] <didrocks> seb128: of course :)
[14:21] <didrocks> (I am catching up my mails)
[14:21] <seb128> didrocks: http://download.gnome.org/sources/gnome-themes/2.26/gnome-themes-2.26.0.tar.gz
[14:22] <seb128> didrocks: http://download.gnome.org/sources/gnome-backgrounds/2.24/gnome-backgrounds-2.24.1.tar.gz ... that one is universe so you can directly upload ;-)
[14:22] <ember> seb128 i can do some updates if you want
[14:23] <seb128> ember: thanks for those were the 2 remaining which just arrived everything else is assigned or waiting for debian right now
[14:24] <ember> ok.
[14:26] <pitti> tedg: do you want to revert the git bits upstream or shall we do that in the ubuntu branch?
[14:26] <tedg> pitti: ?  I'm not sure what you're asking.
[14:26] <pitti> tedg: s/git/gir/, sorry
[14:27] <tedg> pitti: I think do them in the Ubuntu branch.  It should be an easy thing to do.  Are you just not going to package them, or not build them too?
[14:28] <pitti> tedg: we can't build them without the gir build dependency
[14:28] <pitti> that's in fact the entire problem
[14:29] <tedg> pitti: Oh, and what's the problem with the build dependency?  Is it not in main?
[14:29] <pitti> tedg: right
[14:31] <tedg> pitti: Hmm, okay, I'll fix it upstream then.  The autotools patches are too evil :)
[14:31] <pitti> tedg: appreciated, thanks
[14:31] <tedg> I'll see if I can't detect and make it gracefully not build.
[14:31] <pitti> tedg: a configure-time check would be ideal, indeed
[14:34] <pitti> seb128: 342013> handled
[14:34] <seb128> pitti: thanks!
[14:48] <mvo_> kenvandine_wk: if you have a snapshot of the machine, I put another gnome-panel up
[14:48] <mvo_> kenvandine_wk: https://edge.launchpad.net/~mvo/+archive/ppa?field.name_filter=gnome-panel&field.status_filter=published&field.series_filter=any
[14:48] <mvo_> kenvandine_wk: it deals with more configurations, maybe you can even attahc a strace to the running python process? so that we get if anything unusual happens?
[14:49] <kenvandine_wk> sure
[14:50] <didrocks> seb128: gnome-themes bzr branch does not use bzr merge mode, do I create a new banch and remove this one?
[14:53] <seb128> didrocks: overwrite the current one
[14:53] <didrocks> seb128: sorry, there is nothing in common with this branch and the packages, strange :/
[14:53] <seb128> didrocks: we did push some things to bzr over a year ago as an experiment
[14:53] <seb128> didrocks: that failed and we didn't use bzr
[14:53] <seb128> didrocks: but the bzr stayed there
[14:53] <seb128> maybe that's one of those
[14:54] <seb128> just overwritte it if that's the case ;-)
[14:54] <didrocks> seb128: oki, noted :)
[14:54] <seb128> you can bzr push --overwritte I think
[14:54] <seb128> overwrite
[14:55] <seb128> brb
[15:01] <ember> mvo_ thanks for vte
[15:03] <kenvandine_wk> mvo_: ok... it worked this time
[15:03] <kenvandine_wk> mvo_: why does it keep sleeping after the applet was added?
[15:05] <mvo_> kenvandine_wk: it worked? excellent .)
[15:05] <mvo_> kenvandine_wk: hm, but it did not stop? its still running?
[15:06] <mvo_> kenvandine_wk: can I see your .xsession-errors file please?
[15:06] <kenvandine_wk> counted to 89
[15:06] <kenvandine_wk> sure
[15:07] <mvo_> kenvandine_wk: if you have a snpashot of the machine state, could you run it 2-3 times just to be sure that there is no race or other craziness left please?
[15:07] <mvo_> ember: thanks for doing it in the first place :)
[15:07] <kenvandine_wk> mvo_: i attached the latest .xsession_errors to the bug
[15:07] <kenvandine_wk> i will do it several times, yeah
[15:08] <kenvandine_wk> i started tailing the .xsession-errors after i saw the applet appear, and it was at sleep 13
[15:08] <kenvandine_wk> so it was added before that
[15:19] <kenvandine_wk> mvo_: damn... with another test user account, it didn't fire at all again
[15:21] <mvo_> kenvandine_wk: what does gconftool -g /apps/panel/need_add_indicator_applet print for that user?
[15:27] <kenvandine_wk> mvo_: ok, i reverted my snapshot and it is still failing
[15:27] <kenvandine_wk> i have some strace out put
[15:27] <kenvandine_wk> but i don't think it is very revealing
[15:28] <kenvandine_wk> after it finishes sleeping, /apps/panel/need_add_indicator_applet print is false
[15:28] <mvo_> hm, that explains why its not run (it only runs when that is true). but that is not a lot of explaination :)
[15:28] <kenvandine_wk> ok, i have a test user account that doesn't have that set prior to logging in
[15:28] <kenvandine_wk> let me test with that one again
[15:29] <kenvandine_wk> ok, sleeping
[15:30] <kenvandine_wk> confirmed it isn't set while it is sleeping
[15:30]  * kenvandine_wk waits for it
[15:31] <kenvandine_wk> mvo_: ok, it is done sleeping and that key isn't set still
[15:31] <kenvandine_wk> and it didn't get added
[15:31] <kenvandine_wk> what info would be useful?
[15:32] <mvo_> kenvandine_wk: anything in strace that gives me a hint wth its doing when its finished couting :)
[15:32] <mvo_> kenvandine_wk: that is so odd, it should print something or fail with a exception or something, but just stoping silently is so strange
[15:33] <kenvandine_wk> damn... so after logging out and back in, that key is set
[15:33] <seb128> how do you run it?
[15:33] <kenvandine_wk> to false
[15:34] <kenvandine_wk> mvo_: i am going to eat before our meeting, will revert and capture the strace after
[15:34] <kenvandine_wk> seb128: xdg/autostart
[15:34] <mvo_> kenvandine_wk: thanks, sorry that its such a hassle
[15:34] <kenvandine_wk> if i run the script by hand it works reliably
[15:34] <seb128> ok so that's the current user
[15:35] <seb128> weird
[15:35] <kenvandine_wk> mvo_: no worries... just want it to work :)
[15:36] <kenvandine_wk> mvo_: oh scratch that... now it doesn't run manually
[15:36] <kenvandine_wk> it just sleeps
[15:36] <kenvandine_wk> this will make it easier to debug :)
[15:36] <kenvandine_wk> bbiab... gotta eat
[15:45] <didrocks> seb128: do I push gnome-backgrounds in ~ubuntu-desktop too?
[15:45] <seb128> didrocks: no, just upload, I think we will sync with debian when they update, no reason to have ubuntu diff there
[15:46] <didrocks> seb128: ok. I was wondering because we didn't sync to debian during the intrepid cycle, but probably because of debian freeze…
[15:47] <seb128> didrocks: dunno what they did, maybe it's just that nobody watched their updates and ask for a sync
[15:47] <didrocks> seb128: oki
[15:54] <didrocks> seb128: I'm done with the updates, going for a walk, but you can still give me some updates and I will takle them this evening :)
[15:54] <seb128> didrocks: ok, we are good right now, I would like to wait on debian for quite some things where there is no hurry and we are on sync right now (ie all the remaining *mm for example)
[15:55] <seb128> didrocks: enjoy your walk
[15:55] <didrocks> seb128: thanks a lot, enjoy testing :)
[16:01] <ember> seb128 mind if i do sj (universe) ?
[16:01] <seb128> ember: you can do it
[16:02] <seb128> ember: you can also do gnome-system-tools if you want
[16:02] <asac> is meeting in 30 min?
[16:02] <pitti> asac: yes
[16:02] <seb128> asac: correct
[16:02] <ember> seb128 cool, i will have a look
[16:02] <seb128> thanks
[16:02] <kenvandine_wk> mvo_: i attached a patch to the issue
[16:02] <kenvandine_wk> it was a typo :)
[16:03] <seb128> kenvandine_wk: good work ;-)
[16:04] <kenvandine_wk> no idea why the traceback wasn't making it to .xsession-errors
[16:08] <mvo_> kenvandine_wk: gar
[16:08] <mvo_> kenvandine_wk: thanks
[16:08] <mvo_> kenvandine_wk: i was suspecting something like this, but then I even added a exception handler to be sure any errors make it to the console
[16:10] <kenvandine_wk> mvo_: i just assumed anything like this would have made it to the log
[16:10] <mvo_> yeah, strange, strange
[16:10]  * mvo_ scratches head a bit more
[16:10] <kenvandine_wk> i just tested several scenarios, all good
[16:10] <mvo_> ok, cool
[16:11] <kenvandine_wk> i will revert my snapshot and try again when you have a new build in your ppa... to be sure :)
[16:11] <mvo_> I will do a final test with the fix and upload afterwards
[16:11] <mvo_> aha, ok
[16:11] <mvo_> makes sense to have one more ppa version I think, I will remove a lot of the verbosity as well
[16:11] <kenvandine_wk> i also tested without a notification area
[16:12] <mvo_> it should do nothing in this case (only print a error to the logs)
[16:12] <kenvandine_wk> yeah
[16:27] <rickspencer3> desktop team meeting in 3 minutes
[16:27] <pitti> hey
[16:27]  * pedro_ waves
[16:28]  * kenvandine_wk is here
[16:29] <rickspencer3> pedro_: hi!
[16:29] <ArneGoetje> Hi all!
[16:30] <asac> hi
[16:30] <rickspencer3> good evening ArneGoetje
[16:30] <pitti> what a refreshing discussion about units..
[16:30] <seb128> hello
[16:30] <bryce> heya
[16:30] <rickspencer3> I think we have a quorum
[16:30] <rickspencer3> seele: welcome!!
[16:30]  * seele gasps
[16:31] <rickspencer3> how about calc
[16:31] <seele> rickspencer3: hello
[16:31] <rickspencer3> okay, let's go
[16:32]  * asac opens wiki page
[16:32] <rickspencer3> Outstanding actions from last meeting:
[16:32] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/67188
[16:32] <rickspencer3> seemed like an important bug, but also really a collection of other bugs, so I unassigned it based on discussions with bryce
[16:32] <rickspencer3> ACTION: calc and pitti to discuss https://bugs.edge.launchpad.net/bugs/305790 - getting certain java based build depends for OO to build in the build daemons.
[16:33] <pitti> I had a go on those, see my activity report
[16:33] <rickspencer3> it looks like there was some significant pain associated with that
[16:33] <rickspencer3> yes, also see https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:33] <pitti> I wasted some 3 hours and finally succeeded to build it with openjdk
[16:33] <pitti> but it breaks the test suite
[16:33] <rickspencer3> :(
[16:33] <asac> that bug is quite length i lost track what is left
[16:33] <pitti> I quickly consulted with doko
[16:33] <asac> could we update the summary to show what is really the problem?
[16:33] <pitti> and we agreed to just leave it getting built with gcj for now
[16:34] <pitti> asac: jaxme and xom don't build with openjdk, just with gcj
[16:34] <asac> hmm. ok
[16:34] <rickspencer3> pitti: that should suffice for Karmic, right? Even if we need to rebuild for some reason?
[16:34] <pitti> rickspencer3: for jaunty anyway, yes
[16:34] <pitti> eventually we might want to get rid of gcj
[16:34] <rickspencer3> I meant Jaunty, sorry
[16:34] <pitti> but not in jaunty
[16:34] <rickspencer3> ok
[16:34] <pitti> rickspencer3: yes, I confirmed that both build fine with gcj
[16:34] <pitti> calc worked on xom
[16:34] <rickspencer3> so that should help in our bug conversation in a few minutes
[16:35] <pitti> and determined that the failure on i386 is a bug in openjdk
[16:35] <pitti> builds fine on amd64
[16:35] <pitti> he reported it
[16:35] <rickspencer3> interesting
[16:35] <rickspencer3> last action from last week: ACTION: everyone hasn't already to submit a topic by eow (mandated by rickspencer3  )
[16:35] <rickspencer3> I will assume that everyone did this, if not, please let me know and I'll see if I can slide you in
[16:35] <rickspencer3> topic was for all hands, btw
[16:36] <seb128> urg
[16:36] <seb128> I didn't, what should we hand those?
[16:36]  * seb128 has been swamped in GNOME 2.26
[16:36] <rickspencer3> seb128: understood
[16:36] <rickspencer3> I'll talk to silbs and see what we can work out
[16:36] <pitti> seb128: great job with 2.26! *hug*
[16:36]  * seb128 hugs pitti
[16:36] <rickspencer3> seb128: no worries
[16:36] <rickspencer3> moving on ...
[16:37] <rickspencer3> UDS sponsorship: send rickspencer3 an email if there is someone that you feel is important to sponsor
[16:37] <rickspencer3> I've already discussed this with seb128 and bryce
[16:37] <asac> didnt get a mail
[16:37] <rickspencer3> let's not go over that again
[16:37] <rickspencer3> :)
[16:37] <kenvandine_wk> hehe
[16:38] <rickspencer3> I'm just saying, that I can advocate for sponsorship, so if there is someone that you think we should sponsor, send me an email by, say, end of day tomorrow
[16:38] <pitti> breaking news, xom is fixed with openjdk, thanks to doko
[16:38] <rickspencer3> nice!
[16:38]  * calc is here btw :)
[16:39] <rickspencer3> moving on to release status ...
[16:39] <rickspencer3> bugs
[16:39] <rickspencer3> bugs
[16:39] <bratsche> eeejay: Hey, are you doing something already with kerneloops regarding the <a href...></a> stuff?
[16:39] <rickspencer3> great job on the work items for Jaunty!
[16:39] <pitti> rickspencer3: I have some things, when you are done with bugs
[16:40] <rickspencer3> pitti: do you want to go now?
[16:40] <pitti> sure
[16:40]  * rickspencer3 hands mike to pitti
[16:40] <pitti> so, intrusive changes
[16:40] <pitti> new themes are in now, done
[16:40] <pitti> asac: what's the latest word on the firefox start page patch?
[16:41] <asac> pitti: the newtab page you mean?
[16:41] <pitti> bryce: do you still consider updating to the new intel driver, or will we settle on the current version and backport?
[16:41] <pitti> asac: yes
[16:41] <asac> pitti: decision still pending. i think its getting less likely every day
[16:41] <bryce> pitti: still considering
[16:41] <pitti> bryce: we should get that in before beta IMHO (or not at all)
[16:41] <bryce> pitti: right now it depends on a kernel change, but I talked with upstream and may be able to work around that in the driver
[16:41] <pitti> bryce: is there a PPA or something we should test?
[16:42] <bryce> pitti: without the fix, it doesn't build
[16:42] <pitti> asac: understood; it's not the end of the world if it slips to Karmic, right?
[16:42] <bryce> pitti: hopefully should have something in today
[16:42] <pitti> bryce: ok, so it's still on the table
[16:43] <asac> pitti: personally, i dont need it
[16:43] <pitti> thanks for the heads-up
[16:43] <asac> there are other forces ;)
[16:43] <pitti> asac: heh :)
[16:43] <pitti> and finally, new on the list, change of the default font size again
[16:43] <asac> but i hope we have that under control now
[16:43] <pitti> that's another change I'd call "intrusive" and needs lots of feedback
[16:43] <asac> (newtab forces)
[16:43] <pitti> and it should really land in beta
[16:43] <seb128> pitti: right, let's do that before beta
[16:43] <asac> we should get the fontsize change up well before beta and the GUI fix at best before
[16:43] <pitti> from my perspective it seems that discussion is pretty much done on that?
[16:43] <seb128> it's easy enough to roll to what we had if needed
[16:43] <asac> but the defaultis most important
[16:44] <pitti> or are there outstanding things which need input/discussion?
[16:44] <asac> pitti: the default is agreed. the UI thing not so. seems to be in gtk, but i have to read more code to say how to fix the units there
[16:45] <pitti> asac: so you think we shouldn't ship 13.33px and leave the UI in pt?
[16:45] <asac> pitti: i think we should do both. just that we should get the default in now, as the UI will take a few days
[16:45] <pitti> asac: agreed
[16:45] <asac> hopefully we can fix the UI before beta too.
[16:45] <asac> but i havent really found the right place yet so i cannot tell
[16:45] <pitti> is someone working on that already?
[16:46] <pitti> is there an LP # for this?
[16:46] <asac> i started on it. if someone else wants to fix gtk i would be happy to delegate that
[16:46] <seb128> please don't put a float number in the UI ;-)
[16:46] <asac> pitti: no. not yet
[16:46] <seb128> or at least .5 ;-)
[16:46] <eeejay> hey bratsche, nope i am going to get to it this week though
[16:46] <pitti> asac: "gtk" is gnome-appearance-properties"?
[16:47] <pitti> rickspencer3: over to you
[16:47] <asac> pitti: well. its done in the gtkfontselector i think
[16:47] <asac> pitti: thats gtk
[16:47] <bratsche> eeejay: Okay.. I might end up taking it from you.  I'll let you know.
[16:47] <pitti> I see
[16:47] <rickspencer3> can someone please either get the bug # or create a bug for that?
[16:47] <asac> pitti: but i didnt find how the available size choices are assembled there
[16:47] <eeejay> bratsche: no problem
[16:47] <seb128> right, the font picker is a gtk widget
[16:47] <eeejay> bratsche: i'll ping you before i start
[16:47] <bratsche> Cool, sounds good.  Thanks.
[16:47] <seb128> asac: I guess it's using pango or fontconfig to get the list...
[16:48] <asac> seb128: another option would be to keep the fontselector using pt ... jus that those are no real "pt"s, but rather pts for 96 dpi (e.g. 10 will always be 13.333px in the back)
[16:48] <davmor2> bryce: just to let you know I've just done an Oem install of Kubuntu and it's worked fine :)
[16:48] <asac> seb128: a bit hard to not get round issues when calculating current value
[16:48] <pitti> asac: according to our discussion, nobody really knows what those units mean anyway, after all
[16:48] <pitti> if you fiddle with the size, you just set a number that looks good, and be done with it
[16:49] <bryce> davmor2: excellent thanks; if that's in ref to a bug, please comment there (and close the bug if you filed it originally)
[16:49] <asac> pitti: yeah. i think we can keep the current numbers there
[16:49] <rickspencer3> where did this whole thing come from?
[16:49] <pitti> a "pt for 96dpi" is utter bogus anyway, that's a pixel
[16:49] <asac> pitti: just have to find a sensible way back without rounding issues.
[16:49] <davmor2> bryce: np's
[16:49] <bryce> rickspencer3: fallout from switching from 96 dpi override to "true dpi"
[16:49] <asac> pitti: "pt for 72 dpi" is a pixel ;) (me shuts up)
[16:49] <seb128> rickspencer3: feedback from the "let's use the detected dpi value and no 96 dpi"
[16:49] <pitti> asac: ah, you are saying that if we configure 13.333px by default, the font selector won't show "10", but somethign ugly?
[16:50] <rickspencer3> I think we should move this discussion to a lp bug asap
[16:50] <seb128> rickspencer3: bug #310353
[16:50] <asac> pitti: i want it to display 10
[16:50] <pitti> asac: right, that would be nice
[16:50] <seb128> rickspencer3: bug #310353
[16:50] <asac> pitti: just a bit scared about rounding. but thats experimenting
[16:50] <pitti> asac: on a 96dpi, anyway
[16:50]  * seb128 kicks the bot or launchpad
[16:50] <asac> pitti: yes. 10 just means "this is 10pt converted to pixel on a 96 dpi" ;)
[16:50] <rickspencer3> the bug is set to wishlist
[16:50] <calc> hmm shouldn't a pt be 1/72 of an inch?
[16:50] <rickspencer3> why would we be working on it two days before beta lock down?
[16:50] <calc> and if its not its a bug? :)
[16:51] <pitti> oh no not again :)
[16:51] <pitti> calc: cf half an hour in #distro
[16:51]  * calc looks over there after meeting
[16:51] <asac> rickspencer3: its an annoying issue. that if we can fix it would make jaunty better
[16:51] <asac> rickspencer3: also non standard dpi screens become more and more common
[16:51] <pitti> calc: it's an inverse subspace relative megasubpixel
[16:52] <rickspencer3> we need to ensure that we are using our diminishing time on the most important things, and if it's marked as "wishlist" it suggests there are more important things to work on
[16:52]  * kenvandine_wk thinks the font change is important
[16:52] <seb128> rickspencer3: wishlist might not be an adapted setting there
[16:52] <calc> hmm if pt doesn't work at all then i don't see the point in using real dpi to begin with (but will discuss that later)
[16:52] <seb128> rickspencer3: there is case where GNOME is not usable apparently on notebooks due to that
[16:52] <asac> rickspencer3: we can flip it to "high" ;)
[16:52] <pitti> ok, let's move discussion to the bug
[16:52] <rickspencer3> may I suggest that we set the important appropriately, and also assign it to the person who is going to fix it
[16:52] <seb128> rickspencer3: that has just been rasied as a concern recently though
[16:53] <seb128> rickspencer3: good idea
[16:53] <pitti> it's a regression compared to intrepid
[16:53] <seb128> asac: you? ;-)
[16:53] <rickspencer3> then discuss the value and options in the bug itself?>
[16:53] <asac> seb128: yes. do that for now. if i dont figure the font picker interactino i will ask for help though
[16:54] <rickspencer3> moving on, there are a few other bugs that are supposed to be fixed by beta
[16:54] <pitti> marked for jaunty beta
[16:54] <rickspencer3> bug #278095
[16:54] <asac> rickspencer3: not sure why luke hasnt uploaded my fix
[16:54] <asac> its handed over to him for sure
[16:54] <asac> pinging him on -devel now
[16:54] <rickspencer3> ok
[16:54] <rickspencer3> bug #340777
[16:54] <seb128> mvo and kenvandine_wk were still debugging that today
[16:55] <seb128> kenvandine_wk found an issue in the script
[16:55] <seb128> if next testing round is ok we will upload tomorrow I guess
[16:55] <rickspencer3> stupid testing ;)
[16:55] <rickspencer3> ok, so on track, but risky
[16:55] <kenvandine_wk> rickspencer3: i think it is good to go... but needs another test from a real build
[16:55] <rickspencer3> not risky, really
[16:55] <seb128> if that's before beta I think we are fine, it's only the applets layout
[16:56] <rickspencer3> kenvandine_wk: ack
[16:56] <rickspencer3> bug #337869
[16:56] <rickspencer3> we just discussed
[16:56] <rickspencer3> and the related bug #305790
[16:56] <rickspencer3> as well
[16:57] <pitti> rickspencer3: I think that was really for xom, not suitesparse
[16:57] <pitti> and xom is fixed now
[16:57] <rickspencer3> pitti: ok
[16:58] <rickspencer3> It seems like we can move one to "fixed" and the other, just move it out of jaunty altogether
[16:58]  * calc is on phone with doctor
[16:58] <rickspencer3> Riddell has a couple of medium bugs, but he's in the Kubuntu meeting
[16:58] <rickspencer3> moving on to work items ...
[16:59] <rickspencer3> The only one to discuss is asac:Adobe Flash in partner repository with apturl:started
[16:59]  * calc back
[16:59] <rickspencer3> asac: mvo_ what's the status of this? Anything we need to know for beta?
[17:00] <rickspencer3> while we're waiting for that compute ...
[17:00] <asac> rickspencer3: no progress last week. me and mvo_ should find the time
[17:00] <asac> asap
[17:00] <asac> mvo_: ^^^
[17:00] <asac> mvo_: tomorrows?
[17:01] <rickspencer3> ok
[17:01] <rickspencer3> moving on ...
[17:01] <seb128> poor mvo
[17:01]  * seb128 hugs mvo_
[17:01] <rickspencer3> asac: are the new NM icons in Jaunty, ready for beta?
[17:01] <seb128> everybody needs him to get things done before beta ;-)
[17:02] <rickspencer3> are there any other items that anyone wants to bring up regarding getting ready for beta?
[17:02] <pitti> any news wrt. new usplash theme?
[17:02] <rickspencer3> Any dependencies on other teams that we should follow up on, etc... ?
[17:02] <pitti> or desktop background?
[17:03] <pitti> Ken said he'll be working on a new usplash theme, if we get it, but I don't know bout desktop background
[17:03] <seb128> is every settled for the message indicator now?
[17:03] <mvo_> asac, rickspencer3: sorry for the delay. asac and I can work on it tomorrow
[17:03] <seb128> ie pidgin correctly configured by default?
[17:03] <kenvandine_wk> seb128: not yet
[17:04] <pitti> new indicator-applet doesn't build yet
[17:04] <asac> rickspencer3: i think the icons are ready in general. some notifications might not match the spec 100%, but we will be close
[17:04] <kenvandine_wk> i think we are still waiting for clarification on what should happen
[17:04] <rickspencer3> pitti: I think kwwii has them close to done, and will get what he has into the beta, but they may change
[17:04] <pitti> it needs to get the gnome-introspection bits removed
[17:04] <seb128> pitti: build-dep on the gir thing
[17:04] <rickspencer3> asac: ack, thanks
[17:04] <pitti> seb128: it's not just the build dep, it needs code and autofoo changes
[17:04] <seb128> urg, ok
[17:04] <pitti> I'll take that up with tedg
[17:05] <seb128> thanks
[17:05] <rickspencer3> oookay
[17:05] <seb128> are we ready otherwise for notifications? notify-osd still seems to have quite some issues and some applications are not patched yet
[17:05] <rickspencer3> sounds like the MI and configuration of related apps may need some loving attention
[17:05] <seb128> I would say all the dxteam stack need some consolidation work
[17:06] <rickspencer3> seb128: I think they are focused on fixing crashing bugs, and getting pidgin and evo working properly with the MI for beta
[17:06] <seb128> notify-osd was breaking for quite some user until today, I pushed to get an updated version today but nobody is really reactive on those bugs
[17:06] <seb128> we got the updated version
[17:06] <kenvandine_wk> there are a few crashers they are still working on
[17:06] <seb128> (the wording was not clear)
[17:07] <seb128> right
[17:07] <seb128> I'm rather concerned about having lot of users saying that synchronous notifications are broken for them
[17:07] <seb128> or they don't get volume indicators
[17:07] <rickspencer3> seb128: are there bugs for those issues?
[17:07] <seb128> or no rhythmbox artwork
[17:08] <seb128> rickspencer3: yes, I know about the issue because I subscribed to the notify-osd bugs and see the comments
[17:08] <kenvandine_wk> rickspencer3: there are
[17:08] <seb128> I've not really investigated though
[17:08] <seb128> but that doesn't give me a lot of confidence on the robustness
[17:08] <seb128> I think we lag behind in testing and quality work there ... we still have time after beta for that though
[17:08] <rickspencer3> seb128: yes
[17:08] <kenvandine_wk> we need more people using it :)
[17:09] <rickspencer3> and we may have to rally some troops to help
[17:09] <seb128> right, just raising the issue early
[17:09] <rickspencer3> in the meantime, davidbarth is well aware of the bugs and is focused on fixing them asap
[17:09] <seb128> good
[17:10] <rickspencer3> I'm confident that we will be able to help them bring those features together and really have a great system in Karmic
[17:10] <rickspencer3> I think if anyone sees a worrisome bug, and is concerned that it is not getting the attention it needs, to raise the issue with me and/or davidbarth immediately
[17:10] <seb128> right, my comment is rather a call for community help to test everything and make sure we triage bugs correctly and have things under control
[17:11] <rickspencer3> seb128: yes
[17:11] <rickspencer3> but maybe we should err on the side of raising concerned instead of waiting, as time is of the essence
[17:11] <rickspencer3> otherwise ...
[17:12] <rickspencer3> any other business?
[17:12] <bryce> looks like we'll have -fglrx for beta
[17:12] <rickspencer3> nice
[17:12] <kenvandine_wk> oh?
[17:12] <kenvandine_wk> awesome
[17:12] <bryce> also -ati is going to be updated with 6xx/7xx support for 2D (EXA/Xv) acceleration later today.
[17:12] <bryce> so ATI is in wonderful shape right now
[17:13] <bryce> -intel not as much, but I have some ideas of improvements...
[17:13] <asac> ATI Technologies Inc R580 ... still no compiz ;)
[17:13] <pitti> bryce: pour some magic sauce into it?
[17:14] <bryce> where magic sauce == kludges ;-)
[17:14] <bryce> rickspencer3: over.
[17:14] <rickspencer3> ok
[17:14] <rickspencer3> any other business?
[17:14] <rickspencer3> meeting adjourned?
[17:14] <pitti> thanks everyone
[17:14] <bryce> thanks
[17:14] <seb128> thanks
[17:15] <pitti> let's get a great beta out
[17:15] <rickspencer3> thanks all
[17:15] <calc> thanks
[17:15] <rickspencer3> beta beta beta
[17:15] <pitti> I still have the feeling that it's going to be a good one
[17:15]  * kenvandine_wk does too
[17:15] <bryce> pitti: I've been hearing happy anecdotal reports from people, who are finding it much more solid than Intrepi
[17:15] <seb128> yeah, I think jaunty is solid and will be one of the best ubuntu version we rolled until now
[17:15] <bryce> +d
[17:16] <seb128> if not the best one
[17:16] <pitti> now, if only suspend would work, it'd be perfect :)
[17:16]  * asac reminds himself to run alpha6 suspend tests
[17:16] <pitti> well, it's the x.org hang that spoils it, the test suite runs fine for me
[17:17] <asac> hmm
[17:17] <asac> for me things improved when i moved by from UXA to EXA for X
[17:17] <pitti> no answer from upstream about that, though
[17:17] <asac> but thats probably not your issue
[17:17] <pitti> I'm not running UXA
[17:17] <pitti> although, with the recent compiz fix, I should try it again
[17:22] <kenvandine_wk> pitti: UXA is what makes compiz usable for me :)
[17:22] <pitti> hm, works just fine on GMA945 for me
[17:22] <kenvandine_wk> mine's a 965
[17:22] <kenvandine_wk> horribly slow without UXA
[17:22] <bryce> the UXA benefits/problems are not chipset specific
[17:23] <bryce> near as I can tell anyway
[17:23] <bryce> well, not chipset _family_ anyway
[17:23] <calc> OOo hopefully will be much improved for people saving to remote filesystems as well :)
[17:23] <seb128> exa and compiz is just fine on my dell630 intel 965
[17:24] <pitti> calc: it's also the first time we ship 3.0; that got good grades in reviews
[17:24] <calc> i only know of one real bug still and its wrt saving on webdav, the ftp issue was a pureftpd bug
[17:29] <pitti> rickspencer3: 9.10 roadmap call now, right?
[17:31] <rickspencer3> pitti: yes
[17:44]  * didrocks back on the field, if needed :)
[17:48] <seb128> didrocks: how was your walk?
[17:49] <didrocks> seb128: great, thanks! It's good something to breathing some fresh air in the mountains ;)
[17:49] <didrocks> s/something/sometimes
[17:49] <seb128> didrocks: you live in the mountains?
[17:49] <chrisccoulson> didrocks - i would love some fresh air ;)
[17:49] <didrocks> seb128: my parents, yes, near Annecy. I live in Paris for work :/
[17:50] <didrocks> chrisccoulson: where do you live? ;)
[17:50] <seb128> didrocks: ah ok, that's what I though for Paris, I didn't get that you were not at your place today
[17:50] <chrisccoulson> birmingham, uk
[17:50] <chrisccoulson> there's no fresh air here
[17:50] <didrocks> seb128: yes live near Metz, don't you?
[17:50] <seb128> didrocks: yes
[17:50] <didrocks> seb128: vacation IS vacation :p
[17:50] <seb128> ;-)
[17:51] <Laney> mmm birmingham
[17:51] <didrocks> chrisccoulson: yeah, I can imagine :/
[17:51] <chrisccoulson> i only live here because i work here
[17:59] <seb128> didrocks: you can have a look to http://download.gnome.org/sources/gnome-web-photo/0.6/gnome-web-photo-0.6.tar.gz if you want since that's universe
[17:59] <seb128> didrocks: but if you prefer to do something else just relax we are done with most of the updates
[17:59] <didrocks> seb128: don't know this software, I will have a look :)
[18:03] <seb128> didrocks: otherwise there is some desktopish universe updates in the sponsoring queue if you want to help motu there and use your uploads rights ;-)
[18:03] <didrocks> seb128: I have already planned to tackle some tomorrow :)
[18:04] <didrocks> (and I have to update my book in parallel ;))
[18:04] <seb128> didrocks: ok, that's enough for you then, goof work ;-)
[18:05] <seb128> good
[18:05] <didrocks> seb128: thanks, sorry for not having been there from the beginning, but the schedule was not good. Next time!
[18:05] <seb128> didrocks: that's ok you did your share ;-)
[18:06] <didrocks> ^^
[18:06] <seb128> didrocks: do you know how huats is doing btw?
[18:06] <seb128> chrisccoulson: hey, not sure if I already asked yesterday but do you want to do the gnome-session update?
[18:06] <didrocks> seb128: very busy with his company creation, lots of paper to do and so on…
[18:06] <chrisccoulson> yeah, i can do that
[18:06] <seb128> chrisccoulson: thanks
[18:06] <didrocks> seb128: but he seems fine :)
[18:07] <seb128> chrisccoulson: not sure if vuntz commited the code for session storing (it's not active for sure) but there is an update patch otherwise on the GNOME bug
[18:07] <seb128> didrocks: ok good
[18:07] <seb128> chrisccoulson: would be nice to update the patch if it's not in the tarball ifdef-ed #0
[18:07] <chrisccoulson> i'll take a look at that
[18:07] <seb128> thanks
[18:08] <chrisccoulson> i saw the discussions yesterday about session saving behaving differently between shutdown and logout
[18:08] <chrisccoulson> what happened with that in the end?
[18:09] <seb128> vuntz said he would fix it but I don't think it's done yet
[18:09] <chrisccoulson> ah, ok
[18:10] <chrisccoulson> i was going to say that if it gets fixed, it would be nice to make the session saving work with the FUSA too
[18:11] <seb128> it does
[18:11] <seb128> no?.
[18:11] <seb128> I think I tried logout from fusa too and it worked
[18:11] <chrisccoulson> it does for logout, but not for shutdown/reboot
[18:13] <seb128> right, neither does gnome-session
[18:13] <seb128> that's just that the codepath is different for those actions and vuntz didn't notice immediatly
[18:13] <seb128> ie it's a TODO item on his list
[18:14] <didrocks> FUSA calls gnome-session to perform actions, doesn't it?
[18:14] <chrisccoulson> didrocks - for shutdown/reboot, FUSA uses consolekit
[18:14] <chrisccoulson> seb128 - it's probably too late to fix in this cylce isn't it?
[18:14] <seb128> urg
[18:14] <didrocks> chrisccoulson: oh ok, so saving session has to be fixed twice…
[18:14] <seb128> no, that should really be fixed
[18:15] <seb128> it would suck to have gnome-session fixed but fusa buggy
[18:15] <seb128> fusa should just use gnome-session
[18:15] <didrocks> seb128: it seems the right way…
[18:15] <chrisccoulson> seb128 - i agree. the only issue is that gnome-session doesn't provide an API for shutting down or rebooting without popping up the session dialog
[18:16] <chrisccoulson> it does for logging out, but not for shutting down or rebooting
[18:16] <seb128> chrisccoulson: update-notifier manage to do it
[18:17] <seb128> using xsmp I think
[18:17] <chrisccoulson> update-notifier uses gdm-signal and GnomeClient
[18:17] <chrisccoulson> yes
[18:17] <seb128> fusa could do that too
[18:17] <mvo_> MacSlow: compiz with the fade changes uploaded
[18:17] <chrisccoulson> thats pretty much what FUSA used to do, but you cant integrate policykit support that way
[18:17] <seb128> so we have the choice between session saving and policykit?
[18:18] <chrisccoulson> if gnome-session exported a dbus method to immediately shutdown or reboot, then you'd get session saving and policykit support for free;)
[18:18] <seb128> right, that is karmic material though
[18:18] <chrisccoulson> definately
[18:18] <seb128> I guess my choice would be to roll back your policykit change then
[18:19] <seb128> we don't have so many issues to multiple users logged-in
[18:19] <chrisccoulson> possibly. but session saving isn't working at the moment is it?
[18:19] <seb128> but lot of vocal complains about session crashing applications rather than closing those
[18:19] <seb128> what do you call session saving?
[18:19] <seb128> it's working for logout
[18:20] <seb128> it's likely that it will be working for restart etc before GNOME 2.26.1 too
[18:20] <chrisccoulson> by session saving, i suppose i mean "not just killing the users applications"
[18:20] <seb128> ie for jaunty
[18:20] <seb128> right, that's working for logout since saturday in jaunty
[18:20] <seb128> and that will be working for the other actions before jaunty
[18:20] <seb128> ie gedit ask if you want to save your work
[18:21] <seb128> firefox doesn't display the crash dialog on next login
[18:21] <seb128> etc
[18:22] <chrisccoulson> if it is working for 2.26.1, then i don't mind doing work to make this work with FUSA too
[18:22] <seb128> ok so start working on it ;-)
[18:23] <chrisccoulson> i'll take a look and see how much effort it would need. i suspect it probably isn't that much ;)
[18:23] <seb128> you rock!
[18:23] <chrisccoulson> :D
[20:07] <mvo_> chrisccoulson: I looked over #344460 and commented (but go to bed now)
[20:08] <mvo_> chrisccoulson: let me know what you think, I'm happy to sponsor it tomorrow (unless someone else is faster of course)