[00:16] saivann: there also is a menu entry in Tools [00:31] asac, http://news.launchpad.net/cool-new-stuff/stacked-branches-holding-post [00:32] "i.e. Launchpad itself - it now takes less than two minutes to push up a branch. It used to take an hour and a half" ?? 1 & 1/2 hour ????? [00:36] http://ubuntuforums.org/showthread.php?t=953000 [01:01] fta: yeah ... most likely extreme situations like pushing complete ffox tree [01:07] asac, in case you missed it, i packaged that: http://www.instantbird.com/ [01:07] as a xulapp [01:10] fta: so thats a good example of a xulapp that doesnt shipp everything and fork stuff? [01:12] mostly, there's no gecko inside, but there's a kind of build system adapted from comm-central, ie needing access to mozilla-central, exactly like tb3 and sm2 now [01:13] i dropped that build system and replaced it by my xulapp magic, all fine [01:14] asac, ^^ https://code.edge.launchpad.net/~mozillateam/instantbird/instantbird.head [01:18] fta: nice [01:18] fta: just to check [01:18] fta: the build-system.tar.gz is a carefully seclected subtree of the xulrunner tree right? [01:18] right [01:18] do we patch anything before tarring that up? [01:21] it's done in post-patches:: [01:21] fta: right. but do we patch any of the files that get into that build-system.tar.gz [01:21] and if so, is that done for the sole purpose of providing that build system? [01:23] probably yes, configure.in is in there [01:24] ? [01:24] http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.head/annotate/359?file_id=createbuildsystem.sh-20080620161753-mwg01p9oiuq5axbb-1 [01:27] xul provides this tarball in the dev package, callers uses xulapp.mk from m-d, everything else is magic [01:33] hmm [01:34] i will take a closer look tomorrow maybe. too late now [01:34] got bitten by stupid nspluginwrapper [01:34] ;) [01:34] cu tomorrow [01:34] cu [05:02] hey asac [09:01] hi [09:08] how goes it asac [09:08] * NCommander got his AM report sent to the FD [09:13] NCommander: cool :) [09:13] all fine here ;) [09:13] so given that the frontdesk and DAM work well now, you should be a DD in two weeks [09:13] asac, so we did one major boo-boo with the icedove upload [09:13] We updated control.in [09:14] But didn't regenerate control >.<; [09:14] * NCommander notes that slipped past both of us, my sponsor, and a release manager [09:19] NCommander: huh? [09:19] NCommander: a) why did we update control at all? [09:20] b) what is the regression you are seeing? [09:20] asac, Maintainer change [09:20] hmm [09:20] its not a regression [09:20] Remember, you wanted me to change Maintainer to Ubuntu Mozilla Team, then add me, yourself, and someone else to uploaders? [09:20] The change landed in control.in, but the actual control file didn't get regenerated by accident [09:21] yeah [09:21] too bad [09:21] <[reed]> yeah, too many acronyms... AM, FD, DAM, DD... [09:21] <[reed]> :p [09:21] \o/ [reed] is back ;) [09:22] <[reed]> except it's 3:22am, and I have a test in a few hours [09:22] <[reed]> :( [09:22] [reed]: ok. then good luck. would be cool if you could ping me to test something about this EAP issue [09:22] after that ;) (or whenever you feel recovered) [09:23] <[reed]> yeah, I'll try to find you later today or so [09:26] cool [09:26] * asac presses thumbs for the test [09:27] or crosses fingers ;) [09:27] NCommander: feel free to fix that in bzr. we probably will do an upload sooner or later and than this gets auto-fixed [09:28] asac, well, I'd like to fix lintian for icedove [09:29] Hi ! [09:29] NCommander: whatever you want ;) [09:29] asac, its a pity I can't direct commit. When is the next mozillateam meeting so I can be voted in :-)? [09:30] NCommander: isnt that in topic? [09:30] oh [09:30] hmm [09:30] :-) [09:30] The next Ubuntu Mozilla Team meeting will be held on: Sunday, 2nd November, 18:00 UTC [09:30] Your last one was awhile ago [09:30] in #ubuntu-meeting on FreeNode network (irc.freenode.org). [09:31] we have every 6 weeks [09:31] so whens the next meeting that will have quorum :-) (or does mozillateam not suffer from that issue) === asac changed the topic of #ubuntu-mozillateam to: Welcome to the Ubuntu Mozilla Team: | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Please help Mozilla QA tracker: http://tinyurl.com/6yo6g7 | Firefox 3 released to hardy-updates! | Next meeting will be held on Sunday, 2nd November, 18:00 UTC in #ubuntu-meeting (agenda available at: http://tinyurl.com/2ekzoq ) [09:32] NCommander: we have no quorum problems ;) [09:32] Handy [09:32] NCommander: just go ahead and push to your branch [09:32] * NCommander adds himself to the adenga [09:32] *agenda [09:32] NCommander: i dont work on the icedove branch at the moment [09:32] so its just a pull/push for me [09:32] to publish your changes [09:32] which is ok for 2 weeks i guess ;) [09:33] I need your advice on how to fix the engimail serve bug (you said we needed to add .autoreg) [09:33] NCommander: yes. in icedove we have to ensure that we ship an empty or placeholder file /usr/lib/icedove/.autoreg [09:34] what does that do? [09:34] NCommander: in enigmail postinst and rm we have to touch that file if it exists [09:34] e.g. if test -e /usr/lib/icedove/.autoreg; then touch /usr/lib/icedove/.autoreg; fi [09:34] NCommander: it triggers re-registration of system crhome and extensions [09:35] ah [09:35] otherwise icedove might not see that your extension has been added/changed [09:35] So icedove needs that in its post/pre install? [09:35] NCommander: no. icedove has to ship a placeholder file ... enigmail has to touch it [09:35] e.g. just an empty file in icedove package [09:36] Oh! [09:36] so that's why engimail broke [09:37] NCommander: enigmail broke? [09:37] well [09:37] has an RC bug [09:37] NCommander: well. thats my story of it. the NMUer did find another story [09:38] Did you figure out the NMU non-sense? [09:38] i looked at the diff for a second and it didnt make much sense to me ... at least i didnt understand what it tries to achieve [09:38] So you want to NACK it? [09:38] but maybe he had a point. unfortunately there is no comment or so about it in bug [09:38] Isn't that against NMU protocol? [09:38] NCommander: what is a NACK? isnt that just a new upload without that change? [09:38] non-acklodge [09:39] Pretty much. As the maintainer, you can reject NMUs [09:39] NCommander: how? [09:39] Upload a version removing their changes ;-) [09:39] NCommander: i mean this most likely made it into the archive already [09:39] NCommander: right ;) [09:39] asac, it is already in the archive [09:39] thats what i know [09:39] you can use the dcut command to kill an upload if it was still in the delayed queue [09:40] yeah remember about dcut ;) [09:40] anyway. i dont know if his change makes sense. but we should certainly add the .autoreg stuff in postinst [09:41] have to get some breakfast>/coffee now [09:41] same here [09:49] debian bug 486491 [09:49] Debian bug 486491 in enigmail "enigmail: does not upgrade from etch to lenny inside people's" [Normal,Closed] http://bugs.debian.org/486491 [10:01] NCommander: ok. i looked. that change is ok [10:01] so we can do -4 on top of 3.2 [10:01] So we want to ack the NMU [10:01] Ok [10:01] NCommander: how? i only know updload with or without the NMU ;) [10:02] asac, the next upload must have an entry in the changelog acking the NMU [10:02] (its weird, I know) [10:02] acking == repeating the Closes: ? [10:06] asac, no, something like * Ackknlodging the non-maintainer upload by *uploader* [10:07] http://www.debian.org/doc/developers-reference/pkgs.html#ack-nmu [10:11] NCommander: ok. that procedure is what i had in mind [10:11] thank you james_w :-) [10:11] "just keep on going" [10:12] and remember to get the bugs properply clodsed [10:27] we're whalers on the moon [10:37] how comes? [10:39] never seen futurama? === asac_ is now known as asac [11:22] armin76: didnt really like it ;) [11:22] but maybe its just that i never tried ;) [11:52] * NCommander works on icedove [11:55] asac, .autoreg is properly touched by icedove-gnome-support [11:55] asac, should we simply move those post* scripts to icedove vs icedove-gnome-support? [12:03] NCommander: no thats right. this simply means that enigmail should do it too [12:04] asac, what if icedove is installed without gnome support? [12:04] NCommander: everything that adds/removes chrome/extensions/locales need to touch it in postinst and postrm [12:04] so both icedove, and icedove-gnome-support need it, right? [12:04] NCommander: icedove ships the file itself. -gnome-support just touches it [12:04] NCommander: icedove doesnt need to touch it [12:04] just to ship it so its properly registered as a dpkg managed file [12:05] NCommander: e.g. icedove will touch it implicitly because it ships that file [12:05] we do? [12:06] icedove.install says we don't. [12:06] NCommander: most likely done in rules [12:06] Yup [12:06] because there is no source for that file [12:06] Ok [12:06] Just making sure [12:06] sure [12:06] asac, I'm going to split the icedove package to create an icedove-data (for all the arch all files) [12:06] that was one of the points i mentioned: make sure icedove ships that file ;) [12:06] NCommander: err. why? [12:07] that is really unneeded compication [12:07] Kills a lintian warnings. Packages with large amounts of files in /usr/share should split that off [12:07] yeah i know. but doesnt make much sense here. i had that in the past and eliminated it [12:07] Why'd you elimate it? [12:07] because it doesnt make sense ;) [12:08] its really a lot of work for not much benefit [12:08] also _all packages are broken in the archive [12:08] e.g. if anything build depends on it it can cause a bunch of pain on architectures that lack behind [12:08] not that a big reason for icedove ... but well. [12:09] Point taken-ish [12:09] there is one reason to ship _all files in /usr/share [12:09] * NCommander is working to clean out the other lintian errors [12:09] that is to have a single partition shared across multiple architectures [12:09] but i havent heard of anyone actually using that [12:09] NCommander: there are just a few errors ... the rest are warnings [12:10] iirc there are warnings about executable icons or something ;) [12:10] that should be fixed. [12:10] Yup, working on that [12:10] The biggest one that needs to be fixed is that we install a png as icedove's icon [12:10] Which works fine in GNOME/KDE, but breaks in say Window Maker [12:10] NCommander: instead of xpm? [12:11] yeah [12:11] NCommander: i think we should ship both and use a reference without .suffix in .desktop [12:11] and the xpm in icons [12:11] asac, that's easy to fix [12:11] all we do is drop the xpm in debian/ and then have it installed on the fly [12:12] NCommander: if possible generate the .xpm on the fly during build [12:12] Oh [12:12] Not difficult [12:12] But it means a build-dep on imagemagick [12:12] and how often do we really change the icon? [12:12] NCommander: if possible generate. if thats too much work i dont care about .xpm [12:12] at least it can be in the .diff.gz without uuencode business [12:12] but well ... if we can generate it even better [12:12] convert *.png *.xpm :-) [12:12] NCommander: it clutters the diff [12:12] thats the actual command [12:13] most likely there is a lot of clutter, but that doesnt mean we should add more ;) [12:13] I can modify the repack rule to do it on the fly [12:13] NCommander: yeah. i think i already do image transformation duing build [12:13] convert et al [12:13] so just hook it in there [12:13] Can we upload a new orig.tar.gz for Icedove? [12:13] NCommander: if repack is the rule where i do converts atm then yeah. [12:14] Without a new release? [12:14] NCommander: why? [12:14] NCommander: unless we also fix the build system to properly ship the .xpm on make install i would prefer to do the .xpn in rules [12:14] We can do it in the rules [12:14] instead of the ogig [12:15] * NCommander figures out how to attach this [12:15] *attack :-) [12:15] also mozilla droped support for .xpm so putting that file in the orig doesnt sound right [12:15] Oh, I see how we can do it [12:15] I'll just do the conversion during make install [12:15] as gecko itself cannot render it ;) [12:15] NCommander: urgh [12:15] <[reed]> It's a horrible format. [12:16] Well, the debian menu system is a hack [12:16] NCommander: please do it in rules [12:16] asac, no, I mean during the install rule of rules :-) [12:16] NCommander: hacks should go to rules ;) [12:16] ah ok thas ok then ... do it whereever i did the other converts [12:16] unless i dont sdo that anywhere anymore [12:17] You don't [12:17] then just add it wherever you feel its appropriate ;) [12:17] let me get that branch ;) [12:18] my memory appears to have lost some details at some point :) [12:20] asac, a lot of stuff installed into /usr/lib appears platform independent [12:20] * NCommander thinks we can thank upstream for that :-P [12:22] NCommander: thats ok. thats whate i referred to when saying i stopped doing that [12:23] in the past i had links to /usr/share stuff ... but that was too much work and gave zero benefit [12:24] So upstream ships with everything in /usr/lib? [12:24] NCommander: upstream doesnt ship in /usr at all [12:24] NCommander: they ship everything in one directory tree and that tree is not depending on the install location [12:25] even in the source packages? [12:25] r [12:25] eh? [12:26] nm [12:26] if you are asking if they dont install it in /usr/share on make insteall .. then yes. you can be happy if they install all files on make install at all [12:26] Ouch [12:26] I knew Mozilla was bad [12:26] But I didn't know how bad [12:26] Next question (yes, I know), what's cdbs-rules for ;-) [12:28] <[reed]> patches welcome. [12:28] NCommander: its because i have added a feature we shoujld eventually send upstream [12:28] ah [12:29] * NCommander is right now trying to figure where to hang a well placed rm -r command to kill the CVS folders in the binaries [12:31] [reed]: i will re-look at that. but the past told us that it was _too_ hard to maintain proper make install for mozilla devs. benjamin tried to fix that by using the installer code now to pack things up (which appears to be better maintained). not unlikely that we can make this do what linux FHS suggests. and if we have to maintain a separate file we will end up in the situation we had before: make install is always broken and we always run a [12:31] s/not unlikely/not likely/ [12:31] <[reed]> ;) [12:32] [reed]: the reason is that nobody uses make install :) ... so whenever a special file is added to dist/... it gets forgotten [12:32] [reed]: but well. i can live with it as its now ;) [12:33] [reed]: but i think tbird doesnt use that mechanism ... but fta can tell more about that. [12:34] <[reed]> yeah [12:34] [reed]: so ... we have the standard situation here. just a few days left and some users say that EAP is working now [12:34] <[reed]> hmm [12:34] <[reed]> so [12:34] i need a reliable tester ;) [12:34] <[reed]> I'll get with you later today [12:34] <[reed]> it's 6:35am [12:34] <[reed]> I haven't been to bed [12:34] <[reed]> I have to be up at 9am :( [12:35] otherwise it might be broken if i do nothing ... or if i land some unconfirmed patch it might be broken even though it worked before ;) [12:35] [reed]: then go to bed you night-owl ;) [12:35] _just_ this single day :) [12:35] <[reed]> hehe [12:37] asac, woohoo, I think I got the package almost completely lintian clean on both binaries and source [12:39] nice ;) [12:39] did you do overrides for the all files in /usr/lib? [12:41] asac, just did a well placed chmod -x [12:44] asac, added bonus, icedove is now safely binNMUable [12:51] k [12:51] fixed strict depends? [12:53] Yup [12:53] The only lintian warning on the source package now is that a cdbs junk file keeps getting pulled in [12:57] NCommander: cdbs junk file? [12:58] asac, its a bug in CDBS, already reported [12:58] (a manifest of files it tars just gets left behind) [12:58] ok ... so its not us [12:58] Yeah [12:58] We just didn't see it in a see of lintian warnings (all gone now :-)!) [12:58] I'm now looking to see what, if any patches we want to include on this upload [13:18] NCommander: look if debian bug 392603 still applies [13:18] Debian bug 392603 in icedove "thunderbird: Segfault on opening mail folder" [Important,Open] http://bugs.debian.org/392603 [13:18] asac, if the patch applies cleanly I'll add it [13:18] NCommander: well. lets not just add it ;) [13:18] NCommander, you're smart. what's the right version substitution to use for easy binnmuability? [13:18] NCommander: the kbsd can be added if its applying cleanly [13:19] ${binary:Version}, yes? [13:20] NCommander: the manpage is ok. but we should ensure that the examples actually work [13:20] NCommander: debian bug 378741 is old and if it doesnt have a better icedove icon (i hink its about the old tbird icon), then we should close it [13:21] Debian bug 378741 in thunderbird "taskbar and application icon look very jagged and pixelated" [Minor,Open] http://bugs.debian.org/378741 [13:21] directhex, yes [13:21] directhex, if lintian doesn't complain it is usually ok [13:21] it's a while since i ran any lintian tests [13:21] NCommander: xprint using sh instead of bash ... well. do we use xprint at all? [13:22] Not anymore [13:22] debian bug 441038 is fixed upstream ... or if not we have a proper patch for it in firefox 2 packages in ubuntu [13:22] Debian bug 441038 in icedove "icedove: cannot be symlinked" [Minor,Open] http://bugs.debian.org/441038 [13:22] i am quite sure that debian bug 363815 is too outdated to be of much use now [13:22] Debian bug 363815 in mozilla-thunderbird "get-orig-source debian/rules target for Thunderbird" [Wishlist,Open] http://bugs.debian.org/363815 [13:23] we should close it or remove the patch tag [13:23] Don't we have a get-orig-tarball rule? [13:23] * NCommander will just close it [13:24] for debian bug 499309 we should ask him for "evidence from the news" and if thats the case forward upstream [13:24] Debian bug 499309 in icedove "workaround for Cisco PIX text substitution" [Wishlist,Open] http://bugs.debian.org/499309 [13:24] but not just blindly apply [13:24] NCommander: we have repack [13:24] i dont think we have get-orig-source [13:24] not sure if thats really important to have though [13:25] No, since we still need to repack [13:25] urgh. W: moon source: not-binnmuable-all-depends-any libmoon-dev -> libmoon0 [13:25] directhex, do >= ${source:Version} [13:26] debian bug 363858 is somehow unimportant and appears to be fixed upstream in 3.0a3 [13:26] Debian bug 363858 in mozilla-thunderbird "Thunderbird Won't Read Signature From a Pipe" [Unknown,Open] http://bugs.debian.org/363858 [13:26] NCommander, is that the right line for a -dev package? [13:26] directhex, your -dev package is arch: all? [13:26] and your main package is arch any? [13:27] NCommander, you know, that's a good question. why IS it arch:all? [13:27] not sure what is going on with debian bug 476302 [13:27] Debian bug 476302 in iceweasel "iceweasel: ftbfs on armel: temporary object destruction order" [Normal,Open] http://bugs.debian.org/476302 [13:27] gah, there was literally *nothing* usable in marillat's package, then [13:27] asac, I know why. Thats just localized insanity. The patch attached fixes it [13:27] * NCommander notes armel has some "fun" issues [13:28] asac, I already put that patch in the included tarball [13:28] NCommander: we should look what was applied (if any) in iceape [13:28] or iceweasel [13:28] or whatever [13:28] asac, the patch for iceweasel was attached [13:29] NCommander: ok we can take it. just ensure that autoreconf patchis properly refreshed [13:29] (if i still use that mechanism at all=) [13:30] NCommander, i spy only headers and a pkg-config file. is arch:all wrong? there's nothing arch-speficic that i can see [13:30] directhex, if its a C based library, it should have a static library (.a), and a ****load of symlinks [13:32] hm, you're right, there's a missing symlink. [13:32] -dev usually isnt all ;) [13:32] directhex, what are you packaging? [13:33] wait, my mistake. libmoon-dev: /usr/lib/libmoon.so [13:33] NCommander, moonlight. [13:33] asac, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406849 [13:33] Debian bug 406849 in icedove "icedove: Copyright and license info for Debian packaging, including artwork," [Minor,Open] [13:33] directhex, oh, this is a mono based program? [13:33] The normal rules *might* not apply [13:34] NCommander, at this moment in time, it's just c [13:34] directhex, it needs more than that, it needs the full set of soname symlinks [13:34] NCommander, i.e. "1.0 profile" isn't at all monoish, and "2.0 profile" requires mono 2.0 to compile [13:35] fta: if you want something to sponsor for intrepid, look at Bug 286225 [13:35] Launchpad bug 286225 in vimperator "[intrepid] iceweasel-vimperator: Depends: iceweasel (>= 3.0~) but it is not instalable" [Undecided,Confirmed] https://launchpad.net/bugs/286225 [13:35] libmoon0: /usr/lib/libmoon.so.0.0.0 [13:35] libmoon0: /usr/lib/libmoon.so.0 [13:35] :) [13:35] asac, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393237 should we slaughter this while we're at it? [13:35] Debian bug 393237 in icedove "icedove: upgrade fail to remove /etc/thunderbird" [Minor,Open] [13:35] (I figure a rm -r in postinst) [13:35] NCommander: yes. we should remove files that are in dpkg --status of thunderbird, mozilla-thunderbird and icedove and are obsolete [13:36] ok, how do we do that ;-) [13:36] NCommander: i am not 100% sure. but i think on every upgrade parsing dpkg --status PKGNAME for lines that have "obsolete" ... then checking the md5sum and if the md5sum is still equal rmove that file [13:37] otherwise keep it as the user has modified it [13:37] most likely its too late to migrate them to /etc/icedove anyway [13:37] eh [13:37] * NCommander pushes his branch to Launchpad [13:49] NCommander: have to do a few NM things ... let me know hwen everything is up. will look right next there then [13:49] asac, I'm still doing a few test builds, this can probably wait for post lenny to upload [13:51] NCommander: well. lets get the current biuld in. and then get the new build up [13:51] in == lenny [13:51] yup [13:51] Its still not frozen :-/ [13:53] at this rate jaunty will miss mono 2.0, due to lenny freeze [13:53] and maybe killer kilwalla too [14:21] NCommander: http://wiki.debian.org/DpkgConffileHandling might be of interest [14:23] yeah i remember that directly parsing stats will cause lintian to complain [14:50] saivann: any nack/ack for the ubufox translations? [14:53] [reed]: what file .suffix does your cert file for EAP have? [15:09] asac : Give me a few minutes and zh-CN locales will be uploaded to my branch. Outside of this locale, all locales works well [15:20] saivann: great [15:20] saivann: let me know ;) [15:26] asac : Ok :) [15:30] asac : The're ready, rev 146 [15:39] saivann: is that against upstream branch? [15:39] yeah ... seems like (at least the mail suggests it is lp:ubufox) [15:39] asac : Yes, your own branch [15:40] asac : This one https://code.edge.launchpad.net/~asac/ubufox/main [15:40] asac : Let me know if you want me to re-upload the branch, I can do it fast [15:41] saivann: what did you do with your email :( [15:41] saivann: https://code.edge.launchpad.net/~saivann/ubufox/intrepid_translations [15:41] saivann: do you want to recommit that stuff with a good email? [15:41] (or dont you care) [15:41] ? [15:42] asac : Oh.. oups... my ssh key caused this. Well if you merge the branch, will my email appears anywhere? [15:43] saivann: yes it would appear in the nested log [15:43] e.g. bzr log will show the commits as you see them now [15:43] also i could just push your branch directly (as i didnt do any additional cahnge) [15:44] asac : Ok, I will recommit, thanks for finding this [16:23] asac : Sorry for the time it took, I had to re-test all locales. Everything works now : https://code.edge.launchpad.net/~saivann/ubufox/intrepid_translations [16:58] saivann: committed. can you test one more round from the lp:ubufox branch directly? (rev 142) [16:58] so i can bake a package out of it and upload? [16:59] asac : Yes, I do it right now [17:02] thx [17:08] asac : I just noticed a problem related to locales. If you start firefox with a locale that does not exist in the ubufox locales, you won't be able to use "alt" functionnalities. The rest of the functionnalities will simply fallback to english language [17:09] saivann: hmm. even if the -alt is in en-US? [17:09] asac : Yes, see it by yourself : firefox -UILocale gr [17:10] asac : it won't happen if you start firefox with a known locale [17:15] asac : I tried all locales in your branch, everything works correctly [17:15] saivann: have you also tested the "restart" notification? [17:16] saivann: shoudl appear when sudo touch /var/lib/update-notifier/user.d/firefox-3.0-restart-required [17:16] asac : Oh, let me try it [17:16] asac : works well so far, I will test all locales [17:24] Hi [17:25] Hi :) [17:25] Is anyone comming to Mozilla Camp Europe this weekend? [17:25] asac : I found a issue with it-IT locale, I'll update my branch in a few minutes [17:28] saivann: are you testing the "restart" thing too? [17:28] cool [17:28] RainCT: where is that? paris? [17:28] asac: Barcelona [17:28] oh dear. i should have planned that [17:28] why i nobody telling me [17:28] (https://wiki.mozilla.org/EU_MozCamp_2008) [17:28] now its too late unfortunately [17:30] asac : Yes, I'm currently testing the "restart" thing, for all locales and it is the only locale that has a problem so far, and I know where is the problem [17:32] Too bad. So no Ubuntu guy is coming? :( [17:39] RainCT: are you from barcelona? [17:39] saivann: cool [17:39] saivann: so which local has no -alt? [17:39] (so i can test the issue you reported above) [17:39] asac : it-IT [17:40]