[05:12] <crimsun> asac: all 3 tests [from mozilla.qa.ubuntu.com/qatracker] pass for your ppa packages of firefox-3.0/xulrunner-1.9 3.0.5/1.9.0.5 on hardy, intrepid, and jaunty
[05:12] <crimsun> asac: (and thanks for mentioning via identi.ca; i wouldn't have noticed otherwise!)
[07:35] <crimsun> asac: all 3 tests [from mozilla.qa.ubuntu.com/qatracker] pass for your ppa packages of firefox on dapper
[07:36] <crimsun> i think i'm going to crash for the night, tho'; have to get up for work in a few hours
[07:36] <crimsun> (if needed, i'll install gutsy in a vm later this evening)
[09:07] <gnomefreak> X is still broken :(
[09:08] <crimsun> asac: (last one!) all 3 tests [from mozilla.qa.ubuntu.com/qatracker] pass for your ppa packages of firefox on gutsy
[09:10] <gnomefreak> asac: the agenda for last meeting is finished right? items are: Jaunty(we covered alreaady), Universe software security support, actions from last meeting, review or auto extension scripts?
[09:15] <Jazzva> good morning :)
[09:53] <gnomefreak> Jazzva: good morning
[10:39] <asac> crimsun: thanks!!!
[10:46] <Jazzva> asac, for foxyproxy... in-source patch vs. establishing a patch system?
[10:46] <asac> Jazzva: what patch?
[10:46] <Jazzva> regarding yesterday's problem with changing settingsDir... i just changed getDefaultPath not to read settingsDir at all, but to get it from profile dir.
[10:47] <asac> ah right
[10:47] <asac> Jazzva: will this patch stay around forever?
[10:47] <Jazzva> asac: for trying to write settings file in /usr/lib/firefox/
[10:47] <Jazzva> I'm planning to start a topic on upstream's forum to check with them... I don't see a reason why they wouldn't apply this
[10:48] <asac> Jazzva: yeah. your decision then. with or without patchsystem should work
[10:49] <Jazzva> though, their getDefaultPath had commented code for getting a settings dir as a profile dir, and then they just added this code. maybe they assumed that the extension will be installed in a profile dir, so that might be the reason why they removed the preferred way.
[11:04] <Jazzva> asac, I left a comment on the topic for this bug. I'll submit it now as in-source patch, in case he decides not to use it, we can establish a patch system...
[11:07] <asac> Jazzva: fine.
[11:08] <asac> Jazzva: ready for upload then ;)?
[11:08] <Jazzva> no, there is a new version, I'll update it :)
[11:08] <Jazzva> (it still has the same bug, though)
[11:45] <asac> mozilla bug 404314
[11:45] <ubottu> Mozilla bug 404314 in XUL "when I click on a menu instead of click and hold it randomly selects a menu item and activates it" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=404314
[11:45] <asac> fta2: do you have assitive technologies enabled on gnome?
[11:46] <asac> (i think thats the reason why we see this more frequently now)
[11:49] <Jazzva> asac: done, I proposed a merge of ~jazzva/f-e/foxyproxy.ubuntu to ~ubuntu-dev
[11:49] <Jazzva> asac: https://code.edge.launchpad.net/~jazzva/firefox-extensions/foxyproxy.ubuntu/+merge/2395
[11:51] <asac> Jazzva: heh ... you didnt use a "topic" name for the branch :)
[11:51] <Jazzva> yeeeah... I know. I used just this, as it was available...
[11:51] <asac> Jazzva: i dont mind ... just that i cannot say: bzr branch yourbranch; bzr branch ubuntu-devbranch
[11:51] <asac> without renaming ;)
[11:51] <asac> (which is what reminds me of it all the time;)
[11:52] <Jazzva> why can't you use that?
[11:52] <Jazzva> ah...
[11:52] <Jazzva> foxyproxy.ubuntu in both cases
[11:52] <asac> Jazzva: oh ... we could use the builddeb.conf too there ;)
[11:52] <asac> (when we touch it)
[11:52] <Jazzva> bzr branch ubuntu-devbranch, cd ubuntu-devbranch, bzr merge my-branch?
[11:52] <asac> yep
[11:53] <asac> Jazzva: usually branches exept the mainline branch are not .ubuntu branches, but are dedicated for a topic
[11:53] <asac> like 1.5.6 ;)
[11:53] <asac> but well
[11:53] <Jazzva> I wrote little helper for that new part of bzr, it's most probable that I will forgot how to use it. It would be good to put it on wiki somewhere :)
[11:53] <asac> yep
[11:54] <asac> we should put it https://wiki.ubuntu.com/MozillaTeam/Extensions/Bzr
[11:54] <Jazzva> I'll just put it as it is now, and mark that part of doc as WIP
[11:56] <asac> Jazzva: yes. just push whatever you have now .... we can streamline stuff later
[11:57] <Jazzva> yep
[11:57] <asac> Jazzva: oh i think we should use "merge" mode
[11:57] <asac> merge = True
[11:57] <Jazzva> in .bzr-builddeb/default.conf
[11:58] <asac> yep
[11:58] <asac> i add that to for foxyproxy during the merge now
[11:59] <Jazzva> ok
[12:02] <asac> Jazzva: done
[12:02] <asac> now you can just do bzr bd
[12:02] <asac> (even without --merge)
[12:03] <Jazzva> wee :)
[12:05] <asac> Jazzva: hmm ... does the Bzr document make any sense?
[12:07] <Jazzva> apart from some typos, yes...
[12:08] <asac> Jazzva: i think we should definitly use a med-xpi-pack extensions there
[12:08] <asac> and maybe add a second paragraph showing that this can also be done if you hav other sources
[12:09] <asac> #
[12:09] <asac> bzr branch http://bazaar.launchpad.net/~ubuntu-dev/firefox-extensions/firebug.ubuntu firebug.upstream
[12:09] <asac> #
[12:09] <asac> thats rather confusing
[12:09] <asac> and will make folks believe that .ubuntu is used as new .upstream ;)
[12:10] <asac> a bit tricky to describe how to extract upstream tree from .ubuntu one
[12:10] <asac> if we have .bzr-builddeb/default.conf that should work
[12:11] <Jazzva> asac: saving my changes. refresh the Bzr page
[12:11]  * asac  looks
[12:11] <Jazzva> it's probably confusing :)
[12:12] <Jazzva> and we should add examples. for example, we could add an example bzr log entry, and to bold the revision number, etc...
[12:13] <asac> Jazzva: i think we should move the "how to spot upstream revision in bzr log" to a separate section
[12:13] <Jazzva> mhm
[12:13] <Jazzva> brb, making coffee
[12:13] <asac> its basically just a bootstrap thing, isnt it?
[12:13] <Jazzva> bootstrap thing?
[12:13] <asac> i mean once everything uses the default.conf you look there to get the upstream revision
[12:13] <asac> then you commit on top of the extracted upstream tree and then you use the latest commit id
[12:14] <asac> which should be easy to spot
[12:14] <asac> e.g.
[12:14] <asac> 1. bzr branch .ubuntu
[12:14] <gnomefreak> wtf
[12:14] <asac> 2. cat .ubuntu/.bzr-builddeb/default.conf | grep revision -> revisionid
[12:14] <asac> bzr branch -r revisionid .ubuntu .upstream
[12:14] <asac> cd .upstream
[12:14] <asac> commit new upstream revision
[12:15] <asac> bzr log --show-ids | head | grep revision-id
[12:15] <asac> cd ../.ubuntu
[12:15] <asac> bzr merge ../.upstream
[12:15] <asac> update .bzr-builddeb/default.conf for new revision-id
[12:15] <asac> bzr commit -m "* mergfe new upstream revision"
[12:15] <asac> ;)
[12:16] <asac> gnomefreak: whats up?
[12:16] <asac> trashed your system?
[12:16] <gnomefreak> tbird crashing
[12:16] <gnomefreak> cant send email without crash
[12:20] <gnomefreak> asac: latest tbird-3 in fta's PPA work for you?
[12:20] <asac> gnomefreak: i dont upgrade regularly on fta archive
[12:21] <gnomefreak> ah
[12:21] <asac> it usually brings too much new libs and stuff i dont want to add just now
[12:21] <asac> gnomefreak: is that beta1?
[12:21] <Jazzva> asac, I agree... that sounds ok
[12:21] <gnomefreak> asac: 3.0~b1+nobinonly2-0ubuntu1~fta1
[12:22] <gnomefreak> fta2: 3.0~b1+nobinonly2-0ubuntu1~fta1 is crashing whne trying to send email (is this true for you as well?
[12:22] <asac> Jazzva: maybe we should write a script med-xpi-new-upstream
[12:22] <gnomefreak> )*
[12:22] <asac> that does everything except the final commit
[12:23] <asac> adding to mt TODO :)
[12:23] <Jazzva> asac: sounds ok, but shouldn't it be more general? nspluginwrapper could work with it too...
[12:23] <asac> Jazzva: yeah.
[12:24] <Jazzva> so it couls be med-new-upstream... but maybe other packages could use it too... bzr-new-upstream? incorporate it in bzr? :)
[12:24] <asac> something like med-new-upstream ... which then looks whether its an .xpi or a .tarball ?
[12:24] <Jazzva> (ok... the last may be too much)
[12:24] <asac> Jazzva: i think we should work on it in med- and if we have something that is useful in general migrate that to bzr-devtools or something
[12:24] <Jazzva> so, it should also fetch new upstream .xpi or .tarball?
[12:24] <asac> unfortunatley james_w seems to be on holiday
[12:25] <asac> Jazzva: hmm ...thats difficult. we have the scripts from volans that we should finally try to make use of
[12:25] <gnomefreak> i was just gonna ask that about tarball or .xpi however it should be more general than a tarball since we use say svn it comes as a dir not a tarball
[12:25] <Jazzva> hmm... maybe it could use debian/watch to get new upstream...
[12:25] <Jazzva> asac: that would be good...
[12:26] <asac> in genral i like debian/watch
[12:26] <asac> we could also say that get-orig-source is called
[12:26] <gnomefreak> noticed with bzr you have to finish /debian before tarball can be made
[12:26] <asac> but what for such packages that are based on bzr synchs?
[12:27] <gnomefreak> this is fucking annoying E: read, still have 5018251 to read but none left
[12:27] <gnomefreak> E: The package lists or status file could not be parsed or opened.
[12:27] <gnomefreak> while using upgrade and dist-upgrade
[12:28] <gnomefreak> ok smoke than try to downgrade tbird without losing the emails already downloaded
[12:29] <Jazzva> asac: huh? isn't the procedure branch upstream and ubuntu, fetch new source file (be it xpi or tarball), unpack, copy to upstream, commit upstream, merge upstream in ubuntu, update default.conf, commit ubuntu, leave the rest to the maintainer?
[12:34] <asac> Jazzva: yes. thats correct
[12:34] <asac> Jazzva: only other variant would be where fetch new source file means, fetching some bzr branch or something
[12:34] <asac> or svn
[12:35] <asac> but well ... thats details
[12:35] <Jazzva> ah... well, that could be added later :)
[12:35] <asac> also ithink we should auto commit ubuntu, but leave that to maintainer
[12:35] <asac> in best case he can just debcommit
[12:35] <asac> in worst case he has to resolve conflicts
[12:35] <asac> we could auto commit if there are no conflicts though
[12:35] <Jazzva> I meant to commit the part after merge of new upstream, and update of .bzr-builddeb/default.conf
[12:36] <Jazzva> and then to leave the rest of changes to the packaging to the maintainer
[12:42] <asac> Jazzva: yeah. i think we should try to commit with UNRELEASED
[12:42] <asac> which of course would fail if there are merge conflicts (which is a good thing)
[12:54] <jtv2> asac: ping
=== jtv2 is now known as jtv
[12:54] <asac> jtv: yes?
[12:54] <jtv> asac: hi
[12:54] <jtv> asac: would you have time to talk about a technical question?
[12:55] <jtv> asac: it's about generating RDF files.
[12:57] <gnomefreak> why UNREALEASED? there isnt really a need to use it than change it after commit just start out using what dch -i uses and change it as you go
[12:58] <gnomefreak> less commits is best IMHO
[13:04] <asac> jtv: dont ask to ask :)
[13:04] <jtv> asac: skype OK?
[13:05] <asac> jtv: nope ... have no skype
[13:05] <jtv> asac: regular phone?
[13:05] <asac> i have that ;)? :)
[13:05] <jtv> asac: my IRC's a bit flaky atm.
[13:06] <asac> feel free to call ... i am a bit flaky in my brain ... but if you dont mind :)
[13:06] <jtv> :)
[13:07] <asac> jtv: use the number in directory
[13:07] <jtv> asac: I was just looking it up...
[13:08] <jtv> asac: (btw the canonical wiki shows a different set of numbers)
[13:09] <gnomefreak> asac: is there an easy way to find out what debugging packages are needed for an app?
[13:13] <gnomefreak> it seems its related to gpg but doesnt make sense since my key and password is goo
[13:13] <gnomefreak> d
[13:13] <asac> jtv: you were suddenly gone
[13:13] <jtv> asac: I heard very loud noise for a while
[13:13] <jtv> asac: retrying now
[13:14] <asac> jtv: hmm ... somehow i got cut off
[13:14] <asac> jtv: try the mobile then again :)
[13:14]  * jtv goes back to directory
[13:31] <gnomefreak> i'm not so sure we should be closing master bugs just because of no activity. since master bugs are there to collect dups and to be fixed
[13:38] <gnomefreak> fuck tbird
[13:48] <gnomefreak> it is gpg related and my key worked in tbird until today i havent checked email in a few days so i might have been broken than
[13:58] <gnomefreak> i doubt its thunderbird seems signing a file fails due to password not being entered when you type it
[13:59] <gnomefreak> its nto *-agent
[14:07] <gnomefreak> its not tbird its pinentry-gtk2. testing *-qt works
[14:13] <gnomefreak> well guess not since tbird is failing with *-qt installed instead of *-gtk2 so im gonna guess that enigmail uses *-gtk2
[14:18] <gnomefreak> im betting enigmail cant use *-qt
[14:22] <asac> debian bug 505565
[14:23] <ubottu> Debian bug 505565 in iceape "Mozilla SeaMonkey Multiple Vulnerabilities" [Critical,Closed] http://bugs.debian.org/505565
[14:25] <gnomefreak> asac: do you have the iceeasel-firegpg debian bug handy?
[14:25] <gnomefreak> or the failed merge.
[14:26] <asac> gnomefreak: not sure what you mean
[14:26] <gnomefreak> if you plan on dropping the name iceweasel please let me know why the merge matters
[14:27] <gnomefreak> it than turns into my package without all the deps and updated to recent version. im not updating to latest since its all win fixes with like one all fix
[14:27] <gnomefreak> latest == 0.6.3 i have 0.6.2
[15:19] <gnomefreak> im gone for a while
[15:36] <asac> hmm ... i think gnomefreak got something wrong
[15:37] <asac> i asked him to merge the upstream bzr branch
[15:37] <asac> and not copy files over
[16:20] <asac> hmm .. i cannot clean changes for subtrees in hg :(
[16:20] <asac> stupid thing
[16:21] <asac> so now i do ... hg diff subtree/ | patch -p0 -R
[16:21] <asac> dumb
[16:31] <asac> @time
[16:31] <ubottu> Current time in Etc/UTC: December 17 2008, 16:32:22 - Current meeting: Foundation Team
[16:34] <fta2> stevel, i distributed the stickers, all gone in 5 seconds ;)
[16:34] <stevel> fta2: wow! those went fast.
[16:35] <asac> oh ... where were my stickers/t-shirts?
[16:35] <asac> :)
[16:35] <asac> jk
[16:35] <asac> going to christmas market now
[16:35] <asac> cu later
[16:35] <stevel> asac: i didn't get you a t-shirt?
[16:35] <stevel> damn, i brought a whole bag full of them
[16:36] <fta2> asac, i thought you took some too. strange
[16:49] <[reed]> asac: did you use build1?
[16:49] <[reed]> heh
[16:49] <[reed]> we shipped build2
[17:38] <reed> asac: ping?
[17:38] <reed> fta: ping, too
[18:12] <stevel> ooh. multicast ping
[18:38] <jcastro> did someone take notes on what was discussed wrt. songbird at UDS?
[18:38] <jcastro> I don't think it was a session just a break out room
[18:58] <fta> jcastro, most of the discussion happened between stevel and asac while i was in a session :( I arrived near the end.
[18:58] <fta> reed, pong
[18:58] <reed> fta: what build did you all ship for 3.0.5
[18:58] <reed> ?
[18:58] <reed> build1 or build2?
[18:58] <fta> reed, donno, asac did it by itself
[18:59] <fta> reed, did the source change between build1 and build2 ?
[18:59] <gavin> I think reed means "what tag did you use"
[18:59] <gavin> yes, it did
[18:59] <fta> let me check if he documented it..
[19:00] <fta>   New upstream security/stability update (v3.0.5 aka FIREFOX_3_0_5_BUILD1)
[19:00] <fta> so it's build1
[19:00] <gavin> :(
[19:01] <fta> we can do another round. what were the changes?
[19:01] <jdstrand> asac mentioned to me that it was windows specific
[19:02] <jdstrand> and that the tested binaries were fine for us
[19:02] <fta> gavin, reed: ^^
[19:02] <reed> jdstrand: no
[19:02] <reed> jdstrand: you're vulnerable
[19:03] <reed> the issue Mozilla had is win32-only
[19:03] <reed> oh
[19:03] <reed> Firefox 3.0.4
[19:03] <reed> 3.0.5
[19:03] <reed> gavin: did we do build2 for 3.0.5 or just 2.0.0.19?
[19:03] <reed> build1 might be fine for 3.0.5
[19:03] <gavin> I don't know
[19:03] <reed> fta: do you all still do Fx2?
[19:04] <gavin> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.5-candidates/
[19:04] <fta> not me, but sure, asac still maintains it
[19:04] <gavin> only 2.0.0.19
[19:05] <fta> hold on, checking
[19:06] <fta> well, not sure. it's badly documented.
[19:08] <stevel> jcastro: i think asac had said he would check with the archive admins to see how they felt about a xulrunner app going into universe w/ its own private xulrunner
[19:08] <jcastro> ah ok, so there's like an active list of things that need to happen on our side?
[19:08] <reed> stevel: are you all actively working on upstreaming your changes?
[19:09] <stevel> reed: yeah. we've gotten 2 committed in the past month... one more is on checkin-needed
[19:09] <stevel> 456164
[19:09] <stevel> it's slow going though
[19:11] <fta> reed, you're slow going accepting patches into xul.
[19:12] <reed> e
[19:12] <reed> eh
[19:12] <reed> depends on the patch and reviewer
[19:12] <reed> if something is going slow, let me know
[19:12] <reed> I have magical get-things-reviewed-and-landed-quicker powers.
[19:12] <stevel> too bad you don't have magical clean-up-this-patch-update-it-for-tip-and-make-it-less-songbird-specific powers
[19:13] <stevel> i could use some of those
[19:16] <reed> stevel: ;)
[19:19] <fta> my point is, mozilla should be more receptive to xul-only patches. They should help improving patches instead of rejecting/ignoring them.
[19:22] <gavin> what patches were rejected/ignored?
[19:23] <fta> most of the songbird/tomtom
[19:23] <gavin> do you have bug #s?
[19:23] <fta>  /instantbird/openkomodo/...
[19:23] <fta> maybe they need improvement but moz should definitely help here.
[19:24] <fta> xul is supposed to be a framework/sdk for others to build applications on top of it, not just firefox
[19:25] <gavin> the idea that "mozilla" should bear the burden of making a web platform more than the people actually using the platform is rather odd to me
[19:25] <gavin> it sounds like you're asking for a free lunch
[19:26] <gavin> if people are not being cooperative and constructive in accepting patches, that's one thing
[19:26] <gavin> but saying that it should be mozilla's responsibility to fix everything that is wrong with xulrunner and no one elses is another
[19:28] <fta> i meant the latter.
[19:28] <gavin> do you mean the former?
[19:31] <gavin> saying that xulrunner consumers should dictate how mozilla project participants spend their time without sharing some of the burden is a hard position to defend
[19:31] <fta> well, i mean, a lot of patches trying to fix or improve xul are in bugzilla, receiving almost no attention. if the submitter has no time or skill to make the patch perfect, no one is coming to the rescue.
[19:32] <gavin> if the person who cares about the patch doesn't have the time to submit it, why would someone else?
[19:32] <gavin> other people's time isn't free
[19:32] <fta> but forget it, we'll never agree. i guess this means that we're doomed to have a dozen of patched xul downstream forever.
[19:32] <gavin> I'm all for reducing barriers to entry and making the whole process easier - if I can help out in any way with that, I'd be glad to
[19:33] <gavin> send me a list of bug #s where patches were ignored
[19:34] <gavin> but you seem to have the expectation that other people will solve your problems just because you decided to use Mozilla, and that kind of attitude doesn't seem very constructive to me
[19:35] <stevel> sooo... not to try and ride the fence or anything, but there are truths to both arguments
[19:35] <fta> most are not my problems, at least not directly as i'm only downstream
[19:35] <stevel> my personal experience with the 3 XULRunner patches i've worked on has actually been quite good
[19:35] <gavin> sure, I didn't necessarily mean you specifically
[19:35] <stevel> but i've heard negative experiences from other developers too
[19:36]  * reed thinks of the XULRunner talk at Whistler that he missed
[19:36]  * reed chuckles
[19:36] <stevel> i've heard (so feel free to write this off as hearsay) of people attaching bugs that admittedly need more work, and just getting r-'d with no comments or suggestions as to how to fix 'em
[19:36] <gavin> stevel: send me bug #s
[19:36] <stevel> i don't have concrete bug #'s to back that claim up though
[19:37] <stevel> like i said, feel free to write it off as hearsay :) my experience has been quite good
[19:37] <stevel> mossop gave me good feedback on my patches, and i was able to revise and submit updated patches that were r+'d and then commited
[19:37] <gavin> I'm sure you can understand that it might be a bit frustrating to hear about all these problems people are having, but never actually seeing any evidence :)
[19:37] <stevel> gavin: if i have such an experience, i'll let you and reed know.
[19:37] <reed> please do
[19:38] <stevel> gavin: definitely... i totally understand.  i dislike general venting without any concrete actionable next step too... just wanted to say that i've heard the same things fta has heard.
[19:39] <stevel> but i also wanted to say i haven't experienced them ;-)
=== stevel is now known as stevel-fence-sit
[19:39] <stevel-fence-sit> aww. need longer nicks
=== stevel-fence-sit is now known as stevel
[19:40] <gavin> :)
[19:41] <gavin> fwiw, I'm not trying to claim that mozilla's patch submission process is perfect
[19:41] <gavin> I'm not delusional :)
[19:41] <fta> mozilla bug 357052
[19:41] <ubottu> Mozilla bug 357052 in Tracking "Songbird tracking bug" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=357052
[19:42] <fta> mozilla bug 393966
[19:42] <ubottu> Mozilla bug 393966 in Tracking "TomTom HOME tracking bug" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=393966
[19:42] <gavin> those are tracking bugs
[19:43] <gavin> are there bugs being tracked off either of those that have patches that are being ignored?
[19:44] <stevel> i suppose this is the closest songbird one i can think of
[19:44] <stevel> https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=304048
[19:44] <stevel> r+'d, sr+'d - committed, but then backed out for performance regression
[19:45] <stevel> nobody from songbird has looked at it since bent in comment #54 though
[19:45] <stevel> so it's arguably being ignored from both sides
[19:45]  * stevel shrugs
[19:46] <gavin> yeah, that one just doesn't have an assignee...
[19:46] <gavin> looks like there are ideas for what to investigate in the last comment, though
[19:46] <stevel> yeah
[21:07] <fta> reed, FIREFOX_2_0_0_20_BUILD1 ? already?
[21:07] <reed> Firefox 2.0.0.19 on win32 was a dud
[21:32] <armin76> wtf
[21:32] <armin76> reed: only win?
[21:32] <gavin> yeah
[21:32] <reed> armin76: the wrong build was pushed out
[21:32] <reed> :/
[21:32] <armin76> heh, k, thanks
[21:32] <armin76> blame asac :)
[22:02] <asac> reed: any other issues except that win32 is BUILD1?
[22:02] <asac> security team said that they saw some confusion in this channel ;)
[22:03] <asac> reed: we shipped _RELEASE tag
[22:03] <asac> for final
[22:03] <asac> made 24-36h before the final release shipped
[22:03] <asac> reed: did 3.0.5 actually have a BUILD2? thought only 2.0.0.19 had that
[22:04] <reed> no
[22:04] <reed> only fx2
[22:07] <asac> reed: do you know whether win32 really shipped BUILD1 tag or if _RELEASE tag wasnt pushed forward?
[22:07] <reed> the former
[22:58] <fta> asac, did you re-add my build-system into the last xul 1.9 in intrepid?
[23:00] <fta> or was it hardy?
[23:07] <asac> fta: why would i readd it?
[23:07] <asac> the build system isnt really created at source creation time from what i know
[23:07] <asac> but at build time
[23:08] <asac> fta: if you really need the build system in the hardy xul, we can add it to the .hardy branch ... if its unintrusive
[23:11] <fta> it's created in post-patches
[23:12] <asac> please move that to packaging
[23:12] <asac> and not tarball
[23:12] <fta> eh?
[23:12] <asac> fta: post-patches == in cd bs?
[23:12] <fta> it's shipped inside xul-dev
[23:13] <asac> fta: then why would i remove it? i mean i just use the branches we have ... done
[23:14] <asac> you asked whether i re-added it? i dont understand that question ;)
[23:15] <fta> we already discussed about that, remember?
[23:16] <asac> i remember something ... my first thought it was something with the tarballs
[23:16] <fta> nope.
[23:16] <asac> hmm ... then i dont know any details
[23:17] <asac> if its really a packaging issue, then i dont understand why we didnt add that to the current packages
[23:17] <asac> )
[23:18] <asac> if you gave me a patch and i forgot to treview/ land it then i am sorry
[23:55] <asac> Jazzva: why is bugmail extension not in med-xpi format?
[23:56] <Jazzva> med-xpi format?
[23:56] <asac> Jazzva: yes, like med-xpi-unpack
[23:56] <Jazzva> I think it is... although, chrome wasn't in a jar file.
[23:57] <Jazzva> It works with default build command (med-xpi-pack)
[23:57] <asac> Jazzva: hmm ... ok so xpi.mk is really smart enough to zip that up properly
[23:57] <asac> ?
[23:57] <Jazzva> yep
[23:57] <asac> astonishing ;) ... didint know we were so smart
[23:57] <asac> is xpi.mk looking at manifest file?
[23:57] <Jazzva> actually, med-xpi-pack is :).
[23:58] <Jazzva> xpi.mk calls med-xpi-pack as default build, if none is defined in debian/rules
[23:58] <asac> Jazzva: right. but how does med-xpi-pack know that?
[23:58] <asac> it doesnt look at manifest at least
[23:58] <Jazzva> by the format of directory in chrome/
[23:59] <Jazzva> if there's blabla.jar! directory, it will pack it in a jar
[23:59] <asac> ah
[23:59] <asac> ok
[23:59] <asac> it alwasys does: zip -q -r $START_DIR/$XPIFILE * -x debian/\* temp-*/\*;
[23:59] <asac> in case there was .jar it will produce the .jar files in temp- ... so that will be right
[23:59] <asac> otherwise its a copy