[00:16] <asac> saivann: there also is a menu entry in Tools
[00:31] <fta> asac, http://news.launchpad.net/cool-new-stuff/stacked-branches-holding-post
[00:32] <fta> "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] <fta> http://ubuntuforums.org/showthread.php?t=953000
[01:01] <asac> fta: yeah ... most likely extreme situations like pushing complete ffox tree
[01:07] <fta> asac, in case you missed it, i packaged that: http://www.instantbird.com/
[01:07] <fta> as a xulapp
[01:10] <asac> fta: so thats a good example of a xulapp that doesnt shipp everything and fork stuff?
[01:12] <fta> 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] <fta> i dropped that build system and replaced it by my xulapp magic, all fine
[01:14] <fta> asac, ^^ https://code.edge.launchpad.net/~mozillateam/instantbird/instantbird.head
[01:18] <asac> fta: nice
[01:18] <asac> fta: just to check
[01:18] <asac> fta: the build-system.tar.gz is a carefully seclected subtree of the xulrunner tree right?
[01:18] <fta> right
[01:18] <asac> do we patch anything before tarring that up?
[01:21] <fta> it's done in post-patches::
[01:21] <asac> fta: right. but do we patch any of the files that get into that build-system.tar.gz
[01:21] <asac> and if so, is that done for the sole purpose of providing that build system?
[01:23] <fta> probably yes, configure.in is in there
[01:24] <fta> ?
[01:24] <fta> http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.head/annotate/359?file_id=createbuildsystem.sh-20080620161753-mwg01p9oiuq5axbb-1
[01:27] <fta> xul provides this tarball in the dev package, callers uses xulapp.mk from m-d, everything else is magic
[01:33] <asac> hmm
[01:34] <asac> i will take a closer look tomorrow maybe. too late now
[01:34] <asac> got bitten by stupid nspluginwrapper
[01:34] <asac> ;)
[01:34] <asac> cu tomorrow
[01:34] <fta> cu
[05:02] <NCommander> hey asac
[09:01] <asac> hi
[09:08] <NCommander> how goes it asac
[09:08]  * NCommander got his AM report sent to the FD
[09:13] <asac> NCommander: cool :)
[09:13] <asac> all fine here ;)
[09:13] <asac> so given that the frontdesk and DAM work well now, you should be a DD in two weeks
[09:13] <NCommander> asac, so we did one major boo-boo with the icedove upload
[09:13] <NCommander> We updated control.in
[09:14] <NCommander> But didn't regenerate control >.<;
[09:14]  * NCommander notes that slipped past both of us, my sponsor, and a release manager
[09:19] <asac> NCommander: huh?
[09:19] <asac> NCommander: a) why did we update control at all?
[09:20] <asac> b) what is the regression you are seeing?
[09:20] <NCommander> asac, Maintainer change
[09:20] <asac> hmm
[09:20] <NCommander> its not a regression
[09:20] <NCommander> Remember, you wanted me to change Maintainer to Ubuntu Mozilla Team, then add me, yourself, and someone else to uploaders?
[09:20] <NCommander> The change landed in control.in, but the actual control file didn't get regenerated by accident
[09:21] <asac> yeah
[09:21] <asac> too bad
[09:21] <[reed]> yeah, too many acronyms... AM, FD, DAM, DD...
[09:21] <[reed]> :p
[09:21] <asac> \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] <asac> [reed]: ok. then good luck. would be cool if you could ping me to test something about this EAP issue
[09:22] <asac> after that ;) (or whenever you feel recovered)
[09:23] <[reed]> yeah, I'll try to find you later today or so
[09:26] <asac> cool
[09:26]  * asac presses thumbs for the test
[09:27] <asac> or crosses fingers ;)
[09:27] <asac> 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] <NCommander> asac, well, I'd like to fix lintian for icedove
[09:29] <XioNoX> Hi !
[09:29] <asac> NCommander: whatever you want ;)
[09:29] <NCommander> asac, its a pity I can't direct commit. When is the next mozillateam meeting so I can be voted in :-)?
[09:30] <asac> NCommander: isnt that in topic?
[09:30] <asac> oh
[09:30] <asac> hmm
[09:30] <NCommander> :-)
[09:30] <asac> The next Ubuntu Mozilla Team meeting will be held on: Sunday, 2nd November, 18:00 UTC
[09:30] <NCommander> Your last one was awhile ago
[09:30] <asac> in #ubuntu-meeting on FreeNode network (irc.freenode.org).
[09:31] <asac> we have every 6 weeks
[09:31] <NCommander> so whens the next meeting that will have quorum :-) (or does mozillateam not suffer from that issue)
[09:32] <asac> NCommander: we have no quorum problems ;)
[09:32] <NCommander> Handy
[09:32] <asac> NCommander: just go ahead and push to your branch
[09:32]  * NCommander adds himself to the adenga
[09:32] <NCommander> *agenda
[09:32] <asac> NCommander: i dont work on the icedove branch at the moment
[09:32] <asac> so its just a pull/push for me
[09:32] <asac> to publish your changes
[09:32] <asac> which is ok for 2 weeks  i guess ;)
[09:33] <NCommander> I need your advice on how to fix the engimail serve bug (you said we needed to add .autoreg)
[09:33] <asac> NCommander: yes. in icedove we have to ensure that we ship an empty or placeholder file /usr/lib/icedove/.autoreg
[09:34] <NCommander> what does that do?
[09:34] <asac> NCommander: in enigmail postinst and rm we have to touch that file if it exists
[09:34] <asac> e.g. if test -e /usr/lib/icedove/.autoreg; then touch /usr/lib/icedove/.autoreg; fi
[09:34] <asac> NCommander: it triggers re-registration of system crhome and extensions
[09:35] <NCommander> ah
[09:35] <asac> otherwise icedove might not see that your extension has been added/changed
[09:35] <NCommander> So icedove needs that in its post/pre install?
[09:35] <asac> NCommander: no. icedove has to ship a placeholder file ... enigmail has to touch it
[09:35] <asac> e.g. just an empty file in icedove package
[09:36] <NCommander> Oh!
[09:36] <NCommander> so that's why engimail broke
[09:37] <asac> NCommander: enigmail broke?
[09:37] <NCommander> well
[09:37] <NCommander> has an RC bug
[09:37] <asac> NCommander: well. thats my story of it. the NMUer did find another story
[09:38] <NCommander> Did you figure out the NMU non-sense?
[09:38] <asac> 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] <NCommander> So you want to NACK it?
[09:38] <asac> but maybe he had a point. unfortunately there is no comment or so about it in bug
[09:38] <NCommander> Isn't that against NMU protocol?
[09:38] <asac> NCommander: what is a NACK? isnt that just a new upload without that change?
[09:38] <NCommander> non-acklodge
[09:39] <NCommander> Pretty much. As the maintainer, you can reject NMUs
[09:39] <asac> NCommander: how?
[09:39] <NCommander> Upload a version removing their changes ;-)
[09:39] <asac> NCommander: i mean this most likely made it into the archive already
[09:39] <asac> NCommander: right ;)
[09:39] <NCommander> asac, it is already in the archive
[09:39] <asac> thats what i know
[09:39] <NCommander> you can use the dcut command to kill an upload if it was still in the delayed queue
[09:40] <asac> yeah remember about dcut ;)
[09:40] <asac> anyway. i dont know if his change makes sense. but we should certainly add the .autoreg stuff in postinst
[09:41] <asac> have to get some breakfast>/coffee now
[09:41] <NCommander> same here
[09:49] <asac> debian bug 486491
[10:01] <asac> NCommander: ok. i  looked. that change is ok
[10:01] <asac> so we can do -4 on top of 3.2
[10:01] <NCommander> So we want to ack the NMU
[10:01] <NCommander> Ok
[10:01] <asac> NCommander: how? i only know updload with or without the NMU ;)
[10:02] <NCommander> asac, the next upload must have an entry in the changelog acking the NMU
[10:02] <NCommander> (its weird, I know)
[10:02] <asac> acking == repeating the Closes: ?
[10:06] <NCommander> asac, no, something like * Ackknlodging the non-maintainer upload by *uploader*
[10:07] <james_w> http://www.debian.org/doc/developers-reference/pkgs.html#ack-nmu
[10:11] <asac> NCommander: ok. that procedure is what i had in mind
[10:11] <NCommander> thank you james_w :-)
[10:11] <asac> "just keep on going"
[10:12] <asac> and remember to get the bugs properply clodsed
[10:27] <armin76> we're whalers on the moon
[10:37] <asac> how comes?
[10:39] <armin76> never seen futurama?
[11:22] <asac> armin76: didnt really like it ;)
[11:22] <asac> but maybe its just that i never tried ;)
[11:52]  * NCommander works on icedove
[11:55] <NCommander> asac, .autoreg is properly touched by icedove-gnome-support
[11:55] <NCommander> asac, should we simply move those post* scripts to icedove vs icedove-gnome-support?
[12:03] <asac> NCommander: no thats right. this simply means that enigmail should do it too
[12:04] <NCommander> asac, what if icedove is installed without gnome support?
[12:04] <asac> NCommander: everything that adds/removes chrome/extensions/locales need to touch it in postinst and postrm
[12:04] <NCommander> so both icedove, and icedove-gnome-support need it, right?
[12:04] <asac> NCommander: icedove ships the file itself. -gnome-support just touches it
[12:04] <asac> NCommander: icedove doesnt need to touch it
[12:04] <asac> just to ship it so its properly registered as a dpkg managed file
[12:05] <asac> NCommander: e.g. icedove will touch it implicitly because it ships that file
[12:05] <NCommander> we do?
[12:06] <NCommander> icedove.install says we don't.
[12:06] <asac> NCommander: most likely done in rules
[12:06] <NCommander> Yup
[12:06] <asac> because there is no source for that file
[12:06] <NCommander> Ok
[12:06] <NCommander> Just making sure
[12:06] <asac> sure
[12:06] <NCommander> asac, I'm going to split the icedove package to create an icedove-data (for all the arch all files)
[12:06] <asac> that was one of the points i mentioned: make sure icedove ships that file ;)
[12:06] <asac> NCommander: err. why?
[12:07] <asac> that is really unneeded compication
[12:07] <NCommander> Kills a lintian warnings. Packages with large amounts of files in /usr/share should split that off
[12:07] <asac> yeah i know. but doesnt make much sense here. i had that in the past and eliminated it
[12:07] <NCommander> Why'd you elimate it?
[12:07] <asac> because it doesnt make sense ;)
[12:08] <asac> its really a lot of work for not much benefit
[12:08] <asac> also _all packages are broken in the archive
[12:08] <asac> e.g. if anything build depends on it it can cause a bunch of pain on architectures that lack behind
[12:08] <asac> not that a big reason for icedove ... but well.
[12:09] <NCommander> Point taken-ish
[12:09] <asac> 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] <asac> that is to have a single partition shared across multiple architectures
[12:09] <asac> but i havent heard of anyone actually using that
[12:09] <asac> NCommander: there are just a few errors ... the rest are warnings
[12:10] <asac> iirc there are warnings about executable icons or something ;)
[12:10] <asac> that should be fixed.
[12:10] <NCommander> Yup, working on that
[12:10] <NCommander> The biggest one that needs to be fixed is that we install a png as icedove's icon
[12:10] <NCommander> Which works fine in GNOME/KDE, but breaks in say Window Maker
[12:10] <asac> NCommander: instead of xpm?
[12:11] <NCommander> yeah
[12:11] <asac> NCommander: i think we should ship both and use a reference without .suffix in .desktop
[12:11] <asac> and the xpm in icons
[12:11] <NCommander> asac, that's easy to fix
[12:11] <NCommander> all we do is drop the xpm in debian/ and then have it installed on the fly
[12:12] <asac> NCommander: if  possible generate the .xpm on the fly during build
[12:12] <NCommander> Oh
[12:12] <NCommander> Not difficult
[12:12] <NCommander> But it means a build-dep on imagemagick
[12:12] <NCommander> and how often do we really change the icon?
[12:12] <asac> NCommander: if possible generate. if thats too much work i dont care about .xpm
[12:12] <asac> at least it can be in the .diff.gz without uuencode business
[12:12] <asac> but well ... if we can generate it even better
[12:12] <NCommander> convert *.png *.xpm :-)
[12:12] <asac> NCommander: it clutters the diff
[12:12] <NCommander> thats the actual command
[12:13] <asac> most likely there is a lot of clutter, but that doesnt mean we should add more ;)
[12:13] <NCommander> I can modify the repack rule to do it on the fly
[12:13] <asac> NCommander: yeah. i think i already do image transformation duing build
[12:13] <asac> convert et al
[12:13] <asac> so just hook it in there
[12:13] <NCommander> Can we upload a new orig.tar.gz for Icedove?
[12:13] <asac> NCommander: if repack is the rule where i do converts atm then yeah.
[12:14] <NCommander> Without a new release?
[12:14] <asac> NCommander: why?
[12:14] <asac> 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] <NCommander> We can do it in the rules
[12:14] <asac> instead of the ogig
[12:15]  * NCommander figures out how to attach this
[12:15] <NCommander> *attack :-)
[12:15] <asac> also mozilla droped support for .xpm so putting that file in the orig doesnt sound right
[12:15] <NCommander> Oh, I see how we can do it
[12:15] <NCommander> I'll just do the conversion during make install
[12:15] <asac> as gecko itself cannot render it ;)
[12:15] <asac> NCommander: urgh
[12:15] <[reed]> It's a horrible format.
[12:16] <NCommander> Well, the debian menu system is a hack
[12:16] <asac> NCommander: please do it in rules
[12:16] <NCommander> asac, no, I mean during the install rule of rules :-)
[12:16] <asac> NCommander: hacks should go to rules ;)
[12:16] <asac> ah ok thas ok then ... do it whereever i did the other converts
[12:16] <asac> unless i dont sdo that anywhere anymore
[12:17] <NCommander> You don't
[12:17] <asac> then just add it wherever you feel its appropriate ;)
[12:17] <asac> let me get that branch ;)
[12:18] <asac> my memory appears to have lost some details at some point :)
[12:20] <NCommander> 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] <asac> NCommander: thats ok. thats whate i referred to when saying i stopped doing that
[12:23] <asac> in the past i had links to /usr/share stuff ... but that was too much work and gave zero benefit
[12:24] <NCommander> So upstream ships with everything in /usr/lib?
[12:24] <asac> NCommander: upstream doesnt ship in /usr at all
[12:24] <asac> NCommander: they ship everything in one directory tree and that tree is  not depending on the install location
[12:25] <NCommander> even in the source packages?
[12:25] <NCommander> r
[12:25] <asac> eh?
[12:26] <NCommander> nm
[12:26] <asac> 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] <NCommander> Ouch
[12:26] <NCommander> I knew Mozilla was bad
[12:26] <NCommander> But I didn't know how bad
[12:26] <NCommander> Next question (yes, I know), what's cdbs-rules for ;-)
[12:28] <[reed]> patches welcome.
[12:28] <asac> NCommander: its because i have added a feature we shoujld eventually send upstream
[12:28] <NCommander> 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] <asac> [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] <asac> s/not unlikely/not likely/
[12:31] <[reed]> ;)
[12:32] <asac> [reed]: the reason is that nobody uses make install :) ... so whenever a special file is added to dist/... it gets forgotten
[12:32] <asac> [reed]: but well. i can live with it as its now ;)
[12:33] <asac> [reed]: but i think tbird doesnt use that mechanism ... but fta can tell more about that.
[12:34] <[reed]> yeah
[12:34] <asac> [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] <asac> 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] <asac> 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] <asac> [reed]: then go to bed you night-owl ;)
[12:35] <asac> _just_ this single day :)
[12:35] <[reed]> hehe
[12:37] <NCommander> asac, woohoo, I think I got the package almost completely lintian clean on both binaries and source
[12:39] <asac> nice ;)
[12:39] <asac> did you do overrides for the all files in /usr/lib?
[12:41] <NCommander> asac, just did a well placed chmod -x
[12:44] <NCommander> asac, added bonus, icedove is now safely binNMUable
[12:51] <asac> k
[12:51] <asac> fixed strict depends?
[12:53] <NCommander> Yup
[12:53] <NCommander> The only lintian warning on the source package now is that a cdbs junk file keeps getting pulled in
[12:57] <asac> NCommander: cdbs junk file?
[12:58] <NCommander> asac, its a bug in CDBS, already reported
[12:58] <NCommander> (a manifest of files it tars just gets left behind)
[12:58] <asac> ok ... so its not us
[12:58] <NCommander> Yeah
[12:58] <NCommander> We just didn't see it in a see of lintian warnings (all gone now :-)!)
[12:58] <NCommander> I'm now looking to see what, if any patches we want to include on this upload
[13:18] <asac> NCommander: look if debian bug 392603 still applies
[13:18] <NCommander> asac, if the patch applies cleanly I'll add it
[13:18] <asac> NCommander: well. lets not just add it ;)
[13:18] <directhex> NCommander, you're smart. what's the right version substitution to use for easy binnmuability?
[13:18] <asac> NCommander: the kbsd can be added if its applying cleanly
[13:19] <directhex> ${binary:Version}, yes?
[13:20] <asac> NCommander: the manpage is ok. but we should ensure that the examples actually work
[13:20] <asac> 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] <NCommander> directhex, yes
[13:21] <NCommander> directhex, if lintian doesn't complain it is usually ok
[13:21] <directhex> it's a while since i ran any lintian tests
[13:21] <asac> NCommander: xprint using sh instead of bash ... well. do we use xprint at all?
[13:22] <NCommander> Not anymore
[13:22] <asac> debian bug 441038 is fixed upstream ... or if not we have a proper patch for it in firefox 2 packages in ubuntu
[13:22] <asac> i am quite sure that debian bug 363815 is too outdated to be of much use now
[13:23] <asac> we should close it or remove the patch tag
[13:23] <NCommander> Don't we have a get-orig-tarball rule?
[13:23]  * NCommander will just close it
[13:24] <asac> for debian bug 499309 we should ask him for "evidence from the news" and if thats the case forward upstream
[13:24] <asac> but not just blindly apply
[13:24] <asac> NCommander: we have repack
[13:24] <asac> i dont think we have get-orig-source
[13:24] <asac> not sure if thats really important to have though
[13:25] <NCommander> No, since we still need to repack
[13:25] <directhex> urgh. W: moon source: not-binnmuable-all-depends-any libmoon-dev -> libmoon0
[13:25] <NCommander> directhex, do >= ${source:Version}
[13:26] <asac> debian bug 363858 is somehow unimportant and appears to be fixed upstream in 3.0a3
[13:26] <directhex> NCommander, is that the right line for a -dev package?
[13:26] <NCommander> directhex, your -dev package is arch: all?
[13:26] <NCommander> and your main package is arch any?
[13:27] <directhex> NCommander, you know, that's a good question. why IS it arch:all?
[13:27] <asac> not sure what is going on with debian bug 476302
[13:27] <directhex> gah, there was literally *nothing* usable in marillat's package, then
[13:27] <NCommander> asac, I know why. Thats just localized insanity. The patch attached fixes it
[13:27]  * NCommander notes armel has some "fun" issues
[13:28] <NCommander> asac, I already put that patch in the included tarball
[13:28] <asac> NCommander: we should look what was applied (if any) in iceape
[13:28] <asac> or iceweasel
[13:28] <asac> or whatever
[13:28] <NCommander> asac, the patch for iceweasel was attached
[13:29] <asac> NCommander: ok we can take it. just ensure that autoreconf patchis properly refreshed
[13:29] <asac> (if i still use that mechanism at all=)
[13:30] <directhex> 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] <NCommander> directhex, if its a C based library, it should have a static library (.a), and a ****load of symlinks
[13:32] <directhex> hm, you're right, there's a missing symlink.
[13:32] <asac> -dev usually isnt all ;)
[13:32] <NCommander> directhex, what are you packaging?
[13:33] <directhex> wait, my mistake. libmoon-dev: /usr/lib/libmoon.so
[13:33] <directhex> NCommander, moonlight.
[13:33] <NCommander> asac, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406849
[13:33] <NCommander> directhex, oh, this is a mono based program?
[13:33] <NCommander> The normal rules *might* not apply
[13:34] <directhex> NCommander, at this moment in time, it's just c
[13:34] <NCommander> directhex, it needs more than that, it needs the full set of soname symlinks
[13:34] <directhex> NCommander, i.e. "1.0 profile" isn't at all monoish, and "2.0 profile" requires mono 2.0 to compile
[13:35] <asac> fta: if you want something to sponsor for intrepid, look at Bug 286225
[13:35] <directhex> libmoon0: /usr/lib/libmoon.so.0.0.0
[13:35] <directhex> libmoon0: /usr/lib/libmoon.so.0
[13:35] <asac> :)
[13:35] <NCommander> asac, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393237 should we slaughter this while we're at it?
[13:35] <NCommander> (I figure a rm -r in postinst)
[13:35] <asac> NCommander: yes. we should remove files that are in dpkg --status of thunderbird, mozilla-thunderbird and icedove and are obsolete
[13:36] <NCommander> ok, how do we do that ;-)
[13:36] <asac> 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] <asac> otherwise keep it as the user has modified it
[13:37] <asac> most likely its too late to migrate them to /etc/icedove anyway
[13:37] <NCommander> eh
[13:37]  * NCommander pushes his branch to Launchpad
[13:49] <asac> NCommander: have to do a few NM things ... let me know hwen everything is up. will look right next there then
[13:49] <NCommander> asac, I'm still doing a few test builds, this can probably wait for post lenny to upload
[13:51] <asac> NCommander: well. lets get the current biuld in. and then get the new build up
[13:51] <asac> in == lenny
[13:51] <NCommander> yup
[13:51] <NCommander> Its still not frozen :-/
[13:53] <directhex> at this rate jaunty will miss mono 2.0, due to lenny freeze
[13:53] <directhex> and maybe killer kilwalla too
[14:21] <james_w> NCommander: http://wiki.debian.org/DpkgConffileHandling might be of interest
[14:23] <asac> yeah i remember that directly parsing stats will cause lintian to complain
[14:50] <asac> saivann: any nack/ack for the ubufox translations?
[14:53] <asac> [reed]: what file .suffix does your cert file for EAP have?
[15:09] <saivann> 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] <asac> saivann: great
[15:20] <asac> saivann: let me know ;)
[15:26] <saivann> asac : Ok :)
[15:30] <saivann> asac : The're ready, rev 146
[15:39] <asac> saivann: is that against upstream branch?
[15:39] <asac> yeah ... seems like (at least the mail suggests it is lp:ubufox)
[15:39] <saivann> asac : Yes, your own branch
[15:40] <saivann> asac : This one https://code.edge.launchpad.net/~asac/ubufox/main
[15:40] <saivann> asac : Let me know if you want me to re-upload the branch, I can do it fast
[15:41] <asac> saivann: what did you do with your email :(
[15:41] <asac> saivann: https://code.edge.launchpad.net/~saivann/ubufox/intrepid_translations
[15:41] <asac> saivann: do you want to recommit that stuff with a good email?
[15:41] <asac> (or dont you care)
[15:41] <asac> ?
[15:42] <saivann> asac : Oh.. oups... my ssh key caused this. Well if you merge the branch, will my email appears anywhere?
[15:43] <asac> saivann: yes it would appear in the nested log
[15:43] <asac> e.g. bzr log  will show the commits as you see them now
[15:43] <asac> also i could just push your branch directly (as i didnt do any additional cahnge)
[15:44] <saivann> asac : Ok, I will recommit, thanks for finding this
[16:23] <saivann> 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] <asac> saivann: committed. can you test one more round from the lp:ubufox branch directly? (rev 142)
[16:58] <asac> so i can bake a package out of it and upload?
[16:59] <saivann> asac : Yes, I do it right now
[17:02] <asac> thx
[17:08] <saivann> 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] <asac> saivann: hmm. even if the -alt is in en-US?
[17:09] <saivann> asac : Yes, see it by yourself : firefox -UILocale gr
[17:10] <saivann> asac : it won't happen if you start firefox with a known locale
[17:15] <saivann> asac : I tried all locales in your branch, everything works correctly
[17:15] <asac> saivann: have you also tested the "restart" notification?
[17:16] <asac> saivann: shoudl appear when sudo touch /var/lib/update-notifier/user.d/firefox-3.0-restart-required
[17:16] <saivann> asac : Oh, let me try it
[17:16] <saivann> asac : works well so far, I will test all locales
[17:24] <RainCT> Hi
[17:25] <saivann> Hi :)
[17:25] <RainCT> Is anyone comming to Mozilla Camp Europe this weekend?
[17:25] <saivann> asac : I found a issue with it-IT locale, I'll update my branch in a few minutes
[17:28] <asac> saivann: are you testing the "restart" thing too?
[17:28] <asac> cool
[17:28] <asac> RainCT: where is that? paris?
[17:28] <RainCT> asac: Barcelona
[17:28] <asac> oh dear. i should have planned that
[17:28] <asac> why i nobody telling me
[17:28] <RainCT> (https://wiki.mozilla.org/EU_MozCamp_2008)
[17:28] <asac> now its too late unfortunately
[17:30] <saivann> 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] <RainCT> Too bad. So no Ubuntu guy is coming? :(
[17:39] <asac> RainCT: are you from barcelona?
[17:39] <asac> saivann: cool
[17:39] <asac> saivann: so which local has no -alt?
[17:39] <asac> (so i can test the issue you reported above)
[17:39] <saivann> asac : it-IT
[17:40] <RainCT> asac: Yep :)
[17:40]  * asac installs language-pack-it
[17:40] <saivann> asac : Ah wait, do you mean no translations at all?
[17:40] <asac> saivann: you said there are problems when there is no -alt translation with the alt thing
[17:42] <saivann> asac : Ok take grc locale (greek) as an example
[17:43] <saivann> asac : Currently, all locales that does not have alt translations simply have un-translated english files in my branch, so this bug can't happen with any locales that we install. However, if you remove the files from one of the translations, you'll be able to reproduce the problem
[17:45] <asac> ok will try with that
[17:45] <saivann> asac : You should also be able to reproduce the problem with a locale that we didn't install (like hr, grc, etc)
[17:45] <asac> saivann: well. testing grc now ;)
[17:45] <saivann> asac : great
[17:46] <asac> saivann: grc doesnt have a translation at all :/
[17:47] <asac> saivann: and hence alt dialog works for me
[17:47] <saivann> asac : Exactly, the normal behavior would be : ubufox fallback in english, but alt is still working, in english
[17:47] <saivann> asac : Really?
[17:47] <asac> saivann: i start firefox like: LANG=grc firefox
[17:48] <asac> saivann: do we have an incomplete translation?
[17:48] <asac> that doesnt have alt, but the "normal" thing?
[17:48] <saivann> asac : Almost 50% of the translations are incomplete, these locales does have *alt* files un-translated, still in english
[17:48] <asac> seems like all we have are complete
[17:49] <asac> saivann: really?
[17:49] <asac> saivann: http://pastebin.com/f5e3fb450
[17:49] <asac> thats what i have
[17:49] <saivann> asac : Unfortunately, yes, we have a good amount of new locales, but a lot of already existing locales were not updated
[17:50] <asac> saivann: why are those files there for all i have in lp:ubufox then?
[17:50] <asac> saivann: the above are properites ... this is .dtd http://pastebin.com/f3463cae
[17:50] <saivann> asac : Because these files are still in english (a copy of the ones in en-US)
[17:52] <asac> saivann: ok. that wouldnt have been needed
[17:52] <asac> i splitted the files in such a way that not having one shouldnt break
[17:52] <asac> anyway. i cannot reproduce the bug now ;)
[17:53] <saivann> can you try to remove ubufox-restart.properties, ubufox-alt.properties and ubufox-alt.dtd for a locale in your ubufox jar file for a specific locale to see if you can reproduce the problem?
[17:54] <asac> saivann: ah. so you say it was broken without those and now its not broken becaues you copied them?
[17:54] <asac> ok that makes more sense ... let me check
[17:54] <saivann> asac : Yes, exactly
[17:58] <saivann> asac : I tried it with my current env. locale here (fr) and alt and restart functionnalies stop to work if translation files does not exist. The rest of ubufox is properly translated.
[17:59] <saivann> asac : Revision 143 of my branch https://code.launchpad.net/~saivann/ubufox/intrepid_translations fixes "restart" problem with "it" locale.
[18:04] <asac> saivann: so which "first" tier locales have missing translations? fr? I can surely find someone for that. what other?
[18:06] <saivann> asac : No, fr is ok, give me 2 minutes
[18:09] <saivann> asac : cs-CZ el-GR lt-LT pl-PL pt-BR ru-RU sl-SL uk
[18:10] <saivann> asac : These locales have un-translated ubufox-alt.dtd ubufox-alt.properties and ubufox-restart.properties files
[18:10] <RainCT> asac: have you already got the Catalan translation?
[18:35] <asac> RainCT: ask saivann ... he incorporated all the contributions
[18:35] <saivann> RainCT : About ubufox locales?
[18:36] <saivann> asac : Don't forget  to merge rev 143 of my branch https://code.launchpad.net/~saivann/ubufox/intrepid_translations to fix it locales
[18:36] <asac> saivann: i think i already did that ... didnt i?
[18:37] <saivann> asac : you merged rev 142, before you show me how to verify "restart" thing
[18:37] <asac> yeah
[18:37] <asac> ok cool
[18:38] <saivann> RainCT : ubufox does have a complete ca translation
[18:38] <saivann> asac : Thanks :)
[18:39] <asac> saivann: done
[18:39] <asac> rev144
[18:39] <asac> ;)
[18:39] <saivann> asac : rock :)
[18:40] <RainCT> saivann: OK, great. I saw it on the l10n-ca ML but wasn't sure if it was alredy sent to you :)
[18:41] <saivann> asac : An entry will still be needed in debian/changelog about these changes, with a LP field to close bug 283517 in your branch, when it will be ready for repositories
[18:41] <saivann> RainCT : Thanks for asking :)
[19:09] <fta> http://ubuntuforums.org/showthread.php?t=950640
[19:09] <fta> comment #4+
[19:26] <nxvl> asac: hi!
[19:26] <nxvl> asac: i just packaged firefox using the new branch, can you please take a look at it
[19:26] <nxvl> asac: it's on my ppa: https://edge.launchpad.net/~nvalcarcel/+archive
[20:09] <armin76> nxvl: it failed to build :P
[20:11] <nxvl> yeah i just saw that
[20:11] <nxvl> i forgot to bzr add the .desktop
[21:41] <RainCT> Re 285321 and bug 286225, the debdiff adds a dependency on firefox. One for abrowser isn't needed, or? (as abrowser provides firefox, and further abrowser depends on firefox-3.0)
[22:01] <NCommander> asac, E: icedove: menu-icon-too-big /usr/share/pixmaps/icedove.xpm: 48x48 > 32x32
[22:01] <NCommander> We can't win
[22:03] <fta> most of /usr/share/pixmaps/ is far bigger
[22:04] <fta> the whole gnome is 48x48
[22:04] <fta> that what i hate about lintian, it forces you to do unnecessary changes
[22:04] <fta> with no benefit
[22:08] <sebner> fta: therefore lintian overrides exist ^^
[22:10] <fta> $ file /usr/share/pixmaps/* | grep -c '48 x 48'
[22:10] <fta> 90
[22:13] <fta> http://paste.ubuntu.com/60258/ obviously, noone is respecting that 32x32 rule
[22:20] <RainCT> fta: XPM's are 32x32
[22:20] <RainCT> fta: PNG's 48x48
[22:20] <RainCT> ang GNOME is weird and has extra sizes :P
[22:21] <RainCT> and it's not unnecesary at all as XPM's are supposed to be for Debian's menu :P
[22:27] <fta> yeah, but i still hate it ;)
[22:28] <fta> asac, are all the stuff produced by MacSlow used in some way in ubuntu?
[22:42] <fta> http://www.techeblog.com/index.php/tech-gadget/iphone-robot
[22:50] <asac> fta: no idea ;)
[22:50] <asac> what does he do?
[22:51] <fta> asac, http://macslow.thepimp.net/
[22:52] <asac> fta: not much content on there for me
[22:52] <asac> 26th april  and then 20th october
[22:52] <fta> look the 1st video
[22:52] <fta> well, it used to be busier, but it stopped
[22:54] <fta> asac, so you pushed another ff3... still no ff-2 dummy package ? and the amd64 branding ?
[22:58] <fta> http://ubuntuforums.org/showthread.php?t=953320
[22:59] <asac> i dont know anything about amd64
[22:59] <asac> i uploaded a single bug fix
[23:00] <asac> the dummy package is a glitch
[23:00] <asac> too bad
[23:00] <fta> the abrowser branding used on amd64 ff-branding
[23:00] <fta> bug 279083
[23:01] <fta> hm, you said fixed
[23:10] <asac> fta: why would a branding issue be arch dependent?
[23:11] <asac> fta: well. in that bug report nobody reported it as being "abrowser"
[23:13] <asac> i actually assumed you had fixed that in 3.0.3 because i couldnt reproduce it with my firefox
[23:14] <asac> so its really just abrowser on amd64. i remember that you showed me that at some point now that you say that
[23:14] <asac> but i still dont get whats the problem there
[23:15] <asac> fta: did you rename the firefox.png?
[23:15] <asac> hmm
[23:15] <asac> or was that me
[23:15] <asac> the applet starter was supposed to keep an icon
[23:16] <asac> for the .desktop i mean
[23:22] <asac> ok its the the rename from firefox.desktop to abrowser.desktop
[23:22] <fta> i compared the two remember ? http://paste.ubuntu.com/56044/
[23:22] <asac> i remember that. but that doesnt tell me what it is and why it is different
[23:23] <fta> i grepped everywhere for the green version and it was the abrowser version
[23:35] <asac> fta: http://paste.ubuntu.com/60282/
[23:37] <asac> fta: http://paste.ubuntu.com/60284/
[23:37] <asac> however, note that there is still a difference from amd to x86
[23:37] <asac> but the user agent appears to be shipped in a separate file now
[23:38] <asac> and that was you who fixed it ;)
[23:38] <asac> e.g. adding ubuntu-abrowser.js.tmpl
[23:38] <fta> i'm i think i did that, right?
[23:38] <fta> -i'm
[23:38] <asac> yeah
[23:38] <asac> but it fixed that bug
[23:38] <asac> you really confused me now ;)
[23:39] <asac> still a bit of a mystery that the files look so different
[23:39] <fta> but the pref file is still different, while it shouldn't be
[23:39] <asac> but i guess it has something to do with binary-indep and binary-arch
[23:39] <asac> most likely we run someting in -indep which isnt run on amd64
[23:40] <asac> fta: right. but in this case it doesnt hurt at least ;=
[23:40] <asac> not saying that it should be ignored
[23:40] <fta> the start page has no locales
[23:40] <asac> but i am quite sure that it has something to do with either a) indep/arch in rules or b) official/unofficial mozilla architecture
[23:40] <fta> and the moz2 codes are used in search engines
[23:40] <asac> yeah. moz2 codes are overriden by us (i hope)
[23:41] <asac> so tnot that important
[23:41] <asac> and homepage is done in ubufox for default install .. of course its not right for amd64 and without ubufox
[23:41] <asac> but most likely its what mozilla build system does on non-official release archs
[23:41] <asac> we should look into that
[23:42] <asac> most likely we have to force that its an OFFICIAL build (or force that its UNOFFICIAL if you want to appraoch this from other side)
[23:42] <fta> comparing buidlogs didn't give me any clue
[23:43] <[reed]> why override the mozilla codes? :)
[23:43] <fta> not my change