#ubuntu-mozillateam 2007-10-03 * Starting logfile irclogs/ubuntu-mozillateam.log <bluekuja> heya asac <bluekuja> news? <Mark7> UBOTU!!!!!!!!!!!!!!!!!!! <Mark7> Talk to me <Mark7> I need help :( <Mark7> Just tell me how to edit the Mozilla plug ins file <Mark7> That's all I want <Mark7> That's all you have to do <Mark7> Is this stupid thing even working? <Mark7> JUST TELL ME ALREADY <Mark7> JESUS CHRST <Mark7> TELL ME TELL ME TELL ME <Mark7> Fine, I'll fuck up my system on my own then <bluekuja> asac: you there? <cwong1> asac: hi there <Ubulette> hi <gnomefreak> he seemed happy :) <Ubulette> gnomefreak, ? <gnomefreak> mark7 <gnomefreak> 09:45 < Mark7 > TELL ME TELL ME TELL ME <gnomefreak> 09:45 < Mark7 > Fine, I'll fuck up my system on my own then <Ubulette> yep, read that. <gnomefreak> i did <Ubulette> I meant, I've read that <gnomefreak> just shy of banning him but he seems like he was putting too much thought into what the bot does <gnomefreak> oh ok <Ubulette> editing plugin file is a crazy idea for sure * gnomefreak hates engliish for that reaason but i havetn spoken italian since i was like 5-6 <gnomefreak> Ubulette: its not a smart one at all <Ubulette> gnomefreak, you're italian ? <gnomefreak> what would you need to edit? its the conf files that needs to be edited for the plugin <gnomefreak> Ubulette: i was born in US but my mother and father are italian <asac> cwong1: i will bake release tomorrow <asac> cwong1: today is holiday here <gnomefreak> me and sister grew up speaking italian once my mother left it was english <Ubulette> interesting. I like that: http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ <cwong1> asac: sounds good... tx <Ubulette> gnomefreak, so you're a us citizen, right ? no need for green card <gnomefreak> right <Ubulette> :) <Ubulette> asac, will you bake a8 too ? ;) <asac> yes <asac> Ubulette: i committed to do that in my weekly report ;) <Ubulette> good to know <bluekuja> heya asac <asac> bluekuja: 15 minutes :) <asac> then i will be with you <bluekuja> ^^ oki :) <bluekuja> asac: ok cool, I'm leaving in around 30 min <bluekuja> I'm a bit tired today <bluekuja> ping me when ready <Ubulette> asac, I'll push ff3 mt3 to ppa before I fork the branch (non dev for you) and go on with .dev <Ubulette> done <asac> Ubulette: ok thanks <asac> bluekuja: is the diff of Makefile.am intended? <asac> e.g. from .debian to .upstream <bluekuja> asac: mmmm...nope <bluekuja> asac: wait <bluekuja> asac: yes, I had to re-run automake <bluekuja> for a change <asac> yes <bluekuja> on makefile.in <bluekuja> so it's different between .debian and .upstream <asac> bluekuja: how did you do <asac> revno: 10 <asac> committer: Andrea Veri <andrea@nightsong> <asac> branch nick: debian.source <asac> timestamp: Thu 2007-09-27 20:41:33 +0200 <asac> message: New upstream release --> 0.2.3 <asac> did you use bzr merge ? <bluekuja> asac: no, I took the same files and pushed to both branches <asac> bluekuja: thats not the idea <asac> the idea is you apply it to upstream ... then merge that to debian <asac> why does upstream branch need: "resyincing files with debian.source branch for the new upstream release" ? <asac> bluekuja: if you use merge you won't need "revno: 11" <asac> deleted diff_extdoc_DATA = \ from Makefile.am to prevent incorrect doc files to be installed without adding them into debian/docs --> <asac> already done in revision n.3 but needed for the new upstream release files <asac> the whole idea of having upstream/debian branch is to not having to redo every change on every new release, but using bzr merge .. resolving conflicts and going on then <bluekuja> asac: yeah, you're right. I was following a strange concept of merging <bluekuja> I guess <bluekuja> so I had to re-do that change <bluekuja> after the new upstream release <asac> ok what i did now is uncommit all (top is revno 9) <asac> then run aclocal <asac> automake <asac> autoconf <gnomefreak> @schedule new_york <ubotu> Schedule for America/New_York: 05 Oct 16:00: MOTU | 06 Oct 13:00: Xubuntu Developers | 10 Oct 08:00: Forum Council | 10 Oct 12:00: QA Team | 11 Oct 11:00: Community Development Team | 16 Oct 12:00: Kernel Team <asac> then bzr resolved <gnomefreak> hmmmmm qa team meeting? <asac> n$ bzr resolved <asac> WARNING: the 'deb822' top-level module is *DEPRECATED*, please use 'debian_bundle.deb822' <asac> Unable to load plugin 'bzr-svn' from '/home/asac/.bazaar/plugins': It is not a valid python module name. <asac> All conflicts resolved. <asac> then commit bzr commit -m "merge new upstream release 0.2.3" <bluekuja> asac: great, I'll have to clean everything up <bluekuja> then <panosru> hi, i have downloaded firefox 32 and install but mplayer does not work please can someone help me with this issue? <bluekuja> asac: I guess running bzr bd --merge will fix that too <asac> bluekuja: he? <bluekuja> so the package actually dont have any problem <asac> no <asac> elll .. the branches should be right imo <bluekuja> I was just wondering if the branches got corrupted for that <bluekuja> but I ended up everything is ok atm <asac> bluekuja: ok ... at least clean up the uptream branch then <bluekuja> I will <asac> if you want to merge it on debian is your choice ... i would do it, just to prevent pain in future ... using bzr merge is safe and you hardly forget any diff you previously applied <bluekuja> yeah, thanks for the hint, gonna follow your istructions next time to prevent any confusion <Ubulette> asac, do you plan to keep all ppa stuff in changelog or just collapse ? <asac> i plan to keep <asac> just include the changelog entries in upload changes <Ubulette> that's what i call collapse <bluekuja> asac: if the package is ok, I leave and I move to my bed <bluekuja> :D <gnomefreak> Preconfiguring packages ... <gnomefreak> dpkg: syntax error: unknown group `Debian-exim' in statoverride file <gnomefreak> E: Sub-process /usr/bin/dpkg returned an error code (2) <gnomefreak> anyone have a clue where to look for that <Ubulette> /var/lib/dpkg/statoverride ? <Ubulette> that's an ugly debian stuff <Ubulette> I still have that on some servers <Ubulette> $ grep exim /var/lib/dpkg/statoverride <Ubulette> root Debian-exim 0640 /etc/exim4/passwd.client <gnomefreak> root Debian-exim 0640 /etc/exim4/passwd.client <gnomefreak> thats all thats in it <Ubulette> $ grep Debian-exim /etc/group <Ubulette> Debian-exim:x:102: <gnomefreak> i get nothing on grep <gnomefreak> this is in a chroot <Ubulette> so that's the reason <Ubulette> maybe ubuntu changed the group but forgot to update /var/lib/dpkg/statoverride <gnomefreak> wtf would dpkg need -exim for? <Ubulette> no, it's an exim stuff <gnomefreak> -exim is mail <gnomefreak> atleast im fairly sure it is <Ubulette> exim is the default mta on debian <Ubulette> (smtp server) <gnomefreak> ah <gnomefreak> so adding that group might help or should i ping mvo on it <gnomefreak> oh wait <gnomefreak> theres upgrades i missed for dpkg <asac> bluekuja: i pushed branches to http://code.launchpad.net/diff-ext <asac> bluekuja: please test them and let me know if should use them <gnomefreak> !sru <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse. <bluekuja> asac: yeah, we can use the one you created too <asac> bluekuja: pleast test and if they look good overwrite yours ... i will upload then <bluekuja> asac: I branch them out <bluekuja> and I check them <bluekuja> just a mom <asac> right <Ubulette_> strange, my ppa has been rejected <Ubulette_> MD5 sum of uploaded file does not match existing file in archive <Ubulette_> Files specified in DSC are broken or missing, skipping package unpack <Ubulette_> verification. <Ubulette_> I did /w -S -si as it's mt3 <bluekuja> BEGIN not safe after errors--compilation aborted at ../intltool-merge line 252. <bluekuja> <bluekuja> asac: it FTBFS <gnomefreak> !info flashplugin-nonfree feisty <ubotu> flashplugin-nonfree: Adobe Flash Player plugin installer. In component multiverse, is optional. Version 156.14.161.142.0ubuntu1~7.04.1 (feisty), package size 15 kB, installed size 108 kB (Only available for i386) <bluekuja> asac: some changes I made on the source are now on upstream too, that's why I deleted the whole source <bluekuja> and replaced with fresh new files <asac> bluekuja: why did you modify upstream source? <bluekuja> asac: did not modify it, just removed DOC stuff <bluekuja> to prevent docs installation outside debian/docs <asac> thats still in now <bluekuja> it's not in the makefile <bluekuja> rev.11 fixed that <asac> which revision fixed it before <asac> that change should still be there <asac> bluekuja: i just diffed my .debian with my .upstream <asac> and it still contain the "deleted docs" diff <bluekuja> asac: does it FTBFS there too? <asac> yes, because of ukm.po missing <bluekuja> should be uk.po <bluekuja> asac: new upstream release introduced it too <gnomefreak> does anyone have a working dapper install? <asac> well uk.po doesn't exist ... as well as ukm.po <gnomefreak> or a broken one <asac> bluekuja: yes, but you failed to add it to upstream tree then <asac> upgrading upstream tree is always the same: <Ubulette_> gnomefreak, not me. I was still a happy debian user back then <asac> rm -rf * <bluekuja> asac: why my branch works fine? <gnomefreak> Ubulette_: this error doesnt seem fixable at all <bluekuja> I'm trying to understand what's happening there <gnomefreak> and its starting to piss me off <asac> bluekuja: look in your branch ... is there a uk.po ... and if so, why isn't it in revno 2 <Ubulette_> gnomefreak, exim ? <asac> (upstream branch) <gnomefreak> yes <bluekuja> asac: is not there, maybe is generated during build? <asac> bluekuja: no <Ubulette_> gnomefreak, just remove that line from statoverride <gnomefreak> Ubulette_: thats it? <asac> bluekuja: its not even in your .debian branch <Ubulette_> try <bluekuja> asac: I dont understand why the build went fine here then <asac> bluekuja: because you probably fiddled with it until it worked :) <asac> i suspect that you did something wierd in upstream branch revno 3 <asac> hmm you drop ua.po? <bluekuja> asac: yea <bluekuja> was dropped on .debian <asac> why? <bluekuja> dropped by upstream <bluekuja> or well <bluekuja> renamed <bluekuja> to uk <asac> bluekuja: then it should alreyd be gone in rev 2 <bluekuja> uk was ua <bluekuja> *ua was ok <bluekuja> *uk <bluekuja> damn <asac> let me get the upstream tarball ... looks too suspicious ;) <bluekuja> hehe <bluekuja> better <asac> 0.2.4 is out <bluekuja> really? <gnomefreak> fucking dapkg <bluekuja> a new release is out <asac> bluekuja: i can't find diff-ext 0.2.x at all ... only gdiff-ext <bluekuja> asac: that's it <asac> ok <asac> i have 0.2.3 downloaded <bluekuja> they call it gdiff <bluekuja> but it's diff-ext in fact <bluekuja> ;) <gnomefreak> Ubulette: removing it gives a differnet error just stating its empty and still fails <gnomefreak> i cant image all dapper users have this issue <asac> bluekuja: i redo your upstream branch now ... starting from revision 1 <bluekuja> perfect <asac> $ rm -r * <asac> $ cp -r /tmp/diff-ext-0.2.3/* . <asac> bzr add <asac> added po/uk.po <asac> now starting at debian branch revision 9 <asac> $ bzr merge ../diff-ext.upstream <asac> $ aclocal; automake; autoconf <asac> $ bzr resolved <asac> All conflicts resolved. <asac> $ bzr commit -m "merge upstream 0.2.3 release" <asac> $ cp ../diff-ext.debian.blue/debian/changelog debian/ <asac> asac@hector:~/ubuntu_motu/bluekuja/diff-ext.debian$ bzr commit -m "documenting 0.2.3-1 unstable upload in debian/changelog" debian/changelog <bluekuja> pushed? <bluekuja> asac: ^^ <asac> nope it has some other issue with merging intldocs now <bluekuja> damn <asac> LC_ALL=C ../intltool-merge -d -u -c ../po/.intltool-merge-cache ../po diff-ext.desktop.in diff-ext.desktop <asac> Possible unintended interpolation of @INTLTOOL_ICONV in string at ../intltool-merge line 94. <asac> Global symbol "@INTLTOOL_ICONV" requires explicit package name at ../intltool-merge line 94. <bluekuja> asac: yeah <asac> BEGIN not safe after errors--compilation aborted at ../intltool-merge line 252. <bluekuja> the FTBFS i get here <asac> when do you get that? <bluekuja> with building current branches (the one you created) <bluekuja> the one I was working on, builds fine <bluekuja> and are correct <bluekuja> asac: did you test-build them too? <asac> strange stuff <bluekuja> maybe ghosts -.- <asac> no, because they are definitly wrong :) ... you don't have uk.po for instance <asac> clean upstream tarball builds <asac> so its in the diff ... or maybe i used wrong automake version to recreate et al <bluekuja> I'm building them again <bluekuja> and see what happens to uk.po <bluekuja> asac: it builds fine without uk.po too <bluekuja> omg <bluekuja> asac: can you add it manually from my branches <bluekuja> and everything should be ok <bluekuja> then <asac> ok <asac> no <bluekuja> asac: or grab debian dir only <bluekuja> and push it inside upstream source <bluekuja> and that's all <bluekuja> I'll clean up branches soon <bluekuja> maybe I'll overwrite everything <bluekuja> and start again <bluekuja> to prevent any error for the future releases et all <asac> it was just one run of intltoolize --force that was missing <asac> pushing good branches now <bluekuja> great! <asac> look at bzr log to see what to run after bzr merge <asac> ok both are updated <asac> please test if they are good <bluekuja> branching <bluekuja> bzr: ERROR: [Errno 2] No such file or directory: '../build-area/builddeb-IpXt6b/export/intltool-extract.in' <bluekuja> <bluekuja> asac: that's what I get <asac> you need upstream and debian <asac> at least right clicking on files doesn't crash nautilus anymore :) <bluekuja> lol <asac> you need to re-branch ... i did overwrite <bluekuja> maybe was not yet updated <bluekuja> ^^ <bluekuja> asac: as tarball? <asac> log at revision 10 ... comment in new pushed branch is <asac> merge 0.2.3 upstream release and update auto files by: <asac> # aclocal; automake; autconf; intltoolize --force <asac> if you have that ... it should be right <asac> i build like: <asac> bzr bd --merge --export-upstream=../diff-ext.upstream/ . <bluekuja> asac: still getting <bluekuja> bzr: ERROR: [Errno 2] No such file or directory: '../build-area/builddeb-pBqNev/export/intltool-extract.in' <bluekuja> <asac> bluekuja: did you pull my upstream branch as well? <bluekuja> yep <bluekuja> revno: 2 <bluekuja> committer: Alexander Sack <acolon@example.com> <bluekuja> branch nick: diff-ext.upstream <bluekuja> timestamp: Wed 2007-10-03 22:43:14 +0200 <bluekuja> message: <bluekuja> upstream release 0.2.3 <bluekuja> <bluekuja> that's my upstream branch <asac> thats apparently not during build <asac> but during builddeb prepareation <bluekuja> yep <asac> its definitly a problem on your side then :) <asac> try to clean up <asac> remove the stuff in build-area <Ubulette> asac, gnomefreak : i've got md5 issues with ppa caused by mozclient. we fetched sources independently but even if the files are the same, the tarball is not, and could not be, user/group/timestamp etc. so I just re-dled orig from ppa, redid -S -si and dput. fixed. <bluekuja> asac: I build it without bzr bd <asac> remove existing tarballs <asac> bluekuja: well how do you do it then? <asac> bluekuja: you don't have a good tarball then <asac> or something <bluekuja> asac: mmm...I have no tarballs atm <gnomefreak> Ubulette: there shouldnt be any md5sum errors in mt PPA last i knew <bluekuja> as far as I use export-upstream <asac> try the command above <asac> in my debian branch <Ubulette> gnomefreak, there are <Ubulette> Rejected: <Ubulette> MD5 sum of uploaded file does not match existing file in archive <Ubulette> Files specified in DSC are broken or missing, skipping package unpack <Ubulette> verification. <asac> bzr bd --merge --export-upstream=../diff-ext.upstream/ . <bluekuja> asac: that's what I used <asac> bluekuja: why do you say 2 minutes ago: <asac> 23:11 < bluekuja> asac: I build it without bzr bd <asac> ?? <gnomefreak> Ubulette: whos upload, the md5sum error should be prompted at time of upload <gnomefreak> if not than i would look to bug in PPA <bluekuja> asac: I mean, now I will do it <asac> ah <asac> bluekuja: just dpkg-buildpackage -rfakeroot -b works as well directly in debian branch for me <gnomefreak> dput will give you the error if it passes than when you go to download it and gives you md5 something was wrong somewhere <gnomefreak> most likely during buildd process if i had to take wild guess <Ubulette> no, it was not md5 error during upload but during check with the content of the ppa. as it was mt3, orig was already in. -sa or -si doesn't matter here as it's not .changes that is faulty but .dsc <asac> Ubulette: you have to bump upstream version if you change tarball <bluekuja> asac: built <bluekuja> asac: built fine, now watching file destinations <Ubulette> asac, fortunately no. <gnomefreak> Ubulette: but when you dput -f ppa-mt file*_source.changes it will give you md5sum error if the .dsc doesnt match the orig. <gnomefreak> if the dsc and orig differ <Ubulette> gnomefreak, everything was clean on my side <Ubulette> no error at all <gnomefreak> Ubulette: what package is this <bluekuja> asac: problem is we have docs installed in a wrong dir, also they are zero-byte files <Ubulette> gnomefreak, it's just that ppa had a different tarball, the behavior looks sane to me <gnomefreak> Ubulette: remember when i got it (it was during dput) and i fixed that that night <Ubulette> dput was fine here <bluekuja> asac: I'm leaving now, the only thing that needs to be done is deleting doc stuff in the makefile as I did <bluekuja> asac: and that's ready for upload <gnomefreak> Ubulette: were you trying to upload after building with -S -sa or -si <gnomefreak> hint -si doesnt work <asac> bluekuja: which file? <asac> bluekuja: the doc stuff is deleted <asac> take a look <gnomefreak> for some strange fucking reason you havet o replace the orig every upload <bluekuja> asac: the final .deb there doesnt have docs installed in a wrong position? <asac> bluekuja: give me an example <asac> bluekuja: i don't see any bad docs ... but maybe i am just too blind <Ubulette> gnomefreak, tried both. 1st with -S -si => rejected, then -S -sa => rejected same reason, then with orig from ppa and -S -si => accepted <bluekuja> usr/share/doc/diff-ext/README <bluekuja> usr/share/doc/diff-ext/COPYING <bluekuja> usr/share/doc/diff-ext/AUTHORS <bluekuja> W: diff-ext: extra-license-file usr/share/doc/diff-ext/COPYING <bluekuja> W: diff-ext: package-contains-upstream-install-documentation usr/share/doc/diff-ext/INSTALL.gz <bluekuja> W: diff-ext: zero-byte-file-in-doc-directory usr/share/doc/diff-ext/README <bluekuja> W: diff-ext: zero-byte-file-in-doc-directory usr/share/doc/diff-ext/TODO <bluekuja> <gnomefreak> Ubulette: -sa should work if you used right orig. or unless something else happeened <asac> http://paste.ubuntu.com/592/ <asac> bluekuja: thats what is in the package my branch produced <asac> bluekuja: i think its fine then <bluekuja> asac: that's a perfect layout <bluekuja> that's what I wanted to see here locally <asac> bluekuja: ok then you looked at the wrong package :) <asac> strange <asac> maybe try a gain tomorrow <gnomefreak> -S -si doesnt work remember i tried that the night i worked late to get xul and freinds upoaded to PPA, rebuilding after grabbing same tarball it worked fine. not sure why i had to regrab tarball but i did <asac> will upload that way now <bluekuja> asac: great! having a critical bug fixed is alwais nice to hear <gnomefreak> gonna have to assume its PPA issue TBH <bluekuja> asac: anyway I guess something is going bad on my local branches <bluekuja> asac: maybe I took the wrong package <Ubulette> gnomefreak, according to the email i've got, the check is against already existing ppa files so I don't get why you think it's bad. I think it was the correct behavior; i'm glad it rejected me twice <bluekuja> asac: maybe I keep doing a small error, who knows, I'm just tired atm ehhe <asac> bluekuja: yeah right <bluekuja> asac: :) <bluekuja> asac: going to sleep now <bluekuja> cu tomorrow and thanks! <bluekuja> cya all <gnomefreak> Ubulette: you were able to upload mismatched md5sums? <gnomefreak> that is bad <asac> bluekuja: nicht <asac> night <asac> ;) <bluekuja> :) <Ubulette> no. I've checked my md5, they were correct <asac> Ubulette: the archive will complain ... not dput <Ubulette> asac, correct <gnomefreak> Ubulette: you checked them they were correct but you uploaded than they were no longer correct <Ubulette> no <Ubulette> ******** different tarball ********* <gnomefreak> asac: dput will as it did for me see logs of the night i was here working with it <Ubulette> same name + different content => different md5 => reject <gnomefreak> right <gnomefreak> ok so dsc had nothing to do with it <Ubulette> that's it <gnomefreak> the tarballs were differnet <gnomefreak> if the dsc doesnt match tarball dput will fail <gnomefreak> but since the 2 tars were differnet archive complained <Ubulette> orig md5 is in dsc, not in .changes <asac> gnomefreak: it will fail if files don't match .changes md5sums <gnomefreak> Ubulette: you build package your dsc and your orig are differnet dput will fail <gnomefreak> Ubulette: everything that you are explaining is on server side <gnomefreak> not localy <Ubulette> locally, I was all fine <Ubulette> just working with a different tarball <gnomefreak> right hence the reason the upload went <gnomefreak> but server side it was mismatched to what was there im assuming so dput wouldnt know about it but server would <Ubulette> right <Ubulette> you're back to my 1st line :) <gnomefreak> i thought you meant your local dsc was diffent that your local tarball <Ubulette> no * gnomefreak wondered why dput let you upload <Ubulette> so next time we dput a mt > 1, let's remember that :) <Ubulette> no problem for me, upload is fast is fast and retry is harmless <gnomefreak> Ubulette: why didnt you use the tarball on ppa to begin with? if its a version change tarball than you wouldnt but normally best idea if only mt* change to use same tar <Ubulette> I have the same tarball since the beginning of a8. you pushed 1st with your own <Ubulette> remember ? <Ubulette> :) <gnomefreak> but even than you have to use -sa or md5sum will fail <gnomefreak> Ubulette: yes and you are just now getting the error? <asac> so ppa orig is now messed up? <asac> fo a8? <Ubulette> no <gnomefreak> asac: dont know <Ubulette> it's fine <gnomefreak> i didnt touch ff <asac> ok :) <asac> so what is this discussion about? <gnomefreak> Ubulette: if my upload failed i would have gotten a email within a day <gnomefreak> and i havent recieved one <Ubulette> basically, just one of us should run mozclient, then share the tarball <gnomefreak> Ubulette: thats what was done <gnomefreak> i have been using tarball on PPA except in some cases like webrunner and kaze <Ubulette> or we could do separately until the 1st push to ppa, then dl tarball from ppa and work from it <gnomefreak> and remember thats all i worked on last <Ubulette> build started 5 min ago for my arches <asac> Ubulette: we could also push full sources to branches ;) <Ubulette> s/my/both/ <gnomefreak> so im failing to see how mine caused an issue <asac> but in the end we need to share tarballs ... i agree <Ubulette> asac, gasp, too big. <Ubulette> (in bzr) <asac> i always thought that first upload of upstream version to ppa would dictate the orig for any debian revision build ontop of that <Ubulette> asac, it does <gnomefreak> why would you change tarballs since its nothing in source that changed? (instead of using same tarball) <asac> Ubulette: yes technically it does ... question is if we need a procedural change <asac> or maybe extend mozclient to download a tarball from ppa if there is already one <Ubulette> hmm, good idea <Ubulette> i like that <gnomefreak> can it be done without conflicting with say another version? <asac> right ... we could even extend the clean rule to update an orig in case there is a difference <Ubulette> problem remains that until the 1st push, there's nothing in ppa to dl <gnomefreak> like firefox-orig will it check PPA than if not there make one? <asac> we would need to check the md5sum of the tarball on local disc and download Packages from ppa i guess <asac> Ubulette: right ... but we can expect people to just use mozclient to create tarball imo <asac> gnomefreak: yes <asac> Ubulette: in the long run i would like to rename mozclient and make a mozillateam-dev-tools out of it <asac> and upload that to hardy <gnomefreak> Ubulette: what package is this anyway? <Ubulette> ff3 <gnomefreak> well you couldnt use same tarball for that since renae <gnomefreak> rename <Ubulette> ? <gnomefreak> so even using mozclient to do that you would still need to make tarball instead of grab it off PPA <asac> gnomefreak: until first upload <gnomefreak> assuming noone uploaded one since name change <Ubulette> asac, I was thinking of something like that too. but atm, i'm not happy with tags <gnomefreak> asac: right but i mean for the issue about md5sums <Ubulette> rename ? ff3 hasn't been renamed between mt2 and mt3 <gnomefreak> how will they match if they were differnt named tarballs <Ubulette> no, same name <gnomefreak> Ubulette: what is ffox 3 called now (the tarball) <Ubulette> firefox-3.0_3.0~alpha8.orig.tar.gz <gnomefreak> that wasnt uploaded to PPA until you did it or did asac also upload that name to PPA <gnomefreak> as it was firefox-dev iirc <Ubulette> I just did mt3, not 1-2 <gnomefreak> or just cvs date <Ubulette> the branch is called firefox-3.0.dev <gnomefreak> firefox-3.0_3.0 wasnt uploaded ever to PPA afaik <asac> Ubulette: yes, still time to sort htings out <Ubulette> asac, we have 6 months to figure out ;) <gnomefreak> ah asac did upload firefox-3.0 - 3.0~alpha8-0ubuntu1~mt1 and mt2 <gnomefreak> Ubulette: last i knew they werent uploaded <gnomefreak> firefox-trunk is what i was thinking of <Ubulette> gnomefreak, read changelog or bzr log :) even if asac always complains about me, I try my best to keep it in shape and complete <gnomefreak> so what i was referring to firefox-trunk is on PPA you upload fireox-3.0-3.0 you would have to start with clean tarball (i didnt know asac had uploaded) <Ubulette> gnomefreak, we did that <gnomefreak> Ubulette: i dont have ff3 bzr branch as i havent needed it since reinstall <gnomefreak> i dont get emails from PPA unless my name is used on changelog (as with everyone) <Ubulette> mails emails from ppa should go to ppa owner, not package maintainer <Ubulette> s/mails/maybe/ <Ubulette> (god, I'm tired) <gnomefreak> Ubulette: they go to uplaoder and changelog entry <gnomefreak> thats why i got yelled at for building e17 <Ubulette> i remember a bug against ppa for that <gnomefreak> lol there are a bunch of them :) <Ubulette> btw, ff3 is now a9+cvs so minefield is back :) <gnomefreak> shit <Ubulette> asac, please check the gp branding, i haven't spent time on that since i'm running mostly daily minefield <Ubulette> by gp, I mean plain a8 <Ubulette> gnomefreak, why ? <gnomefreak> Ubulette: no nothing i was testing something and i thught it passed but rereading it it failed <Ubulette> asac, did you read my comment about google-gears this morning ? <gnomefreak> asac: if package as ~dapper1 what would the next version be if going for ~proposed but they say not to use ~proposed1 would i use ~dapper2 <asac> Ubulette: unfortunately all my logs are gone <asac> had an issue with my irc system <Ubulette> <Ubulette> I wanted to package google gears so that both ff2/ff3 and webrunner could run some site offline (would be great for laptops) <Ubulette> <Ubulette> it's an extension but it contains a binary (a .so lib) <Ubulette> <Ubulette> so I guess it's no way. maybe through an installer like google-earth <Ubulette> <Ubulette> as for my question about "-" in upstream versions, i was about to package loggerhead-1.1.1+0.13~bzr20070905r162 <Ubulette> <Ubulette> initially, it was 1.1.1-0.13 <Ubulette> <Ubulette> well, 1.1.1-0.13 is already out so it should even be 1.1.1+0.13+bzr20070905r162 <Ubulette> <Ubulette> but I need to updated turbogears first. ubuntu is far behind. don't know if debian is better. <asac> the s/-/+/ is good <asac> Ubulette: is google gears free software? <asac> then we can package it <asac> so the so is build <Ubulette> hmm, I don't think so, <Ubulette> there's no source for sure <asac> then there is no chance other than looking if we can do something on ffox side to support it <Ubulette> http://pastebin.mozilla.org/211488 <gnomefreak> !info flashplugin-nonfree <ubotu> flashplugin-nonfree: Adobe Flash Player plugin installer. In component multiverse, is optional. Version 156.14.161.142.0ubuntu1~7.04.1 (feisty), package size 15 kB, installed size 108 kB (Only available for i386) <gnomefreak> oops <gnomefreak> !info flashplugin-nonfree dapper <ubotu> flashplugin-nonfree: Macromedia Flash Player plugin installer. In component multiverse, is optional. Version 156.14.161.142ubuntu3 (dapper), package size 16 kB, installed size 136 kB (Only available for i386) <gnomefreak> hmmmmmm <Ubulette> asac, thinking about mozclient, the current design is wrong. I mean, I have my onw patches, yet each time you run client.mk, 1st action is to co client.mk from upstream with the proper date or tag, so my patches could (too) easily fail. <Ubulette> runtime changes like that are not good. I'd rather do my own mk file, co client.mk and parse modules and tags from it <asac> Ubulette: yes ... i think its the right direction <asac> predefine application-sets that declare a list of modules, which then get checked out :) #ubuntu-mozillateam 2007-10-04 <Ubulette> a8 mt3 succeeded <Ubulette> got no mail though <asac> successful builds are usually not mailed <Ubulette> oh, ok <bluekuja> heya asac <bluekuja> :) <asac> bluekuja: hi ... all fine? <Chiselhuk> Hi Can anyone here help me plse?? <Chiselhuk> Having trouble with Mozilla Firefox crashing continually in Ubuntu Gutsy Gibbon! <bluekuja> asac: yup :) <bluekuja> asac: I'm studying atm, and later I'll move to fix two agg's bugs <bluekuja> asac: I hope to have them fixed as soon as I can, NM waits me <asac> hehe <carlos> asac: please, ping me when you are back <asac> carlos: ping <carlos> asac: hi <asac> ok how can we get this going <carlos> asac: so, I'm starting implementing the export code to get translations from Launchpad and generate language packs for packages using Mozilla XPI file format <carlos> I did some investigation after our last chat <asac> yes <carlos> and indeed, using .manifest files is the way to go <asac> so how does it currently work? <asac> do you get initial strings from upstream xpis? <carlos> I talked with pitti about how to extract those files on build time like we do for other translation formats and import automatically into Launchpad <carlos> the idea is, you upload a new package into Ubuntu's archive <asac> new package == new firefox package ? <carlos> we extract the strings automatically and import them into Launchpad <asac> ok <carlos> asac: new firefox or any other package that uses xpi files <carlos> the problem is that not all packages are using XPI files <asac> right <carlos> and Martin thought is not a good idea to look for .manifest files + all the subdirectories inside that directory <carlos> because is move file format dependent information in a layer that shouldn't know about it <carlos> so he asked me to check with you whether we could use xpi files inside source packages <carlos> instead of having it uncompressed (like ubufox does) <asac> ubufox currently has no translations <carlos> then, the package build will extract the xpi file content and do the usual things <asac> its actually the same way firefox ships its en-us locale <carlos> yeah, that would need to be updated too <carlos> if possible <carlos> so we only need to look for .xpi files <carlos> and move the logic inside Launchpad and the packages that use it <asac> hmm <carlos> the .xpi file doesn't need to be locale specific <carlos> we are able to discard the bits that are not related with translations inside Launchpad <asac> hmm why do we start with source files at all? <asac> why not look at the contents of the binaries? <carlos> because it's at that level where we get the information for Launchpad <carlos> the extraction process is triggered on build time <carlos> by the pkgstriptranslations script <asac> thats hooked into some standard debhelper command? <carlos> yes <asac> or how is that triggered? <asac> which one? <carlos> I don't know so much details <carlos> let me see whether pitti would join us <asac> yes <carlos> he's the one handling that part <asac> thats probably a good idea <pitti> hello <asac> ola pitti <asac> 17:13 < asac> hmm why do we start with source files at all? <asac> 17:13 < asac> why not look at the contents of the binaries? <asac> 17:13 < carlos> because it's at that level where we get the information for Launchpad <asac> 17:13 < carlos> the extraction process is triggered on build time <asac> 17:14 < carlos> by the pkgstriptranslations script <asac> 17:14 < asac> thats hooked into some standard debhelper command? <asac> 17:14 < carlos> yes <asac> 17:14 < asac> or how is that triggered? <asac> 17:14 < asac> which one? <asac> 17:14 < carlos> I don't know so much details <pitti> asac: dpkg-deb <pitti> asac: that kills *.mo from debs and also extracts po files, etc. from the source tree into a trasnaltion tarball for Rosetta <pitti> plus some custom stuff for OO.o and Mozilla (extract .xpi, etc.) <asac> pitti: can we take a look at the binary results at that point? <pitti> so, just to set the topic, the goal is to extract the rigth set of files for Rosetta from the builds of firefox itself (en-US) and ubufox, right? <carlos> pitti: yes <pitti> asac: we need to mangle at build time, and use the source; we need to strip off .mo files, and the binaries do not have *.po which we need for Rosetta <carlos> asac: what's the point on doing it for binaries instead of source packages? <asac> point is that almost no mozilla source tree has .xpi files ... and that is impossible to change <asac> impossible == without changing the world ;) <carlos> asac: well, that's done *after* source build <pitti> ok <carlos> so it could be done after you build the xpi file in hte source build <pitti> so, which files do we actually need? <carlos> asac: we take that same approach to update all .pot files before extracting them <pitti> we need to balance simplicity of pkgbinarymangler with special knowledge about mozilla-like translations <asac> pitti: we have to search the binary tree for .jar files and extract the entities from there <pitti> asac: that's something the Rosetta importer should do <carlos> asac: no, that's not done at that level <pitti> at build time, the most complex operation possible is "find some files and copy them into the tarball" <pitti> if that grabs a few files too much, it doesn't hurt <pitti> it shouldn't be too many to avoid getting too big tarballs, of course <carlos> asac: then, Launchpad gets that tarball and process it to extract the translations <carlos> but that happens after the build and publishing process ends so we don't interfere with buildd <asac> ok please look at: http://paste.ubuntu.com/603/ <carlos> from my position, what would be quite useful is to add a rule to the packages that use Mozilla l10n infrastructure to generate the .xpi files we need <carlos> and execute that rule before the pkgstriptranslations * carlos looks <asac> usually you would have to take all .jar files that have a locale reference in their manifest <carlos> asac: that's why I talk about xpi, if you zip all those files inside an .xpi file, Launchpad will do that research <carlos> after the package is built <asac> thats not possible ... really <carlos> and pitti's script will only need to know what to extract, because it finds the .xpi file <carlos> hmm <pitti> how many source packages are we talking about? just firefox and ubufox? <asac> i don't understand why you can deal with .xpi while you can't with arbitrary chrome jars <asac> pitti: in the end about all mozilla related packages <pitti> for two packages it makes sense to keep the special logic in their debian/rules, since *.manifest files are by no way mozilla specific <asac> pitti: firefox and ubufox are good corner cases <asac> if both work, most others should work too <pitti> .jar files are mozilla specific <pitti> so if we just extract all .jar files, would that work? <carlos> pitti: no, I need the manifest file too <carlos> pitti: also ubufox doesn't use jar <pitti> meh <asac> pitti: the problem is that you have to generate a proper .manifest file during export ... look at /usr/share/firefox/chrome/en-US.manifest <carlos> it has the files uncompressed <pitti> . o O { gettext FTW! } <asac> the only way this can be done right is too parse all .manifest files <asac> and from there go on. <pitti> that's not something we should ever do for all packages in pkgbinarymangler <carlos> pitti: what about the approach I told you about? <carlos> extract all *.manifest files and any file in subdirectories where that file is <carlos> but <asac> there are different ways to reference locations inside that ... jar: is one option, but there might as well be just directories ... like you can see in ubufox chrome.manifest <carlos> restrict it to a well known list of packages <carlos> asac: I know about that, but we don't want to add that logic to the extract process <carlos> but leave it inside Launchpad <carlos> so we don't need to maintain different code in different places but just in a single place <pitti> so, what about: <asac> carlos: without looking at .manifest you won't be able to export them in a usable fashion. <pitti> if there are any .jar files, extract those, plus all *.manifest <pitti> that's simple enough for pkgbinarymangler <carlos> asac: I want that .manifest file so I will be able to generate the right export, don't worry but at Launchpad level <carlos> pitti: that leaves ubufox outside, it has .manifest files but it lacks .jar files <carlos> pitti: https://pastebin.canonical.com/461/ <asac> carlos: can you psate to paste.ubuntu.com ? <asac> i don't know the pass ;) <pitti> seriously, we cannot code 10 special cases into pkgbinarymangler <pitti> special cases should be handled by the particular source packages <carlos> asac: it's just the content of the ubufox source package <asac> pitti: its not a special case ... its just: look at .manifest ... and use the method listed there <asac> in the forth column: if there is jar:... you can find the right .jar file and extract that ... if its just a directory, you would just use that <carlos> asac: it's even more simple, extract everything in the directory where .manifest is and we will handle the parsing later <carlos> pitti: ^^^ <asac> carlos: maybe that would work <asac> but export needs to be smart then <carlos> if you have concerns for packages using different manifest files, let's lock that extraction to a well known list of sourcepackages <pitti> carlos: we need an additional condition when to do it <carlos> asac: we use the import to generate the export <pitti> *.manifest is way too generic <asac> i would prefer to teach the pkgbinarymangler how to deal with: <asac> locale necko en-US jar:en-US.jar!/locale/en-US/necko/ <asac> and <asac> locale ubufox en-US locale/en-US/ <asac> that will cover all cases i guess <carlos> asac: really, that's useless at that stage <asac> carlos: why? you would get the right list on what you want to import into launchpad <carlos> asac: because that adds more complexity and we can handle the filtering on Launchpad side where we need to know about .manifest content anyway <asac> ok <carlos> pitti: combined with a well know list of sourcepackages shouldn't be a problem... <asac> but you could at least filter out not needed .jar files/directories <pitti> right, we need something dead simple and 100% robust in the binary mangler <carlos> asac: right, that would generate smaller tarballs, although it's not a big problem, we could even get the source tar.gz imported into Launchpad, we ignore the files that are not interesting for us <carlos> so if it adds extra complexity, let's not do that <carlos> asac: what's the list of sourcepackages that use Mozilla like translations? Do you know that list? <asac> ok ... to summarize: we use the binary results present at the end of build <carlos> asac: just to clarify, that's not the binary packages, but the final version of the built package <asac> and unzip all .jar files that are in a directory that with at least one chrome.manifest? <carlos> asac: no need to unzip them * carlos is confused now... <asac> i don't understand the difference ... for me its just debian/firefox or debian/ubufox at the end of build <asac> no need to unzip? <carlos> no, Launchpad will inspect them <carlos> based on the manifest files <asac> ok, so why wouldn't ubufox work at the moment? <asac> i understood that launchpad would choke on that if we don't do anything <carlos> if pitti agrees on extract directory and contents that have a *.manifest file inside it for a given list of packages (so we only do that for packages that are really using this kind of translations) <carlos> ubufox will work without changes <pitti> as I said, that will work if you give me an additional conditions how to detect a mozilla-style package <carlos> pitti: I'm talking about giving you a fixed list of sourcepackages <pitti> no need to move gigabytes of OpenOffice stuff over, just because that happens to have a manifest file, too <carlos> pitti: isn't that enough? <pitti> carlos: ugly <asac> pitti: how about looking for locale lines in .manifest? <pitti> it won't allow us to easily add stuff to that list <asac> if they exist its likely a mozilla-style package <asac> you can even test if the locale line has 4 columns <pitti> isnt' there a typical directory name, or something like that? <asac> not really <asac> pitti: extensions have a install.rdf file <pitti> ah, now that's something <carlos> asac: does main firefox package have it too? <asac> no <asac> just extensions <asac> for moz apps we can only test if the .manifest file is in the chrome/ directory <carlos> asac: In fact, I think is more reliable to look for chrome.manifest for extensions, isn't that the name always? (except for xul applications) <asac> so either you find a install.rdf ... or one or more manifest files in a chrome directory ... is that good enough pitti ? <asac> carlos: i think pitti feares that there will be other packages shipping .manifest files <carlos> asac: well, he fears of looking for *.manufest <asac> which is why i suggested to also introspect those .manifest files and search for lines that start with ^locale and have 4 columns <carlos> chrome.manifest should be enough <asac> carlos: thats not given <carlos> ok <asac> look at dpkg -L firefox <pitti> asac: yeah, .../chrome/.../*.manifest sounds good to me <asac> pitti: its always directly in the chrome directory <pitti> ah <asac> so chrome/*.manifest <pitti> so, a test for chrome/*.manifest <carlos> asac: that's why I said that xul applications are an exception, it's only valid for extensions ;-) <asac> pitti: yes ... and if you have a install.rdf you have an extension package <pitti> asac: and fire firefox itself? <pitti> ah, ok <pitti> so "-e <arbitrary path>/chrome/*.manifest || -e ./install.rdf" <carlos> pitti: so that will give me that directory + all its content? <pitti> in this case I'll extract all *.manifest files and all files in their directories <pitti> (including subdirs, of course) <asac> pitti: yes, but thats all only valid for the binary tree <asac> (just to repeat) <pitti> that's quite a lot of non-trivial code for binarymangler, but bearable <asac> in source tree there is no chance to find something common <pitti> if it cannot be simplified, I'm ok with that <carlos> asac: we have that, if the extract script is run before cleaning the build directory <asac> ok <pitti> asac: oh, all rules need to be for the root directory of the built source tree <carlos> pitti: that means you don't need to look for .xpi files <pitti> ok <carlos> ok, so we had half task clear ;-) <carlos> asac: I need to talk with you about deploy translations from Launchpad <carlos> pitti: if you are busy you don't need to care about this part <carlos> asac: Is there any way to override mozilla translations without overwrite what you are installing right now? <carlos> for instance, If I want to ship a Spanish translation update for Firefox, is there a way to do it without overwriting /acolon@example.com/ directory content? <asac> carlos: well ... should be <asac> just /acolon@example.com/ <pitti> alright; so the rule from above makes everyone happy? <asac> and fill in previously not tranlsate strings <carlos> pitti: yes <pitti> carlos: did you already file a bug about this this morning? <carlos> pitti: no, not yet <pitti> ok <pitti> I'll create one <carlos> asac: yeah, I was thinking about using a Launchpad specific ID, although I would like to be able to change also existing translations in the other directory <carlos> asac: but I didn't find how Firefox looks for the translation directory <carlos> pitti: thank you <asac> carlos: what do we want to achieve? why don't we try to export complete translations from rosetta? <asac> will rosetta have the complete translations? if not, how does rosetta know the strings that need to be translated? <carlos> yes, we will have complete translations (or at least we should) <carlos> but we want to ship them inside language packs <carlos> so we cannot overwrite files from another package <carlos> like mozilla-firefox-locale-es-es <carlos> and we still need them built to get updates from upstream <asac> hmm <carlos> asac: if it's a single file (like .mo ones for gettext applications) is quite trivial to remove them from the binary packages, but in this case, is not so trivial... <asac> ok, so we need two packages anyway? <carlos> asac: yeah, you keep current ones, although the updates will be included in the standard existing language packs ones <asac> will rosetta automatically package a locale package for me? <carlos> yes, that's the idea <asac> or will i have to include translations that are somehow dumped from it <carlos> you need to keep packaging whatever is in upstream, though <carlos> no, you don't need to care about Rosetta <carlos> that's why I need to know how to override translations from upstream <asac> carlos: i don't think you can reliably override ... would be more or acolon@example.com. so lets just fill in the gaps <asac> is that enough? <asac> e.g. only export entities that don't exist? <carlos> that prevents us to fix broken translations <carlos> and will be a bit confusing <carlos> maybe we could do something like we did with glibc to check first in language pack translations and then fall back into the standard translations... <carlos> but in Firefox <asac> how about just removing all .jars in binarymanagler from language packs? <asac> so all translations will live in our -rosetta packages? <asac> e.g. mozilla-locale-de will be more or less empty ... and depend on mozilla-locale-de-rosetta <carlos> asac: will not that break having manifest files pointing to a non existing file? <asac> carlos: since manifests need to be in -rosetta as well, we should drop them as well <asac> e.g. rm *.jar *.manifest :) <carlos> pitti: we need you here again... <carlos> that's done in pitti's land so he's the one to answer that question <carlos> asac: btw, what's /var/lib/mozilla-firefox/extensions.d directory for ? <asac> thats old ... you can ignore it <carlos> seems like you are able to give a priority to the extensions... <carlos> ok <asac> no its not used anymore <carlos> ok <carlos> asac: how does Firefox know about which language pack use? where is noted that? <carlos> does it iterates over all extensions available on /usr/lib/firefox/extensions and your home directory? <asac> carlos: it loads all extensins that way ... right <asac> then it resolves all locale/ uris with the locale found in OS environment <carlos> so that's why you say it's random? <asac> more or less yes. <carlos> it depends on which directory picks first? <carlos> ok <asac> there are other source of randonmenss as well <carlos> that sounds sooo broken <asac> for instance stuff gets indexed in hash maps ... so order gets lost <carlos> I see <asac> welll overwriting locales isn't really a strong usecase :) <asac> maybe for us, but not for others <pitti> re <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/pkgbinarymangler/+bug/149017 <ubotu> Launchpad bug 149017 in pkgbinarymangler "extract Mozilla-ish translations" [Undecided,New] <pitti> can you please scrutinize the description again and give your ack in the bug report? <carlos> pitti: we need to figure a way to remove Mozilla translation files like we do with .mo files <carlos> pitti: sure... <pitti> carlos: oh, why? <pitti> carlos: do the extensions ship their own translations? <carlos> pitti: because there is no way to override upstream ones installed <carlos> pitti: yeah, and also, language packs from upstream need to be still built and uploaded to Ubuntu's archive so we are able to keep Launchpad update <carlos> updated <pitti> btw, this rule does not really work with https://pastebin.canonical.com/461/ <pitti> well, it would just copy the entire source and build tree <carlos> pitti: if that bug description covers this: <carlos> /usr/share/firefox/chrome/en-US.jar <carlos> /usr/share/firefox/chrome/en-US.manifest <carlos> yes, that's it (I'm not sure I'm understanding it completely) <carlos> pitti: which is ok <carlos> pitti: Launchpad will discard the files that are not related with localisation <pitti> carlos: it won't cover /usr <pitti> it will pick up ./debian/foo/usr/share/firefox/chrome/en-US.{jar,manifest}, though <carlos> pitti: yeah, sorry, /debian/foo/usr/... <asac> pitti: its best to remove all translations from locale packages if we want to support translation fixes from rosetta <asac> i don't feel so good about that ... i would prefer just to fill the gaps and if we have improvements send them upstream <asac> regularly <carlos> asac: my only concern about removals is that, if we have a package like ubufox including 'es-ES'
{'channel': 'ubuntu-mozillateam', 'month': 10}