=== asac_ is now known as asac [03:59] 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] good morning [08:13] morning mvo [08:14] 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] hey glatzor, good morning! [08:17] glatzor: sure thing, many thanks :) [08:19] mvo, have a nice day! I have to leave for "school". [08:20] see you glatzor [08:32] 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] x11-common xserver-common xserver-xephyr xserver-xorg-input-all xserver-xorg-video-all [08:32] is it safe to upgrade those packages with the previous Xorg server or is it a packaging issue? [08:35] Good morning [08:40] didrocks: I *think* those are all safe. [08:41] Guten Morgen pitti :) [08:41] RAOF: ok, I'll send you a reclamation letter if I can't restart :p [08:41] hey didrocks [08:41] didrocks: :) [08:41] G'Morning! [08:42] RAOF: thanks! I'll try that ;) [08:42] hey Sweetshark [08:42] hello Sweetshark, wie gehts? [08:42] Morning Sweetshark & pitti. [08:42] RAOF: ¡ɐıןɐɹʇsnɐ oʇ sƃuıʇǝǝɹƃ [08:43] excellent! ;) [08:43] :) [08:50] 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] 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] Launchpad bug 711304 in app-install-data-ubuntu "Create icon-theme.cache file to support mmap()ed icon loading" [Medium,In progress] [08:59] Sweetshark: ooh, nice! do they work now? [08:59] Sweetshark: you mean you added them upstream, too? [08:59] kamstrup: aha, right - I look into that today [09:00] mvo: awesome. njpatel ^^ [09:02] hey didrocks pitti [09:02] hey mvo [09:02] hey seb128 [09:02] hello seb128 [09:02] mvo, how are you? [09:03] good, thanks ! how are you? [09:03] hey seb128 [09:03] I'm fine thanks [09:04] 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] thanks mvo ! [09:06] * mvo just needs to finish this code-review work [09:07] gord: sorry dude, i #failed... gio/gvfs I just impossible to grok! [09:07] 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] Nicke: [09:09] sorry, "nice" [09:09] 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] jasoncwarner: hello [09:14] morning pitti [09:16] 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] 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] pitti: no worries...we'll check with seb...feel better. [09:17] 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] ;) [09:18] got it [09:18] cool. [09:19] pitti, sure no worry [09:19] Ok, I need to get some sleep. Trying to get a full 4 hours before my baby shift starts ;) good night everyone! [09:19] hey jasoncwarner, how are you? [09:19] jasoncwarner: sleep well! [09:19] hey seb...pretty good... [09:19] jasoncwarner, 'night ;-) [09:19] though, now I know why people say that we as humans have defense mechanisms about babies [09:20] our defenses are we forget all about the work, sleepless nights and other stuff that is the first year! ;) [09:20] now I remember....oh do I ever ;) [09:21] 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] jasoncwarner: G'night! [09:23] thanks Sweetshark, no worries! [09:23] talk to you tomorrow [09:24] mind you, that the above is not a bash of LO: OOo had ten rcs for the last release ... [09:25] Sweetshark: heh, ok [09:29] good morning everyone [09:29] hey jasoncwarner! [09:29] hey chrisccoulson [09:30] hi pitti, how are you? [09:30] hey chrisccoulson [09:30] chrisccoulson: feeling a bit sick actually (light fever), so I'll take it light today [09:30] hey jasoncwarner, chrisccoulson [09:30] s/light/easy/ [09:30] hey seb128, didrocks, how are you too? [09:30] * chrisccoulson hugs pitti [09:31] hmmm, could someone accept thunderbird for me? it's sat in binary NEW atm :) [09:31] 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] didrocks, oh, excellent. that's good to hear :) [09:32] chrisccoulson, I'm fine, what about you? [09:32] chrisccoulson, did you get the appmenu update? does it fix your issue? [09:33] didrocks: oooh [09:33] seb128 - yeah, good thanks. a little tired though. i was up late last night getting the appmenu work in for thunderbird [09:33] i've not tried the indicator-appmenu update just yet [09:33] chrisccoulson, didn't the upstream guy got someone to do that for you? [09:33] guys [09:34] seb128 - for thunderbird? yeah, there is somebody helping out with that now [09:34] mike conley, he hangs out in #ayatana [09:34] you should let him deal with it :p [09:34] 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] let's cross fingers :) === bilalakhtar_ is now known as cdbs [09:38] morning [09:38] hey rodrigo_, how are you? [09:38] hi seb128 === smspillaz is now known as smspillaz|swap [09:52] 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] htorque, yes, it doesn't do anything anymore [09:53] take a look in /usr/share/gnome-session/sessions instead [09:54] htorque: you need to add a file to /usr/share/xsessions/ pointing one in /usr/share/gnome-session/sessions [09:54] chrisccoulson, didrocks thanks! :) [09:54] htorque: the /desktop/gnome/session/required_components/windowmanager is working in the gnome classic session though [09:55] (using gnomewm) [09:55] didrocks, oh, that would be fine too, thanks [09:58] didrocks - you're an archive admin now aren't you? :) [09:58] * didrocks hides ;) [09:58] chrisccoulson: what's up? :) [09:58] didrocks - would you mind accepting https://launchpad.net/ubuntu/+source/thunderbird/3.1.8+build1+nobinonly-0ubuntu6 please :) [09:58] chrisccoulson: looking :) [10:02] 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] didrocks, ok, thanks :) [10:04] re [10:06] pitti, there is a gobject-introspection new tarball today [10:06] ooh, finally [10:06] pitti, just pointing it in case you want to do the update [10:07] seb128: yeah, will do [10:07] pitti, danke [10:08] seb128: there's just one small bug fix compared to our current git snapshot, so this should be easy [10:09] great [10:12] seb128: hm, have you seen this before? [10:12] --- gobject-introspection-1.0.pc 2011-02-02 13:48:50 +0000 [10:12] +++ gobject-introspection-1.0.pc 2011-02-08 10:09:31 +0000 [10:13] @@ -1,6 +1,6 @@ [10:13] -prefix=/usr/local [10:13] +prefix=/src/build/jhbuild [10:13] seb128: is that normal or a faulty make dist? [10:13] (that's our current git snapshot vs. 0.10.2 tarball) [10:13] pitti, check your build but I guess the tarball ships the .pc where it doesn't need to [10:13] pitti, like it's likely build from a .pc.in at build time [10:13] ok, I'll build it and check there [10:13] ah, right [10:13] so should be harmless [10:14] pitti, so it gets the value from whoever make dist it [10:14] but will be regenerated at build [10:14] right [10:26] 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] 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] mvo: yeah, that crossed my mind as well... just trying something is a good start [10:28] mvo: the problem is that all the icons in the dir have wildly variying sizes [10:29] yep [10:29] exactly [10:45] 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] hmmm, why does it look in xpi/firefox-4.0? [10:45] (the source package is just called firefox) [10:46] the lucid/maverick one is quite broken as well, but for now I'm trying to make the po2xpi trunk work first [10:47] hm, even if I symlink it to firefox-4.0 it still doesn't work [10:47] $ sh -x bin/process-xpi test/xpi-natty/ /tmp/t 11.04 [10:48] using data dir: /home/martin/ubuntu/langpack-o-matic/po2xpi/data//8.04 [10:48] this looks really wrong -- it shouldn't use its internal data dir at all any more, even less so for hardy?? [10:50] chrisccoulson, dpm: for lucid/maverick, is po2xpi actually meant to produce .xpis on the fly from launchpad .po files? [10:50] or should it use the pregenerated xpis from po2xpi.maverick/data.orig/common_xpi/ ? [10:50] pitti - i'm not sure about that, but dpm might know more ;) [10:50] asac: ^ perhaps you still remember? [10:54] 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] uh [10:55] dpm: so that should be po2xpi/data/common_xpi/*.xpi then? [10:55] as 8.04/, 8.10/, and 9.04/ are all obsolete [10:56] http://paste.ubuntu.com/564349/ is what I get right now [10:58] i have to enqueue checking that for a later day [10:58] maybe tomorrow? [11:00] 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] pitti - yeah, i guess so [11:00] 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] it seems like a lot of effort :/ [11:03] re [11:03] chrisccoulson, dpm: hm, danilo is not online; it seems that nobody really knows how po2xpi is supposed to work then? [11:03] 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] pitti - yeah, i've not worked enough with it yet to help you i'm afraid :( [11:04] dpm: right, but for DEV_MODE it's supposed to just use the po? [11:04] 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] PO2XPI_INSTALL_DATA=$PO2XPI_INSTALL_DATA_BASE/8.04 [11:05] so that's actually hardcoded in rosetta_xpi_to_sources [11:06] dpm, chrisccoulson: ah, seems better if I add "devmode" argument [11:06] 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] but no actual content [11:07] 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] ah, it's later overwritten by the third cmd line arg; I think I'll need to change this handling a bit [11:09] 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] after release, devmode is 0, and [11:10] 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] all xpis that have got a corresponding upstream xpi are generated (copied?) with runxpi2xpi [11:10] but a few of them are "whitelisted" and generated through po2xpi [11:10] dpm: so the purpose was that the updated XPIs get submitted upstream, and for stables we only use the upstream XPIs? [11:11] what does runxpi2xpi do then? [11:11] that was asac's design, the explanation is just my understanding (I might be wrong) [11:11] I'm not sure what runxpi2xpi does [11:12] but I think it's the part that requires the upstream xpis to be in data/ [11:13] dpm: but even in devmode it seems to look for them.. [11:13] * pitti dives into that code some more [11:14] i guess i really need top spend some time on this soon [11:14] ah, strange, perhaps it looks for the en-US.xpi template only? [11:14] dpm: that's not in po2xpi data, that gets exported into the launchpad tarball (as it should be) [11:14] hang on, I think I spotted something else [11:14] dpm - do you think it would be easier if we did something similar to what fta is doing for chromium? [11:14] /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] 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] 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] 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] I think we could live for now fixing the po2xpi scripts [11:17] and documenting them, so we don't have to go through this again [11:18] 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] 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] dpm - i was referring to shipping the xpi's as part of the firefox source upload [11:20] then I still need to unbreak the lucid/maverick langpacks somehow [11:20] but just now, i was talking about an entirely new source package (like we do for thunderbird) [11:21] well, right now langpack-o-matic still uses devmode for maverick, so I guess I need to fix both cases [11:21] we have a separate thunderbird-locales source package for the thunderbird translations [11:22] brb, phone call [11:24] kklimonda, hey, there is a new gtkmm update if you want to work on it [11:25] chrisccoulson, dpm: I just don't understand how the lucid langpacks ever had firefox translations.. [11:27] 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] i bet that's couchdb crashing! [11:28] aquarius: what does /var/log/apport.log say? [11:28] * chrisccoulson runs [11:28] :) [11:28] aquarius: and do you see anythign apport GUI related at all? or just the /usr/share/apport/apport process? [11:28] chrisccoulson, almost certainly, given that I'm compiling weird new versions :) [11:28] pitti, nothing on the GUI [11:28] heh. and with weird new versions of libmozjs [11:28] oh [11:28] i haven't tested it since i did the B11 upload [11:29] perhaps there was an ABI break, like there has been for every beta so far [11:29] yep, couch crashing. thanks, pitti: I didn't know there was a log :) [11:29] oh, yes [11:29] i just tried that here too. couchjs crashing again :( [11:29] maaaaaaaaaan, that's depressing [11:30] chrisccoulson, yeah, couchjs, so this is gonna be xulrunner fun again, isn't it? [11:30] * chrisccoulson switches to couchdb mode again [11:32] 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] mvo: ping? [11:33] chrisccoulson, so my suggestion would be for you as the FF maintainer to give pitti a hand with po2xpi :P [11:33] mvo: i'm looking at the compiz branch import at https://code.edge.launchpad.net/~vcs-imports/compiz/trunk [11:34] dpm - right ;) [11:34] i just need to find some time :/ [11:34] 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] 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] dpm: right, my more immediate concern are the lucid langpacks [11:37] aquarius, i think i'm going to package libmozjs as a separate system library [11:37] 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] but demonstrably it did [11:37] to try and decouple couchdb from these firefox releases [11:37] dpm: or it really just used the hardy data all along [11:37] it's getting crazy now, it has broken with every single one of the beta releases [11:37] 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] 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] i'm talking about making it an entirely separate source package, so we don't have to track firefox releases with it [11:39] pitti, I'm not sure how ArneGoetje and asac did it, I noticed there wasn't a data/9.10 folder, either [11:40] pitti, so perhaps they built them somewhere with local upstream xpis, which were never committed to any branch [11:41] dpm: they should still be on macquarie then [11:41] oh, couchdb does build against the latest mozjs. hopefully it is just an ABI break rather than a change in API too [11:41] right [11:41] dpm: I copied the old po2xpi/ verbatim to po2xpi.maverick/ (it's got tons of changes) [11:41] and want to use that for lucid/maverick, and po2xpi from the master branch for natty onwards [11:42] ok [11:42] 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] brb, session restart [11:43] 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] I know, that was what I was thinking as well [11:43] as I said, the preprocessing scripts seem more complex than the po2xpi C binary [11:43] aah [11:44] data -> ../mozilla-upstream-locales/ [11:44] ^ that's a dangling symlink on macquarie which I don't have locally [11:44] oh, are they still there then, or were they deleted? [11:45] apparently they got removed; mozilla-upstream-locales/ doesn't exist [11:45] bummer [11:45] I'll try the ones from po2xpi master [11:47] pitti, if that does not work, I can try to fetch the mozilla xpis corresponding to the FF version in Lucid [11:47] if that helps [11:47] well, I guess we'll have to do that anyway [11:48] as the xpis in the branch are translations from an older FF [11:48] dpm: can you commit them to lp:~mozillateam/po2xpi/trunk ? [11:49] pitti, I'll send a MP for chrisccoulson to accept [11:49] as we have the same firefox version in lucid and maverick anyway [11:49] which exact version is it, btw? [11:49] 3.6.13 [11:49] ok, let me get the upstream xpis [11:50] well, 3.6.14 on monday ;) [11:51] but that doesn't really make any difference [11:51] once I get actually working langpacks with 3.6.13, we can do the update [11:51] but right now the data dir is completely messed up [11:51] aquarius, couchjs isn't crashing anymore, but i can't really test if it works properly, because desktopcouch-service crashes [11:51] the scripts look for "firefox-3.6/", the data dir has "firefox", which on top of things points to a nonexisting dir [11:52] (i was just using didrocks oneconf-query to test it, as that made couchjs crash before) [11:52] i'm not sure how else to test it ;) [11:52] chrisccoulson: can we had onconf-query to the testsuite? :) [11:55] ooh, it's running [11:57] didrocks, don't joke, oneconf-query *is* my testsuite atm ;) [11:58] chrisccoulson: hehe, excellent! === MacSlow is now known as MacSlow|lunch [12:01] hey dbarth, I don't think I have the needed LP permission to do this, probably needs a launchpad admin [12:01] asac, chrisccoulson, dpm: hm, seems the xulrunner XPIs got lost; xpi -> /home/asac/mozilla-rosetta/po2xpi/data/common_xpi/ [12:02] but that dir doesn't exist any more [12:02] pitti - not sure we care about those too much [12:02] pitti, xulrunner translations are not needed after 3.0 or 3.5 [12:02] i don't know if there is anything in the archive using visible strings from xulrunner [12:02] (and if there is, they'll be in universe) [12:02] can't remember which, but in any case nowadays we've only got translatable strings for firefox in LP [12:03] I mean 'firefox' is the only translatable template, and the only one we get xpis for [12:03] 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] chrisccoulson: oh, we don't? [12:03] 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] chrisccoulson: that might be fine for natty, but for lucid we should keep them [12:04] pitti - translations for just firefox is fine. we don't have any for xulrunner in lucid or maverick anyway [12:04] (or, at least, i don't think we do) [12:04] hmkay [12:04] we shouldn't care about that anyway, i want to get xulrunner out of main ;) [12:04] 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] dpm: ah, so I'll pull them into the data [12:05] thanks [12:05] yeah, I'm uploading the lucid ones to a po2xpi branch right now [12:05] seb128: I'd love to take a look, but not before thursday - till then I'm stuck without my broadband :) [12:06] dpm: ah, ok; into common_xpi? [12:06] dpm: I'm currently preparing a branch of po2xpi to fix and clean up the data dir [12:06] dpm: so I'll keep using common_xpi for now [12:07] pitti, no, I thought for now under data/10.04/firefox/xpi. I didn't want to overwrite common_xpi [12:07] but you can rearrange it as you like [12:07] dpm: we'll share them between maverick and lucid, though [12:07] dpm: ok, will do [12:07] ok, sounds good [12:08] dpm: it seems you are already pushing, so I'll wait for this? (otherwise I'll just do the entire thing here) [12:08] lp has given up pushing my branch, trying again [12:09] and I think I'll abandon po2xpi.maverick [12:09] don't want to fix everything twice [12:14] mvo: ok, thanks; i'll try to find one [12:16] 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] Sweetshark: yes, absolutely [12:16] k [12:16] Sweetshark: we should upgrade to all 3.3.x releases and RCs that they do [12:17] so that we have more updates with smaller steps, and can also help testing them [12:21] kklimonda, can you open a bug and tag it desktop-upgrade so it shows on the version list? [12:22] kklimonda, just say you will do the update later this week on it [12:22] kklimonda, so nobody else duplicate work [12:23] seb128: will do [12:23] kklimonda, thanks [12:26] dpm: https://code.launchpad.net/~dpm/po2xpi/lucid-mozilla-upstream-locales -> still trouble pushing? [12:27] right, time to kill abrowser [12:27] pitti, yes :( [12:27] * chrisccoulson sharpens axe [12:27] $ bzr push lp:~dpm/po2xpi/lucid-mozilla-upstream-locales [12:27] Write failed: Broken pipehing revisions:Inserting stream [12:27] Write failed: Broken pipe [12:27] dpm: hm, perhaps I'll just include the new XPIs in my branch then? [12:28] pitti, yes, I think that'll be quicker [12:28] sorry about that, I'm not sure why bzr or LP are not cooperating [12:29] dpm - i'll be able to fix bug 705392 later ;) [12:29] Launchpad bug 705392 in firefox "The generated en-US.xpi translation template lacks branding" [Undecided,New] https://launchpad.net/bugs/705392 [12:30] chrisccoulson, \o/ [12:30] thanks [13:01] dpm, chrisccoulson: so, apparently something changed in the jar structure for firefox-4.0 [13:01] /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] that works and produces a full de.xpi for lucid [13:01] /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] this is firefox-3.6 -> 4.0 and pointing to the natty export [13:02] and produces a small and basically empty de.xpi [13:02] chrisccoulson, dpm: I got lucid working now, but natty is broken still; this ^ is how far I got breaking it down [13:03] chrisccoulson, dpm: I'll build new lucid langpacks now [13:03] chrisccoulson: would you mind pulling lp:~pitti/po2xpi/fix-update-data into lp:~mozillateam/po2xpi/trunk ? [13:03] chrisccoulson: I updated the data directory and fixed two bugs in rosetta_xpi_to_sources [13:06] 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] https://code.launchpad.net/~arnegoetje/old-lp-translations/po2xpi-arne [13:07] Especially rev. 59 [13:12] dpm: ah, we might need those indeed === artir is now known as afk|artir === afk|artir is now known as artir [13:32] vuntz, hey [13:32] vuntz, do you think http://people.gnome.org/~vuntz/tmp/versions/versions-stable could point to gtk 2.24? [13:33] vuntz, or do you keep it on purpose to 2.22? [13:36] seb128: it's generated from the GNOME 2.32 modulesets, and the GNOME 2.32 modulesets track gtk 2.22 [13:36] seb128: so it's kind of on purpose [13:37] vuntz, ok [13:37] vuntz, thanks [13:37] let's set a local overwrite for that one ;-) [13:37] 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] well, let's add nice hacks rather :p [13:37] but yeah, fair enough, I can overwrite that in our version tracker === oubiwann is now known as oubiwann_ [14:14] * bcurtiswx waves to room [14:15] * kenvandine waves to bcurtiswx [14:15] im finally looking forward to some warm weather coming to us in the mid-atlantic region [14:16] 50's by weeks end [14:16] we had 50s yesterday, but expecting light snow again on thursday [14:16] :( [14:16] i am enjoying as much cool weather as possible [14:17] before the long, really hot summer [14:17] good point, summer isn't fun around here [14:18] i guess growing up in western NY, i still like it warmer than cold ;) === MacSlow|lunch is now known as MacSlow === alf_ is now known as alf__ [15:15] didrocks, is there any news of the compiz upload? [15:16] seb128: isn't it done? [15:16] didrocks, no... [15:16] I dput IIRC [15:16] let me check [15:16] well it didn't work [15:16] thanks [15:17] argh, I bzr bd -S failed (gpg key signature, couldn't connect to the daemon) so && dput ubuntu didn't worked :/ [15:17] fixed now [15:17] didrocks, thanks [15:17] thanks seb128, I was really thinking it was uploaded [15:17] didrocks, yw ;-) [15:17] (you can see I pushed the branch right after we discussed) [15:17] btw, the stacking seems way stronger here [15:18] and I didn't get invisible window [15:18] (yet) [15:18] yeah, I figured you probably didn't notice the upload failed that's why I pinged you [15:18] great === bjf[afk] is now known as bjf [15:32] kenvandine, around? [15:38] rodrigo_, yeah, in a meeting [15:38] rodrigo_, give me 5m [15:38] kenvandine, ok, no hurry :) [15:40] rodrigo_, how is your todos list at the moment? ;-) [15:40]