[03:59] <robert_ancell> Have you guys been looking at the software centre reviews?  It's nice to start getting some good feedback on what users like...
[08:11] <didrocks> good morning
[08:13] <glatzor> morning mvo
[08:14] <glatzor> mvo, I pushed a lot of changes to the lp:~aptdaemon-developers/aptdaemon/ubuntu-natty/ branch. Would be nice if you could find the time for a review and upload
[08:17] <mvo> hey glatzor, good morning!
[08:17] <mvo> glatzor: sure thing, many thanks :)
[08:19] <glatzor> mvo, have a nice day! I have to leave for "school".
[08:20] <mvo> see you glatzor
[08:32] <didrocks> RAOF: bryceh: so, I have a nvidia card, see that there is still no new driver. I'm wondering however why apt-get upgrade still wants to upgrade some X packages, namely:
[08:32] <didrocks> x11-common xserver-common xserver-xephyr xserver-xorg-input-all xserver-xorg-video-all
[08:32] <didrocks> is it safe to upgrade those packages with the previous Xorg server or is it a packaging issue?
[08:35] <pitti> Good morning
[08:40] <RAOF> didrocks: I *think* those are all safe.
[08:41] <didrocks> Guten Morgen pitti :)
[08:41] <didrocks> RAOF: ok, I'll send you a reclamation letter if I can't restart :p
[08:41] <pitti> hey didrocks
[08:41] <RAOF> didrocks: :)
[08:41] <Sweetshark> G'Morning!
[08:42] <didrocks> RAOF: thanks! I'll try that ;)
[08:42] <didrocks> hey Sweetshark
[08:42] <pitti> hello Sweetshark, wie gehts?
[08:42] <RAOF> Morning Sweetshark & pitti.
[08:42] <pitti> RAOF: ¡ɐıןɐɹʇsnɐ oʇ sƃuıʇǝǝɹƃ
[08:43] <didrocks> excellent! ;)
[08:43] <RAOF> :)
[08:50] <Sweetshark> pitti: Im fine. I got my first commits in LO yesterday (about the human icons). Got to fight to get them backported to the 3.3 branch today. ;)
[08:53] <kamstrup> mvo: Hey, https://bugs.launchpad.net/app-install-data-ubuntu/+bug/711304, is becoming increasingly important to us - still not super-duper-urgent, but njpatel is at a point where it would at least be nice to have it for testing
[08:53] <ubot2> Launchpad bug 711304 in app-install-data-ubuntu "Create icon-theme.cache file to support mmap()ed icon loading" [Medium,In progress]
[08:59] <pitti> Sweetshark: ooh, nice! do they work now?
[08:59] <pitti> Sweetshark: you mean you added them upstream, too?
[08:59] <mvo> kamstrup: aha, right - I look into that today
[09:00] <kamstrup> mvo: awesome. njpatel ^^
[09:02] <seb128> hey didrocks pitti
[09:02] <seb128> hey mvo
[09:02] <mvo> hey seb128
[09:02] <didrocks> hello seb128
[09:02] <seb128> mvo, how are you?
[09:03] <mvo> good, thanks ! how are you?
[09:03] <pitti> hey seb128
[09:03] <seb128> I'm fine thanks
[09:04] <Sweetshark> pitti: Well, to be honest I dont know yet for sure if they truely work. I updated the patch with the changes that are needed in source, to that there is no need for patching there. I tested by renaming the tango theme in my install to human an it showed up as an option. So the rest is hopefully just configuration stuff that can be done in our packaging voodoo.
[09:05] <njpatel> thanks mvo !
[09:06]  * mvo just needs to finish this code-review work
[09:07] <kamstrup> gord: sorry dude, i #failed... gio/gvfs I just impossible to grok!
[09:07] <Sweetshark> pitti: I wanted to get this stuff in upstream as source file patches might break again with the next change, while the configuration stuff is unproblematic. Actually the upstream changes are trivial because of the refactoring that broke the patch.
[09:09] <pitti> Nicke:
[09:09] <pitti> sorry, "nice"
[09:09] <pitti> Sweetshark: btw, if LibO 3.4 will be released well before Natty, then you might not need to backport, but we could instead follow upstream alphas/betas until 3.4?
[09:14] <pitti> jasoncwarner: hello
[09:14] <jasoncwarner> morning pitti
[09:16] <pitti> jasoncwarner: wrt. meeting, just sent a reminder; I might not be available either (apparenlty caught some kind of infection); seb128, would you be able to chair the meeting today?
[09:16] <jasoncwarner> I was about to go to sleep and then I saw your comment on LibO 3.4.. when are people thinking LibO 3.4 would be ready to go ? wow
[09:17] <jasoncwarner> pitti: no worries...we'll check with seb...feel better.
[09:17] <pitti> I don't really know -- I was just saying that _if_ it's planned to release soon anyway, then we don't need to backport stuff
[09:18] <jasoncwarner> ;)
[09:18] <jasoncwarner> got it
[09:18] <jasoncwarner> cool.
[09:19] <seb128> pitti, sure no worry
[09:19] <jasoncwarner> Ok, I need to get some sleep. Trying to get a full 4 hours before my baby shift starts ;) good night everyone!
[09:19] <seb128> hey jasoncwarner, how are you?
[09:19] <pitti> jasoncwarner: sleep well!
[09:19] <jasoncwarner> hey seb...pretty good...
[09:19] <seb128> jasoncwarner, 'night ;-)
[09:19] <jasoncwarner> though, now I know why people say that we as humans have defense mechanisms about babies
[09:20] <jasoncwarner> our defenses are we forget all about the work, sleepless nights and other stuff that is the first year! ;)
[09:20] <jasoncwarner> now I remember....oh do I ever ;)
[09:21] <Sweetshark> pitti, jasoncwarner: As the LO is still pretty young, there might be some hickups on the release planning, so I will try to get the changes into 3.3 upstream just to make sure. I dont want to get in trouble by trusting release dates ;)
[09:22] <Sweetshark> jasoncwarner: G'night!
[09:23] <jasoncwarner> thanks Sweetshark, no worries!
[09:23] <jasoncwarner> talk to you tomorrow
[09:24] <Sweetshark> mind you, that the above is not a bash of LO: OOo had ten rcs for the last release ...
[09:25] <pitti> Sweetshark: heh, ok
[09:29] <chrisccoulson> good morning everyone
[09:29] <chrisccoulson> hey jasoncwarner!
[09:29] <pitti> hey chrisccoulson
[09:30] <chrisccoulson> hi pitti, how are you?
[09:30] <seb128> hey chrisccoulson
[09:30] <pitti> chrisccoulson: feeling a bit sick actually (light fever), so I'll take it light today
[09:30] <didrocks> hey jasoncwarner, chrisccoulson
[09:30] <pitti> s/light/easy/
[09:30] <chrisccoulson> hey seb128, didrocks, how are you too?
[09:30]  * chrisccoulson hugs pitti
[09:31] <chrisccoulson> hmmm, could someone accept thunderbird for me? it's sat in binary NEW atm :)
[09:31] <didrocks> chrisccoulson: I'm fine, thanks :) I'm pushing a fix for compiz which should fix incendentally the invisible window bug, be ready to test :)
[09:31] <chrisccoulson> didrocks, oh, excellent. that's good to hear :)
[09:32] <seb128> chrisccoulson, I'm fine, what about you?
[09:32] <seb128> chrisccoulson, did you get the appmenu update? does it fix your issue?
[09:33] <pitti> didrocks: oooh
[09:33] <chrisccoulson> seb128 - yeah, good thanks. a little tired though. i was up late last night getting the appmenu work in for thunderbird
[09:33] <chrisccoulson> i've not tried the indicator-appmenu update just yet
[09:33] <seb128> chrisccoulson, didn't the upstream guy got someone to do that for you?
[09:33] <seb128> guys
[09:34] <chrisccoulson> seb128 - for thunderbird? yeah, there is somebody helping out with that now
[09:34] <chrisccoulson> mike conley, he hangs out in #ayatana
[09:34] <seb128> you should let him deal with it :p
[09:34] <didrocks> pitti: chrisccoulson: the fix is to fix a restacking issue at startup. Hence the "incendentally" as the invisible window isn't at startup. I'm tested it from yesterday evening without any glitch. Same for Jason who did the patch
[09:34] <didrocks> let's cross fingers :)
[09:38] <rodrigo_> morning
[09:38] <seb128> hey rodrigo_, how are you?
[09:38] <rodrigo_> hi seb128
[09:52] <htorque> hello everyone! is the '/desktop/gnome/session/required_components/windowmanager' key obsolete in natty? i set it to "gnome-shell", but that didn't change anything (unlike in 10.10).
[09:53] <chrisccoulson> htorque, yes, it doesn't do anything anymore
[09:53] <chrisccoulson> take a look in /usr/share/gnome-session/sessions instead
[09:54] <didrocks> htorque: you need to add a file to /usr/share/xsessions/ pointing one in /usr/share/gnome-session/sessions
[09:54] <htorque> chrisccoulson, didrocks thanks! :)
[09:54] <didrocks> htorque: the /desktop/gnome/session/required_components/windowmanager is working in the gnome classic session though
[09:55] <didrocks> (using gnomewm)
[09:55] <htorque> didrocks, oh, that would be fine too, thanks
[09:58] <chrisccoulson> didrocks - you're an archive admin now aren't you? :)
[09:58]  * didrocks hides ;)
[09:58] <didrocks> chrisccoulson: what's up? :)
[09:58] <chrisccoulson> didrocks - would you mind accepting https://launchpad.net/ubuntu/+source/thunderbird/3.1.8+build1+nobinonly-0ubuntu6 please :)
[09:58] <didrocks> chrisccoulson: looking :)
[10:02] <didrocks> chrisccoulson: hum, I don't have the sudo access yet to change my user. I can't check the .deb then, doing in another way
[10:02] <chrisccoulson> didrocks, ok, thanks :)
[10:04] <seb128> re
[10:06] <seb128> pitti, there is a gobject-introspection new tarball today
[10:06] <pitti> ooh, finally
[10:06] <seb128> pitti, just pointing it in case you want to do the update
[10:07] <pitti> seb128: yeah, will do
[10:07] <seb128> pitti, danke
[10:08] <pitti> seb128: there's just one small bug fix compared to our current git snapshot, so this should be easy
[10:09] <seb128> great
[10:12] <pitti> seb128: hm, have you seen this before?
[10:12] <pitti> --- gobject-introspection-1.0.pc        2011-02-02 13:48:50 +0000
[10:12] <pitti> +++ gobject-introspection-1.0.pc        2011-02-08 10:09:31 +0000
[10:13] <pitti> @@ -1,6 +1,6 @@
[10:13] <pitti> -prefix=/usr/local
[10:13] <pitti> +prefix=/src/build/jhbuild
[10:13] <pitti> seb128: is that normal or a faulty make dist?
[10:13] <pitti> (that's our current git snapshot vs. 0.10.2 tarball)
[10:13] <seb128> pitti, check your build but I guess the tarball ships the .pc where it doesn't need to
[10:13] <seb128> pitti, like it's likely build from a .pc.in at build time
[10:13] <pitti> ok, I'll build it and check there
[10:13] <pitti> ah, right
[10:13] <pitti> so should be harmless
[10:14] <seb128> pitti, so it gets the value from whoever make dist it
[10:14] <seb128> but will be regenerated at build
[10:14] <seb128> right
[10:26] <mvo> kamstrup: hm, makes me wonder what icon-size I need to put there, I get odd results, no matter what I put there
[10:27] <mvo> kamstrup: I can upload it for now with size=32 so that you have something to work against, but I'm pretty sure this will need tweaking
[10:27] <kamstrup> mvo: yeah, that crossed my mind as well... just trying something is a good start
[10:28] <kamstrup> mvo: the problem is that all the icons in the dir have wildly variying sizes
[10:29] <mvo> yep
[10:29] <mvo> exactly
[10:45] <pitti> chrisccoulson, dpm: current po2xpi seems to look in xpi/firefox-4.0/de.xpi, but launchpad exports them as xpi/firefox/de.xpi
[10:45] <chrisccoulson> hmmm, why does it look in xpi/firefox-4.0?
[10:45] <chrisccoulson> (the source package is just called firefox)
[10:46] <pitti> the lucid/maverick one is quite broken as well, but for now I'm trying to make the po2xpi trunk work first
[10:47] <pitti> hm, even if I symlink it to firefox-4.0 it still doesn't work
[10:47] <pitti> $ sh -x bin/process-xpi test/xpi-natty/ /tmp/t 11.04
[10:48] <pitti> using data dir: /home/martin/ubuntu/langpack-o-matic/po2xpi/data//8.04
[10:48] <pitti> this looks really wrong -- it shouldn't use its internal data dir at all any more, even less so for hardy??
[10:50] <pitti> chrisccoulson, dpm: for lucid/maverick, is po2xpi actually meant to produce .xpis on the fly from launchpad .po files?
[10:50] <pitti> or should it use the pregenerated xpis from po2xpi.maverick/data.orig/common_xpi/ ?
[10:50] <chrisccoulson> pitti - i'm not sure about that, but dpm might know more ;)
[10:50] <pitti> asac: ^ perhaps you still remember?
[10:54] <dpm> pitti, chrisccoulson, I was having a look at po2xpi the other day, and I seem to remember it needs the original upstream xpis in data/ in addition to the Launchpad exports. I think I mentioned/asked this on my e-mail (I can't remember though)
[10:54] <pitti> uh
[10:55] <pitti> dpm: so that should be po2xpi/data/common_xpi/*.xpi  then?
[10:55] <pitti> as 8.04/, 8.10/, and 9.04/ are all obsolete
[10:56] <pitti> http://paste.ubuntu.com/564349/ is what I get right now
[10:58] <asac> i have to enqueue checking that for a later day
[10:58] <asac> maybe tomorrow?
[11:00] <pitti> dpm, chrisccoulson: so it seems that  po2xpi/data/common_xpi/ still has XPIs for 3.6, and we'd actually need to add the original 4.0 XPIs to po2xpi/data/11.04/ ?
[11:00] <chrisccoulson> pitti - yeah, i guess so
[11:00] <pitti> I just thought that having en-US.xpi (which launchpad exports from firefox) and the .po files would be enough to construct the new XPIs
[11:01] <chrisccoulson> it seems like a lot of effort :/
[11:03] <seb128> re
[11:03] <pitti> chrisccoulson, dpm: hm, danilo is not online; it seems that nobody really knows how po2xpi is supposed to work then?
[11:03] <dpm> pitti, chrisccoulson, so that's how I understood it works: http://i.imgur.com/o3TRG.png - for the runxpi2xpi part it seems to need the upstream xpis to generate them again. That's the part I cannot quite understand
[11:04] <chrisccoulson> pitti - yeah, i've not worked enough with it yet to help you i'm afraid :(
[11:04] <pitti> dpm: right, but for DEV_MODE it's supposed to just use the po?
[11:04] <dpm> pitti, danilo is not the maintainer (and said he's not interested in it, either). asac and ArneGoetje were the maintainers in the past
[11:05] <pitti> PO2XPI_INSTALL_DATA=$PO2XPI_INSTALL_DATA_BASE/8.04
[11:05] <pitti> so that's actually hardcoded in rosetta_xpi_to_sources
[11:06] <pitti> dpm, chrisccoulson: ah, seems better if I add "devmode" argument
[11:06] <pitti> that at least generates a /tmp/t/de.tar.gz with an install.rdf and a manifest for ./usr/lib/firefox-addons/extensions/langpack-de@firefox-4.0.ubuntu.com/
[11:06] <pitti> but no actual content
[11:07] <dpm> pitti, it is hardcoded in the branch because danilo published the project online when he did his changes and gave ownership to the mozillateam. I think asac did the changes locally every time there was a release?
[11:07] <pitti> ah, it's later overwritten by the third cmd line arg; I think I'll need to change this handling a bit
[11:09] <dpm> pitti, chrisccoulson so here's how I understood it: during the development cyclethe 'devmode' argument is 1 and this makes all xpis to be built from the launchpad export, using the po2xpi binary. Then,
[11:09] <dpm> after release, devmode is 0, and
[11:10] <pitti> dpm: oh, I thought we introduced devmode in lucid or so, and just used "no devmode" for the older releases where we didn't test this yet?
[11:10] <dpm> all xpis that have got a corresponding upstream xpi are generated (copied?) with runxpi2xpi
[11:10] <dpm> but a few of them are "whitelisted" and generated through po2xpi
[11:10] <pitti> dpm: so the purpose was that the updated XPIs get submitted upstream, and for stables we only use the upstream XPIs?
[11:11] <pitti> what does runxpi2xpi do then?
[11:11] <dpm> that was asac's design, the explanation is just my understanding (I might be wrong)
[11:11] <dpm> I'm not sure what runxpi2xpi does
[11:12] <dpm> but I think it's the part that requires the upstream xpis to be in data/
[11:13] <pitti> dpm: but even in devmode it seems to look for them..
[11:13]  * pitti dives into that code some more
[11:14] <chrisccoulson> i guess i really need top spend some time on this soon
[11:14] <dpm> ah, strange, perhaps it looks for the en-US.xpi template only?
[11:14] <pitti> dpm: that's not in po2xpi data, that gets exported into the launchpad tarball (as it should be)
[11:14] <pitti> hang on, I think I spotted something else
[11:14] <chrisccoulson> dpm - do you think it would be easier if we did something similar to what fta is doing for chromium?
[11:14] <pitti> /home/martin/ubuntu/langpack-o-matic/po2xpi/src/runpo2xpi: Zeile 258: /home/martin/ubuntu/langpack-o-matic/po2xpi/src/po2xpi: Datei oder Verzeichnis nicht gefunden
[11:15] <dpm> I had a look at it, but shell code is not particularly my strength. The scripts and the logic to call the po2xpi binary seem even more complex than po2xpi itself
[11:16] <pitti> ah, I need to build the po2xpi project; I do have src/po2xpi binary now, but the tar is still by and large empty
[11:17] <dpm> chrisccoulson, I think doing the same would be quite a lot of work. Ideally, po2xpi should be part of Launchpad, but the fact that it's shell + C and not python does not make that easier
[11:17] <dpm> I think we could live for now fixing the po2xpi scripts
[11:17] <dpm> and documenting them, so we don't have to go through this again
[11:18] <chrisccoulson> i don't mind, but it would be easier for me to get translations in to ubuntu for now (i'd just upload a firefox-locales package, and then we could worry about fixing the launchpad bits later on)
[11:20] <dpm> chrisccoulson, but you were telling me the other day that this would not be possible because you were packaging prereleases and the xpis might not be ready?
[11:20] <chrisccoulson> dpm - i was referring to shipping the xpi's as part of the firefox source upload
[11:20] <pitti> then I still need to unbreak the lucid/maverick langpacks somehow
[11:20] <chrisccoulson> but just now, i was talking about an entirely new source package (like we do for thunderbird)
[11:21] <pitti> well, right now langpack-o-matic still uses devmode for maverick, so I guess I need to fix both cases
[11:21] <chrisccoulson> we have a separate thunderbird-locales source package for the thunderbird translations
[11:22] <dpm> brb, phone call
[11:24] <seb128> kklimonda, hey, there is a new gtkmm update if you want to work on it
[11:25] <pitti> chrisccoulson, dpm: I just don't understand how the lucid langpacks ever had firefox translations..
[11:27] <aquarius> pitti, I appear to have apport processes starting which are using a lot of cpu -- one starts, it exits, another starts, and so on. How can i work out what it's doing?
[11:27] <chrisccoulson> i bet that's couchdb crashing!
[11:28] <pitti> aquarius: what does /var/log/apport.log say?
[11:28]  * chrisccoulson runs
[11:28] <chrisccoulson> :)
[11:28] <pitti> aquarius: and do you see anythign apport GUI related at all? or just the /usr/share/apport/apport process?
[11:28] <aquarius> chrisccoulson, almost certainly, given that I'm compiling weird new versions :)
[11:28] <aquarius> pitti, nothing on the GUI
[11:28] <chrisccoulson> heh. and with weird new versions of libmozjs
[11:28] <chrisccoulson> oh
[11:28] <chrisccoulson> i haven't tested it since i did the B11 upload
[11:29] <chrisccoulson> perhaps there was an ABI break, like there has been for every beta so far
[11:29] <aquarius> yep, couch crashing. thanks, pitti: I didn't know there was a log :)
[11:29] <chrisccoulson> oh, yes
[11:29] <chrisccoulson> i just tried that here too. couchjs crashing again :(
[11:29] <chrisccoulson> maaaaaaaaaan, that's depressing
[11:30] <aquarius> chrisccoulson, yeah, couchjs, so this is gonna be xulrunner fun again, isn't it?
[11:30]  * chrisccoulson switches to couchdb mode again
[11:32] <dpm> chrisccoulson, ok, back :) Yeah, I understand that. Regardless of whether translations are imported through a firefox upload or through a firefox-locales package, I think we should still ship them in language packs, rather than on their own package (i.e. using firefox-locales also for shipping them). Language packs allow us for regular updates without translators having to worry to request SRUs when they do new translations
[11:33] <dbarth> mvo: ping?
[11:33] <dpm> chrisccoulson, so my suggestion would be for you as the FF maintainer to give pitti a hand with po2xpi :P
[11:33] <dbarth> mvo: i'm looking at the compiz branch import at https://code.edge.launchpad.net/~vcs-imports/compiz/trunk
[11:34] <chrisccoulson> dpm - right ;)
[11:34] <chrisccoulson> i just need to find some time :/
[11:34] <dbarth> mvo: could you raise the mirror frequency to 1h? we would like to have continuous builds of compiz now
[11:34]  * dpm hugs chrisccoulson
[11:35]  * chrisccoulson hugs dpm
[11:36] <dpm> I'll try to have another look myself, but I can't promise anything, I easily get lost with all that shell code
[11:36] <pitti> dpm: right, my more immediate concern are the lucid langpacks
[11:37] <chrisccoulson> aquarius, i think i'm going to package libmozjs as a separate system library
[11:37] <pitti> I can't get them to build with firefox, and as there is no data/10.04/ I don't see how it could ever have worked
[11:37] <pitti> but demonstrably it did
[11:37] <chrisccoulson> to try and decouple couchdb from these firefox releases
[11:37] <pitti> dpm: or it really just used the hardy data all along
[11:37] <chrisccoulson> it's getting crazy now, it has broken with every single one of the beta releases
[11:37] <aquarius> chrisccoulson, well...that idea makes sense, and it made sense when we used to do it, but we stopped doing it for a reason, no?
[11:38] <chrisccoulson> aquarius, yeah, that was when we used to provide it from the xulrunner source package, so it was still coupled with firefox releases
[11:38] <chrisccoulson> i'm talking about making it an entirely separate source package, so we don't have to track firefox releases with it
[11:39] <dpm> pitti, I'm not sure how ArneGoetje and asac did it, I noticed there wasn't a data/9.10 folder, either
[11:40] <dpm> pitti, so perhaps they built them somewhere with local upstream xpis, which were never committed to any branch
[11:41] <pitti> dpm: they should still be on macquarie then
[11:41] <chrisccoulson> oh, couchdb does build against the latest mozjs. hopefully it is just an ABI break rather than a change in API too
[11:41] <dpm> right
[11:41] <pitti> dpm: I copied the old po2xpi/ verbatim to po2xpi.maverick/ (it's got tons of changes)
[11:41] <pitti> and want to use that for lucid/maverick, and po2xpi from the master branch for natty onwards
[11:42] <dpm> ok
[11:42] <pitti> I think what I want is a script that I give the en-US.xpi and a XX.po, and it builds the XX.xpi out of that
[11:42] <chrisccoulson> brb, session restart
[11:43] <pitti> with all that extra white/blacklisting, data dirs, scripts that call scripts that call other scripts it's not really obvious how it's supposed to work
[11:43] <dpm> I know, that was what I was thinking as well
[11:43] <dpm> as I said, the preprocessing scripts seem more complex than the po2xpi C binary
[11:43] <pitti> aah
[11:44] <pitti> data -> ../mozilla-upstream-locales/
[11:44] <pitti> ^ that's a dangling symlink on macquarie which I don't have locally
[11:44] <dpm> oh, are they still there then, or were they deleted?
[11:45] <pitti> apparently they got removed; mozilla-upstream-locales/ doesn't exist
[11:45] <dpm> bummer
[11:45] <pitti> I'll try the ones from po2xpi master
[11:47] <dpm> pitti, if that does not work, I can try to fetch the mozilla xpis corresponding to the FF version in Lucid
[11:47] <dpm> if that helps
[11:47] <dpm> well, I guess we'll have to do that anyway
[11:48] <dpm> as the xpis in the branch are translations from an older FF
[11:48] <pitti> dpm: can you commit them to lp:~mozillateam/po2xpi/trunk ?
[11:49] <dpm> pitti, I'll send a MP for chrisccoulson to accept
[11:49] <pitti> as we have the same firefox version in lucid and maverick anyway
[11:49] <dpm> which exact version is it, btw?
[11:49] <pitti> 3.6.13
[11:49] <dpm> ok, let me get the upstream xpis
[11:50] <chrisccoulson> well, 3.6.14 on monday ;)
[11:51] <chrisccoulson> but that doesn't really make any difference
[11:51] <pitti> once I get actually working langpacks with 3.6.13, we can do the update
[11:51] <pitti> but right now the data dir is completely messed up
[11:51] <chrisccoulson> aquarius, couchjs isn't crashing anymore, but i can't really test if it works properly, because desktopcouch-service crashes
[11:51] <pitti> the scripts look for "firefox-3.6/", the data dir has "firefox", which on top of things points to a nonexisting dir
[11:52] <chrisccoulson> (i was just using didrocks oneconf-query to test it, as that made couchjs crash before)
[11:52] <chrisccoulson> i'm not sure how else to test it ;)
[11:52] <didrocks> chrisccoulson: can we had onconf-query to the testsuite? </kidding> :)
[11:55] <pitti> ooh, it's running
[11:57] <chrisccoulson> didrocks, don't joke, oneconf-query *is* my testsuite atm ;)
[11:58] <didrocks> chrisccoulson: hehe, excellent!
[12:01] <mvo> hey dbarth, I don't think I have the needed LP permission to do this, probably needs a launchpad admin
[12:01] <pitti> asac, chrisccoulson, dpm: hm, seems the xulrunner XPIs got lost; xpi -> /home/asac/mozilla-rosetta/po2xpi/data/common_xpi/
[12:02] <pitti> but that dir doesn't exist any more
[12:02] <chrisccoulson> pitti - not sure we care about those too much
[12:02] <dpm> pitti, xulrunner translations are not needed after 3.0 or 3.5
[12:02] <chrisccoulson> i don't know if there is anything in the archive using visible strings from xulrunner
[12:02] <chrisccoulson> (and if there is, they'll be in universe)
[12:02] <dpm> can't remember which, but in any case nowadays we've only got translatable strings for firefox in LP
[12:03] <dpm> I mean 'firefox' is the only translatable template, and the only one we get xpis for
[12:03] <pitti> chrisccoulson, dpm: do you know where I can get the XPIs for current firefox and xulrunner? I'd like to do a branch with the data dir fixed and cleaned up
[12:03] <pitti> chrisccoulson: oh, we don't?
[12:03] <pitti> chrisccoulson: I finally got my rebuild to spit out a de.tar.gz with a de.jar for firefox, but not for xulrunner
[12:04] <pitti> chrisccoulson: that might be fine for natty, but for lucid we should keep them
[12:04] <chrisccoulson> pitti - translations for just firefox is fine. we don't have any for xulrunner in lucid or maverick anyway
[12:04] <chrisccoulson> (or, at least, i don't think we do)
[12:04] <pitti> hmkay
[12:04] <chrisccoulson> we shouldn't care about that anyway, i want to get xulrunner out of main ;)
[12:04] <dpm> pitti, that's where I'm getting them from right now: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.6.13/linux-i686/xpi/
[12:05] <pitti> dpm: ah, so I'll pull them into the data
[12:05] <pitti> thanks
[12:05] <dpm> yeah, I'm uploading the lucid ones to a po2xpi branch right now
[12:05] <kklimonda> seb128: I'd love to take a look, but not before thursday - till then I'm stuck without my broadband :)
[12:06] <pitti> dpm: ah, ok; into common_xpi?
[12:06] <pitti> dpm: I'm currently preparing a branch of po2xpi to fix and clean up the data dir
[12:06] <pitti> dpm: so I'll keep using common_xpi for now
[12:07] <dpm> pitti, no, I thought for now under data/10.04/firefox/xpi. I didn't want to overwrite common_xpi
[12:07] <dpm> but you can rearrange it as you like
[12:07] <pitti> dpm: we'll share them between maverick and lucid, though
[12:07] <pitti> dpm: ok, will do
[12:07] <dpm> ok, sounds good
[12:08] <pitti> dpm: it seems you are already pushing, so I'll wait for this? (otherwise I'll just do the entire thing here)
[12:08] <dpm> lp has given up pushing my branch, trying again
[12:09] <pitti> and I think I'll abandon po2xpi.maverick
[12:09] <pitti> don't want to fix everything twice
[12:14] <dbarth> mvo: ok, thanks; i'll try to find one
[12:16] <Sweetshark> pitti: Do you think it would be ok to go for the LO 3.3.2 release for natty? RC1 would be Mar 7, final would be Mar 14. Keep in mind that this is already on a relatively stable 3.3 release branch.
[12:16] <pitti> Sweetshark: yes, absolutely
[12:16] <Sweetshark> k
[12:16] <pitti> Sweetshark: we should upgrade to all 3.3.x releases and RCs that they do
[12:17] <pitti> so that we have more updates with smaller steps, and can also help testing them
[12:21] <seb128> kklimonda, can you open a bug and tag it desktop-upgrade so it shows on the version list?
[12:22] <seb128> kklimonda, just say you will do the update later this week on it
[12:22] <seb128> kklimonda, so nobody else duplicate work
[12:23] <kklimonda> seb128: will do
[12:23] <seb128> kklimonda, thanks
[12:26] <pitti> dpm: https://code.launchpad.net/~dpm/po2xpi/lucid-mozilla-upstream-locales -> still trouble pushing?
[12:27] <chrisccoulson> right, time to kill abrowser
[12:27] <dpm> pitti, yes :(
[12:27]  * chrisccoulson sharpens axe
[12:27] <dpm> $ bzr push lp:~dpm/po2xpi/lucid-mozilla-upstream-locales
[12:27] <dpm> Write failed: Broken pipehing revisions:Inserting stream
[12:27] <dpm> Write failed: Broken pipe
[12:27] <pitti> dpm: hm, perhaps I'll just include the new XPIs in my branch then?
[12:28] <dpm> pitti, yes, I think that'll be quicker
[12:28] <dpm> sorry about that, I'm not sure why bzr or LP are not cooperating
[12:29] <chrisccoulson> dpm - i'll be able to fix bug 705392 later ;)
[12:29] <ubot2> Launchpad bug 705392 in firefox "The generated en-US.xpi translation template lacks branding" [Undecided,New] https://launchpad.net/bugs/705392
[12:30] <dpm> chrisccoulson, \o/
[12:30] <dpm> thanks
[13:01] <pitti> dpm, chrisccoulson: so, apparently something changed in the jar structure for firefox-4.0
[13:01] <pitti> /home/martin/ubuntu/langpack-o-matic/po2xpi/src/runpo2xpi firefox-3.6 /home/martin/ubuntu/langpack-o-matic/test/xpi-lucid/xpi/firefox-3.6/en-US.xpi /home/martin/ubuntu/langpack-o-matic/test/xpi-lucid/xpi/firefox-3.6/de.po
[13:01] <pitti> that works and produces a full de.xpi for lucid
[13:01] <pitti> /home/martin/ubuntu/langpack-o-matic/po2xpi/src/runpo2xpi firefox-4.0 /home/martin/ubuntu/langpack-o-matic/test/xpi-natty/xpi/firefox/en-US.xpi /home/martin/ubuntu/langpack-o-matic/test/xpi-natty/xpi/firefox/de.po
[13:01] <pitti> this is firefox-3.6 -> 4.0 and pointing to the natty export
[13:02] <pitti> and produces a small and basically empty de.xpi
[13:02] <pitti> chrisccoulson, dpm: I got lucid working now, but natty is broken still; this ^ is how far I got breaking it down
[13:03] <pitti> chrisccoulson, dpm: I'll build new lucid langpacks now
[13:03] <pitti> chrisccoulson: would you mind pulling lp:~pitti/po2xpi/fix-update-data into lp:~mozillateam/po2xpi/trunk ?
[13:03] <pitti> chrisccoulson: I updated the data directory and fixed two bugs in rosetta_xpi_to_sources
[13:06] <dpm> pitti, chrisccoulson, in case it helps there was a branch from Arne which seem to fix some other issues, and might be worth looking at to merge:
[13:07] <dpm> https://code.launchpad.net/~arnegoetje/old-lp-translations/po2xpi-arne
[13:07] <dpm> Especially rev. 59
[13:12] <pitti> dpm: ah, we might need those indeed
[13:32] <seb128> vuntz, hey
[13:32] <seb128> vuntz, do you think http://people.gnome.org/~vuntz/tmp/versions/versions-stable could point to gtk 2.24?
[13:33] <seb128> vuntz, or do you keep it on purpose to 2.22?
[13:36] <vuntz> seb128: it's generated from the GNOME 2.32 modulesets, and the GNOME 2.32 modulesets track gtk 2.22
[13:36] <vuntz> seb128: so it's kind of on purpose
[13:37] <seb128> vuntz, ok
[13:37] <seb128> vuntz, thanks
[13:37] <seb128> let's set a local overwrite for that one ;-)
[13:37] <vuntz> I don't like it much, but I prefer to avoid adding some bad hacks on top of that to handle this special case
[13:37] <seb128> well, let's add nice hacks rather :p
[13:37] <seb128> but yeah, fair enough, I can overwrite that in our version tracker
[14:14]  * bcurtiswx waves to room
[14:15]  * kenvandine waves to bcurtiswx
[14:15] <bcurtiswx> im finally looking forward to some warm weather coming to us in the mid-atlantic region
[14:16] <bcurtiswx> 50's by weeks end
[14:16] <kenvandine> we had 50s yesterday, but expecting light snow again on thursday
[14:16] <bcurtiswx> :(
[14:16] <kenvandine> i am enjoying as much cool weather as possible
[14:17] <kenvandine> before the long, really hot summer
[14:17] <bcurtiswx> good point, summer isn't fun around here
[14:18] <bcurtiswx> i guess growing up in western NY, i still like it warmer than cold ;)
[15:15] <seb128> didrocks, is there any news of the compiz upload?
[15:16] <didrocks> seb128: isn't it done?
[15:16] <seb128> didrocks, no...
[15:16] <didrocks> I dput IIRC
[15:16] <didrocks> let me check
[15:16] <seb128> well it didn't work
[15:16] <seb128> thanks
[15:17] <didrocks> argh, I bzr bd -S failed (gpg key signature, couldn't connect to the daemon) so && dput ubuntu didn't worked :/
[15:17] <didrocks> fixed now
[15:17] <seb128> didrocks, thanks
[15:17] <didrocks> thanks seb128, I was really thinking it was uploaded
[15:17] <seb128> didrocks, yw ;-)
[15:17] <didrocks> (you can see I pushed the branch right after we discussed)
[15:17] <didrocks> btw, the stacking seems way stronger here
[15:18] <didrocks> and I didn't get invisible window
[15:18] <didrocks> (yet)
[15:18] <seb128> yeah, I figured you probably didn't notice the upload failed that's why I pinged you
[15:18] <seb128> great
[15:32] <rodrigo_> kenvandine, around?
[15:38] <kenvandine> rodrigo_, yeah, in a meeting
[15:38] <kenvandine> rodrigo_, give me 5m
[15:38] <rodrigo_> kenvandine, ok, no hurry :)
[15:40] <seb128> rodrigo_, how is your todos list at the moment? ;-)
[15:40] <rodrigo_> seb128, unity, the gconfpeditor thing and the g-s-d bug
[15:40] <seb128> rodrigo_, I will add a vino issue to your assigned bugs, would be nice to fix for natty but no hurry
[15:40] <rodrigo_> seb128, ok
[15:41] <seb128> rodrigo_, don't forget about g-s-d, gdm also
[15:41] <rodrigo_> right, the gdm/gsd race
[15:41] <seb128> rodrigo_, vino, there is some cases where it starts eating 100% cpu
[15:41] <rodrigo_> did you assign that bug to me?
[15:41] <seb128> rodrigo_, yes
[15:41] <rodrigo_> the gdm race one?
[15:41] <seb128> yes
[15:41] <rodrigo_> hmm
[15:41] <seb128> rodrigo_, https://bugs.launchpad.net/~rodrigo-moya/+assignedbugs
[15:42] <seb128> "the session settings manager can try starting before the login screen one exits"
[15:45] <kenvandine> hey rodrigo_, what's up?
[15:45] <rodrigo_> kenvandine, in a call, give me 5 mins more :-)
[15:46] <bcurtiswx> between calls and meetings, who has time for packaging :P j/k
[15:47] <kenvandine> hehe
[15:50] <seb128> kenvandine, btw seems there is a geoclue crasher in the indicator
[15:52] <kenvandine> seb128, that is what i am talking about in #ayatana
[15:52] <seb128> kenvandine, right, gotcha, I just read the backlog
[15:55] <fta> chrisccoulson, wrt to your xpi translations, my stuff gives me full control over the upstream vs lp choices, but imho, lp's last update made it unusable for such use case
[15:55] <chrisccoulson> fta - oh, that's not good to hear :(
[15:56] <fta> chrisccoulson, i'm not really sure where they are going with this. maybe bug 710591 will solve it, not sure
[15:56] <ubot2> Launchpad bug 710591 in launchpad "Ubuntu upstream translation imports overwrite Ubuntu translations" [Critical,In progress] https://launchpad.net/bugs/710591
[16:05] <fta> chrisccoulson, btw, don't let this stop you from trying ;)
[16:30] <seb128> hey
[16:30] <seb128> it's meeting time
[16:30] <rodrigo_> o/
[16:30]  * kenvandine waves
[16:30] <seb128> https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-02-08
[16:31] <tremolux> heyer
[16:31] <Sweetshark> /o/ \o\ \o/
[16:31] <seb128> hey kenvandine, rodrigo_, pitti, didrocks, chrisccoulson, Sweetshark, tremolux, Riddell
[16:31]  * pitti waves hello
[16:31] <seb128> pitti, hey, you are still around, do you want to lead or should I do it?
[16:31] <didrocks> hey
[16:32] <pitti> seb128: please do, if you wouldn't mind? still a bit dizzy today
[16:32] <seb128> ok
[16:32] <seb128> how is everybody today?
[16:32] <kenvandine> pitti, hope you feel better soon!
[16:32]  * kenvandine is great!
[16:32] <chrisccoulson> hi!
[16:32] <seb128> so jasoncwarner is catching on sleep and pitti feeling unwell, I will lead this one
[16:33] <seb128> let's get started
[16:33] <seb128> https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-02-08
[16:33] <seb128> no action from the previous meeting it seems
[16:33] <seb128> did anybody had any action which is not noted there?
[16:33] <seb128> ok, let's say that's a "no"
[16:34] <rodrigo_> :)
[16:34] <mterry> hi
[16:34] <seb128> kenvandine, hey, partner updater?
[16:34] <kenvandine> yup
[16:34] <seb128> hey mterry, I knew I forgot to list people! sorry
[16:34] <kenvandine> DX:
[16:34] <kenvandine> everyone note indicator-datetime with geoclue support has been uploaded
[16:34] <kenvandine> so watch for bugs
[16:35] <kenvandine> only known crasher bug was just fixed a few minutes ago
[16:35] <seb128> out of the known crasher one you mean? ;-)
[16:35] <seb128> great!
[16:35] <kenvandine> bug 714763
[16:35] <ubot2> Launchpad bug 714763 in indicator-datetime "indicator-datetime-service crashed with SIGSEGV in geoclue_master_client_set_requirements_async()" [Medium,In progress] https://launchpad.net/bugs/714763
[16:35] <kenvandine> eds integration with indicator-datetime is coming this week
[16:35] <kenvandine> so expect more bugs :)
[16:35] <kenvandine> but goodness!
[16:36] <kenvandine> tedg is trying to focus on feature work for dbusmenu and libappindicator this week
[16:36] <kenvandine> details are on the wiki
[16:36] <kenvandine> UbuntuOne:
[16:36] <kenvandine> shotwell integration has been picked up by dobey, there was a delay due to injury
[16:37] <rodrigo_> injury?
[16:37] <kenvandine> rodrigo_, i don't recall his name, but he broke his arm
[16:37] <kenvandine> manuel?
[16:37] <kenvandine> anyway... that is back in progress
[16:37] <seb128> kenvandine, what integration is that?
[16:37] <rodrigo_> oh, I'll ask the u1 guys
[16:37] <seb128> kenvandine, uploading to a website work?
[16:38] <seb128> kenvandine, i.e what's coming in shotwell 0.9?
[16:38] <kenvandine> making sure photos sync
[16:38] <kenvandine> this is just for U1
[16:38] <kenvandine> i think some metadata as well
[16:38] <kenvandine> they say it is minimal integration for now
[16:38] <seb128> ok
[16:38] <kenvandine> so should land in time for ffe
[16:39] <kenvandine> also support for the libunity api ubuntuone-client needed has landed in the launcher (trunk)
[16:39] <kenvandine> so they have something they can test against, for displaying status and such in the launcher
[16:39] <kenvandine> so progress there
[16:39] <kenvandine> that is all i have for U1
[16:39] <kenvandine> any questions for either?
[16:40] <seb128> not from me
[16:40] <seb128> ok, thanks kenvandine
[16:40] <seb128> didrocks, hey
[16:40] <seb128> didrocks, unity update?
[16:40] <didrocks> hey o/
[16:40] <didrocks> No unity release this week due to alpha2 out.
[16:40] <didrocks> Next release is due to Thursday. We will have a lot of bug fixes as usual, but more important, the places will have some nice enhancements from latest release!
[16:40] <didrocks> libunity will have a new release for application quicklists to land, the ui part is already merged. So progress bar, count and such is coming soon.
[16:40] <didrocks> New compiz ahead, depending on when upstream will merge the glib branch to trunk
[16:40] <didrocks> we got an insane 100% CPU issue with the appmenu in unity-panel-service, but the fix is under way it seems
[16:40] <didrocks> The invisible window bug should be fixed by forcing the restacking at compiz task. Update and report if it's not the case for you as this issue is pretty random to get!
[16:41] <didrocks> any questions?
[16:42] <mterry> didrocks, so invisible window will be fixed on thursday?
[16:42] <didrocks> mterry: no, the compiz upload was today
[16:42] <mterry> didrocks,  and if it's not for us, complain loudly?
[16:42] <mterry> didrocks, ok
[16:42] <didrocks> mterry: so, you can complain starting now ;)
[16:42] <seb128> well it might not be published yet
[16:42] <mterry> seb128, don't rain on my complaining parade
[16:43] <kenvandine> hehe
[16:43] <seb128> ;-)
[16:43] <didrocks> i386 is
[16:43] <seb128> great
[16:43] <didrocks> not the others :)
[16:43] <seb128> let me try as well
[16:43] <seb128> no reason mterry should be the only one to complain there!
[16:43] <seb128> ;-)
[16:43] <didrocks>  /quit
[16:43] <didrocks> :-)
[16:44] <didrocks> (is everybody restarting unity now?)
[16:44] <chrisccoulson> lol
[16:44] <rodrigo_> :)
[16:44] <seb128> not yet ;-)
[16:45] <seb128> but most of the people there are on amd64 I think
[16:45] <chrisccoulson> yeah, i am
[16:45] <seb128> ok
[16:45] <seb128> questions for didrocks?
[16:45] <seb128> thanks didrocks
[16:46] <seb128> tremolux, hey
[16:46] <seb128> tremolux, s-c update?
[16:46] <tremolux> hey seb128  \o
[16:46]  * Sweetshark feels a bit left out on the compiz/unity crashes as he is still on nouveau drivers ...
[16:46] <tremolux> yep, it's on the wiki, but in summary:  we are tweaking/improving ratings and reviews
[16:46] <tremolux> lots of new reviews appearing, it's cool  :)
[16:47] <seb128> nice
[16:47] <tremolux> and now on to other new features
[16:47] <pitti> seb128: heh -- stability by using nouveau, who'd have thought that :)
[16:47] <seb128> great work on that
[16:47] <tremolux> (smaller ones)  ;)
[16:47] <seb128> pitti, you want to talk to Sweetshark ;-)
[16:47] <pitti> erk, yes
[16:48] <seb128> tremolux, looking forward seeing the launcher integration
[16:48] <seb128> tremolux, will that use libunity as well?
[16:48] <tremolux> seb128: on the client side we are firing a dbus message
[16:49] <seb128> ok, anyway great work
[16:49] <seb128> questions for tremolux?
[16:50] <seb128> seems not
[16:50] <seb128> thanks tremolux
[16:50] <tremolux> ok, thanks  :)
[16:50] <seb128> Riddell, hey
[16:50] <seb128> Riddell, kubuntu update?
[16:50] <Riddell> hi
[16:50] <Riddell>  * Alpha 2 is out, plenty of bugs but nothing worrying for this stage in the cycle
[16:50] <Riddell>  * libindicate-qt updated for new API
[16:50] <Riddell>  * Qt now being built with gcc 4.4 to fix issues on ARM
[16:50] <Riddell>  * various space saving changes mean we have some space on the CDs for language packs now (except PowerPC)
[16:51] <seb128> thanks for fixing the libindicate-qt binary naming while you were at it btw ;-)
[16:51] <seb128> seems kubuntu is on track as usual
[16:51] <seb128> questions for Riddell?
[16:52] <seb128> ok, seems not
[16:52] <seb128> thanks Riddell
[16:52] <seb128> ok, natty status
[16:52] <seb128> http://people.canonical.com/~pitti/workitems/natty/canonical-dx-team-natty-alpha-3.html
[16:52] <seb128> http://people.canonical.com/~platform/workitems/natty/canonical-desktop-team.html
[16:52] <seb128> seems we a almost flat work items count
[16:52] <seb128> it should go down rather ;-)
[16:53] <seb128> so please close WIs as you get work done
[16:53] <seb128> we are just on the trend line for natty now
[16:53] <seb128> but the almost flat for a month doesn't shape nicely
[16:53] <seb128> the a3 curve is over the trend as well
[16:53] <kenvandine> nope :/
[16:54] <chrisccoulson> my main task was never tracked as a work item :(
[16:54] <seb128> seems most of it is dx and oneconf then
[16:54] <chrisccoulson> which is why mine is flat, but i think most of mine got moved to beta by pitti anyway ;)
[16:54] <pitti> the trend line also is a bit misleading -- most of the stuff needs to be done by FF, not by release
[16:54] <pitti> so if we need to drop stuff, let's do that earlier
[16:54] <didrocks> (speaking on oneconf… it seems that desktopcouch is broken for some people once again :/)
[16:55] <chrisccoulson> didrocks, fixed already
[16:55] <chrisccoulson> ;)
[16:55] <didrocks> chrisccoulson: uploaded?
[16:55] <chrisccoulson> didrocks - yeah, sometime this morning
[16:55] <didrocks> mvo: ^^
[16:55] <chrisccoulson> it should be working again now
[16:55] <seb128> does it break every time there is a xulrunner upload?
[16:55] <chrisccoulson> seb128 - yeah, it's broken with every single upload so far this cycle
[16:55]  * didrocks really thinks to move oneconf away of desktopcouch
[16:55] <seb128> urg
[16:56] <seb128> can we do something to avoid that?
[16:56] <chrisccoulson> seb128 - but, these are still beta uploads. hopefully it will get better
[16:56] <seb128> would g-s break the same way? ;-)
[16:56] <chrisccoulson> seb128 - yeah ;)
[16:56] <mvo> didrocks: aha, thanks, let me update then
[16:56] <seb128> ok
[16:56] <chrisccoulson> i think i'm going to package spidermonkey as a totally separate package
[16:56] <chrisccoulson> and decouple it from these uploads entirely
[16:57] <chrisccoulson> every week for the past month i've had to spend time unbreaking couchdb ;)
[16:57] <seb128> well, looking at the natty items it seems ok
[16:57] <seb128> there is oneconf and telepathy-approver have a bunch
[16:57] <seb128> there is the xulrunner-2.0 port items
[16:58] <chrisccoulson> i'm really quite concerned about those now, i have had hardly any time to work on them
[16:58] <seb128> otherwise it seems mostly other teams (dx) or things which are on track
[16:58] <seb128> chrisccoulson, will micahg have time when he starts?
[16:58] <chrisccoulson> seb128 - not sure, but probably not ;)
[16:58] <seb128> those are assigned to him right now
[16:58] <seb128> hum k
[16:58] <seb128> well I will let you sort that
[16:58] <seb128> enough for the status update
[16:58] <chrisccoulson> the issue is that most of these applications are in universe, and are stuff that nobody really cares about ;)
[16:58] <seb128> is there any comments?
[16:59] <chrisccoulson> (well, i don't particularly care about them)
[16:59] <chrisccoulson> that's what i meant to say ;)
[16:59] <seb128> chrisccoulson, well then those are not really blockers for our team
[16:59] <seb128> you should perhaps do a call for volunteer on the list to port those
[16:59] <chrisccoulson> seb128 - this is why i want to drop xulrunner from main entirely
[16:59] <pitti> chrisccoulson: is that the "port to 2.0" WIs?
[16:59] <chrisccoulson> pitti - yeah
[16:59] <pitti> I'd really be aggressive with removing stuff instead
[17:00] <chrisccoulson> that's what i'm thinkin
[17:00] <chrisccoulson> g
[17:00] <didrocks> chrisccoulson: wait, couchdb needs xulrunner and is still in main?
[17:00] <chrisccoulson> didrocks - i'm probably going to package libmozjs separately, and we'll have that in main for couchdb
[17:00] <didrocks> chrisccoulson: ok :)
[17:00] <seb128> well maybe do an email for the list saying you will drop everything not ported and call for help porting things users care about
[17:01] <chrisccoulson> but, based on this, we're going to have a hard time keeping up: https://wiki.mozilla.org/Firefox/Roadmap
[17:01] <chrisccoulson> not sure if anyone else saw that yet ;)
[17:01] <seb128> heh
[17:01] <seb128> going to be fun for you ;-)
[17:01] <seb128> ok
[17:01] <chrisccoulson> oh yes
[17:01] <seb128> so one question from me
[17:02] <bryceh> I like the 'tl;dr' at the beginning ;-)
[17:02] <seb128> what should we do with vala?
[17:02] <chrisccoulson> the firefox part is not so bad tbh, it's the rest of the stuff that's a pain ;)
[17:02] <pitti> what does tl;dr mean?
[17:02] <mterry> seb128, what about it?
[17:02] <seb128> we still have quite some applications using vala-0.10
[17:02] <micahg> I'm hoping to have some time for porting, but it probably won't be part of my work day
[17:02] <mterry> pitti, too long, didn't read
[17:02] <mterry> pitti, it's a summary
[17:02] <pitti> ah, nice :)
[17:02] <seb128> we vala-0.11 packaged as a vala update
[17:02] <seb128> not a new source
[17:02] <chrisccoulson> micahg - don't worry about it too much, you'll have more than enough to do ;)
[17:02] <seb128> so I'm wondering if we should bring vala-0.10 back
[17:02] <seb128> debian packaged both a different source
[17:03] <seb128> of if we should try porting the rdepends
[17:03] <seb128> vala-0.10 is on the nbs list for a while
[17:03] <seb128> but there is still shotwell and some others using it
[17:03] <seb128> http://people.canonical.com/~ubuntu-archive/NBS/valac-0.10
[17:04] <seb128> does anybody has an opinion?
[17:04] <seb128> kenvandine, mterry: ^
[17:04] <pitti> is it that hard to port? i. e. does 0.11 really change the language that much?
[17:04] <seb128> you are probably the ones who used vala most there
[17:04] <kenvandine> hum
[17:04] <seb128> pitti, that's part of the question, I didn't use vala enough to say
[17:04] <seb128> I know kenvandine and mterry did some fixing for 0.11
[17:04] <mterry> pitti, it does change the language, but not difficult...
[17:05] <mterry> how many rdepends we talking?  /me checks
[17:05] <Amaranth> It's not a large charge
[17:05] <kenvandine> i didn't need to fix much, mostly gir generation stuff
[17:05] <Amaranth> err, change
[17:05] <kenvandine> probably not something shotwell would be concerned with
[17:05] <seb128> mterry, see the url I coied
[17:05] <seb128> copied
[17:05] <kenvandine> we should talk to them
[17:05] <mterry> seb128, ah, :)
[17:05] <seb128> well it's rather shotwell
[17:05] <slomo> why do you want to have 0.11 as an update instead of new source package anyway?
[17:06] <seb128> slomo, because the guy who did the update didn't think about it by then
[17:06] <mterry> slomo, it wasn't necessarily intentional at the time
[17:06] <seb128> slomo, well it didn't rename the source, he just versioned the binaries for the new version
[17:06] <mterry> so what would be bad about having new source?
[17:06] <seb128> slomo, which sent the 0.10 to nbs
[17:07] <seb128> mterry, out of bring back old cruft?
[17:07] <pitti> I think we should revert -0.10 to the actual -0.10 (including binaries)
[17:07] <slomo> i see, well, can't this be reverted somehow? :)
[17:07] <pitti> and package 0.11, and then do the transition properly
[17:07] <slomo> like uploading vala 1:0.10.3-1 ;)
[17:07] <seb128> slomo, that's what I'm asked there
[17:07] <seb128> I'm asking
[17:07] <mterry> seems best all around, if it wouldn't cause hang-ups.  I note that the new source is vala-0.12, so we'd have to throw out our vala source changes...
[17:07] <seb128> is there any point doing that since we ported most of what we use to 0.11 by now
[17:08] <mterry> seb128, long term delta from debian is one
[17:08] <seb128> mterry, well no, I would sync vala-0.12 from debian
[17:08] <slomo> seb128: well, difference to debian ;)
[17:08] <seb128> the question is whether we want to sync 0.10 as well
[17:08] <seb128> or just drop it
[17:08] <mterry> seb128, I see, and drop 'vala'
[17:08] <slomo> oh, then just drop it
[17:08] <seb128> right
[17:09] <seb128> ok sorry that was not clear
[17:09] <seb128> we will bring 0.12 from debian
[17:09] <seb128> the question was whether we port the few 0.10 users
[17:09] <mterry> seb128, well, I am a good person to port things to 0.12...  out of that list, would I have to get all of them, or just main ones if I did that?
[17:09] <seb128> or if we bring that one back from debian as well
[17:09] <seb128> mterry, well, main is "shotwell" it seems
[17:10] <mterry> seb128, yeah, one is an easy enough task...  :)
[17:10] <seb128> mterry, I will drop an email to the yorba guys and Cc robert_ancell and you on it to see if there is any reason it's still on 0.10
[17:10] <mterry> seb128, k
[17:10] <seb128> mterry, then you can sort with robert_ancell who want to port it ;-)
[17:10] <seb128> ok
[17:10] <seb128> thanks mterry, kenvandine, slomo
[17:11] <kenvandine> np
[17:11] <seb128> that's all from me I think
[17:11] <seb128> anything else?
[17:11] <kenvandine> not from me
[17:12] <pitti> thanks seb128
[17:12] <tremolux> thanks everybody
[17:12] <seb128> ok, that's a wrap then
[17:12] <seb128> thanks everybody
[17:12] <Sweetshark> can we add "FOSDEM was awesome" to the summary? ;)
[17:12] <seb128> Sweetshark, sure ;-)
[17:12] <Amaranth> didrocks: any idea what is going on with bug 703988?
[17:12] <ubot2> Launchpad bug 703988 in appmenu-gtk "(various) crashed with SIGSEGV in g_atomic_int_exchange_and_add()/g_variant_unref/?libappmenu.so/g_simple_async_result_complete" [Undecided,Fix committed] https://launchpad.net/bugs/703988
[17:13] <seb128> Amaranth, it has been fixed yesterday
[17:13] <Amaranth> I thought my RAM was dying yesterday thanks to that :)
[17:13] <Amaranth> seb128: Well the bug says it was fixed in a version of appmenu-gtk I already seem to have
[17:13] <seb128> https://launchpad.net/ubuntu/+source/indicator-appmenu/0.1.93-0ubuntu2
[17:13] <seb128> ^
[17:13] <didrocks> Amaranth: what seb128 said
[17:14] <seb128> I think it's the same issue
[17:14] <seb128> well at least I didn't get the bug again today so it seems to work
[17:15] <Amaranth> hrm, was it fixed twice?
[17:15] <seb128> mterry, well done on fixing the swt issues btw
[17:15] <mterry> seb128, yeah, eclipse is doing something insane though.  I'm taking a sabbatical from that bug  ;)
[17:15] <kenvandine> seb128, geoclue-providers is in source NEW, think you can review it for me again?
[17:15] <seb128> the indicator-appmenu fix seems to solve what was leading to the crash
[17:15] <seb128> Riddell, ^
[17:16] <seb128> kenvandine, it's Riddell's archive day ;-)
[17:16] <kenvandine> ok :)
[17:16] <seb128> mterry, do you have other bugs on your list or do you want a new one?
[17:16] <mterry> seb128, I've got stuff right now, but will ask if you've got known pending bugs
[17:17] <mterry> seb128, actually, give me stuff
[17:17] <seb128> mterry, I always have known pending bugs :p
[17:17] <seb128> mterry, well, playing with baobab there crashes unity-panel-service
[17:17] <mterry> seb128, ooh, let me see
[17:18]  * mterry is determined that the panel will be stable for 11.04
[17:18] <seb128> mterry, I'm not sure how exactly, like I run it, play a bit with the view items to show the bars and close it and it crashed twice today this way
[17:18] <mterry> seb128, huh, OK
[17:18] <mterry> seb128, no open bugs that you know of?  I'll play with it
[17:19] <seb128> mterry, ok, so it seems to be, start baobab, use the menu to open the preferences dialog
[17:19] <seb128> close the dialog
[17:19] <seb128> close baobab
[17:20] <seb128> mterry, I think it's https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/714439
[17:20] <ubot2> seb128: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/714439)
[17:20] <seb128> well the stacktrace in this one is useless
[17:22] <seb128> mterry, let me know if you get it this way
[17:22] <seb128> if not I can get a bug with debug infos
[17:23] <mterry> seb128, k, one sec
[17:25] <pitti> dpm: finally! uploading fresh lucid-proposed langpacks; I tested the German one and it works just fine
[17:25] <pitti> had to wrestle with the gpg key a bit stilll, it expired two days ago
[17:25] <pitti> seems it really doesn't want me to do that, or so
[17:26] <mterry> seb128, I'm not getting a crash, but I'm seeing output from appmenu that could indicate code that would crash.  Please file a bug just to be sure that my hunch is actually what you're sseeing
[17:30] <seb128> mterry, http://paste.ubuntu.com/564574/
[17:30] <seb128> mterry, bah, it lacks debug symbols for libdbusmenu
[17:31] <seb128> mterry, let me get a new one
[17:32] <kenvandine> rodrigo_, still need me for anything?
[17:32] <rodrigo_> kenvandine, no, in the call I was I solved it
[17:32] <kenvandine> :)
[17:32] <rodrigo_> kenvandine, it was about this -> https://bugs.launchpad.net/indicator-application/+bug/715291
[17:32] <ubot2> Launchpad bug 715291 in indicator-application "Need more information about IndicatorObject's for a11y" [Undecided,New]
[17:32] <kenvandine> ah
[17:33] <rodrigo_> kenvandine, thanks anyway for your help :)
[17:33] <kenvandine> that was easy :)
[17:33] <rodrigo_> :D
[17:37] <dpm> pitti, ah, great. So it looks a bit tight to me, assuming all langpacks will be in -proposed by tomorrow, if they need to be tested and uploaded by Thursday. Do you think we should still aim for 10.04.2, or do the update immediately after?
[17:38] <rodrigo_> seb128, hmm, did you assign the vino bug to me? I can't see it my list
[17:38] <seb128> rodrigo_, not yet
[17:38] <rodrigo_> seb128, ah, ok
[17:39] <pitti> dpm: I'd still see what we can get tested
[17:39] <seb128> rodrigo_, but basically try to enable vino and disable it a few time and it will start eating cpu
[17:39] <rodrigo_> ok
[17:39] <pitti> dpm: I can help with the German/English ones, too
[17:39] <pitti> dpm: I'm shepherding stuff through the queues now, and bumping build score for the languages which we have on the CDs (bn,de,en,es,pt,xh)
[17:40] <pitti> dpm: so they'll be available for testing in ~ 2 hours
[17:40] <dpm> pitti, ah, awesome. So do you think we could do something like uploading the ones that got feedback for by Thursday, and then give another deadline for next week for the people who didn't have time for the first deadline?
[17:41] <pitti> dpm: sorry that it took so long; it just hated me :/
[17:41] <pitti> dpm: absolutely; the others can stay in -proposed for some weeks, and we move them to -updates in some smaller batches
[17:41] <pitti> according to test results
[17:42] <dpm> pitti, what? You're apologizing for having done awesome work in sorting this out?
[17:42]  * dpm hugs pitti!
[17:42]  * pitti hugs back dpm
[17:43] <seb128> mterry, ok, so I get it every second time I do this "run boabab, use the menu to open the preference dialog, close the dialog (esc on keyboard, click, as you want), use the menu to exit
[17:43] <mterry> seb128, k...
[17:43] <dpm> pitti, ok, let's do that then, let me send an announcement to translators
[17:43] <pitti> dpm: thanks
[17:43] <rodrigo_> ok, out for a bit, later all
[17:43] <pitti> dpm: btw, do we have a wiki page with testing steps now?
[17:43] <pitti> dpm: such as "check menus, check evolution, check update-manager"?
[17:44] <pitti> and "check firefox" of course?
[17:44] <dpm> pitti, yeah, I just need to update it with the langpack version numbers, let me give you the link
[17:44] <pitti> dpm: ok, all -base packages on the CD accepted and build score bumped, ETA on archive.u.c. 90 mins
[17:45] <pitti> dpm: still need to shepherd the corresponding -updates packages, ETA 150 mins
[17:45] <dpm> pitti, ack. Here's the page, btw: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA - I'll update it now
[17:45] <pitti> cool, thanks
[17:46] <dpm> what's the langpack version number?
[17:46] <pitti> dpm: that's what I had in mind indeed; small, but sufficient to provide a safety net
[17:46] <pitti> dpm: 1:10.04+20110204
[17:46] <dpm> ok
[17:46] <dpm> thanks
[17:48] <seb128> mterry, http://paste.ubuntu.com/564585/
[17:49] <seb128> bah that one lacks appmenu symbols!
[17:49] <mterry> seb128, hah
[17:49] <mterry> seb128, whatever, this is enough for now
[17:49] <seb128> mterry, ok great, thanks
[17:49] <seb128> weird that you don't get it though ;-)
[17:49] <seb128> I can get it every second try there
[17:50] <mterry> seb128, I have a custom compiled appmenu from my typing, maybe that's why
[17:50] <seb128> mterry, let me know if you need extra details or me to try a fix for it
[17:50] <mterry> s/typing/testing/
[17:51] <seb128> mterry, you can use bug #694699 for it
[17:51] <ubot2> Launchpad bug 694699 in unity "unity-panel-service crashed with SIGSEGV in g_type_check_instance_is_a()" [High,Triaged] https://launchpad.net/bugs/694699
[17:51] <seb128> mterry, hum, in fact maybe not the same one
[17:52] <didrocks> is it just me having issue with pushing branches to launchpad?
[17:52] <didrocks> for an hour, it's stucking a lot…
[17:53] <pitti> I pushed a 40 MB branch earlier on, worked ook
[17:53] <seb128> didrocks, I've been pushing small commits but it worked
[17:53] <seb128> mterry, ok
[17:53] <didrocks> hum… weird
[17:53] <seb128> #685151
[17:53] <pitti> didrocks: dpm had problems, too, though
[17:53] <didrocks> my Internet connexion work well though…
[17:53] <didrocks> ah?
[17:53]  * pitti -> supermarket and dinner, bbl
[17:54] <pitti> or rather, "see you tomorrow"
[17:54] <didrocks> see you tomorrow pitti
[17:55] <dpm> didrocks, yeah, I was pushing a ~9Mb branch and it didn't take it
[17:55] <didrocks> dpm: hum, my branch are really small and either sotfware-center nor oneconf are easy to push…
[17:56] <dpm> didrocks, I'd mention it to someone from the maintenance squads in #launchpad. I think sinzui is leading one of them right now
[17:56] <didrocks> dpm: ok
[17:56] <jcastro> chrisccoulson: I don't see the appmenu working when I fire up tbird
[17:57] <chrisccoulson> jcastro, which version of tbird have you got?
[17:57] <didrocks> dpm: thanks, let's have a try
[17:57] <jcastro> chrisccoulson:  3.1.8+build1+nobinonly-0ubuntu6
[17:58] <seb128> rodrigo_, you can read bug #31037 about the vino issue btw
[17:58] <ubot2> Launchpad bug 31037 in vino "Vino-server takes 90% of cpu when only listening for incoming connections" [High,Fix released] https://launchpad.net/bugs/31037
[17:58] <chrisccoulson> jcastro, ah. you need https://launchpad.net/ubuntu/+source/thunderbird/3.1.8+build2+nobinonly-0ubuntu2 for it to work ;)
[17:58] <chrisccoulson> the upgrade didn't work properly
[17:58] <chrisccoulson> dbarth had the same issue too
[17:58] <seb128> rodrigo_, that one is closed but it keeps getting comment and I got the issue as well while starting and stopping vino to test the appindicator icon
[17:58] <jcastro> chrisccoulson: ah ok, so I can just wait for it to be published, no worries
[17:58] <chrisccoulson> jcastro, it should already be published i think
[17:58] <chrisccoulson> might be worth trying an apt-get update to refresh your package list
[17:58] <dbarth> chrisccoulson: but now i'm an happy user of the new thunderbird extension ;)
[17:59] <chrisccoulson> :)
[17:59] <jcastro> chrisccoulson: I think my mirror is behind, I'll sort it, thanks!
[18:03] <charlie-tca> jcastro: thank you for the shortcut page
[18:04] <jcastro> charlie-tca: no problem!
[18:05] <jcastro> chrisccoulson: man, this looks /nice/
[18:05] <jcastro> well done!
[18:05] <chrisccoulson> jcastro, excellent :)
[18:12] <jcastro> chrisccoulson: is it just me or does it "feel" like the toolbar (get mail, etc) should be shifted over to be lined up with the menu?
[18:13] <chrisccoulson> jcastro, do you have the standard layout?
[18:13] <jcastro> yeah
[18:13] <jcastro> I have whatever the default is
[18:13] <chrisccoulson> if it was lined up with the menu, you'd end up with an empty space on the left of the toolbar though wouldn't you?
[18:14] <jcastro> yeah
[18:14] <chrisccoulson> (and it's difficult to line it up too, as thunderbird doesn't know where the menu is)
[18:14] <seb128> tkamppeter, pitti: https://code.launchpad.net/~pascal-devuyst/ubuntu/natty/system-config-printer/bug204732/+merge/48724 needs review
[18:14] <jcastro> that would be weird too, I'm just saying, it also feels weird now
[18:15] <chrisccoulson> jcastro, i think it's because the window controls are shifted over. i get the same feeling in other windows too ;)
[18:15] <jcastro> yeah
[18:16] <tkamppeter> seb128, will look into it.
[18:16] <seb128> tkamppeter, thanks
[18:16] <didrocks> have a good evening everyone
[18:33] <mterry> tedg, why was the recent commit in indicator-appmenu necessary?  You call menus_destroyed, but the unref from being pulled out of the table should have called that itself.  Now I'm seeing behavior where menus_destroyed is being called twice (once directly, once on unref)
[19:02] <janimo_> dobey, hello. I saw your email on the shotwell list. I think the plugin archiotecture is not yet ready, but worked on for 0.9
[19:02] <janimo_> dobey, is the U1 server side done?
[19:04] <dobey> janimo_: i'm not working on anything on the server side, so i'm not sure what specifically you're asking about. but #ubuntuone might be a better place to have the conversation
[19:05] <seb128> janimo_, it was planned to land in trunk last week, did you check if that happened?
[19:05] <janimo_> dobey, I was assuming if you want to write the plugin you need to know the server-side REST (or whatevr) API that is provided
[19:05] <dobey> seb128: there is some basic plug-in support in shotwell trunk, but nothing that is usable to do anything
[19:05] <janimo_> seb128, I did not check anything related to shotwell lately
[19:06] <dobey> janimo_: no, we have ubuntuone-syncdaemon to deal with files stuff, generally.
[19:06] <desrt> kamstrup: hihi
[19:07] <janimo_> dobey, hmm, then there is no explicit need for support from shotwell I guess?
[19:07] <janimo_> the current shotwell exporters explciitly export to a REST API provided by various services
[19:07] <kamstrup> desrt: hi sorry for being late... xchat/connman kept me in limbo for a few minutes me thinking that I was online :-S
[19:07] <kamstrup> bad combo :-)
[19:07] <dobey> janimo_: well we want a plug-in to integrate stuff better, and provide some folders as extra libraries
[19:08] <dobey> janimo_: right, because they are simply exporting; and they don't have pre-existing integration in ubuntu
[19:08] <janimo_> dobey, ok. It means I did not fully understand the scope of the uplaod to U1 spec
[19:09] <janimo_> dobey, did not follow their plugin development, and was under the impression that initially they pluginize only the current export functionality
[19:09] <janimo_> but I may be wrong.
[19:11] <dobey> well like i said in the mail, it is unclear what is actually going on, because they use an odd homebrew build system, and the code isn't well organized. and there's no documented external API for the plug-ins to use
[19:11] <dobey> i think they are just built into the shotwell binary
[19:11] <kenvandine> that wouldn't be very plugin-like :/
[19:12] <janimo_> dobey, I could work with the code after a few days looking, and I think lately the code got better organized. It used to be a single src/ dir
[19:13] <janimo_> as for the MAkefile, they specifically avoid autotools. I can't blame them and that file seems fit for their monolithic build. Not sure how much of a challange it will be for plugins
[19:13] <dobey> kenvandine: yeah, and they did homebrew plug-ins instead of using libpeas, because libpeas isn't "stable enough" i guess
[19:14] <dobey> well if they enjoy reimplementing all the useful stuff from automake/autoconf so be it, but it's rather a pain to deal with when it could be so much simpler :-/
[19:14] <dobey> granted, vala's autotools integration bits aren't the best yet, but i've been doing some stuff with that as well
[19:14] <janimo_> dobey, I am pretty sure they don't plan on implementing autoconf fucntionality, but rather take the burden of manually adding deps and expecting people to install them
[19:15] <janimo_> dobey, they are generally very pragmatic. And they deliver one of the slickest apps in the desktop, I think making unusual choices is a good tradeoff
[19:17] <dobey> well, so far i am not impressed.
[19:17] <janimo_> dobey, matter of taste I guess. I was :)
[19:18] <dobey> no, my qualms are purely technical
[19:19] <janimo_> dobey, I was only talking about the technical side too (quality is an effect of that imo)
[19:19] <janimo_> dobey, relying to omuch on 3rd party libs leaves them less control over schedules and features
[19:20] <kenvandine> but in the long run that is a big lose for everyone imo
[19:20] <dobey> the libpeas thing i could understand, maybe
[19:20] <janimo_> I sure prefer it to many gnome apps that are in a constant state of 'almost there' because of too many developer-happy choices being made
[19:20] <dobey> but it's not like shotwell is the pinnacle of stability
[19:20] <kenvandine> better to work with the developers on those libs to ensure everything works out
[19:20] <janimo_> let's jump on latest plugin lib, separate backend, integrate this and that fancy new lib which is still in alpha , etc
[19:21] <dobey> but the roll-your-own build system is a waste
[19:21] <janimo_> dobey, true, I managed to crash it quite a few times during maverick, but all bugs were fixed quicly
[19:21] <dobey> janimo_: i don't see how writing a brand new, less stable lib, is a good argument against using someone else's slightly unstable lib that does the same thing.
[19:21] <janimo_> dobey, actually it is a MAkefile last time I looked, so they did not watse much on it
[19:22] <dobey> it's just NIH syndrome
[19:22] <dobey> janimo_: it's not just a Makefile; it's very hard to comprehend and has many flaws already solved by all the other build systems that everyone else uses.
[19:22] <janimo_> dobey, don;t know libpeas or plugin system specifics, I just saw they prefer working from their feature requirements downwards, instead of picking a gnome lib and seeing how it can be bent to fit
[19:23] <seb128> mterry, I've assigned you bug #685151, that seems to match the crash we were talking about before
[19:23] <ubot2> Launchpad bug 685151 in unity "unity-panel-service crashed with SIGSEGV in g_type_check_instance()" [Medium,Triaged] https://launchpad.net/bugs/685151
[19:23] <mterry> seb128, k
[19:23] <janimo_> dobey, I don;t remember the exact reason mentioned, but deep dislike of autotools is not an unlikely reason
[19:23] <seb128> mterry, thanks ;-)
[19:23] <dobey> janimo_: autotools isn't the only build system out there.
[19:24] <dobey> but frankly, it suits the needs of shotwell pretty much perfectly
[19:24] <janimo_> dobey, everyone else in GNOME, shotwell devs have no gnome backround, so they probably think they';d waste too much time picking up all the GNOME bits before doing actual work
[19:24] <dobey> janimo_: i don't understand why you keep mentioning GNOME
[19:24] <janimo_> dobey, I think they even rejected a patch that switched them to autotools so there is something serious there
[19:24] <dobey> yes, misunderstanding is often serious
[19:25] <janimo_> dobey, well, I assume you meant they should reuse more of the GNOME processes and devel tools (autotools, libpeas, etc)
[19:25] <janimo_> as they are a Gtk/gnomish app after all
[19:25] <janimo_> certainly closer to GNOME than to any other framework and community
[19:26] <dobey> i mean, they should not be making the pretty much same mistakes that eveyrone was making in 1995, in 2011; but they seem to be.
[19:27] <janimo_> dobey, I would holeheartedly agree with that if they turned out a NIH system which was useless otherwise, but shotwell is a great product imho so this all seems to not have been made just to be on the NIH side
[19:27] <janimo_> I mean it's not the let's write a photo manager to learn programming Gtk then throw it on sf.net :)
[19:27] <dobey> no, they started a non-profit org and set up svn and trac to do it
[19:28] <janimo_> I wish most apps on the desktop would start up as fast as shotwell (even if most don;t have 30GB of data to look after)
[19:28] <janimo_> dobey, right
[19:28] <dobey> shotwell is slow
[19:28] <dobey> every time i start it, it rescans all of my $HOME
[19:28] <dobey> and i even told it not to import everything
[19:29] <janimo_> dobey, ok, so the reason we're both right is probably we have a very differnet shotwell experience. To me is the nicest app of 2010 :)
[19:29] <dobey> so basically, it just goes through all of my $HOME and stats every file, and does nothing
[19:29] <dobey> well 2010 is no more :)
[19:29] <janimo_> most complains I had were in the 0.7 cycle which I reported and got fixed or fixed myself
[19:30] <janimo_> found them to be a most welcoming and friendly (if tiny) community too
[19:30] <dobey> sure, but i don't want to end up fixing all the other bugs in the photo manager, just so i can write a plug-in for the photo manager
[19:30] <janimo_> dobey, sure
[19:30] <dobey> i'm a software engineer, not a yak farmer
[19:30] <janimo_> yak hairdresser
[19:32] <janimo_> dobey, asked on U1 just to see what the status of the REST API is. After UDS I got the impression there's going to be one for uploads, regardless of other ways that photos and files can be synced to U1
[19:32] <tedg> mterry, I think that it was switching on the default case.  So using the destroy function causes it to switch.
[19:33] <tedg> mterry, Yeah, I removed the destroy signal entirely, and that seems to make things better.
[19:33] <tedg> mterry, Let me push that branch.
[19:33] <mterry> tedg, k
[19:34] <dobey> janimo_: there is some work happening to have REST APIs for some things, yes.
[19:41] <dobey> janimo_: but there is no intention of using the REST APIs for the shotwell plug-in afaik
[19:42] <janimo_> dobey, ok, thanks
[19:43] <janimo_> makes sense if U1 experience needs to be different from the online galleries
[19:44] <dobey> eh, the flickr/facebook/etc... exprience in photo managers is classically wrong anyway.
[19:44] <janimo_> dobey, I am sure it serves quite a few people well
[19:44] <dobey> and u1 is not a gallery to publish to. it is a synchronization service
[19:47] <dobey> but none of this answers the questions i asked on the list, so that i can work on that plug-in
[19:48] <janimo_> dobey, then the first WI in the blueprint is misleading https://blueprints.launchpad.net/ubuntu/+spec/multimedia-ubuntuone-n-shotwell-integration
[19:48] <janimo_> shotwell's publish options mean , export to REST service
[19:49] <dobey> no
[19:49] <dobey> "publish options" means "UI"
[19:49] <dobey> i don't see why it matters if the backend is REST or UUCP or what
[19:50] <janimo_> dobey, that's the only publish class they have afaik - REST. The UI is quite linked to that at least in the current implementation
[19:57] <dobey> janimo_: ok, so it's not architecturally sound then i guess. :-/
[20:13] <chrisccoulson> seb128 - is this your fault? http://launchpadlibrarian.net/63816286/buildlog_ubuntu-natty-i386.thunderbird_3.1.8%2Bbuild2%2Bnobinonly-0ubuntu3_FAILEDTOBUILD.txt.gz
[20:13] <chrisccoulson> :)
[20:27] <seb128> chrisccoulson, yes \o/ ;-)
[20:27] <chrisccoulson> heh ;)
[20:27] <seb128> chrisccoulson, will teach you to not use the default email client :p
[20:28] <chrisccoulson> seb128 - is libcairo-script-interpreter2 in universe?
[20:28] <chrisccoulson> it installs fine here ;)
[20:29] <seb128> hum
[20:29] <seb128> that's a good question
[20:29] <seb128> Riddell, ^ ;-)
[20:29] <chrisccoulson> i think it is. the update added libcairo-script-interpreter2 as a dependency of libcairo2-dev
[20:29] <seb128> right
[20:29] <seb128> https://launchpad.net/ubuntu/natty/i386/libcairo-script-interpreter2/1.10.2-2ubuntu1
[20:29] <chrisccoulson> aha :)
[20:29] <chrisccoulson> i guess we need to fix that fairly quick ;)
[20:30] <seb128> right
[20:30] <seb128> I can't see ssh to the dc from that box
[20:30] <seb128> but I will promote it later on if Riddell doesn't
[20:30] <chrisccoulson> thanks
[20:30] <seb128> or some other archive admin
[20:30] <seb128> try maybe pinging jdstrand or someone who is still in work hours
[20:31] <chrisccoulson> cool, i've just pinged jdstrand too
[20:33] <seb128> thanks
[20:36] <chrisccoulson> seb128 - ok, sorted
[20:38] <seb128> chrisccoulson, thanks
[20:55] <stgraber> hello, Edubuntu just started running WebLive for Natty and we seem to get some issues with gnome-panel applets
[20:55] <stgraber> usually the error message is: http://paste.ubuntu.com/564677/
[20:56] <stgraber> you can quite easily test it on http://www.edubuntu.org/vmmanager (need the java applet and select 11.04)
[21:39] <stgraber> oh, it's worth noting that the issue above doesn't always appear, seems like a race condition is going on somewhere (thanks cyphermox ;))
[22:04] <jasoncwarner> so the wiki is giving me fits right now! throwing 500 errors...I think the western team meeting log should be in there now (fingers crosseed)
[22:06] <jasoncwarner> Ok, eastern edition team, ready for meeting? RAOF, bryceh, robert_ancell? TheMuso
[22:06] <jasoncwarner> you guys around?
[22:06] <RAOF> Yo yo!
[22:06] <jasoncwarner> morning!
[22:07] <jasoncwarner> lets get started and if people join, greate
[22:07] <jasoncwarner> great, even
[22:07]  * Sweetshark lurks
[22:07] <jasoncwarner> Ok, RAOF, looks like X.Org was updated on wiki. Do you have anything to add?
[22:07] <jasoncwarner> this is on wiki
[22:07] <jasoncwarner> X.org
[22:07] <jasoncwarner> XServer 1.10 deployment was completed and deployed in time for Alpha-2.
[22:07] <jasoncwarner> There was a brief period when xserver was temporarily uninstallable while drivers rebuilt. This confused many users who tried to upgrade during this window.
[22:07] <jasoncwarner> There was some breakage for people who still had xorg-edgers or other random X bits installed. We helped these people over the hump as we encountered them.
[22:07] <jasoncwarner> We learned some tricks we can use next time to further reduce the duration and severity of breakage people encounter.
[22:07] <jasoncwarner> -fglrx and -nvidia are currently unusable as they do not yet support XServer 1.10.
[22:07] <jasoncwarner> We anticipate getting updated drivers with this support by release, but for now recommend uninstalling them and using -ati or -nouveau instead.
[22:08] <jasoncwarner> The -intel driver seems to be getting a lot of bug reports regarding GPU lockups. This is probably due to issues in the .38-2 kernel. We're putting a priority on communicating these bugs upstream.
[22:08] <jasoncwarner> There are a handful of XServer segfault bug reports (possibly sharing same root cause?), some of which seem to be a consequence of an out-of-memory situation during installation; it's not yet known if this is caused by X or if it's elsewhere in the system and X is just the most notable thing to fail.
[22:08] <jasoncwarner> There is also a common X assert failure (bug #711422) that a number of people are hitting. We've not yet gotten a good backtrace on this, but need to do more investigation.
[22:08] <ubot2> Launchpad bug 711422 in xorg-server "Xorg assert failure: *** glibc detected *** X: double free or corruption (!prev): 0x089f5b20 - Unhandled dwarf expression opcode 0x9f" [Critical,Triaged] https://launchpad.net/bugs/711422
[22:08] <jasoncwarner> xkeyboard-config has had a major version update which we merged post-alpha-2, bringing in new support for more keyboards and better support for more languages.
[22:08] <bryceh> heya
[22:08] <RAOF> That's pretty much what I was going to put in, thanks bryceh  :)
[22:09] <jasoncwarner> Ok...well then, looks like we have some work to do ;) Thanks...
[22:09] <bryceh> just chatting with kernel team about the intel bugs.  I've forwarded some of them upstream and gotten confirmation they're kernel drm issues
[22:09] <RAOF> I'll add that I think I've got a good idea where bug 711422 is happening, but need investigation.
[22:09] <ubot2> Launchpad bug 711422 in xorg-server "Xorg assert failure: *** glibc detected *** X: double free or corruption (!prev): 0x089f5b20 - Unhandled dwarf expression opcode 0x9f" [Critical,Triaged] https://launchpad.net/bugs/711422
[22:10] <bryceh> RAOF, ah cool, was going to ask if you'd had a chance to look at that
[22:10] <bryceh> duped a *bunch* of reports of that one just a bit ago
[22:10] <jasoncwarner> well, lets gt this meeting over so you guys can get to collaborating :)
[22:10] <bryceh> heh
[22:10] <jasoncwarner> TheMuso: or Robert_Ancell, anything to add? Anything you want ot talk about?
[22:12] <jasoncwarner> ok... bryceh or RAOF, anything else? if not, calling it early ;)
[22:12] <RAOF> Feel free to test nouveau+xorg-edgers+unity on nv5x+ cards?  If it works, there might be fixes to backport.
[22:13] <TheMuso> nothing from me
[22:13] <bryceh> jasoncwarner, am idly curious if anyone is getting use out of the arsenal reports at http://www.bryceharrington.org/X/Reports/
[22:14] <bryceh> jasoncwarner, but no, other than boring everyone with X bugs nothing else from me :-)
[22:15] <jasoncwarner> bryceh: I'll let other people comment or if they have questions or comments to contact you directly. I personally have mostly worked off of LP only b/c I am trying to get acclimated.
[22:16] <TheMuso> jasoncwarner: Oh congratulations! Have hardly seen you online recently, at least when I've been looking. :)
[22:17] <TheMuso> And I hope everything is going well.
[22:17] <jasoncwarner> TheMuso: thanks! yeah, things are pretty good now. We are still away from home but are hoping to be back in our house maybe end of this week
[22:17] <jasoncwarner> staying with friends at the moment.
[22:17] <RAOF> Oh, yeah!  Congratulations!
[22:18] <jasoncwarner> baby girl and mom are doing great...hopefully feeding tube can get removed thursday or friday this week
[22:18] <jasoncwarner> RAOF: thanks :)
[22:18] <jasoncwarner> bit of a shock to get the call a month early...being away at LCA and all!
[22:19] <TheMuso> Certainly would be. Of more concern is how well the baby is doing being born so early.
[22:20] <Sweetshark> jasoncwarner: Great to hear that everything is going well.
[22:20] <jasoncwarner> TheMuso: small but healthy. Getting bigger each day. Has to reach a certain weight before she is deemed fit to go home, but we are getting closer to that each day
[22:20] <TheMuso> Cool.
[22:20] <jasoncwarner> Sweetshark: i'm just sorry for the upheaval right as you started! We haven't talked too much yet!
[22:21] <seb128> seems .au is awake at this hour ;-)
[22:21] <jasoncwarner> Sweetshark: perhaps if you are free tomorrow during a more reasonable hour your time we can spend some time talking
[22:21] <RAOF> seb128: It's half-past nine in the morning; I'd hope so! :)
[22:22] <seb128> RAOF, seems about the right time to start a day ;-)
[22:22] <jasoncwarner> seb128: yeah, but what are .fr and .Allemagne doing up?
[22:22] <seb128> jasoncwarner, .de ;-)
[22:22] <seb128> jasoncwarner, it's only 11pm here
[22:23] <seb128> so it's still an ok time to be online ;-)
[22:23] <seb128> or as asac would say "sleep is for the weaks"
[22:23] <Sweetshark> jasoncwarner: Sure, just make a proposal for a rough timeslot!
[22:23] <seb128> ;-)
[22:23] <jasoncwarner> Sweetshark: ok..finding time now
[22:27] <Sweetshark> jasoncwarner: As for being up now, FOSDEM caused lot of tailwind - I hardly got to do any "real work", with all the communication going on.
[22:28]  * Sweetshark is currently at 21 irc windows and counting ...
[22:28] <Sweetshark> maybe I just need to get used to that.
[22:30] <seb128> you probably do
[22:30] <seb128> or to cut a bit on "noise" channels ;-)
[22:30] <bryceh> Sweetshark, it seems a common situation.  With truly brutal pruning I can keep it to a dozen
[22:35] <seb128> TheMuso, hey
[22:35] <TheMuso> seb128: hi
[22:35] <seb128> TheMuso, did you check on the new at-spi for natty?
[22:36]  * Sweetshark is still spoiled from working at the developer enclave at Oracle ;)
[22:36] <TheMuso> seb128: Yes I did, and it still falls over a bit too much, and in a few too many painful ways...
[22:37] <seb128> TheMuso, ok, next cycle then, thanks
[22:37] <TheMuso> np
[22:37] <seb128> TheMuso, there is no hurry but better to now if it's worth spending time cleaning other components or not
[22:37] <seb128> still we should make sure it's in shape for next cycle
[22:37] <seb128> because we will likely want to switch next cycle
[22:38] <TheMuso> I'll still update at-spi2 in natty as new releases come out, up until its no longer possible to do so, then maintain updated packages in a ppa for people to test on natty
[22:38] <TheMuso> I totally understand.
[22:38] <TheMuso> I want to switch, and the code should be much more mature.
[22:39] <seb128> ok
[22:41] <robert_ancell> seb128, hey
[22:41] <seb128> robert_ancell, howdy
[22:41] <seb128> robert_ancell, how are you?
[22:42] <robert_ancell> who should https://code.launchpad.net/~mathieu-tl/unity/ubuntu-local-bzr-bd/+merge/48993 be reassigned to?
[22:42] <seb128> robert_ancell, didrocks
[22:42] <robert_ancell> is there not a "unity-team" or similar?
[22:42] <seb128> robert_ancell, is that upstream or distro?
[22:42] <robert_ancell> distro
[22:42] <seb128> the unity-team owns the upstram code
[22:43] <seb128> robert_ancell, well then ~ubuntu-desktop
[22:43] <seb128> lp:~ubuntu-desktop/unity/ubuntu
[22:43] <robert_ancell> ok, that's what it's assigned to now.  I guess I'll just leave it for didrocks
[22:43] <seb128> right, he will probably deal with it tomorrow
[22:44] <robert_ancell> Did you guys decide on what to do with vala? I vote for matching debian
[22:45] <seb128> robert_ancell, btw in versions.py the line checking for build failures has a source name coded is that wanted?
[22:45] <robert_ancell> ah, no
[22:45] <seb128> robert_ancell, l1225
[22:46] <seb128> robert_ancell, I guess it should be source_name = source?
[22:46] <robert_ancell> yeah, just pushed it now
[22:46] <seb128> robert_ancell, thanks ;-)
[22:46] <robert_ancell> versions is a bit of a monster :)
[22:47] <ari-tczew> robert_ancell: hi. can I pm you?
[22:47] <robert_ancell> ari-tczew, pm?
[22:48] <seb128> robert_ancell, right, I didn't check it for a while, I like how you special cased gtk, libunique, etc
[22:48] <seb128> robert_ancell, I'm thinking about adding extra hacks to strip ~ from upstream versions
[22:48] <seb128> so speex stops being listed ;-)
[22:48] <robert_ancell> seb128, hacks on hacks...
[22:49] <robert_ancell> seb128, agreed, I've been thinking about that for a while
[22:49] <ari-tczew> robert_ancell: private message ;-)
[22:49] <robert_ancell> ari-tczew, yes, I don't think you need to ask permission for that...
[22:49] <ari-tczew> :)
[22:55] <asac> seb128: yay!!
[22:55] <asac> though i could sleep a bit ;)
[22:56] <seb128> hey asac;-)
[22:56] <asac> hehe ... guess i proofed that midnight is also ok ;)
[22:58] <ari-tczew> hey, are we going to get network-manager 0.8.2 in natty?
[22:58] <seb128> asac, you are getting old it seems
[22:58] <ari-tczew> it's possible to merge with unstable
[22:59] <micahg> ari-tczew: we have a git snapshot of 0.8.3
[23:03] <ari-tczew> micahg: :(
[23:03] <ari-tczew> (guess you know what sad)
[23:03] <ari-tczew> s/what/why
[23:05] <asac> :)
[23:11] <ari-tczew> micahg: maybe upload 0.8.3 to unstable first?
[23:12] <micahg> ari-tczew: /me doesn't know who handles n-m in Debian
[23:13] <robert_ancell> seb128, mterry, what was the decision on vala?
[23:13] <Sweetshark> jasoncwarner: reping for timeslot? (just roughly so I have an idea)
[23:14] <jasoncwarner> I sent an invite...check your email it should be there
[23:16] <seb128> robert_ancell, to stay on 0.11 if we can
[23:16] <seb128> robert_ancell, cf your emails for shotwell
[23:16] <seb128> robert_ancell, i.e with the next vala tarball we should be able to switch it
[23:16] <Sweetshark> jasoncwarner: got it, accepted it. that would be 8pm here.
[23:16] <robert_ancell> seb128, so why not switch now?  I can do that today
[23:17] <seb128> robert_ancell, we need a vala fix and we might need some shotwell fixes from trunk as well
[23:17] <seb128> if you want to do backporting feel free
[23:17] <seb128> but we can as well be lazy and wait for the next tarball
[23:17] <seb128> vala0.10 is nbs for a while
[23:17] <seb128> he's going to stay there so there is no hurry
[23:18] <seb128> that's just something to sort before end of the cycle
[23:18] <robert_ancell> in the email you said two options, 1) bring back the old vala-0.10 source (which is what you said Debian did).  So why not just do that?
[23:18] <seb128> because we will need to support it as well
[23:18] <seb128> why bother if we don't need it?
[23:19] <seb128> less archive clutter, less bugs, less work in summary
[23:19] <robert_ancell> ok, so then we don't support vala 0.10 in Ubuntu, and wait for Shotwell 0.9 so we don't have anything in the archive that needs vala 0.10
[23:19] <seb128> right, well there is still a bunch of universe sources
[23:19] <seb128> but we have time to clean those
[23:20] <robert_ancell> I think it will be easier just to get vala-0.10 so we don't have to touch those, and Debian source packages will build
[23:20] <seb128> robert_ancell, http://people.canonical.com/~ubuntu-archive/NBS/valac-0.10
[23:21] <seb128> robert_ancell, ok, works for me
[23:21] <seb128> robert_ancell, I will clean that tomorrow
[23:22] <micahg> seb128: is there a way with cgit to run blame to find out when something changed? ( I have a fix for gpdftext and I want to version the poppler dep properly)
[23:22] <seb128> or do it today if you want
[23:22] <seb128> micahg, not that I know about no
[23:23] <robert_ancell> seb128, I think it just needs a sync, so I can't do it
[23:23] <micahg> seb128: k, I just have to bite the bullet and clone poppler to figure it out :)
[23:23] <Sweetshark> g'night guys.
[23:23] <seb128> robert_ancell, sync will not work for 0.10 but yeah for the new once that's likely
[23:23] <seb128> robert_ancell, I will do it tomorrow
[23:23] <robert_ancell> ok
[23:23] <seb128> 'night Sweetshark
[23:24] <seb128> ok, enough for today for me as well
[23:24] <seb128> bye everybody
[23:25] <seb128> doh
[23:25] <seb128> robert_ancell, so versions shows you fixed the build issues :p
[23:25] <robert_ancell> oh dear
[23:26] <seb128> robert_ancell, have fun ;-)
[23:27] <seb128> bye
[23:28] <seb128> robert_ancell, btw you should also fix the gjs case in versions ;-)
[23:28] <seb128> i.e if there is only an unstable version in the ppa use that to compare to upstream and debian
[23:28] <seb128> bye
[23:28] <robert_ancell> :P