[02:47] <nekohayo> ping jono?
[02:47] <jono> nekohayo, hey
[02:48] <nekohayo> hey there, I was curious about something regarding the pitivi MIR... I never really got an answer whether it was possible or not for pitivi to go past the 18th's feature freeze deadline or not
[02:48] <nekohayo> (maybe I didn't ask the proper people or clearly enough)
[02:48] <nekohayo> I'd just like to know if this is an option available
[02:49] <nekohayo> or if it really really has to be done within the next 2 days
[02:49] <nekohayo> so wondering if you have any idea regarding that
[02:54] <dobey> isn't pitivi in main already?
[02:55] <dobey> it appears it is
[02:55] <nekohayo> dobey, yes, but it's an old version
[02:55] <dobey> at least, apt thinks it is, and it was installed when i upgraded to lucid
[02:55] <nekohayo> (that's the problem)
[02:56] <nekohayo> many bugs are fixed in the dev version, and we'd like to at least have basic crossfade transitions in
[02:56]  * dobey thinks it was a noble goal, but perhaps poor timing, to include pitivi by default
[02:57] <nekohayo> perhaps
[02:58] <nekohayo> if it can't be done it could be postponed to lucid+1, but if it can be squeezed with crossfade transitions, that could do it
[02:59] <nekohayo> emdash is working on easy crossfading transitions, but I'm hesitant to say it would be completed in the next 48 hours
[03:01] <nekohayo> maybe rickspencer3 would know :)
[03:01] <rickspencer3> maybe
[03:01] <rickspencer3> what's up?
[03:01]  * rickspencer3 has no scrollback
[03:02] <nekohayo> rickspencer3, http://pastebin.com/d133bc4c
[03:02]  * rickspencer3 braces for rickroll
[03:02] <nekohayo> :)
[03:03] <rickspencer3> nekohayo, what do you mean about going past feature freeze?
[03:03] <rickspencer3> we typically do lots of bug fixing and tweaking past feature freeze, but stop adding features
[03:03] <nekohayo> a freeze exception
[03:03] <nekohayo> hm
[03:03] <rickspencer3> (but there are exceptions)
[03:03] <rickspencer3> what are you wanting to do?
[03:04] <rickspencer3> crossfades and transitions?
[03:04] <nekohayo> we'll I'm just evaluating the options, 'cause 0.13.3 is old now, but 0.13.4 is not yet out the door
[03:04] <rickspencer3> ah
[03:04] <rickspencer3> these are indeed tough calls to make
[03:04] <nekohayo> there are many users struggling with weird bugs that are absent from the git version
[03:04] <rickspencer3> when is 13.4 currently scheduled to be ready?
[03:05] <rickspencer3> we often update to a later version after freeze
[03:05] <nekohayo> that's the thing, I'm not sure; https://bugzilla.gnome.org/buglist.cgi?product=pitivi&target_milestone=0.13.4
[03:05] <nekohayo>  <-- could help seeing the bugs remaining
[03:05] <rickspencer3> but if there are risky new features in the newest release, we sometimes dig up
[03:05] <rickspencer3> patches from upstream to fix bugs in what we've got
[03:05] <rickspencer3> so, I guess "it depends"
[03:06] <nekohayo> well the git version is more stable/dependable than the 0.13.3 release, from my experience
[03:06] <rickspencer3> hmmm
[03:06] <rickspencer3> well, we certainly can evaluate which is the right version to go with
[03:07] <rickspencer3> if there is a high probability that 13.4 will be ready well before we release Lucid, it may be a good idea
[03:07] <rickspencer3> to just update to it now
[03:07]  * rickspencer3 adds to list of topics for desktop team meeting tomorrow
[03:08] <nekohayo> limited to this feature set it would be possible IMHO (but no fancy poney-shaped wipe transitions)
[03:08] <rickspencer3> yeah
[03:08] <nekohayo> so yeah bring it up to the meeting and do tell me what happens
[03:08] <rickspencer3> tbh, I'm more interested in the bug fixes, but some basic transitions would be good as well ;)
[03:08] <nekohayo> methinks that https://bugzilla.gnome.org/show_bug.cgi?id=579230 could be implemented in time for lucid since emdash is currently working on it
[03:09] <rickspencer3> ok
[03:09] <nekohayo> and it's the absolute priority feature for the next release (I "settled" for it :)
[03:09] <nekohayo> just not user that it would be done in 2 days
[03:09] <dobey> Hrmm. the 'anonymous' access to the LP API is annoyingly annoying
[03:09] <nekohayo> s/user/sure/
[03:09] <rickspencer3> nekohayo, what's you gut tell you about readiness for Lucid?
[03:09] <rickspencer3> (regarding pitivi of course ;) )
[03:10] <dobey> hrmm
[03:10] <nekohayo> what date must it be ready for, before april first I assume huh
[03:11]  * rickspencer3 checks release schedule\
[03:11] <nekohayo> my understanding of the situation is that once we get those easy crossfades implemented, and maybe that I kick the devs' butts so that they merged 2-3 patches on those bug reports, the release could be done
[03:11] <dobey> rickspencer3: my gut feeling is that something like pitivi is a pretty big change to be bringing into an LTS, without it having been part of the default install prior to LTS. but maybe the code in git is stable-ish now.
[03:12] <rickspencer3> basically, all the features need to be in by next Tuesday, though officially this Thur is the cut off
[03:12] <nekohayo> dobey, you're not entirely wrong on this, I'd say. On the other hand, I've been worrying a bit about the LTS Thing
[03:12] <nekohayo> otoh, maybe the visibility will make pitivi contributors appear in droves :)
[03:12] <rickspencer3> Then it's fixing bugs up until we ship
[03:13] <dobey> 3 years is a long time to be supporting unstable software :)
[03:13] <nekohayo> hm hm
[03:13] <dobey> nekohayo: is there a PPA with the git pitivi in it?
[03:13] <nekohayo> dobey, there is, since a few days
[03:13]  * TheMuso can't believe rickspencer3 is in here on his day/evening off. :p
[03:13]  * nekohayo searches for it
[03:13] <rickspencer3> Lets make it stable if we can
[03:14] <nekohayo> http://rowinggolfer.blogspot.com/2010/02/pitivi.html
[03:14] <rickspencer3> it's a good product that users like
[03:14] <dobey> TheMuso: freezes can be at rather inopportune times :)
[03:14] <TheMuso> dobey: yeah I am aware of that, but a day off is a day off. :)
[03:14] <rickspencer3> I'll be off in a few
[03:14] <dobey> nekohayo: get kenvandine to use that version for a bit then. I *know* he was having issues with pitivi :)
[03:15] <rickspencer3> I was just online wokring on some of my side projects
[03:15] <rickspencer3> dobey, it wasn't pitivi that was the problem
[03:15] <rickspencer3> his problem was that the gtk-recordmydesktop was not encoding files correctly
[03:15] <dobey> rickspencer3: ah
[03:15] <dobey> rickspencer3: ok. i didn't know if he got it resolved or not :)
[03:16] <rickspencer3> he didn't, but the bug is not in pitivi
[03:16] <dobey> well, garbage files are garbage files. probably can't really fix the files i guess. but good to know where the problem is
[03:18] <dobey> TheMuso: eh, I worked today too. trying to get all the ubuntu one client stuff 'done' for feature freeze
[03:19] <nekohayo> kenvandine, get your crack right there.
[03:19] <nekohayo> https://launchpad.net/~rowinggolfer/+archive/pitivi-unstable
[03:19] <nekohayo> depends on the gstreamer-developers PPA
[03:19] <nekohayo> aah, that good old recordmydesktop
[03:19] <nekohayo> I'll feel the pain again when I'll have to make a pitivi 0.13.4 screencast.
[03:19] <rickspencer3> nekohayo, just fyi, we are scheduled to make the pitivi go/no go descion for beta 2, I think
[03:20] <rickspencer3> oops, beta 1, I mean
[03:22] <TheMuso> dobey: fair enough
[03:24] <nekohayo> dobey, /me has more hopes in gnome-shell becoming the new decent screencasting tool than recormydesktop ever being fixed :|
[03:26] <dobey> Eh. I wish I could get interest and help on my project. I don't really have time to work on it though.
[03:27] <nekohayo> recordmydesktop is yours?
[03:29] <dobey> no
[03:29] <dobey> deskscribe is
[03:30]  * nekohayo searches
[03:30] <dobey> it doesn't do video recording yet, but i want it to
[03:30] <dobey> launchpad.net/deskscribe :)
[03:30] <nekohayo> oh I see
[03:32] <Amaranth> I've been tempted to resurrect the compiz video recording plugin just to get good screencasts
[03:33] <Amaranth> seems using recordmydesktop with compiz requires something better than 2Ghz C2D and intel X3100 graphics
[03:33]  * nekohayo just found out https://bugzilla.redhat.com/show_bug.cgi?id=525155
[03:33] <nekohayo> this may explain my recent troubles with r-m-d in karmic
[03:33] <nekohayo> but it doesn't explain the "broken" theora frames (https://sourceforge.net/tracker/?func=detail&aid=2827013&group_id=172357&atid=861428)
[03:34] <nekohayo> bleh
[03:37] <nekohayo> with istanbul and recordmydesktop being abandonned, my only hope is gnome shell
[07:03] <pitti> Good morning
[07:08] <baptistemm> hllo
[08:10] <didrocks> good morning
[08:10] <pitti> bonjour didrocks
[08:12] <didrocks> hey pitti
[08:15] <mvo> asac: did someone mention the GtkCellRendererSpinner to you yesterday btw?
[09:03] <chrisccoulson> good morning everyone
[09:03] <pitti> hey chrisccoulson, good morning
[09:03] <chrisccoulson> hey pitti, how are you?
[09:04] <pitti> I'm great, thanks! how about you?
[09:04]  * pitti is packaging upower
[09:04] <chrisccoulson> i'm quite tired this morning. my girlfriend is not very well, so i had quite a restless night
[09:04] <chrisccoulson> are we migrating to upower this cycle?
[09:04] <pitti> uh, I hope she'll get well soon
[09:05] <pitti> chrisccoulson: yes, I'd like to (same as udisks)
[09:05] <pitti> will make backporting patches much easier
[09:05] <chrisccoulson> cool!
[09:05] <pitti> or running backports
[09:05] <chrisccoulson> i subscribed to the bugs in udisks already
[09:05] <seb128> hey chrisccoulson pitti
[09:05] <chrisccoulson> hey seb128
[09:05] <pitti> and I already did some bug fixes in upstream trunk which the OEM team is waiting on :)
[09:07] <chrisccoulson> HR have arranged a leaving interview here with me on friday morning
[09:07] <chrisccoulson> right at the same time my breakfast arrives!
[09:08] <didrocks> hey chrisccoulson, seb128
[09:08] <chrisccoulson> hey didrocks
[09:08] <pitti> bonjour seb128
[09:09] <seb128> chrisccoulson, way to finish a week!
[09:09] <seb128> chrisccoulson, hope your gf get better too btw
[09:09] <chrisccoulson> thanks :)
[09:09] <seb128> hello didrocks, pitti
[09:12] <baptistemm> hey chrisccoulson, I saw your message or yesterday this mornig, what so I do so? comment the missing symbols ?
[09:13] <chrisccoulson> hey baptistemm - the missing symbol was never part of the public API, so it's not an issue that it is no longer exported in the new version
[09:17] <baptistemm> so I just need to remove it from the .symbols file before the building and that's it
[09:18] <chrisccoulson> baptistemm: yeah, that will work
[09:21] <chrisccoulson> baptistemm: the removed symbol was never included in any public headers
[09:22] <chrisccoulson> so i assume that they exported it by accident
[09:22] <pitti> seb128: do you have a minute to source NEW upower? (it's just a package rename)
[09:22] <seb128> pitti, sure
[09:22] <pitti> seb128: merci!
[09:23] <seb128> de rien!
[09:23] <baptistemm> chrisccoulson, by accident means a bug in dpkg-gensymbols (osrry I have now knowledge about symbol export)
[09:23] <chrisccoulson> baptistemm: the exported symbols is controlled by upstream
[09:24] <chrisccoulson> i think they ship a symbols file to control that
[09:24] <baptistemm> what does dpkg-gensymbols to knwo public symbols, does it scan *.h files?
[09:24] <baptistemm> *scans*
[09:25] <chrisccoulson> baptistemm: dpkg-gensymbols scans for symbols exported by a library (using nm, I think)
[09:25] <chrisccoulson> baptistemm: http://people.redhat.com/drepper/dsohowto.pdf
[09:25] <baptistemm> thanks
[09:25] <chrisccoulson> that has a good section of how to control symbols exported by shared libraries
[09:27] <chrisccoulson> section 2.2 "Export Control"
[09:32] <seb128> pitti, do you need shlibs when you use .symbols?
[09:33] <pitti> seb128: no, you don't
[09:33] <seb128> pitti, ok, because upower has one in the rules?
[09:33] <pitti> DEB_DH_MAKESHLIBS_ARGS_libdevkit-power-gobject1 = -- -v1:$(DEB_VERSION)
[09:33] <pitti> you mean this?
[09:33] <seb128> yes
[09:34] <pitti> seb128: without that, dpkg-makeshlibs drops the epoch from debian/libdevkit-power-gobject1.symbols and complains about the file having totally changed
[09:34] <pitti> it gets confused because it gets the package version from debian/changelog usually
[09:34] <seb128> ah I see
[09:35] <pitti> but debian/rules adds an epoch to the devkit-power-* stuff
[09:35] <pitti> (which we need, because 0.9 < 011
[09:35] <pitti> we can drop the libdevkit-power-gobject* bits at some point when everything got ported to libupower-glib
[09:37] <seb128> pitti, ok makes sense, looks good, newed
[09:37] <pitti> seb128: merci
[09:37] <seb128> de rien
[10:09] <seb128> what is working on nm-applet there?
[10:09] <seb128> what -> who
[10:10] <seb128> I got the lazy icon loading change done yesterday evening and waiting for upstream review
[10:10] <seb128> I would appreciate review and sponsoring from somebody working on nm-applet if we want that in lucid for alpha3 now
[10:11] <seb128> seems the packaging is using source in git and I'm not sure how to deal with it too
[10:11] <seb128> asac, ^?
[10:11] <pitti> Vcs-Bzr: https://code.launchpad.net/~network-manager/network-manager-applet/ubuntu.head
[10:11] <pitti> oh, it's not that one?
[10:12] <pitti> seb128: I'm happy to help out with git stuff, by now I got fairly familiar with it (*sigh*)
[10:12] <seb128> pitti, let me look again
[10:13] <seb128> I though that was in git I'm not sure why now
[10:15] <seb128> pitti, ok, I think I got confused, I will work on the update now
[10:15] <seb128> still a review from somebody else would be welcome once that is done ;-)
[10:15] <pitti> o/
[10:15] <seb128> pitti, thanks
[10:17] <asac> seb128: our packaging doesnt use git
[10:17] <asac> its the branch pitti pointed to
[10:17] <seb128> asac, yeah I got confused apparently
[10:18] <asac> seb128: get me the patch you want reviewed
[10:18] <asac> seb128: already submitted upstream?
[10:18] <seb128> asac, https://bugzilla.gnome.org/show_bug.cgi?id=609134
[10:18] <seb128> asac, the current change on this bug
[10:18] <asac> startup time?
[10:18] <seb128> asac, yes...
[10:18] <seb128> lazy icon loading
[10:18] <seb128> ie not loading 35 icons for animation when not needed
[10:19] <seb128> + the vpn ones when not using a vpn
[10:19] <seb128> etc
[10:19] <kklimonda> btw - do you have any idea why are fields in debian/control called Vcs-Bzr: Vcs-Git: instead of (for example) Vcs-Ubuntu: Vcs-Debian?
[10:20] <asac> seb128: ok. doesnt look bad on first glance. i assume you want that to be prepatched in our packaging?
[10:20] <seb128> asac, I've no strong opinion, I'm fine waiting a few days for dan to comment upstream
[10:21] <seb128> pitti, ^ how much do we want that one in for alpha3?
[10:21] <asac> ok. if you say its ok to wait, i can poke him to give his review too
[10:22] <asac> seb128: there are some indentation style changes
[10:22] <asac> like here:
[10:22] <asac> +nma_icon_check_and_load (const char *name, GdkPixbuf **icon, NMApplet *applet,
[10:22] <asac> +gboolean fallback)
[10:23] <seb128> right
[10:23] <seb128> asac, do you want a lp bug for that?
[10:23] <asac> not needed if you dont need it ;)
[10:23] <seb128> ok good
[10:23] <seb128> less work ;-)
[10:24] <asac> tell me if you want that up today for a3
[10:24] <pitti> seb128: I don't consider it a blocker for alpha-3, it doesn't have any functional change
[10:24] <pitti> seb128: so if it's easier to get in after alpha-3, fine
[10:25] <asac> k
[10:25] <asac> i will let cyphermox commit this to our branch ... so it gets in daily
[10:25] <seb128> asac, wait
[10:25] <seb128> there is another change required
[10:25] <seb128> I'm on it
[10:26] <asac> seb128: ok. let me know.
[10:28] <didrocks> note to myself: never work directly in quilt with bzr bd-do… to much chance to exit 0 before quilt refresh…
[10:31] <chrisccoulson> didrocks - oops ;)
[10:32] <chrisccoulson> did you lose much work?
[10:32] <seb128> asac, http://people.canonical.com/~seb128/nm-applet.debdiff
[10:32] <didrocks> chrisccoulson: yesterday's evening work on force refreshing cache
[10:32] <seb128> asac, one distro patch needed to be updated for the change
[10:33] <didrocks> chrisccoulson: but that's ok, 30 min to redo it when you know what to do :)
[10:33] <seb128> asac, that one should be good to use
[10:36] <seb128> asac, also can we get it to use automake1.10 instead of .9? ;-)
[10:39] <pitti> didrocks: hang on
[10:39] <pitti> didrocks: if you exit bd-do, it doesn't wipe anything
[10:39] <pitti> didrocks: it's still in ../build-tree/gnome-desktop-<version>/
[10:39] <pitti> just go back there and diff/hack/copy
[10:39] <didrocks> pitti: yes, but this morning, I've redone a bzr-do
[10:40] <didrocks> bd-do*
[10:40] <pitti> or presumably quilt diff/quilt refresh
[10:40] <pitti> ah, you lose then :(
[10:40] <didrocks> right
[10:40] <didrocks> it's ok, I've rewrite it now
[10:40] <didrocks> I launched nm on the old bin to see I didn't forget anything
[10:40] <pitti> didrocks: using the image_serialize bits?
[10:41] <didrocks> pitti: to force the caching? no, I use some part of the libgnome-desktop API
[10:41] <pitti> didrocks: no, to write the cache
[10:41] <pitti> didrocks: right now you are storing a .jpg?
[10:41] <didrocks> pitti: I didn't changed that yet
[10:41] <pitti> ah, ok
[10:42] <seb128> why does that need to be changed?
[10:42] <didrocks> pitti: I'm storing in the same format than the original file, why?
[10:42] <pitti> didrocks: mclasen suggested using this serializing API, which is even faster (avoids decoding the jpg, etc.)
[10:42] <pitti> might be worth a try
[10:43] <didrocks> pitti: right, I just want to finish my WI before alpha3, we can change that later, right?
[10:43] <seb128> brb, trying gnome-keyring update
[10:43] <pitti> didrocks: sure
[10:43] <didrocks> pitti: I still have this 2D/3D thing that was added last week on netbook-launcher
[10:44] <didrocks> pitti: so, finishing the command line, postinst is ready and then, go to the other task
[10:48] <baptistemm> asac, bluez will have a fixed release about API breakage
[11:36] <didrocks> ok, work lost again…
[11:37] <seb128> didrocks, how did you do that?
[11:38] <didrocks> seb128: this time I really don't know. I quilt add Makefile.am to include the file in the build
[11:38] <didrocks> refresh then…
[11:38] <didrocks> quilt pop -a
[11:38] <didrocks> exit 0
[11:38] <didrocks> and then, I only see the Makefile.am in the patch, no more source file
[11:39]  * didrocks get stressed
[11:39] <pitti> didrocks: why would you expect anything else than Makefile.am if you didn't add anything else?
[11:39] <didrocks> pitti: I added before the other file
[11:39] <didrocks> pitti: refresh, exit 0, and so on
[11:40] <didrocks> I obviously did something wrong, but can't find what now
[11:40] <didrocks> so, I will rewrote for the third time the file, out of quilt + bzr, and then, copy to it
[11:40] <pitti> didrocks: don't rewrite the file, it should still be in ../build-area/dir/
[11:40] <pitti> DON'T do bzr bd-do now!
[11:41] <didrocks> pitti: I saw that the file wasn't there when I did bzr bd which failed logically as no source file there
[11:41] <didrocks> so, too late
[11:41] <pitti> urgh
[11:41] <didrocks> well, first time, 1h, second time 30m, third time 15min?
[11:41] <pitti> perhaps copy the file to your home dir right before doing the patch building
[11:41] <didrocks> pitti: I will work in my home dir this time :)
[11:42]  * didrocks start timer
[11:42] <pitti> I seldomly do patches in bzr bd-do and quilt these days
[11:42] <pitti> but still, it shouldn't be that hard :)
[11:43] <didrocks> I don't understand what was wrong this time. I know for yesterday's mistake and it's all my fault. But today…
[11:43] <didrocks> well, let's go back to it
[11:44] <asac> baptistemm: great. so when thats out we can update ;)
[11:44] <asac> baptistemm: how happy were they about this incident?
[11:46] <baptistemm> asac, Apparently holtman already fixed on saturday night that on git after I had a look there.
[11:46] <baptistemm> but he didn't send an ack on IRC for that
[11:46] <asac> yeah.
[11:47] <baptistemm> so it didn't really care my mail :)
[11:47] <baptistemm> s/it/he/
[11:47] <baptistemm> asac, should I wait next really or push bluez with the fix
[11:47] <asac> baptistemm: i dont see a reason to make an early push
[11:48] <asac> bluez releases often enough
[11:48] <baptistemm> hey, they wasn't any really for a month :)
[11:48] <baptistemm> s/really/release/ doo
[11:49] <asac> right. if they dont release in one or two weeks, lets request a release to unbreak api
[11:49] <baptistemm> holtman said a release will be pushed soon
[11:59] <kwwii> seb128: hey, I have an update for the humanity-icon-theme package (lp:~ubuntu-art-pkg/humanity/release) can you upload it when you get a chance?
[12:02] <didrocks> ok, redone. /me triple backups it
[12:05] <seb128> kwwii, ok
[12:11] <didrocks> ah found it, I quilt add after adding the file the tree
[12:13] <seb128> well that should make it ignore your change
[12:14] <seb128> but not drop other changes
[12:14] <seb128> like that doesn't explain the "editing makefile.am dropped source changes"
[12:17] <didrocks> well, right, I don't know what I did wrong. This time, I have it, let's build the package. Too much thing for a tiny script a little postinst call :/
[12:21] <seb128> kwwii, impressive list of bugs closed by this update mr wimer ;-)
[12:22] <kwwii> seb128: hehe, thanks go to vish (I only made on of those icons!)
[12:22] <kwwii> vish: ^ (well done!)
[12:25] <seb128> vish, good work!
[12:26] <seb128> kwwii, there is no upstream tarball right?
[12:26] <seb128> kwwii, ie usually it's just built from bzr
[12:27] <kwwii> seb128: yepp
[12:27] <seb128> ok, good
[12:29] <seb128> kwwii, ok, I'm uploading that, can you change the bzr to have "0.5.1" as version?
[12:29] <seb128> kwwii, since you don't have a diff.gz you don't need an ubuntu revision
[12:30] <seb128> kwwii, just delete the "-0ubuntu1" in the changelog
[12:31] <kklimonda> it seems that bug 434316 is back (at least for me, not every time bug if I use system for a while it shows up eventually) - have it been reported already?
[12:31] <kklimonda> s/bug/but
[12:31] <seb128> kklimonda, are you sure it's due to empathy?
[12:31] <kklimonda> seb128, if I kill empathy line goes away
[12:32] <seb128> ok, so I don't know
[12:36] <seb128> djsiegel, so the hundredpapercut you pointed yesterday is not really one
[12:36] <seb128> djsiegel, you don't usually need password storage since once a share is mounted it will stay mounted for the session
[12:37] <seb128> djsiegel, and on the smb case it's done this way because sometime you need different credentials to have write access to some shares
[12:37] <seb128> djsiegel, and if you were automatically using the default password you would break those usecases
[12:38] <seb128> djsiegel, let me know if you disagree there or need extra details
[12:38] <seb128> (that's from a discussion with upstream today)
[13:02] <kwwii> seb128: yes, will do
[13:14] <vish> kwwii: seb128: thanks :)
[13:16] <didrocks> I need to know as well what display the user is on too (so that gdk_init succeed). /proc/{pid}/environ or is there a nicer way?
[13:17] <chrisccoulson> didrocks - consolekit?
[13:18] <didrocks> chrisccoulson: in a postinst script? is it easy to call?
[13:18] <pitti> didrocks: eww
[13:18] <chrisccoulson> hmmmm, i'm not too sure
[13:18] <chrisccoulson> what are you trying to do?
[13:18] <pitti> didrocks: aren't you looking for running gnome-settings-daemon processes anyway?
[13:18] <pitti> didrocks: you could just fish it out of /proc/pid/env
[13:19] <didrocks> pitti: right, hence my proposal. I was asking if there was a nicer way
[13:19] <pitti> $ xargs -0n1 < /proc/$$/environ |grep ^DISPLAY
[13:19] <pitti> DISPLAY=:0.0
[13:19] <pitti> didrocks: not to my knowledge
[13:20] <didrocks> ok, will use that so. Thanks :)
[13:20] <pitti> gosh, how hackish; well, sabdfl always wins :)
[13:21] <didrocks> pitti: yeah, was not that easy… a lot of time for tiny result…
[13:23]  * hyperair wonders if it's okay to be running some graphical program from within a postinst
[13:24] <hyperair> surely all kinds of strange things can happen during installation, like X crashing or something that will cause the postinst to fail spectacularly?
[13:24] <didrocks> hyperair: it's not running a graphical soft, just need X for gdk getting things
[13:24] <hyperair> didrocks: what if the upgrade was done without X running?
[13:25] <didrocks> hyperair: g-s-d will not run so
[13:25] <pitti> seb128: ah, with yesterday's update teh sound indicator started working \o/ so it wasn't due to a bad PPA
[13:25] <hyperair> ah
[13:26] <pitti> kenvandine: does the power indicator still have a chance to land this week? or should we postpone to beta-1?
[13:30] <pitti> kenvandine: (I'm a bit nervous about that TBH; unlike gnome-volume-control-applet, gnome-power-manager is a huge piece of code to replace..)
[13:31] <hyperair> eh? gnome-power-manager's getting replaced?
[13:33] <seb128> pitti, there is a gpm port to the indicator system waiting in launchpad
[13:33] <pitti> ah, it's a patch, not a rewrite
[13:33] <seb128> it's gpm patch for now apparently yes
[13:37] <pitti> tseliot, bryceh: given that the "Fix logic in patches 104 and 105 to correctly select -nvidia when appropriate" work item was postponed, would it be correct to postpone "Auto-config nvidia: Identify logic in jockey which inserts configuration into xorg.conf and create analogous logic in xserver" as well?
[13:37] <pitti> ISTR that you didn't want to do that kind of magic in lucid?
[13:38] <tseliot> pitti: yes, I think we should definitely postpone it. I don't think I will have the time to implement it any time soon
[13:39] <tseliot> not in time for Lucid
[13:39] <pitti> tseliot: ack, will do
[13:39] <tseliot> ok
[13:41] <pitti> tseliot: what about bug 258038?
[13:42] <pitti> I haven't followed using the alternatives system for fglrx
[13:42] <pitti> is that even necessary?
[13:42] <pitti> i. e. does fglrx also divert libGL and the like?
[13:42] <pitti> it seemed much less intrusive to me
[13:43] <didrocks> pitti: g-s-d pushed, postinst and bin on it
[13:43] <tseliot> pitti: that's fixed. I have already worked on that together with superm1, we pushed the changes to the upstream git. I will pull them when AMD releases an fglrx driver which works with Lucid's xserver
[13:43] <didrocks> pitti: as gnome-desktop hasn't been sponsored yet with fixed quality cache. I will try to do the change about serializing now
[13:44] <tseliot> pitti: currently the package is not installable and doesn't contain our changes.
[13:44] <pitti> didrocks: \o/
[13:47] <seb128> didrocks, do you need gnome-desktop sponsoring?
[13:48] <didrocks> seb128: hum, there is one version waiting, but as I'll erase the changes and saving with serializing the pixbuf, this will go away, so no need now, thanks :)
[13:48] <seb128> ok
[13:48] <didrocks> just hackish g-s-d needs :)
[13:49] <seb128> didrocks, oh please don't do that for g-s-d
[13:49] <seb128> don't patch makefile.am with a new source
[13:49] <seb128> you should rather put your .c in the debian dir
[13:49] <seb128> and call gcc in the changelog to build it
[13:49] <didrocks> oh really? I saw that for gdmsetup and other packages
[13:50] <seb128> gdmsetup is code we try to get upstream
[13:50] <pitti> didrocks: it's fine to do that in your upstream patch, of course
[13:50] <seb128> your change has nothing to do with g-s-d code
[13:50] <seb128> and it forces us to keep running autoreconf
[13:51] <didrocks> there was already one autoreconf file, but yes, I put the .c in the debian dir, and call gcc in control
[13:51] <seb128> (we need it for other changes right now but still we try to get away from those not to add new ones)
[13:51] <didrocks> rules*
[13:51] <didrocks> ok
[13:51] <seb128> well my opinion
[13:51] <seb128> didrocks, maybe do that for now and revisit after ff
[13:51] <seb128> what you did work but will be extra work over time I feel
[13:51] <seb128> we can clean that later though
[13:52] <seb128> didrocks, "that" being what you commited now
[13:52] <didrocks> ok, I'll prefer if we can change that after FF :)
[13:52] <djsiegel1> seb128: I see
[13:53] <pitti> tseliot: so is that blocked on getting a new upstream release which works with our X.org?
[13:53] <tseliot> pitti: yep
[13:53] <pitti> tseliot: thanks
[13:54] <pitti> tseliot: but still planned for lucid?
[13:54] <tseliot> see my PM
[13:55] <seb128> didrocks, did you try how gdk_init behaves if you run your code on vt?
[13:56] <didrocks> seb128: I didn't try without X running, but I tried with two connected users (so, one, not being the one connected to current gnome-terminal)
[13:56] <seb128> didrocks, well not running X is not the issue, just run the binary on a real vt
[13:56] <seb128> didrocks, not under an xorg session
[13:57] <didrocks> seb128: the binary will fail, but the postinst should export the right DISPLAY before, let me check to reinstall it
[13:58] <seb128> didrocks, does it?
[13:58] <didrocks> seb128: right
[13:58] <seb128> oh, ok
[13:58] <didrocks> seb128: let me check install previous version to try an "upgrade" again on a vt to ensure it works
[13:58] <chrisccoulson> didrocks - does your binary not cause an extra dbus-daemon and gconfd process to run?
[13:58] <chrisccoulson> and do you need to clean those up afterwards?
[13:58] <didrocks> chrisccoulson: no, it's connect to current gconf
[13:59] <didrocks> connected*
[13:59] <seb128> didrocks, also calling sudo in the postinst might lead to pam password prompts
[13:59] <chrisccoulson> didrocks: how does it do that? it needs the session bus address to do that
[13:59] <seb128> we ran into lot of weird bugs when we did that for gdm gconftool calls
[13:59] <seb128> we moved to ship the .xml rather
[13:59] <chrisccoulson> yeah, it can get messy doing things like that from a postinst
[14:00] <pitti> kenvandine: sound menu> "integrate with the backend components (PA): INPROGRESS" -> what's that about?
[14:00] <didrocks> seb128: sudo was to get the user's environnement to get it runned. I don't know how to do in an other way
[14:00]  * didrocks doesn't like that change
[14:00] <didrocks> too much time
[14:00] <didrocks> under fire by everybody
[14:00] <seb128> didrocks, we failed for gdm
[14:00] <seb128> didrocks, well I highly dislike the hack too, but it's not your fault you are just the messenger there...
[14:00] <seb128> didrocks, well I highly dislike the hack too, but it's not your fault you are just the messenger there...
[14:00] <seb128> ups
[14:01] <seb128> didrocks, I'm just pointing that we fought with bugs about sudo use in postinst for gdm before karmic
[14:01] <seb128> and did decide to roll back to not use sudo there
[14:01] <seb128> it's a can of worms for issues
[14:01] <didrocks> seb128: right, I agree that running sudo is not good…
[14:01] <seb128> I'm trying to think to a better way
[14:02] <didrocks> so, I need to connect to user's gconfd
[14:02] <seb128> do you really need gconf there?
[14:02] <seb128> that's to get the background image in use?
[14:02] <didrocks> seb128: right
[14:02] <didrocks> seb128: I didn't find any other way in the API
[14:03] <seb128> dealing with gconf in a postinst is going to be an issue
[14:03] <seb128> we really need a proper system to do such things
[14:04] <didrocks> I agree
[14:04] <seb128> and stop doing things likely to break in maintainer scripts
[14:04] <seb128> ask mvo
[14:04] <pitti> ok, this now sounds too messy to get working, I think
[14:04] <seb128> we get so many things going wrong
[14:04] <pitti> perhaps we can cowboy it into update-manager for lucid
[14:04] <pitti> if we're going to have a better solution for manic monkey anyway
[14:04] <pitti> update-manager at least has X, gconf, and all taht
[14:05] <didrocks> pitti: it doesn't have X for other users, so it will still be hackish
[14:05] <pitti> didrocks: nevermind other users
[14:05] <seb128> mvo, ^ how easy would it be to run a small piece of C or python code in update-manager after install?
[14:05] <Nafai> Good morning
[14:05] <pitti> didrocks: the primary user is "good enough" here
[14:05] <mvo> sorry, I did not follow the discussion
[14:05] <seb128> mvo, just for the current user
[14:05] <seb128> mvo, we are still try to get the background image cached after upgrade
[14:05] <mvo> seb128: without asking? or with a prompt?
[14:06] <seb128> mvo, it's basically calling gnome_bg_draw()
[14:06] <pitti> mvo: noninteractive
[14:06] <seb128> which will trigger the caching if new gnome-desktop is installed
[14:06] <seb128> mvo, without asking
[14:06] <mvo> ok, you want to run that on first login for every user, right?
[14:06] <seb128> mvo, it's just a "trigger background caching by doing a libgnome-desktop call after install"
[14:07] <pitti> mvo: no, problem is we need to run it after the upgrade, but before reboot
[14:07] <seb128> mvo, no, it's too late, we want to do it before reboot
[14:07] <seb128> mvo, otherwise we miss the profiling which happens on reboot
[14:07] <mvo> ohh, but what about users that exist and are not logged in?
[14:07] <seb128> Nafai, hey
[14:07] <mvo> how would it work for them?
[14:07] <pitti> I suppose it doesn't have to be C/Python, we could also call didrocks's small binary
[14:07] <seb128> mvo, they lose
[14:08] <seb128> mvo, we do profile for one user only anyway
[14:08] <mvo> ok
[14:09] <mvo> we can add it to u-m, its going to be a bit of a hack because the release-upgrade part runs as root - so we need to so something like sudo -u $SUDO_USER
[14:09] <mvo> *ugly*
[14:10] <pitti> mvo: the UI runs as root as well?
[14:10] <mvo> yes
[14:11] <pitti> so that doesn't have the user's d-bus connection, etc?
[14:17] <vish> seb128: yeah , that icon was a place holder for someone to file a bug :)
[14:17]  * vish currently working on a better icon
[14:18] <vish> seb128: also , we have a ppa for humanity , wouldnt we need the "-0ubuntu1" ?
[14:18] <seb128> vish, not really no
[14:18] <seb128> vish, you can use 0.5.1+r<nn<
[14:18] <vish> ah , cool

[14:19] <seb128> vish, you can use 0.5.1+r<nn>
[14:19] <seb128> I meant
[14:19] <vish> k..
[14:19] <seb128> if you build from commits
[14:20] <seb128> chrisccoulson, btw do you know what is happening with the gpm libindicator change?
[14:31] <pitti> tedg: good morning
[14:36] <kenvandine> pitti, i'll talk to ronoc about it, but i imagine it is still open because it isn't working yet for a lot of people
[14:37] <pitti> kenvandine: since yesterday's update the slider and mute seem to work
[14:37] <kenvandine> pitti, not for me
[14:37] <kenvandine> well, i haven't updated yet :)
[14:38] <pitti> kenvandine: well, it's not working very well; it feels too much logarithmic
[14:38] <pitti> but it does work
[14:38] <kenvandine> progress :)
[14:38] <pitti> kenvandine: so the "PA integration" means "volume slider/mute button"?
[14:38] <seb128> pitti, right, ronoc found the issue some users were having which was a default audiosink selection one apparently
[14:38] <kenvandine> i think so
[14:38] <seb128> pitti, nice to get confirmation it's working ;-)
[14:38] <tedg> Good morning pitti
[14:39] <seb128> hey tedg
[14:39] <huats> seb128, for the record I am updating deskbar-applet
[14:39] <pitti> tedg: I wondered, was there a particular reason for indicator-session to talk to devicekit-power over d-bus directly?
[14:39] <seb128> huats, ok thanks
[14:39] <huats> (and I have noted that in the page)
[14:39] <seb128> huats, how are you?
[14:39] <tedg> Morning seb128
[14:39] <huats> seb128, very very good :)
[14:40] <pitti> tedg: I ported it to libupower-glib today (merge proposal sent), but I wondered why you didn't use libdevkit-power-gobject; to avoid the dependency?
[14:40] <seb128> huats, good to hear ;-)
[14:40] <huats> with a cute little by standing next to me :)
[14:40] <tedg> pitti: Yes, it needs to find out whether we can suspend and/or hibernate
[14:40] <huats> seb128, you ?
[14:40] <pitti> tedg: right, for that reason I used the client side lib
[14:40] <seb128> huats, quite good actually though a bit tired
[14:40] <pitti> tedg: the server side can't check policykit privs (i. e. it might be disallowed only for some users)
[14:40] <huats> seb128, yeah I can imagine that during the FF week
[14:41] <tedg> pitti: There was an issue with this lib at some point, I don't remember what.  But it should probably be changed.
[14:41] <kenvandine> good morning rickspencer3
[14:41] <tedg> pitti: I think that it was mostly a port from using the GPM DBus interface, so it was easier to just change the interface rather than port to a lib.
[14:42] <rickspencer3> good morning kenvandine
[14:42] <pitti> hey rickspencer3
[14:42] <baptistemm> seb128, for https://bugs.edge.launchpad.net/bugs/456200 the user is user karmic, would you like to have a gnome-bluetooth update?
[14:43] <seb128> baptistemm, not a version upgrade no but feel free to backport the fix if you want
[14:43] <seb128> hey rickspencer3
[14:48] <mvo> pitti: sorry, phonecall. no, no dbus connection. there is update-notifier, but that gets deactived during a upgrade
[14:51] <chrisccoulson> hey seb128
[14:52] <chrisccoulson> sorry, i was away from my desk there
[14:52] <chrisccoulson> i thought kenvandine said he was reviewing the gpm appindicator change
[14:52] <chrisccoulson> i can progress that though if it needs someone else to review it
[14:54] <chrisccoulson> kklimonda: do you know when we're likely to see a 1.90 release of transmission?
[14:54] <kenvandine> chrisccoulson, i did last week
[14:54] <kklimonda> chrisccoulson, charles was planning on releasing it this week
[14:55] <kenvandine> gave him my feedback and hadn't see anything else
[14:55] <vish> seb128: upstream has accepted the commit in Bug #513864 , [you had asked a question]
[14:55] <kklimonda> chrisccoulson, but that depends on whenever he has managed to fix two bugs that result in some private trackers banning transmission
[14:56] <kklimonda> chrisccoulson, also the only new feature is application-indicator so I think we should be safe in case 1.90 miss FeatureFreeze
[14:56] <seb128> vish, I just pinged them on IRC
[14:56] <vish> seb128: hasnt been committed yet , but accepted.. [rubens seems to have lost his SSH key]
[14:56] <seb128> vish, so thanks but I know they are reviewing it ;-)
[14:56] <vish> seb128: cool thanks :)
[14:56] <seb128> vish, he hasn't lost his key he just doesn't have it on the computer he's using
[14:56] <seb128> he might be at work or something
[14:56] <vish> ah.. k..
[14:57] <seb128> vish, thanks for following up though ;-)
[14:59] <kklimonda> chrisccoulson, there is also some bug in libappindicator that have to be fixed for Transmission to display menu correctly.. but I can't find the bug number now
[14:59] <chrisccoulson> kklimonda: oh, ok. thanks
[15:00] <seb128> kklimonda, what does the bug do?
[15:00] <chrisccoulson> i'm thinking about just uploading the appindicator change for transmission
[15:00] <chrisccoulson> it would be nice to start getting user feedback
[15:01] <kklimonda> chrisccoulson, charles is saying that he's probably going to roll a tarball today to get it into Fedora before freeze
[15:01] <chrisccoulson> but if we get 1.90 this week, then there maybe isn't much point
[15:01] <chrisccoulson> cool, i can wait for that then
[15:01] <seb128> chrisccoulson, doit!
[15:02] <chrisccoulson> heh, i can do that this evening :)
[15:02] <kklimonda> seb128, it's easier to show than to explain - basically all menu entries use stock icons and stock names
[15:02] <seb128> tedg, ^
[15:03] <seb128> tedg, do you know if that's fixed or scheduled for this week?
[15:03] <chrisccoulson> is that a known issue then?
[15:03] <kklimonda> chrisccoulson, I believe qense has reported it
[15:03] <qense> yes
[15:04] <qense> The fix for that bug should be in 0.0.14.
[15:04] <chrisccoulson> awesome, thanks :)
[15:04] <jcastro> chrisccoulson, you're handling the g-p-m upload with the app indicators iirc?
[15:05] <qense> kklimonda: bug 520048
[15:05] <seb128> jcastro, no he isn't
[15:05] <tedg> seb128: Yes, it's in trunk as qense said.
 sorry, i was away from my desk there
[15:05] <seb128>  i thought kenvandine said he was reviewing the gpm appindicator change
 gave him my feedback and hadn't see anything else
[15:05] <seb128> jcastro, ^
[15:05] <jcastro> kenvandine, I just found a crasher bug in the xchat message indicator thing
[15:06] <seb128> tedg, http://bazaar.launchpad.net/~qense/indicator-application/fix-520048/revision/81
[15:06] <seb128> tedg, that one?
[15:06] <qense> seb128: that should be the fix, yes
[15:07] <seb128> ok
[15:07]  * seb128 backports to lucid now
[15:07] <seb128> let's get that indicator work moving
[15:07] <seb128> qense, tedg: thanks
[15:07] <pitti> tedg: do you think you'll have time this week to review the merge proposal for indicator-session? it's keeping us from removing devicekit-power (and thus boot time/cd space/etc.)
[15:07] <tedg> pitti: Review should be in your mailbox :)
[15:08] <qense> btw, what's holding Anjuta up? For more than a day I've only got a new version for anjuta-common, anjuta itself isn't there yet. FTBS?
[15:08] <tseliot> pitti: would it be possible to collect the output of "ldconfig -p | grep GL" and of "update-alternatives --display gl_conf" in apport for nvidia, fglrx and X bugs in general?
[15:08] <pitti> tedg: ah, thanks; will followup there
[15:08] <seb128> qense, am64?
[15:08] <jcastro> seb128, yeah Nafai will probably finishing up a bunch of indicator work before FF so it's going to start piling up
[15:08]  * kenvandine waits for evolution to filter the past 3 days worth of email...
[15:09] <qense> seb128: yes
[15:09] <pitti> tseliot: sure; sounds like it could be added to the "catch all" xorg hook (/usr/share/apport/package-hooks/source_xorg.py)
[15:09] <seb128> qense, ftbfs yes
[15:09] <qense> ok
[15:09] <qense> I'll wait patiently then
[15:09] <kenvandine> it might finish by feature freeze :)
[15:09] <tseliot> pitti: sounds good to me. It would be a real time saver
[15:10] <geser> qense: anjuta got hit too by the libmysqlclient16 breakage
[15:10] <qense> damn libmysqlclient16! ;)
[15:10] <chrisccoulson> hmmm, i build anjuta successfully last night on amd64. i thought it FTBFS due to version skew in some build-depends, so i retried the build after i managed to build it at home
[15:10] <chrisccoulson> it still fails?
[15:10] <tseliot> pitti: also, any ideas about this? http://launchpadlibrarian.net/39068474/Traceback.txt
[15:11] <geser> chrisccoulson: "libsvn-dev: Depends: libaprutil1-dev but it is not going to be installed
[15:11] <pitti> tseliot: yes
[15:11] <geser> " from the build from today morning
[15:11] <tseliot> ah
[15:11] <pitti> tseliot: d-bus spawned programs have no $PATH
[15:11] <pitti> tseliot: you need to call /sbin/ldconfig
[15:12] <chrisccoulson> geser - yeah. that was the same issue as yesterday, but i managed to install that package in my pbuilder and successfully build anjuta
[15:12] <pitti> tseliot: but probably, since this bit us more than once already, the backend should just check $PATH, and if it's empty, set a reasonable default one
[15:12] <chrisccoulson> so i retried the build, and it still gets the same issue
[15:12] <tseliot> pitti: oh, I think I remember that bug from a previous release cycle
[15:12] <kenvandine> wow... the new icons in empathy are awesome!
[15:12] <Nafai> seb128: I need version 82 to lucid as well for indicator-application
[15:12] <Zdra> kenvandine, ubuntu changed empathy icons?
[15:13] <qense> yes, they look really neat
[15:13] <kenvandine> not sure where they came from
[15:13] <qense> the humanity theme update
[15:13] <kenvandine> i just noticed new presence icons
[15:13] <geser> chrisccoulson: I still get this error message on amd64
[15:13] <seb128> Nafai, does it fix an open launchpad bug?
[15:13] <tseliot> pitti: so would it work if I checked os.environ["PATH"]?
[15:13] <pitti> tseliot: I'd use "if not os.environ.get('PATH')
[15:14] <pitti> tseliot: I'm not sure whether it's empty, or not present at all
[15:14] <seb128> Zdra, depends what you call empathy icons, humanity icon theme got updated
[15:14] <Nafai> seb128: Let me check, part of it fixes something I just told bratsche, but there might be a bug for part of it
[15:14] <pitti> tseliot: so let's rather account for both
[15:14] <tseliot> pitti: ah, ok
[15:14] <seb128> Zdra, so some status icons are nicer in the humanity theme now
[15:14] <vish> Zdra: yeah ,i added those icons in humanity.. as emapthy-*    is that not allowed ?
[15:15] <Nafai> nope, I didn't file a bug for this one, just told bratsche about it
[15:15] <qense> vish: I think the bug report that was fixed said they should have been called user-*
[15:15] <Nafai> seb128: Should probably get in the habit for filing bugs for everything
[15:15] <tseliot> pitti: I would do that from my own library though. Is it ok?
[15:15] <vish> qense: works both ways :)
[15:15] <vish> qense: there are those too
[15:15] <seb128> Nafai, ok, what is the effect of the bug?
[15:15] <pitti> tseliot: sure
[15:15] <tseliot> ok
[15:15] <tseliot> pitti: thanks for your help
[15:16] <pitti> tseliot: you're welcome!
[15:16] <Nafai> seb128: Changes made to menus after it has been set on the indicator were not being reflected
[15:17] <Zdra> vish, sure it's allowed, we (empathy upstream) asked MANY times to have fd.o icon naming spec include IM related icons so we can drop that "empathy-" prefix
[15:17] <vish> Zdra: yeah , the emapthy bug upstream seemed to have stalled , so i just added it for now :)
[15:19] <seb128> Nafai, bug #521181?
[15:19] <Nafai> oh yeah :)
[15:19]  * vish just realized that it was kenvandine who pinged Zdra with an "empathy" highlight .. got confused earlier :)
[15:19] <Nafai> I didn't file it
[15:20] <kenvandine> vish, the icons look awesome :)
[15:20] <kenvandine> hey rodrigo_
[15:20] <vish> kenvandine: thanks :)
[15:20] <rodrigo_> hi kenvandine
[15:20] <kenvandine> rodrigo_, i see a tarball
[15:20] <Zdra> vish, yep I have an highlight on "empathy", to spy what people do with it :D
[15:20] <seb128> Nafai, ok, backporting that too
[15:20] <rodrigo_> kenvandine, yes, 0.2.1, ready to be packaged
[15:20] <kenvandine> great
[15:21] <kenvandine> rodrigo_, i can do that today :)
[15:21] <rodrigo_> kenvandine, cool!
[15:22] <Nafai> kenvandine: Looks like seb128 is taking care of packaging the latest changes for app indicator  that I need.  So you can ignore the email jcastro sent
[15:23] <kenvandine> Nafai,  cool
[15:23]  * kenvandine still can't get into email... i really think evo has gotten slower at filtering mail
[15:23] <Nafai> evo has always been slow whenever I've tried it
[15:24] <chrisccoulson> congrats hyperair \o/
[15:24] <kenvandine> it's always been slow at filtering for sure... but this is nuts
[15:24] <hyperair> \o/
[15:24] <kenvandine> i started it an hour ago and it is 23% done  with filtering new mail
[15:24] <chrisccoulson> hyperair for MOTU :)
[15:24] <kenvandine> it is only 3 days worth!
[15:24] <seb128> Nafai, qense: kenvandine: both changes uploaded to lucid
[15:24] <seb128> enjoy
[15:24] <kenvandine> unless seb128 had a really busy day :)
[15:24] <seb128> jcastro, ^
[15:24] <qense> seb128: that's great, thank you!
[15:24] <jcastro> \o/ seb128
[15:24] <kenvandine> thx se
[15:25] <kenvandine> thx seb128
[15:25] <seb128> np
[15:25] <jcastro> wow, lots of great stuff fixed today!
[15:25] <qense> I suspect that some of my issues with Banshee will also be fixed by this new upload of Indicator Application.
[15:25] <Nafai> seb128, Yay!  thanks
[15:29] <pitti> tedg: replied and updated, thanks for review
[15:31] <tedg> pitti: Cool, I'll look when LP catches up :)
[15:33] <tgpraveen12> vish: with the humanity theme update with new status icons of empathy in the panel with me menu the status icons have colour
[15:34] <tgpraveen12> no longer mono chrome
[15:34] <vish> tgpraveen12: thats not humanity bug ;)  .. the memenu needs to be fixed to use the monochrome icons
[15:35] <vish> tgpraveen12: the icons are in humanity now with the -panel names...
[15:35]  * vish looks at tedg  ;)
[15:35] <tgpraveen12> ok and the green border drawn on the message indicator envelope is intentional?
[15:36] <tgpraveen12> it also breaks mono chrome scheme
[15:36] <desrt> tgpraveen12: it's debugging
[15:36] <tedg> vish: Ah, I didn't think of doing that in -me as well.  I'll put that on my TODO list.
[15:36] <desrt> wait.  disregard.
[15:36] <tedg> vish: AppIndicators should look for -panel now.
[15:37] <seb128> tedg, Nafai: r82 seems to make rhythmbox crash on closing
[15:38] <vish> tgpraveen12: it was a placeholder icon , since i didnt have time to do it for today's upload
[15:38] <tgpraveen12> also sound pref icon has changed. and sound indicator icon looks bad in dark theme (though this was the case earlier also). i should probably hope over to #ubuntu-artwork now
[15:38] <seb128> vish, next time let we know before upload so we wait for upload
[15:38] <seb128> vish, it's sort of weird to have a placeholder icon for alpha3
[15:38] <vish> seb128:  shall i push the fix for the mail icon?
[15:38] <vish> i have done it now..
[15:38] <LaserJock> is there a better place to talk about the indicator applet than here?
[15:39] <seb128> vish, would be nice
[15:39] <seb128> LaserJock, #ayatana
[15:39] <tgpraveen12> LaserJock: ayatana
[15:39] <vish> seb128: cool , i'm uploading the change
[15:39] <seb128> vish, thanks
[15:42] <seb128> tedg, could you try if rhythmbox crashes on closing for you?
[15:43] <tedg> seb128: No, I don't think so.  Let me try again.
[15:44] <pitti> rickspencer3: ah, you are currently editing https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-16 ?
[15:44]  * pitti was just about to add his report
[15:44] <rickspencer3> yeah
[15:44] <rickspencer3> pitti, I cancelled
[15:44] <rickspencer3> but bryceh started it without the template :,(
[15:44] <pitti> oh, why that?
[15:45] <rickspencer3> pitti, on call now, will ping back soon
[15:46] <pitti> rickspencer3: page templateified, added my report
[15:48] <seb128> tedg,
[15:48] <seb128> #0  0x021da1dc in setup_dbusmenu (self=0x8388190)
[15:48] <pitti> tseltiot, ArneGoetje, ccheney, didrocks, Riddell, kenvandine, seb128: can you please add your report to https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-16 ? TIA
[15:48] <seb128>     at libappindicator/app-indicator.c:1255
[15:48] <seb128> #1  0x021da271 in client_menu_changed (widget=0x8982050, child=0x8979f10,
[15:48] <seb128>     indicator=0x8388190) at libappindicator/app-indicator.c:1276
[15:48] <seb128> pitti, ok
[15:48] <pitti> seb128: sorry for breaking your stacktrace
[15:48] <seb128> tedg, it crashes with that since I backported r82
[15:48] <tedg> bratsche: ^
[15:48] <seb128> pitti, np, you didn't break it, or at least not seen from there ;-)
[15:49] <seb128> tedg, you don't get the issue are you sure?
[15:49] <seb128> bratsche, hey ;-)
[15:51] <tedg> seb128: Let me start from teh command line incase I accidentally turned of apport.
[15:55] <vish> seb128: uploaded the icon  change to branch.. lp:humanity
[15:56] <vish> is that good or how would you wish for me to do it?
[15:59] <seb128> vish, that's good thanks, I will check with kwwii for the package update
[16:00] <vish> hehe , he'll probably ask me to propose a merge anyway...
[16:00]  * vish gets started on that ;p
[16:15] <bratsche> seb128: Hey.
[16:16] <seb128> bratsche, hello, how are you?
[16:17] <bratsche> seb128: I'm okay.  I see a stack trace above that has my name on it though. :)
[16:17] <seb128> bratsche, yeah, seems ted is blame you for this one...
[16:18] <seb128> bratsche, rhythmbox crashes this way every time I close it since I backport r81 and 82
[16:18] <seb128> backported
[16:18] <seb128> speaking about indicator-application
[16:18] <seb128> bratsche, do you think you would have time to look at the issue? or at least try if you get it too ;-)
[16:19] <bratsche> seb128: Okay I just pushed r83 that checks priv->menu for non-NULL first.
[16:19] <bratsche> seb128: I think this will fix it, but if not then ping me again. :)
[16:19] <seb128> ok thanks
[16:19] <seb128> will try in a bit
[16:20] <bratsche> tedg: I just committed r83 without review, hope that's cool.  It's just checking something for non-NULL.
[16:21] <tedg> bratsche: Cool with me.  Thanks for fixing it!
[16:26] <rickspencer3> team meeting in 5 minutes
[16:26] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-16
[16:26] <seb128> is there anybody who would like to write a mir for mako there? ;-)
[16:27] <vish> tedg: the rhythmbox app indicator icon is mixed up.. the icon now uses the playing icon when the app starts. [app is actually not-playing ] before with notification area , it used to use the not-playing icon
[16:28] <tedg> bratsche: ^  (/me is having fun pinging bratsche for things ;) )
[16:30] <bratsche> Yeah, this is why I said I'm going to work from a coffee shop with no Internet today.  Yesterday I managed to hardly work on my own stuff. :)
[16:30] <rickspencer3> meeting time!
[16:30] <ccheney> here
[16:30] <didrocks> tseliot: still editing?
[16:30] <seb128> bratsche, just close IRC ;-)
[16:31] <tseliot> didrocks: yes, I was about to save
[16:31] <rickspencer3> bryceh, ccheney, didrocks, kenvandine, pitti, Riddell, seb128, tseliot
[16:31] <rickspencer3> who am I missing?
[16:31] <kenvandine> hey hey hey!
[16:31] <pitti> o/
[16:31] <Riddell> hi hi
[16:31] <seb128> hello
[16:31]  * rickspencer3 taps gavel
[16:31] <didrocks> o/
[16:32] <tseliot> didrocks: just a sec
[16:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-16
[16:32] <rickspencer3> oops
[16:32] <rickspencer3> I forgot "previous actions"
[16:32] <rickspencer3> an oversite which will save us some time
[16:32] <rickspencer3> ;)
[16:32] <rickspencer3> kenvandine, partner update?>
[16:32] <pitti> rickspencer3: they are on https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-09
[16:33] <tseliot> didrocks: done, you can edit the wiki now
[16:33] <tkamppeter> hi
[16:33] <bryceh> morning
[16:33] <kenvandine> sure
[16:33] <didrocks> tseliot: thanks :)
[16:33] <rickspencer3> ok
[16:33] <rickspencer3> previous actions seem done
[16:33] <rickspencer3> # Bryce to BP/WIify new work assigned on the sprint
[16:33] <rickspencer3> #
[16:33] <rickspencer3> Alberto to add missing alpha-3 WIs to foundations-lucid-boot-experience
[16:33] <kenvandine> i am still waiting on dbarth to update the weekly releases page
[16:33] <kenvandine> so that should happent oday
[16:34] <kenvandine> today
[16:34] <bryceh> rickspencer3, done
[16:34] <rickspencer3> bryceh, tseliot did you guys get those?
[16:34] <tseliot> rickspencer3: yep
[16:34] <pitti> rickspencer3: I think I'm done with the alpha-3 BP mangling
[16:34] <rickspencer3> (sorry kenvandine)
[16:34] <pitti> rickspencer3: except for one which I'd like to discuss in the meeting
[16:34] <rickspencer3> ok, so now ...
[16:34] <rickspencer3> kenvandine, partner update?
[16:34] <kenvandine> OLS is rocking the desktop, libubuntuone and rhythmbox-ubuntuone-music-store just had releases
[16:34] <kenvandine> i will get the packages ready for review later today for lucid
[16:34] <pitti> we need to rush them through NEW, etc.
[16:35] <pitti> FF in two days
[16:35] <kenvandine> the service isn't quite there, but damn close
[16:35] <kenvandine> pitti, yeah.. hopefully today :)
[16:35] <kenvandine> i have been maintaining the packages locally :)
[16:35] <rickspencer3> pitti, does someone need to be ready to do the NEW rush?
[16:35] <kenvandine> so shouldn't take me long
[16:35] <pitti> rickspencer3: a prod to whoever's archive day is is prudent, I think
[16:35] <pitti> (I'll be away later tonight, sorry; but I can have a look tomorrow morning)
[16:36] <rickspencer3> pitti, ok
[16:36] <Riddell> that'll be me today
[16:36] <kenvandine> pitti, it will be ready for you in the AM :)
[16:36] <kenvandine> or Riddell later today :)
[16:36] <rickspencer3> kenvandine, all done partner update?
[16:36] <kenvandine> the new U1 client is still coming this week, i will harass dobey asap for real code :)
[16:36] <kenvandine> yup
[16:37] <seb128> kenvandine, ping me if you want review and sponsoring
[16:37] <kenvandine> seb128, will do :)
[16:37] <seb128> I can probably do a first check and uploads
[16:37] <pitti> kenvandine: do you know when we'll drop the U1 applet?
[16:37] <seb128> then Riddell and pitti can NEW
[16:37] <dobey> pitti: it's already dropped in trunk
[16:37] <pitti> dobey: \o/
[16:37] <kenvandine> dobey, release eta?
[16:38] <dobey> kenvandine: this evening or tomorrow. i'll be poking statik to upload when ready
[16:38] <kenvandine> ok
[16:38] <kenvandine> thx
[16:38] <kenvandine> only new dep is libu1?
[16:38] <dobey> no, libu1 isn't a dep for ubuntuone-client any more
[16:38] <kenvandine> oh... ok
[16:38] <dobey> webkit will be though
[16:38] <kenvandine> ok
[16:39] <dobey> python-webkit i guess. whatever the package for the py bindings is
[16:39] <kenvandine> moving along
[16:39] <pitti> kenvandine: pywebkit is already on the CD, no prob there
[16:39] <kenvandine> yeah
[16:39] <dobey> yay
[16:39] <kenvandine> yay for gwibber too :)
[16:40] <dobey> and music store :)
[16:40]  * dobey goes off to lunch
[16:40] <rickspencer3> kenvandine, all done?
[16:40] <kenvandine> yup
[16:40] <rickspencer3> thanks kenvandine
[16:40] <rickspencer3> Riddell, Kubuntu status?
[16:40] <Riddell> * 4.4 final is in
[16:40] <Riddell> * daily images are looking good for i386/amd64 except for blocking on mysql fixed, amd64 should fit in CD size tomorrow
[16:40] <Riddell> * kdebindings not compiling on ARM (the important bits do compile so we can just work around the unimportant bits)
[16:40] <Riddell> * Qt 4.6.2 due today, and then we're in a good position for feature freeze
[16:41] <rickspencer3> hmm
[16:41] <rickspencer3> thanks Riddell
[16:42] <rickspencer3> ccheney, mozilla update?
[16:42] <ccheney> rickspencer3: i got everything that i think belongs into soup done, there are about 4 symbols left that it uses that i understand probably belong in glib/gnutls directly and that is what i am working on next
[16:43] <rickspencer3> ccheney, how long until you complete it?
[16:43] <ccheney> rickspencer3: i was off thu - mon, so haven't progressed since my last update with you
[16:44] <ccheney> rickspencer3: hopefully not more than a day or two for that part, will need to discuss with asac how to make sure i don't break anything in the process since i will be modifying glib directly it is the most dangerous part of the change
[16:44] <rickspencer3> ok
[16:44] <rickspencer3> moving on
[16:44] <pitti> as long as we just add new code/symbols, it should be okay
[16:44] <asac> the glib changes really looked confined well
[16:44] <pitti> and glib has a large test sutie
[16:44] <asac> but yes, lets look together
[16:45] <ccheney> asac: ok
[16:45] <rickspencer3> ok
[16:45] <asac> (just convenience funcs for thread-local stuff)
[16:45] <rickspencer3> so next team meeting we should hear that libsoup is complete
[16:45] <asac> \o/
[16:45] <rickspencer3> and work has started on the next item
[16:46] <ccheney> wrt OOo 3.2.0 is now out upstream but hasn't been updated by ooo-build and debian yet, hoping to get the final uploaded to ubuntu in the next week
[16:46]  * rickspencer3 crosses fingers
[16:46] <ccheney> yes soup should be done by next week
[16:46] <asac> yes. webkit and ephy is next
[16:46] <asac> webkit -> easy (just the rename is painful); ephy require a few symbols (not that many from what i saw)
[16:46] <rickspencer3> ccheney, thanks for the update on OOo, too bad it won't be ready for A3, but not a real problem
[16:46] <ccheney> yea, hopefully no more cascading effects like with soup/glib, heh :)
[16:47] <rickspencer3> ok, thanks ccheney and asac
[16:47] <rickspencer3> moving on ...
[16:47] <ccheney> rickspencer3: yea i doubt the ooo-build/debian stuff will be done by thu
[16:47] <asac> rickspencer3: next week upload would hit a3, wouldnt it?
[16:47] <asac> but please dont upload ooo in a3 week ;)
[16:47] <rickspencer3> Transitioning from A3
[16:47]  * asac with armel hat on
[16:47] <ccheney> asac: yea i won't be uploading it unless it is done by friday
[16:47] <asac> good
[16:47] <asac> thx
[16:47] <rickspencer3> ok, Transitioning from A3
[16:47] <rickspencer3> ;)
[16:47] <rickspencer3> so, this is pretty much the last week for blueprint work
[16:48] <rickspencer3> so anything that you don't think will be done by Thursday, consider it more or less postponed to Lucid + 1
[16:48] <rickspencer3> if you have any concerns about specific work items, please discuss with pitti, and if he is not available, you can ask me as well
[16:49] <rickspencer3> after this week, we have three areas of focus
[16:49] <rickspencer3>  1. Find and fix the worst bugs (how to find and track?)
[16:49] <rickspencer3>  1. Ensure a smooth upgrade experience (how to test?)
[16:49] <rickspencer3>  1. Integrate the latest and greatest
[16:49] <rickspencer3> in terms of the first two items, I feel there is some ambiguity
[16:49] <rickspencer3> hmm, pedro is not around :/
[16:49] <desrt> rickspencer3: all tied for first place priority? :)
[16:49] <rickspencer3> ?
[16:49] <pitti> on a tangent, http://people.ubuntu.com/~mvo/automatic-upgrade-testing/
[16:49] <rickspencer3> desrt, yes, of course, I am an manager
[16:50] <rickspencer3> note that the list is subject to change :/
[16:50] <pitti> http://people.ubuntu.com/~mvo/automatic-upgrade-testing/2010-02-16-12:16:25/
[16:50] <rickspencer3> just kidding, that's just Moin formatting
[16:50] <pitti> in short, defualt install upgrades are all working now
[16:50] <rickspencer3> thanks pitti
[16:51] <rickspencer3> I would like to discuss with QA team how we can better organize upgrade testing with the community
[16:51] <rickspencer3> this is ofter a sore point, and since we have created a good amount of time to focus on quality, I am hoping we can do a good job there
[16:51] <mvo> I'm working on a stepmaker based upgrade test (in addition to the one that pitti showed)
[16:51] <rickspencer3> mvo, are you working with marjo on this?
[16:51] <rickspencer3> or ara or pedro?
[16:52] <rickspencer3> also, we probably need to define some upgrade behaviors and make sure they work well
[16:52] <mvo> rickspencer3: no, I discussed it with soren at the sprint and created a profile. but I will and hope they can take it over
[16:52] <rickspencer3> like, different cases if the user removed or moved an indicator, etc...
[16:52] <rickspencer3> mvo ok
[16:53] <rickspencer3> anyone particularly passionate about upgrade experience who would like to work on planning for this aspect?
[16:53] <pitti> the trouble with us developers is that we don't have good real-life test cases for upgrades
[16:53]  * rickspencer3 listens to crickets chirping
[16:53] <pitti> we upgrade every day
[16:53] <pitti> so we do them in small steps
[16:54] <rickspencer3> yeah, I think we need to organize some test cases and some community efforts around this
[16:54] <rickspencer3> ACTION: rickspencer3 to engage QA wrt upgrade testings
[16:54] <pitti> we need to receive lots of feedback at beta-1, when all Canonical folks upgrade
[16:54] <rickspencer3> ^sound okay?
[16:54] <pitti> likewise with community feedback, of course (around beta-1)
[16:55] <rickspencer3> pitti, right, but I would like to see some more organized, rigorous testing, since we have created a long period of time to focus on quality
[16:55] <pitti> well, synthetic upgrades are already tested automatically
[16:55] <rickspencer3> ok, I have an action item
[16:55] <rickspencer3> tseliot, bryceh have you anything set up to test upgrades wrt the new alternatives system?
[16:55] <pitti> what they miss is customizations in /etc/, wild package combinations, nvidia drivers, broadcom wifi, all the stuff that makes real boxes explode
[16:56] <tseliot> rickspencer3: yes, today I've put my new nvidia card in my testing box so now I should have all the hardware I need
[16:56] <rickspencer3> tseliot, so you are doing all the testing yourself?
[16:57] <rickspencer3> (until the community starts upgrading)?
[16:57] <pitti> I seriously think that we'll get lots of bug reports after beta-1
[16:57] <rickspencer3> pitti, I know
[16:57] <bryceh> rickspencer3, I have hardware set up for it as well, but time is the main limiting factor
[16:57] <rickspencer3> I would like to get some of those earlier if we can
[16:57] <tseliot> rickspencer3: yes but we also have a mailing list for that
[16:57] <seb128> pitti, upgrade bugs or just bugs?
[16:57] <pitti> so far our problem has always been to fix everything, not really not getting enough feedback
[16:57] <pitti> seb128: upgrade problems
[16:57] <pitti> seb128: well, "bugs" as well, of course
[16:58] <rickspencer3> ok
[16:58] <tseliot> bryceh: +1 on lacking the time
[16:58] <rickspencer3> I will talk to marjo and see if we can organize something a tad more methodical than "everyone update for beta-1 and tell us what is broken"
[16:58] <rickspencer3> so, that brings us back to
[16:58] <rickspencer3> find and fix the worst bugs
[16:59] <rickspencer3> I think that with the new gravity system, we might be a tad more effective at picking out actionable and important bugs
[16:59] <rickspencer3> thoughts on how we could do better finding the worst bugs?
[17:00] <rickspencer3> oookay
[17:00] <rickspencer3> moving on
[17:00] <pitti> rickspencer3: btw, ISTR that ara wanted to organize that as well
[17:00] <bryceh> rickspencer3, hehe
[17:01] <bryceh> rickspencer3, I think that same question gets asked every release ;-)
[17:01] <pitti> rickspencer3: "that" > driver upgrade testing, etc.
[17:01] <rickspencer3> bryceh, yes
[17:01] <rickspencer3> and we have taken some action wrt the problem
[17:01] <bryceh> rickspencer3, in fact I was asking myself the same question in the shower this morning
[17:01] <rickspencer3> gravity + JSON searches
[17:01] <rickspencer3> okay
[17:02] <rickspencer3> by next week I will have the perfect bug finding workflow figured out
[17:02] <bryceh> awesome
[17:02] <rickspencer3> ;)
[17:02] <rickspencer3> ok
[17:02] <rickspencer3> speaking of which
[17:02] <rickspencer3> pitivi
[17:02] <rickspencer3> so, we are to decide by beta 1 if pitivi is in or out
[17:02] <rickspencer3> but we didn't really discuss the criteria for that
[17:03] <bryceh> whats the word on the street?
[17:03] <pitti> ideally we'd have a set of use cases that it needs to fulfill
[17:03] <pitti> IOW, a "test plan"
[17:03] <pitti> and then check the bug situation (incoming bugs vs. activity on them)
[17:03] <seb128> I still failed to do anything useful with pitivi
[17:03] <seb128> but maybe that's only me
[17:03] <pitti> I just don't see anyone who currently maintains it on the Ubuntu side
[17:03] <rickspencer3> bryceh, works on the street that the next version will be ready almost on time, fixes a lot of bugs, and has simple fade transitions
[17:04] <rickspencer3> pitti, right
[17:04] <rickspencer3> does someone want to step up and be ubuntu pitivi maintainer?
[17:04]  * seb128 hides
[17:04] <rickspencer3> also, of course, the pitivi team has a big say in this, especially if they don't feel it is ready
[17:05] <seb128> I'm fine doing updates
[17:05] <seb128> but I don't want to do extra work on it
[17:05] <pitti> seb128: would not make much sense anyway if you aren't even using it
[17:05] <rickspencer3> there may be some codecy stuff that needs to be tweaked
[17:05] <rickspencer3> yeah
[17:05] <seb128> pitti, well I'm doing updates for lot of GNOME things I don't use
[17:06] <rickspencer3> seb128, right, I think he was referring to the "extra work" part
[17:06] <pitti> seb128: is that an argument that you want pitivi maintenance pushed to you? :-)
[17:06] <seb128> noooo ;-)
[17:06] <rickspencer3> ok, let's carry this over to next week
[17:07] <rickspencer3> see how everyone feels after ff ;)
[17:07] <rickspencer3> perhaps I will have talked someone into it by then
[17:07] <rickspencer3> pitti, did you have an "other business" item?
[17:07] <pitti> anyone at least got a video cam?
[17:07] <seb128> hehehe
[17:07] <pitti> rickspencer3: some stragglers
[17:07] <rickspencer3> ok
[17:07]  * rickspencer3 hands mic to pitti
[17:07] <pitti> kenvandine: I saw that power-indicator just got dropped, so that settles question 1
[17:07] <kenvandine> :)
[17:08] <pitti> http://people.canonical.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html
[17:08] <pitti> I cleaned up a little today (some people got nagging questions from me, sorry)
[17:08] <pitti> so we are by and large back on track
[17:08] <pitti> I went through the remaining WIs, and they seem sensible and current to me
[17:08] <pitti> if you sort this list by number of "todo", you'll see that 9 specs are just having 1 WI left
[17:09] <seb128> there is probably some that can be moved there
[17:09] <seb128> like speeding xrandr
[17:09] <pitti> also, things like "write test plan", etc.
[17:09] <pitti> which can be done after FF, and in freezes
[17:09] <pitti> startup-speed is obviously the biggest one left
[17:09] <pitti> we still have some stuff in the pipe
[17:09] <pitti> oh, btw
[17:09] <pitti> http://people.canonical.com/~scott/ratchet-netbook-lucid-20100216-23.png
[17:10] <pitti> 10.8 s!
[17:10] <pitti> that's with some tweaks of Keybuk which will get uploaded soon
[17:10] <rickspencer3> oh man
[17:10] <rickspencer3> go go go
[17:10] <didrocks> :)
[17:10] <seb128> ;-)
[17:10] <pitti> all other bits are in the budget, just desktop is at 4.8
[17:10] <pitti> but this is awesome
[17:10] <rickspencer3> so where do we get the .8 seconds?
[17:11] <pitti> kenvandine: sfts -> remaining ones is integration (MIR and the like)? or still coding work to do?
[17:11] <pitti> it gets tight for this
[17:11] <pitti> rickspencer3: we still have some stuff in the pipe, like seb128's current work on nm-applet
[17:12] <rickspencer3> great
[17:12] <pitti> (which doesn't influence this particular chart, though)
[17:12] <seb128> I'm done with it
[17:12] <kenvandine> pitti, just one coding item
[17:12] <seb128> it has been handed to upstream and nm-applet packaging team now
[17:12] <kenvandine> and a few docs
[17:12] <kenvandine> pitti, i still hope to be done
[17:12] <kklimonda> chrisccoulson: bug 522726 - builds fine, haven't found any problems
[17:12] <pitti> seb128: rock, thanks a lot
[17:13] <seb128> pitti, you're welcome
[17:13] <rickspencer3> pitti, any other wi business to discuss?
[17:13] <pitti> the other bigger bit is the remaining mobile-lucid-une-2d-launcher
[17:13] <didrocks> pitti: so, you think that the 2D/3D detection added last week is still relevant? (this will slow down the boot, without speaking I wasn't able to work on that today)
[17:13] <pitti> didrocks: you had some concern there which is worth discussing?
[17:13] <pitti> didrocks: heh, snap :)
[17:14] <rickspencer3> asac has stepped out
[17:14] <didrocks> well, with the bg cache WI always changing, I don't know if I will have the time to do this (the 3 WI related)
[17:14] <rickspencer3> but I wanted to discuss with him today
[17:14] <pitti> didrocks: I saw another WI in a different spec which just said "if mutter fails to load, present a dialog and explain how to switch" or so?
[17:14] <didrocks> pitti: right, hence the "3" :)
[17:14] <rickspencer3> what is the consequence of not getting those items done?
[17:14] <pitti> didrocks: we certainly shouldn't reintroduce something like the compiz wrapper
[17:15] <kwwii> seb128: lp:~ubuntu-art-pkg/humanity/release is updated with the new message menu icon
[17:15] <didrocks> pitti: that was the plan: a wrapper to choose right "netbook-launcher{,-efl}
[17:15] <seb128> kwwii, danke
[17:15] <didrocks> but well, as it has been added at some kind of last minute effect, I don't know if it is really important
[17:15] <pitti> didrocks: can't we put that as code into n-l itself, with a very cheap test?
[17:16] <pitti> didrocks: anyway, I don't think it's an alpha-3 blocker
[17:16] <pitti> if we need it, it can land by beta-1
[17:16] <rickspencer3> ok, I'll talk to asac about just removing it from Lucid altogether
[17:16] <pitti> if we determine that the current behaviour breaks too much on boxes without 3D support
[17:16] <didrocks> pitti: so, asking for a FFe?
[17:16] <rickspencer3> pitti, but if we keep working on it, that's less bandwidth for:
[17:16] <rickspencer3> 1. find and fix teh worst bugs
[17:16] <rickspencer3> 2. ensure a smooth upgrade experience
[17:16] <pitti> didrocks: well, a fallback to the 2D launcher is a bug fix if starting thhe 3D launcher totally breaks the box
[17:17] <didrocks> pitti: heh, right
[17:17] <pitti> right, it's not even an upgrade problem, is it"
[17:17] <pitti> ?
[17:17] <jpds> 12
[17:17] <pitti> karmic's netbook-laucher totally screws up in kvm
[17:17] <pitti> i. e. on non-3D machines
[17:18] <didrocks> no, nothing was done previously
[17:18]  * Amaranth sees compiz mentioned
[17:18] <pitti> didrocks: so if at all, I'd like to see the live system installer make the change (with an alternative perhaps)
[17:18] <pitti> depending on whether the live system detects 3D caps or not
[17:19] <didrocks> pitti: only on the live system so, what if you have a nvidia card and install 3D acceleration?
[17:19] <pitti> didrocks: then you have a postinst to change the alternative
[17:19] <pitti> but still, it seems quite complex to me
[17:19] <pitti> so my question would rather be, how much are we required to get this in the first place?
[17:20] <pitti> didrocks: if we can do something cheap and easy, like a 0.01 s runtime test in n-l which, when fails, executes n-l-2d, that's fine
[17:20] <didrocks> that's not on my call, asac or rickspencer3, maybe :) for me, at least, it's not a regression, just a better experience thing
[17:20] <pitti> didrocks: right, it's a question for asac
[17:20] <didrocks> pitti: right, not sure about the test to do yet TBH
[17:20] <rickspencer3_> my tubes!
[17:21] <pitti> rickspencer3_: wb
[17:21] <rickspencer3_> heh
[17:21] <pitti> seb128 fell off the planet as well
[17:21] <rickspencer3_> my network connection went down, am on 3g now :/
[17:21] <rickspencer3_> anywho,
[17:21] <pitti> didrocks: ok, too complex for meeting topic; let's discuss tomorrow morning with asac, shall we?
[17:21] <seb128> sorry about that
[17:21] <seb128> I'm back
[17:21] <rickspencer3_> pitti, all done?
[17:21] <didrocks> pitti: sure
[17:21] <pitti> rickspencer3_: yes, from my side
[17:22] <rickspencer3_> any other business?
[17:22] <kenvandine> not from me
[17:22] <seb128> no
[17:22]  * rickspencer3_ taps gavel
[17:22] <rickspencer3_> thanks all!
[17:22] <pitti> thanks everyone
[17:22] <ccheney> thanks
[17:22] <pitti> dinner o'clock
[17:22] <didrocks> thanks
[17:22] <seb128> thanks
[17:23]  * didrocks returns fighthing the deserialize stuff
[17:23] <bryceh> thanks
[17:28] <LaserJock> didrocks: so I got around the UNE panel immutability thing by creating my own ubuntu-netbook-default-settings for the short term
[17:28] <seb128> LaserJock, why don't you just change your session to be similar to une in that regard?
[17:28] <seb128> ie one bar with the applets you ned
[17:28] <seb128> need
[17:30] <didrocks> right, after discussion, UNE panel will keep the mandatory layout as the "UNE experience". if people wants to configure their panel, they can change the default GNOME session to fit their need (if you want to write a doc on that, I can help you)
[17:30] <ccheney> pitti: are the changes to reach 10.8s going to make alpha 3?
[17:31] <james_w> ah!
[17:31] <james_w> my gpg agent grabbed all keyboard input to the system
[17:31] <james_w> then displayed the results in the box
[17:31] <james_w> without masking any of it
[17:31] <james_w> has anyone else seen that?
[17:32] <didrocks> james_w: what version of seahorse-plugin do you have?
[17:33] <didrocks> seahorse-plugins* even
[17:33] <james_w> 2.29.90-0ubuntu3
[17:33] <james_w> that's not necessarily what is running in my session though, if this was recently fixed
[17:33] <didrocks> hum, not me this time ;) let me have a test, I have to build something
[17:34] <james_w> yeah
[17:34] <james_w> seb has already fixed it
[17:34]  * james_w hugs him
[17:35] <LaserJock> didrocks: I guess I didn't know it would be easy to convert a normal GNOME panel into a netbook one, what about things like the launcher?
[17:36] <kklimonda> james_w: I have a problem with merging transmission using bzr full source branches - sid packages is using new source format, it have patches from debian/patches/ applied but no .pc directory so when I try to generate source package I get errors. known problem or am I doing something wrong way?
[17:36] <didrocks> LaserJock: just add a symlink from /etc/xdg/autostart/netbook-launcher.desktop pointing to /etc/xdg/xdg-une/netbook-launcher.desktop (same for maximus)
[17:36]  * seb128 hugs james_w
[17:36] <didrocks> LaserJock: if you want to write a doc for others people wanting customization and who don't care having both session, that whould rock :)
[17:37] <LaserJock> didrocks: yeah, I think I'd be up for that
[17:37] <seb128> or if that's for your user only add those to your session
[17:37] <didrocks> LaserJock: if you want me to have a look once done, do not hesitate
[17:37] <LaserJock> didrocks: that seems like a decent compromise for "power" users
[17:37] <didrocks> seb128: right, maybe easier this way
[17:37] <LaserJock> didrocks: is there an existing "space" for UNE docs?
[17:37] <james_w> kklimonda: I haven't come across that
[17:38] <didrocks> LaserJock: I agree. And as seb128's suggested, we can do one part "for all users" and one part "for your user only"
[17:38] <james_w> kklimonda: I know there have been a couple of dpkg bugs in this area, perhaps it is related to those
[17:38] <didrocks> LaserJock: TBH, I don't know :)
[17:38] <james_w> kklimonda: I don't think it's specific to the merge is it? You can't build the sid branch?
[17:39] <LaserJock> didrocks: in the past the Netbook wiki pages have often been pretty outdated and less-than-helpful just due to the in-development nature of things
[17:39] <didrocks> LaserJock: true, maybe lucid is time to write something small and up to date
[17:42] <pitti> ccheney: I think so
[17:43] <kklimonda> james_w: I can and that's why I'm wondering if I do something wrong - do you have any documentation I could read? Things I've found were.. incomplete :)
[17:44] <ccheney> pitti: cool :)
[17:44] <kklimonda> james_w: right now I branch lucid branch, merge debian branch, fix all conflicts (and I get a few outside of the debian/ directory), then commit and use bzr bd to create package - at this point I get "dpkg-source: warning: patches have not been applied, applying them now"
[17:46] <james_w> kklimonda: looking
[17:49] <pitti> didrocks: actually, perhaps we could just install n-l on i386/amd64, and n-l-efl on armel by default
[17:50] <didrocks> pitti: yes, this is the default fallback. It would just be a little better if we can be more fine-grained
[17:50] <didrocks> pitti: the issue is not technical issue, just time issue
[17:51] <pitti> if that's good enough for asac, let's keep it that way
[17:51] <didrocks> pitti: the background cache is just failing on deserialization now btw
[17:51] <didrocks> ok
[17:51] <pitti> :(
[17:51]  * pitti hugs didrocks
[17:51] <didrocks> I'm stuck with it for 30 min now :/
[17:51]  * didrocks hugs pitti back
[17:53] <pitti> didrocks: like, the deserialization doesn't work?
[17:54] <asac> didrocks: whats up?
[17:54] <didrocks> pitti: right
[17:54] <asac> too hard to implement the fallback?
[17:54] <asac> (or too time consuming?)
[17:55] <didrocks> asac: just no time. I haven't been able to even give it a look
[17:55] <didrocks> I was thinking working on that yesterday and today
[17:55] <asac> didrocks: ok. no problem.
[17:55] <asac> just dont seed the 3d launcher on armel ;)
[17:55] <pitti> asac: are there actually any arm devices which can (and should) run n-l instead of n-l-efl?
[17:55] <asac> yes
[17:55] <asac> in theory most ... its just a driver issue
[17:56] <chrisccoulson> good evening everyone
[17:56] <seb128> hey chrisccoulson
[17:56] <chrisccoulson> hey seb128. have you had a good day?
[17:56] <didrocks> as pitti said, we can still consider that as a bug and so, target it just after FF
[17:56] <didrocks> asac: ^
[17:56] <asac> didrocks: works for me
[17:56] <pitti> the other major question is how much effort (boot speed wise) it is to figure out 3D support
[17:56] <seb128> chrisccoulson, okish, I managed to get some work today but I think I got a cold too
[17:57] <didrocks> (in exchange, I hope to have a FFe for Quickly too ;))
[17:57] <asac> i thought you planned to do that anyway?
[17:57] <pitti> asac: we certainly don't want another compiz wrapper thing, taking more than a second
[17:57] <didrocks> pitti: right
[17:57] <seb128> I've a start of running nose
[17:57] <pitti> seb128: urgh, cold?
[17:57] <chrisccoulson> seb128 - thats not good. i hope the cold doesn't develop in to something too bad
[17:57] <pitti> seb128: hot tub, book, bed?
[17:57] <seb128> pitti, yeah, something like that I guess ;-)
[17:57] <didrocks> pitti: I'll try to have a look on netbook-launcher, see where it fails and so, respawn netbook-launcher-efl in that case
[17:57] <seb128> still half an hour finishing things and I'm off for diner and relaxing
[17:58] <pitti> didrocks: if it properly fails, launching -efl in a kind of "exception" handler is best; saves the startup cost up-front
[17:58] <didrocks> pitti: right, seems to be a good things. We should just check if it properly fails in those case
[17:59] <didrocks> asac: do you have some arm where you can try netbook-launcher and see if it fails or just hang on?
[17:59] <didrocks> (clutk_init or clutter_init should fail, I guess)
[18:00] <didrocks> s/arm/arm hw/
[18:00] <asac> i will ask someone to try that ;)
[18:00] <didrocks> thanks asac :)
[18:02] <chrisccoulson> kklimonda, thanks for doing transmission
[18:02] <chrisccoulson> i'll sponsor that now
[18:06] <LaserJock> didrocks: is there a mailing list for UNE where there could be a doc discussion?
[18:07] <chrisccoulson> kklimonda, i can't merge your transmission branch
[18:08] <kklimonda> chrisccoulson: problem with rich support or something else?
[18:08] <chrisccoulson> bzr: ERROR: KnitPackRepository('file:///home/chr1s/src/transmission/ubuntu-desktop/ubuntu/.bzr/repository/') is not compatible with CHKInventoryRepository('file:///home/chr1s/src/transmission/kklimonda/lp.522726/.bzr/repository/')
[18:08] <didrocks> LaserJock: not from what I know of, there are some bug triagers mostly but not a proper doc handling (as there it's diveded more on multiple components).
[18:08] <didrocks> LaserJock: if you find one, ping me, I'll subscribe :)
[18:09] <chrisccoulson> ooh, nice icons:)
[18:09] <LaserJock> didrocks: help.ubuntu.com/community has a number of wiki pages but only on specific netbook hardware (eeepc, aspire one, etc.)
[18:09] <kklimonda> chrisccoulson: maybe I have a newer version of bzr?
[18:09] <chrisccoulson> kklimonda, what version do you have?
[18:09] <kklimonda> chrisccoulson: when I branch lp:~ubuntu-desktop/transmission/ubuntu I get "Doing on-the-fly conversion from <RemoteRepositoryFormat> to <RepositoryFormat2a>."
[18:09] <seb128> chrisccoulson, bzr upgrade I would say
[18:10] <didrocks> LaserJock: maybe time to gather everything if you are interested in it. that would rock :)
[18:10] <chrisccoulson> seb128 - thanks, that fixed it :)
[18:10] <LaserJock> didrocks: yeah, looks like a landing page would be good, then clean up of the outdated stuff
[18:10] <kklimonda> chrisccoulson: no - it wasn't that but seb128 has helped as always :)
[18:10] <LaserJock> didrocks: then adding of LTS documentation for things like this panel issue
[18:10] <seb128> chrisccoulson, you might also want to bzr upgrade lp:~ubuntu-desktop/etc
[18:11] <seb128> chrisccoulson, or you will not be able to push I think
[18:11] <didrocks> LaserJock: so, should I understand that you volonteer? ;)
[18:11] <seb128> sort of stupid but I got stucked due to that several times
[18:11] <chrisccoulson> seb128 - thanks, i will do that before i push then
[18:11] <LaserJock> didrocks: to some extent, yes
[18:12] <LaserJock> didrocks: I'll start working on it and see how far I get
[18:12] <didrocks> LaserJock: sweet! thanks a lot. Ping me if you need help (after FF) :)
[18:12] <LaserJock> didrocks: my full-time "production" machine is an Aspire One, it benefits me to have good docs ;-)
[18:12] <didrocks> LaserJock: sure ;-)
[18:12] <LaserJock> I also have a horrible memory, that's the other reason
[18:14] <didrocks> heh
[18:15] <seb128> hum
[18:28] <pitti> good night everyone
[18:29] <didrocks> good night pitti
[18:30] <kklimonda> chrisccoulson: I got a black vertical line from empathy again - any idea how to debug it? ;)
[18:30] <kklimonda> seb128 has just went to sleep :/
[18:30] <chrisccoulson> kklimonda, i'm not sure. i've noticed that too
[18:31] <chrisccoulson> kenvandine - have you noticed that too?
[18:53] <seb128> I'm uploading gnome-keyring 2.29 to the ubuntu-desktop ppa for those who want to try it
[18:54] <seb128> out of mission-control which fails after autologin (but works after being restarted) it seems to work fine there
[19:03] <qense> fta: the version number used in the Gwibber PPA makes it older than the release included in the Lucid repositories. Is this desired?
[19:05] <rickspencer3> kenvandine, I am loving the multi stream view in Gwibber
[19:06] <qense> so am I
[19:08] <james_w> kklimonda: I've managed to reproduce now
[19:09] <rickspencer3> seems some folks are having good success with pitivi: http://www.0xdeadbeef.com/weblog/2010/02/sunrise-over-sweden/
[19:11] <LaserJock> didrocks: https://help.ubuntu.com/community/UbuntuNetbookEdition is an intitial stab at rounding up pages
[19:12] <james_w> kklimonda: it's not the .pc dir
[19:12] <james_w> it's that the top patch has to fuzz to apply now
[19:13] <didrocks> LaserJock: awesome, will be a good base for gathering everything :)
[19:14] <chrisccoulson> yay, transmission with app-indicator support uploaded \o/
[19:14] <kklimonda> and I've heard people at #ayatana talking about making a new icon for transmission :)
[19:15] <qense> kklimonda: It would be nice if Humanity would include a monochrome tray icon for transmission.
[19:16] <LaserJock> didrocks: I'm not sure what to do with all the stuff for like pre-karmic releases, I guess maybe first thing should be to get more Lucid docs and then archive the rest?
[19:16] <fta> qense, no, but as kenvandine (upstream) uploads to lucid as soon as there's an upstream commit, there's nothing i can do ;)
[19:16] <chrisccoulson> qense - vish might be the person to ping about that
[19:16] <chrisccoulson> but yeah, it would be nice :)
[19:16] <didrocks> LaserJock: I'm in favor on that, "UNE" is only lucid (and karmic) interface
[19:17] <qense> chrisccoulson: I think jorge was going to talk with some people about the icon.
[19:17] <didrocks> grrr, g_file_get_contents () doesn't give me the right length, this is from where come the error
[19:17] <qense> fta: well, then I'll just wait until a new version lands in Lucid. ;)
[19:20] <vish> qense: transmission icon? for now i havent icon any new monochrome icons.. the ones in the recent update were rather old ones which only got pushed recently   ;)   [/me still waiting for info from UX team]
[19:21] <vish> havent done*
[19:21] <qense> vish: jorge was going to hand the transmission icon names to the design team, so I'm not sure if you'll be asked to do it
[19:21] <jcastro> I told kwwii about it, I'll bug him about it tomorrow
[19:22]  * vish uses vuze
[19:22] <vish> qense: i have a neat vuze icon though ;)
[19:22] <kklimonda> james_w: any guidelines how to fix it or should I just sit tight and wait? :)
[19:23] <qense> vish: Well, someone better give Vuze Indicator Application support then!
[19:23] <james_w> kklimonda: quilt push; quilt refresh; quilt pop; would be a good start
[19:23] <Nafai> Is there a way to print the XML from a GtkBuilder?
[19:23] <fta> qense, the daily starts at 4am UTC (or when someone asks me to boost it manually)
[19:24] <qense> fta: but the version of Gwibber in Lucid really is older than the one in the PPA. I think it's because of the ~ that 2.29.1 is regarded as newer than a later commit.
[19:26] <didrocks> spotted the bug, I think \o/
[19:26] <mvo> james_w: or edit-patch ;)
[19:27] <james_w> mvo: \o/
[19:28] <fta> qense, well, it's not my choice, the packaging should either use "+" instead of "~" in g-o-s, or upstream should bump the version just after release
[19:28] <fta> kenvandine, ^^, could you please do one of those?
[19:29] <qense> fta: but in lucid we've got gwibber 2.29.1-0ubuntu1 whereas the PPA as got 2.29.1~bzr597-0ubuntu2~daily1
[19:29] <qense> 2.29.1 is older than revision 597
[19:29] <fta> qense, i know
[19:29] <qense> ok
[19:30] <fta> 2.29.1~bzr597-0u1 < 2.29.1-0u1 < 2.29.1+bzr597-0u1 < 2.29.2~bzr597-0u1
[19:30] <chrisccoulson> vish - why use vuze?
[19:30] <chrisccoulson> transmission rocks ;)
[19:30] <chrisccoulson> we should be ditching the icons in the transmission menu though shouldn't we?
[19:31] <chrisccoulson> all of the items there are actions rather than objects
[19:31] <kenvandine> fta, i'll bump it
[19:31] <vish> chrisccoulson: havent used transmission recently, but earlier[1-2yrs ago] it seemed to lack a lot of features.. been using vuze since a long time
[19:32] <vish> chrisccoulson: the first thing after an install i do is remove transmission ;p
[19:32] <chrisccoulson> vish - which features in particular? the newer transmission releases are pretty sweet :)
[19:32] <chrisccoulson> although, i don't use that many features
[19:32] <Nafai> vish: Yeah, vuze has been my usual choice, that's mainly out of habit though
[19:33] <chrisccoulson> i tend to stick with all the applications on the stock install
[19:33] <chrisccoulson> it's difficult for me to test apps that i don't use daily
[19:33] <vish> chrisccoulson: i think it was per torrent speed control.. but not sure ,  that might be it... i should try transmission.. vuze  just hogs memory :(
[19:34] <qense> vish: Transmission really improved over the last few releases
[19:34] <fta> kenvandine, thanks
[19:35]  * vish takes transmission for a spin
[19:43] <vish> ooh.. transmission has indeed improved , neeeat :D
[19:44] <chrisccoulson> brb, session restart
[19:49] <chrisccoulson> does gnome-screensaver fade out work for anybody running proprietary nvidia drivers in lucid?
[19:52] <rodrigo_> hey kenvandine, how's the libu1 work going? do you need anything from me?
[19:53] <kenvandine> rodrigo_, nope
[19:53] <rodrigo_> kenvandine, ok, cool!
[19:53] <kenvandine> rodrigo_, :)
[19:53] <rodrigo_> :)
[19:53] <kenvandine> rodrigo_, congrats on the 3G modem
[19:53]  * kenvandine wants one
[19:53] <rodrigo_> kenvandine, yeah, works great indeed, just had to tweak a wvdial.conf file
[19:53] <kenvandine> :)
[19:54] <rodrigo_> kenvandine, I got it for free from my DSL company
[19:54] <rodrigo_> kenvandine, maybe you can get one from yours?
[19:54] <kenvandine> i wish
[19:54] <rodrigo_> kenvandine, I won't use it much, but it's great to be able to do some work while travelling :-)
[19:55] <chrisccoulson> mdeslaur, mind running gnome-screensaver --debug for your fade issue?
[19:55] <chrisccoulson> i suspect the issue is the proprietary driver
[19:56] <mdeslaur> chrisccoulson: sure...
[19:57] <chrisccoulson> mdeslaur, it seems g-s uses the XRANDR extension now for doing the fade, and the proprietary nvidia driver might not support that
[19:58] <didrocks> pitti: I honestly wonder if the serialization thing is good: On my laptop (1920x1200) original file: 175058, serialized_file: 3183453 (18x bigger!). If you want to give a benchmark test tomorrow morning, here you will find the i386 debs: http://people.canonical.com/~didrocks/
[19:59] <vish> chrisccoulson: qense: thanks for reminding me of transmission :D   , it does indeed look nicer now.. only problem i loose all my ratio in vuze :(
[19:59] <vish> ;)
[19:59] <qense> vish: well, write a convertor for it!
[19:59] <mdeslaur> chrisccoulson: I attached the debug log to the bug
[20:00] <vish> qense: meh.. too much work just for bragging.. i lost similarly when i converted from windows ;)
[20:00] <chrisccoulson> mdeslaur, thanks
[20:00] <mdeslaur> chrisccoulson: curiously, it used to work with 2.29.1, and I don't see any changes related to that in git
[20:01] <mdeslaur> chrisccoulson: unless the stoopid nvidia driver changed
[20:01] <vish> maybe i'm like Nafai still liking the trusty old vuze  :)
[20:01] <chrisccoulson> mdeslaur, oh, that's strange if it worked in 2.29.1
[20:01] <chrisccoulson> that version uses the new fade
[20:02] <asac>  /win7
[20:02] <mdeslaur> chrisccoulson: let me downgrade for a sec...my memory is usually unreliable :)
[20:03] <vish> qense: does the memory usage stay low?  what i see now is 1/10th of vuze 0.o   unbelievable
[20:03] <kenvandine> asac, is win7 better than vista ?
[20:03]  * kenvandine ducks
[20:03] <chrisccoulson> [gs_fade_init] gs-fade.c:889 (14:58:13):	 Fade type: 3
[20:03] <chrisccoulson> which is FADE_TYPE_XRANDR
[20:04] <mdeslaur> chrisccoulson: you're right, it stopped fading with 2.29.1
[20:05] <qense> vish: I never tested it, but I also never noticed it using a lot of memory.
[20:05] <chrisccoulson> mdeslaur, i suspect then that this is not supported in the nvidia driver
[20:05] <mdeslaur> chrisccoulson: yeah
[20:05] <chrisccoulson> mdeslaur, would you mind running gnome-screensaver through xtrace, so i can see the X protocol calls?
[20:06] <mdeslaur> chrisccoulson: sure, hold on a sec
[20:06] <chrisccoulson> thanks
[20:09] <kklimonda> vish: it does
[20:10] <mdeslaur> chrisccoulson: I've attached an xtrace
[20:11] <asac> kenvandine: lol
[20:12] <vish> neat...  now i have to wean from vuze slowly ;)
[20:12] <kklimonda> vish: transmission's developer have made a benchmark some time ago: http://pastehtml.com/view/091108Kw3uDGmn.html
[20:13] <kklimonda> vish: you can't really even compare T with Vuze in terms of memory usage - it isn't fair fight
[20:13] <vish> yeah , vuze consistently stays over 120MB :(
[20:20] <chrisccoulson> mdeslaur, so, it seems like it's not supported by the nvidia drivers
[20:21] <chrisccoulson> g-s thinks it is, because:
[20:21] <chrisccoulson> 000:>:002c:32: Reply to QueryVersion: major-version=1 minor-version=3
[20:21] <mdeslaur> chrisccoulson: great...it says it supports RANDR, but it doesn't really :)
[20:21] <chrisccoulson> the server says it supports version 1.3 of the RANDR extension, which is a lie
[20:21] <chrisccoulson> yeah
[20:21] <mdeslaur> chrisccoulson: typical proprietary crap :)
[20:22] <mdeslaur> chrisccoulson: thanks for taking a look, I'll close the bug
[20:22] <chrisccoulson> i'll try and think of a way to work around that in g-s, that still makes it possible for us to have the nice fade :)
[20:22] <chrisccoulson> you can keep ths bug open for now, as we will probably have to work around it anyway
[20:22] <mdeslaur> chrisccoulson: by "us", you mean the smart devs who bought an intel chipset, right? :)
[20:23] <chrisccoulson> the proprietary drivers won't be going away unfortunately
[20:23] <chrisccoulson> mdeslaur, yeah, the people with an intel chipset ;)
[20:23] <mdeslaur> hehe
[20:23] <chrisccoulson> although, my desktop upstairs has a nvidia card too, but it still runs karmic
[20:23] <Nafai> Are they intel chips that go up to 1920x1200?
[20:23] <chrisccoulson> so, it would be nice if i could fix it
[20:24] <Nafai> s/they/there/
[20:24] <Nafai> That's one of the reason I like the nvidia card in my Thinkpad
[20:33] <Nafai> This looks like an interesting program: http://kaizer.se/wiki/kupfer/
[20:38]  * mvo hugs james_w for bzr-builddeb
[20:57] <superm1> hi.  can someone desktopy take a look at gnome-panel-data's postinst and see if there is any logical reason why we're still calling (casper|dpkg)-reconfigure as the live cd boots?  I don't see any particular reason that code snippet needs to stick in there and reconfigure the package
[21:34] <bryceh> erf, this shifting from X blueprint work to bugs again is rough.  There are **so** many bug reports 8-|
[21:34] <bigon> sorry to ask again but could somebody make that merge ? https://bugs.edge.launchpad.net/ubuntu/+source/papyon/+bug/520699
[21:35] <chrisccoulson> mdeslaur, i'm trying to figure out how to work around this nvidia issue. i don't know if you have time for doing any debugging, but i'm interested in whether xrandr_fade_setup returns FALSE when attempting to do the fade (because gnome_rr_crtc_get_gamma returns FALSE)
[21:36] <chrisccoulson> and if that's the case, i'm trying to figure out what triggers the blanking of the screen eventually
[21:36] <mdeslaur> chrisccoulson: sure, I've got time
[21:37] <chrisccoulson> from comparing xtrace with and without nvidia, i think we can work around the issue and fall back to the non-randr gamma fade on nvidia
[21:39] <mdeslaur> chrisccoulson: let me install the debugging symbols and figure out how to check with gdb
[21:42] <chrisccoulson> mdeslaur, thanks :)
[21:45] <mdeslaur> chrisccoulson: it's returning TRUE
[21:46] <chrisccoulson> oh, that's unexpected ;)
[21:49] <chrisccoulson> mdeslaur, does xrandr_crtc_whack_gamma get called when the fade is meant to happen?
[21:50] <chrisccoulson> and does "if (gamma_info->size == 0)" evaluate to TRUE in xrandr_crtc_whack_gamma ?
[21:50] <chrisccoulson> i suspect that is probably what happens
[21:51] <chrisccoulson> it certainly doesn't get as far as setting the gamma, as i don't see any calls in xtrace
[21:52] <mdeslaur> chrisccoulson: yes, xrandr_crtc_whack_gamma gets called a bunch of times, and always return with that condition being true
[21:52] <chrisccoulson> cool, thanks. that's probably all i need to know for now then
[21:53] <mdeslaur> chrisccoulson: cool, let me know if you need anything else
[21:56] <Ian_Corne> Hello :)
[22:00] <rickspencer3> TheMuso, robert_ancell hi
[22:00] <seb128> re
[22:00] <robert_ancell> rickspencer3, hi
[22:00] <seb128> hey robert_ancell
[22:00] <robert_ancell> seb128, hey
[22:00] <seb128> kenvandine, still needing sponsoring?
[22:00] <seb128> robert_ancell, how are you?
[22:01] <robert_ancell> seb128, good, just woke up :)
[22:02] <TheMuso> rickspencer3: yo
[22:03] <rickspencer3> TheMuso, robert_ancell I'm putting the irc log on the meeting agenda right now
[22:03] <TheMuso> ok
[22:05] <rickspencer3> TheMuso, robert_ancell Eastern Edition?
[22:05] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-02-16
[22:05] <TheMuso> Sure
[22:05] <rickspencer3> let me know when you've read it through
[22:08] <kenvandine> seb128, yup
[22:08]  * kenvandine looks for branches
[22:09] <kenvandine> lp:~ken-vandine/rhythmbox-ubuntuone-music-store/ubuntu
[22:09] <kenvandine> lp:~ken-vandine/libubuntuone/ubuntu
[22:09] <kenvandine> seb128,
[22:09] <kenvandine> temp branches, then need to go to lp:ubuntu/NAME
[22:09] <robert_ancell> rickspencer3, I'll put my hand up for pitivi but not until I return to Desktop
[22:09] <robert_ancell> (full time)
[22:09] <kenvandine> then i will delete them
[22:10]  * TheMuso has read
[22:10] <rickspencer3> robert_ancell, thank you
[22:10] <rickspencer3> maybe we can find someone to fill in until then
[22:10] <rickspencer3> ok
[22:10] <rickspencer3> let me run through the high points as I see them
[22:10] <rickspencer3> 1. lots of U1 stuff is going to land this week
[22:10] <rickspencer3> 1.1 I mean *lots*
[22:10] <rickspencer3> 1.2 seriously
[22:11] <rickspencer3> 2. Kubuntu seems in quite good shape, Riddell seems to have it in hand (no surprise there I suppose)
[22:12] <rickspencer3> 3. Libsoup porting is almost done and should be done this week (I report for about the 5th week running)
[22:12] <rickspencer3> 4. Post A3
[22:12] <rickspencer3> this part I am not sure impacts TheMuso and robert_ancell so much, but it bears repeated
[22:12] <rickspencer3> blueprint work should finish off this week
[22:12] <rickspencer3> A3 will be substantially what the desktop team will deliver for final
[22:12] <robert_ancell> blueprint work = blueprints for Lucid?
[22:12] <rickspencer3> robert_ancell, yes
[22:13] <rickspencer3> so the rest of the cycle is:
[22:13] <rickspencer3> 1. find and fix the worst bugs
[22:13] <rickspencer3> 2. ensure a smooth upgrade experience
[22:13] <rickspencer3> 3. integrate teh latest and greates (as appropriate)
[22:13] <rickspencer3> robert_ancell, are there work items for lucid that you are concerned about?
[22:14] <robert_ancell> rickspencer3, no, I think mine are all postponed/been claimed by seb128 :)
[22:14] <rickspencer3> thank you robert_ancell
[22:14] <rickspencer3> TheMuso, audio update?
[22:15] <TheMuso> rickspencer3: Nothing significant this week other than the fix for the ideapad machines being committted upstrea and available in crack of the day now.
[22:15] <rickspencer3> oh, great
[22:15] <TheMuso> upstream even, and I wasn't the one who wrote the patch, someone else did for another ideapad variant which uses the same chip.
[22:15] <rickspencer3> that's great news
[22:16] <rickspencer3> ok, so in terms of #1 above, no one had any great ideas about how to improve our ability to find the right bugs to fix
[22:16] <rickspencer3> I am intending to work on this a bit with marjo, I am hoping that bdmurray's new tools help (especially gravity)
[22:16] <TheMuso> Not really, other than scane packages one works on to find the bugs./
[22:16] <seb128> robert_ancell, oh please feel free to still do you gdmsetup hacks if you get to that first though ;-)
[22:16] <rickspencer3> *cough*
[22:17] <rickspencer3> too late
[22:17] <rickspencer3> *couch*
[22:17] <rickspencer3> ;)
[22:17] <seb128> lol
[22:17] <robert_ancell> rickspencer3, :P
[22:17] <seb128> I will bug fix gdm otherwise to turn login sound off by default
[22:17] <rickspencer3> for #2, I would like to see some more planning and rigor in finding upgrade bugs a bit earlier
[22:17] <robert_ancell> seb128, did you find a good method to do that?
[22:17] <seb128> which is a "ups, default value changed I don't know why"
[22:17] <rickspencer3> but again, no one had any good ideas, so I will approach marjo abotu that as well
[22:18] <seb128> robert_ancell, we have a custom gconf config which sets the theme etc
[22:18] <seb128> robert_ancell, I can add the key there
[22:18] <seb128> (sorry to disturbe the meeting)
[22:18] <robert_ancell> seb128, ok, talk about it later
[22:18] <rickspencer3> for Easter Edition, any other business?
[22:18] <TheMuso> seb128: please no
[22:18] <TheMuso> a11y people will go skitso over that
[22:19] <rickspencer3> TheMuso, he's teasing me, don't worry, seb128 wouldn't really do something like that :P
[22:19] <seb128> TheMuso, let's discuss it after meeting but 99% of users don't need sound and get embarassed in public places due to that
[22:19] <rickspencer3> robert_ancell, what about the new configurator that you blogged about
[22:19] <rickspencer3> can we get that into universe?
[22:19] <robert_ancell> rickspencer3, yes, talking with the developers about it
[22:19] <TheMuso> seb128: Ok, I can turn it on for a11y profiles during the install.
[22:19]  * TheMuso sighs.
[22:19] <rickspencer3> so I think that is just grand
[22:20] <seb128> robert_ancell, I'm not sure I'm happy about you promoting hacking things having pygtk running under sudo and gconftool calls btw ;-)
[22:20] <rickspencer3> seb128, not turning the sound off "by accident"
[22:20] <robert_ancell> seb128, a hack is good enough for most people :)
[22:20] <rickspencer3> seb128, are you concerned about the implementation of the new gdm configurator?
[22:20] <seb128> rickspencer3, yes, cf my reply on the list
[22:20] <seb128> it's a very hackish way to do things
[22:20] <rickspencer3> list?
[22:21] <seb128><EMAIL_ADDRESS>[22:21] <TheMuso> An alternative is to allow people to mute the sound from within gdm. The volume will be saved for the gdm user, and no harm will be done once users do that.
[22:21] <seb128> sorry I though you were reading this one
[22:21] <rickspencer3> man, I have no recollection of that thread :/
[22:21] <robert_ancell> (which was my earlier question, seb128 have you worked out a safe way of settings gdms gconf?  or are you moving to a global gconf setting only used by gdm)
[22:21]  * rickspencer3 has tooooo much email
[22:21] <seb128> I know the feeling ;-)
[22:22] <seb128> robert_ancell, not really no, but changing from the greater would be easier since it runs as gdm user no?
[22:22] <rickspencer3> seb128, I assume you mean "hackish" in a "can lead to bad results" way, and not in a "clever problem solving" way
[22:22] <robert_ancell> seb128, oh, I see
[22:22] <seb128> rickspencer3, no, I mean "running gui under gksudo when we try to move away from this model" and "doing things like system("gconftool...")"
[22:23] <seb128> or rather sudo -u user gconftool --set...
[22:23] <rickspencer3> hmmm
[22:23] <rickspencer3> seems fine for a universe app, and a good contribution for users who want it
[22:23] <seb128> agreed
[22:24] <seb128> I would like to see useful options available in the default install though
[22:24] <seb128> but not really a meeting topic ;-)
[22:24] <rickspencer3> seb128, right, maybe Lucid + 1
[22:24] <rickspencer3> I think the meeting is over, actually
[22:24] <rickspencer3> there was no other business
[22:24] <seb128> I think that ought to be in lucid
[22:24] <rickspencer3> seb128, well, feature freeze is in 2 days
[22:24] <seb128> I will spend weekend time on it I guess if nobody gets to it first
[22:24] <rickspencer3> hmmm
[22:24] <seb128> it really sucks to have your computer being loud at boot in library or plane
[22:25] <robert_ancell> seb128, this is an idea - we make a new gconf key "/desktop/gnome/login_mute" that is only read by gdm and set the default from gdmsetup
[22:25] <seb128> it gives me a feeling of job not well done
[22:25] <rickspencer3> seb128, I suppose, I don't think it's that big of a deal
[22:25] <seb128> ie that was the sort of things I mentionned when we talked some days ago that I was envisioning getting fixed in a lts
[22:25] <rickspencer3> well, I suppose we can treat that as a bug
[22:25] <rickspencer3> no, I think the sound should be on by default
[22:25] <robert_ancell> rickspencer3, a _lot_ of people complain about it.  And the worst thing is PA takes so long to register the mute button that you hear it for a few seconds (in a crowded room)
[22:26] <TheMuso> you only need to turn off /desktop/gnome/sound/event_sounds and the libcanberra desktop ready autostart event will not be run.
[22:26] <seb128> TheMuso, right, which as you pointed is an a11y issue
[22:26] <robert_ancell> TheMuso, yes, but we need to set that in gdm's gconf from another user
[22:26] <TheMuso> robert_ancell: right
[22:26] <seb128> TheMuso, I mean if we do it by default
[22:26] <rickspencer3> robert_ancell, we can't just change the whole start up experience as a bug fix to a problem that annoys us
[22:26] <robert_ancell> which is easy if you are root
[22:26] <TheMuso> seb128: Right, if we really want it off by default as I said, I can turn it on for a11y profile users.
[22:26] <seb128> otherwise we need a gui way to set gconf keys for an another user
[22:27] <rickspencer3> there must be myriad ways to turn off the start up sound
[22:27] <seb128> rickspencer3, I would argue that having no sound by default and sound only in a11y profile is a better default then
[22:27] <seb128> which I can get in by ff
[22:27] <TheMuso> There are, but turning off /desktop/gnome/sound/event_sounds is probably the best.
[22:27] <rickspencer3> seb128, no
[22:27] <rickspencer3> like I said, we can't just change the startup experience like that
[22:27] <rickspencer3> there are too many stake holders
[22:28] <seb128> ok
[22:28] <seb128> rock, hard place, us?
[22:28] <rickspencer3> nice Friends reference, seb128
[22:28] <seb128> it's really a show stopper for many users
[22:28] <seb128> rickspencer3, ;-)
[22:28] <rickspencer3> well, now they have a sweet tool that they can use to make GDM do whatever they want
[22:29] <rickspencer3> and it's community contributed software, too
[22:29] <seb128> if they go to universe is fetch it
[22:29] <seb128> anyway I think we agree
[22:29] <rickspencer3> I think we should rather focus on code defects and such
[22:29] <seb128> I just with we could have fixed that by now
[22:29] <seb128> but that's life
[22:29] <robert_ancell> seb128, there'll be enough forum posts pointing out how to do it
[22:29] <seb128> we can't get everything done
[22:29] <rickspencer3> we would have if we hadn't lost robert_ancell
[22:29] <rickspencer3> see robert_ancell we really miss you!
[22:29] <robert_ancell> rickspencer3, blame OEM, blame O-E-M!
[22:29]  * seb128 hugs robert_ancell
[22:29] <seb128> come back!
[22:30] <seb128> we will be nice to you
[22:30] <robert_ancell> seb128, that will make a change :P
[22:30] <seb128> ;-)
[22:31] <robert_ancell> seb128, if I get around to it i'll make that second gconf key patch and it will automagically work :)
[22:31] <seb128> waouh
[22:31] <seb128> $beers++ for you at next uds ;-)
[22:33] <seb128> kenvandine, did you consider those review ready for upload?
[22:33] <seb128> kenvandine, or do you just want a first quick review?
[22:34] <kenvandine> seb128, i wonder what that means :)
[22:34] <kenvandine> bad errors?
[22:34] <seb128> honest question
[22:34] <kenvandine> oh... yeah... they should be ready
[22:34] <seb128> libubuntuone has no COPYING
[22:34] <seb128> or any license
[22:34] <kenvandine> oh!
[22:34] <ebartilson> hello, I have a quick problem, I have a server computer at work, when I go to install ubuntu ( any iteration)  when i click install only a dialog box appears
[22:34] <kenvandine> oh... damn
[22:34] <rickspencer3> ebartilson, hi
[22:34] <ebartilson> i think its not allowing the CD to load into ram
[22:34] <seb128> kenvandine, so I was wondering if that was just a "review the packaging they will sort licenses"
[22:34] <ebartilson> How're y'all doin?!
[22:34] <seb128> kenvandine, or it's that a "ups"
[22:34] <kenvandine> it's in trunk
[22:34] <rickspencer3> ebartilson, this channel is typically for developers working on the distro
[22:34] <kenvandine> but not be in dist
[22:35] <kenvandine> seb128, let me look again
[22:35] <seb128> ebartilson, hi, you might want to ask on #ubuntu rather
[22:35] <rickspencer3> support questions typically get answered better in #ubuntu
[22:35] <kenvandine> i reviewed it before doing a source package branch import thingy
[22:35] <seb128> kenvandine, ok ;-)
[22:35] <kenvandine> which sucks in the tarball
[22:35] <ebartilson> I'm sorry, I've tried boot and server
[22:35] <rickspencer3> ebartilson, but you are sure welcome to hang out!
[22:35] <ebartilson> thanks tho!
[22:35] <ebartilson> ill leave the channel open thank you
[22:37] <ebartilson> I haven't used an IRC client in ages!, I'm using a web based one and it sucks
[22:37] <ebartilson> I feel like im not synced with any servers
[22:39] <seb128> kenvandine, also
[22:39] <seb128> $ grep "version 2 of the GNU Lesser" libubuntuone/* -r
[22:39] <seb128> libubuntuone/syncdaemon.c: * modify it under the terms of version 2 of the GNU Lesser General Public
[22:39] <seb128> libubuntuone/syncdaemon.h: * modify it under the terms of version 2 of the GNU Lesser General Public
[22:39] <seb128> libubuntuone/u1-music-store.c: * modify it under the terms of version 2 of the GNU Lesser General Public
[22:39] <seb128> libubuntuone/u1-music-store.h: * modify it under the terms of version 2 of the GNU Lesser General Public
[22:39] <seb128> kenvandine, those are under the LGPL2
[22:39] <seb128> kenvandine, which is neither in the debian copyright on in the missing COPYING
[22:39] <seb128> ups
[22:39] <kenvandine> it is in the copyright file
[22:40] <seb128> libubuntuone/xmalloc.c: GPL (with incorrect FSF address)
[22:40] <seb128> it's the other way around
[22:40] <seb128> kenvandine, ^
[22:40] <seb128> kenvandine, sorry, that one is under GPL and not LGPL
[22:40] <kenvandine> ah... i can fix that :)
[22:40] <seb128> good ;-)
[22:43] <seb128> kenvandine, configure.ac looks for gconf-2.0
[22:43] <seb128> kenvandine, but you don't build-depends on libgconf2-dev
[22:43] <seb128> dbus-glib-1 and libxml-2.0
[22:43] <seb128> too
[22:44] <kenvandine> i bet those aren't needed
[22:44]  * kenvandine checks
[22:44] <seb128> well they are using in configure
[22:44] <seb128> so configure will fail if they are not there
[22:45]  * TheMuso assumes the meeting is done...
[22:45] <seb128> so you need to fix either configure or build-depends
[22:45] <rickspencer3> TheMuso, sorry
[22:45] <rickspencer3> yeah, like 20 minutes ago :/
[22:45] <TheMuso> rickspencer3: np
[22:46] <seb128> TheMuso, <rickspencer3> I think the meeting is over, actually about 21 minutes ago there
[22:46] <seb128> ups
[22:46] <seb128> I added what is after the ","
[22:46] <rickspencer3> TheMuso, thanks!
[22:46] <seb128> ir rather the "about 21..."
[22:47] <seb128> kenvandine, right, gconf doesn't seem to be used
[22:47] <seb128> libubuntuone/u1-music-store.c:#include <libxml/HTMLparser.h>
[22:47] <seb128> libubuntuone/syncdaemon.c:#include <dbus/dbus-glib.h>
[22:47] <seb128> kenvandine, ^ those are though
[22:47] <kenvandine> this has been building in my ppa... so i would be confused if it actually fails to build
[22:48] <seb128> well transitional depends
[22:48] <seb128> like webkit probably triggers some
[22:48] <seb128> it doesn't mean you package should rely on those
[22:48] <seb128> webkit might stop doing that one day
[22:48] <seb128> you should trigger what you actually need
[22:48] <seb128> or pull what you need rather
[22:48] <kenvandine> ok
[22:49] <seb128> we had quite some of those bugs when things stopped using deprecated gnome libs
[22:49] <seb128> other things started failing to build because they were relying on depends to be installed by other packages which stopped doing that
[22:50] <kenvandine> yeah, good practice to include what you check for :)
[22:50] <seb128> kenvandine, out of the xmalloc.c GPL issues and the missing explicit build-depends it seems good ;-)
[22:50] <seb128> and the lack of COPYING
[22:51] <seb128> hum
[22:51] <seb128> kenvandine, debian/tmp/usr/share/libubuntuone/javascript/*
[22:51] <seb128> in libubuntuone-1.0-1.install
[22:51] <seb128> that's also problematic
[22:52] <kenvandine> ?
[22:52] <seb128> library packages usually have only the library
[22:52] <kenvandine> well, but those are used by the library
[22:52] <seb128> you need to be able to install several soname versions together
[22:52] <kenvandine> oh
[22:52] <kenvandine> damn...
[22:52] <seb128> the binaries would conflict there
[22:52] <kenvandine> i guess a new package it is :)
[22:52] <seb128> can't you version the dir too?
[22:52] <seb128> like having it follow the soname
[22:52] <seb128> debian/tmp/usr/share/libubuntuone-1.0
[22:53] <seb128> so if the abi change the dir change
[22:53] <kenvandine> ok, that will require rodrigo to make code changes and a new release :)
[22:53] <seb128> and you avoid the conflict
[22:53] <kenvandine> but that is the right thing
[22:53] <seb128> otherwise you need a new binary package
[22:53] <kenvandine> the lib might need a specific version of the js
[22:53] <seb128> right
[22:53] <kenvandine> can we ship this version like this and advise him to fix it?
[22:53] <seb128> yes
[22:53] <seb128> just fix the license issue
[22:54] <seb128> other ones can be fixed after alpha3
[22:54] <seb128> the build-depends are easy to fix too while you are at it
[22:54] <seb128> the versionning can wait
[22:54] <kenvandine> yeah
[22:54] <seb128> it needs to be fixed before lucid though
[22:54] <kenvandine> done... just verifying all is sane in pbuilder
[22:54] <seb128> good ;-)
[22:55] <seb128> kenvandine, also the find and delete .a and .la in rules can be dropped
[22:55] <seb128> those are not installed by the .install
[22:56] <kenvandine> ok
[22:56] <seb128> brb, session restart and I will review the other source ;-)
[22:58] <chrisccoulson> mdeslaur, if you're still around, would you mind testing this patch: http://paste.ubuntu.com/377969/
[22:59] <mdeslaur> chrisccoulson: sure, give me a few minutes
[22:59] <chrisccoulson> thanks
[23:00] <kenvandine> seb128: libubuntuone should be good
[23:03] <kenvandine> seb128: libubuntuone should be good
[23:03] <seb128> kenvandine, looking
[23:05] <seb128> kenvandine, you need a COPYING.GPL too
[23:05] <seb128> kenvandine, since you have a GPL source
[23:05] <kenvandine> oh crap... yeah :)
[23:06] <kenvandine> one sec
[23:06] <seb128> sorry to be picky there
[23:06] <kenvandine> no prob
[23:06] <seb128> but if I'm not pitti will not accept those tomorrow ;-)
[23:06] <kenvandine> glad upstream will be happy to accept my merge proposal :)
[23:06] <seb128> hehe
[23:06] <seb128> the other bzr doesn't work
[23:06] <seb128> lp:~ken-vandine/rhythmbox-ubuntuone-music-store/ubuntu
[23:07] <kenvandine> oh... i blame aquarius
[23:07] <seb128> is it private?
[23:07] <kenvandine> aquarius, i bet cause it is stacked on your branch that had been private!
[23:07] <aquarius> damn.
[23:07]  * kenvandine grumbles
[23:07] <aquarius> mbarnett unprivated my branch and the default setting for the project, but probably didn't do the other branches in the project. Sorry.
[23:08] <aquarius> it is my fault, although in my defence the fact that you have to get a losa to fix it for you is *not* my fault :)
[23:09] <kenvandine> seb128, aquarius has been battling that for a bit today :)
[23:10] <seb128> so still an extra bit to go ;-)
[23:10] <aquarius> my bit of advice for today: do not get a launchpad project made private. Doing so will make your life a misery later on when you change your mind.
[23:11] <kenvandine> seb128, libubuntuone pushed
[23:12] <mdeslaur> chrisccoulson: works great!
[23:13] <chrisccoulson> mdeslaur, excellent!
[23:13] <chrisccoulson> i'll get that uploaded in a few minutes
[23:13] <seb128> kenvandine, sorry still one issue, debian copyright says LGPL2+ when license is LGPL2
[23:14] <seb128> is the any later version should not be there
[23:14] <kenvandine> all the source files say or any later version
[23:14] <mdeslaur> chrisccoulson: sweet :)
[23:14] <seb128> " * This library is free software; you can redistribute it and/or
[23:14] <seb128>  * modify it under the terms of version 2 of the GNU Lesser General Public
[23:14] <seb128>  * License as published by the Free Software Foundation.
[23:14] <seb128> "
[23:14] <mdeslaur> chrisccoulson: and thanks!
[23:14] <kenvandine> or not
[23:14] <seb128> kenvandine, libubuntuone/syncdaemon.c
[23:14] <chrisccoulson> you're welcome:)
[23:14] <seb128> kenvandine, ;-)
[23:14] <kenvandine> ok, that is easier to fix :)
[23:15]  * kenvandine has read lots of license files today :)
[23:15] <seb128> hehe
[23:15] <seb128> that's something that upstream tends to always get wrong for some reason
[23:15] <seb128> like most of us wouldn't care about those details for some reasons ;-)
[23:17] <kenvandine> seb128, so the COPYING file's example text includes the "or (at your option) any later version."
[23:17] <kenvandine> but since the headers don't have that, i should just make the copyright file match what's in the headers?
[23:18] <rickspencer3> seb128, kenvandine is the latest pitivi in the default install atm?
[23:18] <seb128> hum?
[23:18] <seb128> rickspencer3, yes
[23:18] <rickspencer3> thanks
[23:19] <seb128> kenvandine, I fail to parse that I think
[23:19] <kenvandine> seb128, the example block in that COPYING file is exactly how it is in the copyright file
[23:19] <kenvandine> but the source headers don't include the "or later version" bit
[23:20] <seb128> kenvandine, just delete what is after the "," in the debian copyright
[23:20] <kenvandine> ok
[23:20] <kenvandine> so make it match the source headers :)
[23:20] <seb128> the COPYING section you mention is " How to Apply These Terms to Your New Libraries"
[23:20] <seb128> ie it's an howto about how you can do it
[23:21] <seb128> if the source text dropped the "or..." do the same in the copyright
[23:22] <kenvandine> seb128, pushed
[23:22]  * kenvandine needs to head afk for a bit, kids are begging me for dinner :)
[23:22] <seb128> kenvandine, ok, seems good now, I will get that one in by time you get up tomorrow
[23:23] <kenvandine> ok
[23:23] <kenvandine> lets look at rb tomorrow :)
[23:23] <seb128> kenvandine, drop me an email if you get the other one public or do a source upload somewhere
[23:23] <kenvandine> sure
[23:23] <kenvandine> well, if i recreate the branch
[23:23] <seb128> I will review that by time you get up
[23:23] <kenvandine> it will be public
[23:23] <seb128> and upload if it's good
[23:23] <kenvandine> so i can do that tonight
[23:23] <seb128> ok good
[23:23] <seb128> thanks
[23:23] <seb128> enjoy your evening
[23:23] <seb128> see you tomorrow!
[23:25] <rickspencer3> by seb128