[00:00] <fta> so apt still wants to upgrade it
[00:01] <asac> fta: kick calc in -devel about it
[00:01] <asac> fta: he should still be there
[00:01] <fta> bug 192310
[00:01] <ubotu> Launchpad bug 192310 in openoffice.org-hyphenation "package openoffice.org-hyphenation-en-us None [modified: /var/lib/dpkg/info/openoffice.org-hyphenation-en-us.list] failed to install/upgrade: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation" [High,Confirmed] https://launchpad.net/bugs/192310
[00:01] <fta> nope
[00:02] <fta> ok
[00:02] <asac> calc is the openoffice man in charge here i guess ;)
[00:03] <fta> no calc in -devel
[00:04] <asac> most likely by accident :)
[00:07] <asac> there he is ;)
[00:12] <asac> hehe
[00:22] <Sergeant_Pony> I have a question... I made a folder under inbox and now for some reason it won't show up... I even subscribed to the folder and can't get it to come back. Any ideas?
[00:23] <Sergeant_Pony> this is in Thunderbird
[00:23] <asac> not sure. i think inbox is special
[00:23] <Sergeant_Pony> all my other folders show up fine
[00:23] <asac> i think there is a setting somewherein the gutsy of imap server settings to change that
[00:25] <asac> Sergeant_Pony: try to enable "server supports folders that contain sub-folders and messages maybe"
[00:25] <asac> in imap server settings -> advanced
[00:27] <Sergeant_Pony> asac: where is that?
[00:27] <asac> in imap server settings -> advanced ;)
[00:28] <asac> if yo don't have an imap account then i don't know
[00:28] <Sergeant_Pony> it is an imap account
[00:28] <asac> then you have that advanced dialog :)
[00:28] <Sergeant_Pony> looking for settings advanced
[00:28] <asac> Sergeant_Pony: account settings -> server settings- > advanced that is
[00:31] <Sergeant_Pony> that is already checked off
[00:31] <asac> check it on :)
[00:31] <asac> e.g. check it
[00:31] <asac> if that doesn't help then its most likely a server issue
[00:32] <Sergeant_Pony> all my other folders under inbox show up
[00:33] <Sergeant_Pony> got it
[00:33] <asac> ?
[00:33] <Sergeant_Pony> got the folder to show up
[00:33] <asac> Sergeant_Pony: what was it?
[00:33] <Sergeant_Pony> I had imap show all imap folders...
[00:34] <asac> Sergeant_Pony: so the setting helped?
[00:52] <Sergeant_Pony> yes
[00:54] <Sergeant_Pony> I unchecked "Show only subscribed folders"
[00:54] <Sergeant_Pony> and it appeared even tho I am subscribed to it
[00:56] <asac> ok
[00:56] <asac> server issue then i guess
[00:57] <Sergeant_Pony> I don't care... as long as I can display all my folders
[00:58] <asac> hehe
[00:58] <asac> hope you still see messages ;)
[01:00] <Sergeant_Pony> yup, can see my messages in the folder
[01:01] <Sergeant_Pony> now to figure out if I can have the mail deposited into certain folders.
[01:01] <asac> filter i guess ;)
[01:02] <Jazzva> fta, thanks for the comment on teatime :)
[01:23] <asac> 2 days till release :)
[02:20] <Sergeant_Pony> can tb be set to automatically run a filter to sort mail? or do I need to run it by hand?
[02:22] <asac> it can ... but we are not focussed on that depth of user-support here in this channel in general. try the forums.mozillazine.org for such tb general questions.
[02:25] <asac> most likely your question has already been asked there, so use the search facility there
[02:25] <asac> Sergeant_Pony: ^^
[09:05]  * asac *yawns*
[09:05] <phoenix> Hi there, anyone successfully using an LDAP Directory as an Address Book while offline - I do say, that I want to have it off-line and it replicates fine, but as soon as I switch thunderbird off-line I get zero results from queries...
[09:19] <asac> mdke: you gave me a loitered branch with additional changes :(
[09:23] <asac> mdke: uploading a cherry pick of the latest checkin on top of the 8.04.1 package shipped as 8.04.2~hardy
[09:37] <asac> mdke: why does the .deb has lots more changes than the links?
[09:37] <asac> thats a mystery
[10:02] <asac> mdke: ok the -docs are up ... once they are published on LP we should integrate the changelog into the bzr branch
[10:02] <asac> maybe ping me about it
[10:21] <asac> phoenix24: hmm
[10:21] <asac> phoenix24: i guess thats a bug
[10:21] <asac> phoenix24: but online it works fine?
[10:24] <asac> phoenix24: in advanced config .. there is a isOffline config for each ldap provider
[10:24] <asac> whats the value for that?
[10:25] <phoenix24> I'm sorry which; extension are we talking about ?
[10:26] <asac> phoenix24: ?
[10:27] <asac> you asked a bout LDAP directory
[10:27] <asac> offline
[10:27] <asac> remember?
[10:27] <phoenix24> No, not me.
[10:27] <asac> oh ;)
[10:27] <asac> 10:05 < phoenix> Hi there, anyone successfully using an LDAP Directory as an Address Book while  offline - I do say, that I want to have it off-line and it replicates fine, but as  soon as I switch thunderbird off-line I get zero results from queries...
[10:27] <phoenix24> I Dont work with LDAP :(
[10:27] <asac> hehe
[10:27] <asac> someone spoofing you then ;)
[10:27] <asac> not the 24 of course
[10:28] <phoenix24> Oh!
[10:28] <phoenix24> are you giving any talk at the upcoming UDW ?
[10:28] <asac> yes .... again about extension packaging ... this time more focussed on the mass-maintenance part i hope
[10:29] <asac> but mostly depends on how far we get with the procedure, but i think with the help of fta and Jazzva we can have something initially
[10:29] <phoenix24> Nice!! looking forward to it again.
[10:29] <phoenix24> what are these? fta & Jazzva.
[10:30] <asac> i would have done more complex things like "porting applications to xulrunner 1.9" ... but was told that that I should rather use something more basic ;)
[10:31] <asac> phoenix24: fta wrote a script that automatically checks if there are new upstream releases available
[10:31] <asac> now we need to tools to automatically upgrade the upstream branch and so on
[10:31] <asac> and do releases ;)
[10:31] <asac> and procedures
[10:31] <phoenix24> that's great
[10:32] <asac> 29th 1800 UTC iirc
[10:33] <phoenix24> I had a problem fetching sources from CVS repos, it will be great if you could shed few lines on it too :)
[10:33] <asac> huh? about what?
[10:33] <asac> CVS usage?
[10:33] <phoenix24> fetching the latest code.
[10:33] <phoenix24> tags and stuff.
[10:33] <asac> ok
[10:33] <asac> ill see how it fits in there
[10:33] <phoenix24> ok
[10:34] <phoenix24> Or maybe you could include Thunderbird extensions packaging too ?
[10:35] <asac> phoenix24: yeah. that should be similar
[10:35] <phoenix24> yep
[10:37] <asac> hmm ... maybe i should have added another sessino about "mozilla translations in launchpad - how it works and how to test" :)
[10:39] <phoenix24> yeah, I'd love to see attend that.
[10:40] <phoenix24_> in the topic, "firefox b5 in final hardy? p > 95% :(" ;
[10:41] <phoenix24_> What does "p>95%" mean ?
[10:41] <asac> probability > 0.95 :)
[10:41] <phoenix24_> ah!
[10:42] <Jazzva> shouldn't the topic be updated?
[10:42] <Jazzva> ah
[10:42] <asac> just noticed ;)
[10:42] <phoenix24_> :D
[10:42] <Jazzva> hehe :)
[10:43] <Jazzva> What's that? 0.0 b5? :P
[10:43] <Jazzva> Just kidding :)
[10:43] <Jazzva> :)
[10:46] <asac> jetsaredim: ok, can we have a bug about the firebug issue so we can start working on a -proposed update?
[10:50] <asac> Jazzva: so how should the workflow for updating extensions work?
[10:50] <asac> one probably runs a derivate of fta script to see which extension needs update
[10:51] <asac> but whats next ;)?
[10:51] <Jazzva> If there's a new upstream, download it, extract it in upstream and then push it as upstrem branch ... that should be automatical :)
[10:51] <asac> ok concur on that
[10:52] <Jazzva> And ... where are we gonna download from? a.m.o xpi, then unzip it? That's uniform for (almost) all extensions
[10:52] <asac> but thats not even 10% of the work ;)
[10:52] <asac> good question
[10:53] <asac> we have extensions from svn/cvs atm ... and those from .xpi
[10:53] <asac> most likely every extension should provide its own update target ... for which we can implement a default for AMO sources in xpi.mk
[10:53] <Jazzva> That would be good.
[10:54] <asac> so if you have an extension with source from AMO you just would add a MOZ_AMO_ID=XXX to rules
[10:54] <Jazzva> If not, MOZ_SOURCE? :)
[10:55] <asac> maybe a MOZ_GET_SOURCE_CMD would be good ... that would implement a default that uses the MOZ_AMO_ID to get the latest
[10:55] <asac> and extensions could override it
[10:55] <Jazzva> Ok, since packagin doesn't change sources we could try to make a new dir, copy the new upstream and old debian dir there, and try to run the build. If it builds OK, the maintainer would be suggested to try it and see if everything works.
[10:55] <asac> but that also means that we can only use the current script for AMO extensions
[10:56] <Jazzva> *packaging
[10:56] <Jazzva> current script?
[10:56] <asac> Jazzva: yes, ftas
[10:56] <asac> it only detects divergence based on AMO ids i guess
[10:56] <Jazzva> Oh... I think it does...
[10:57] <Jazzva> Well, that maybe isn't that big problem for now, I think there's only one or two extensions that are not on a.m.o...
[10:57] <asac> yeah
[10:57] <asac> most likely we need to blacklist them from auto upgrading
[10:58] <Jazzva> Mhm ... And to say that's not implemented for now :)
[10:58] <asac> e.g. just a warning "this extension might need a manual update on branch X,Y,Z"
[10:59] <asac> Jazzva: i think for testing auto upgrade we should upgrade .upstream
[10:59] <asac> then run bzr merge ... and add a new changelog entry in that commit if no conflicts are detected during merge
[10:59] <Jazzva> Then comes the testbuild... I forgot we should unzip the chrome/*.jar, since most of them come with zipped chrome
[10:59] <asac> then it should be pushed automatically to some staging area from where we manually push it to the release area once we have verified that it works
[11:00] <asac> Jazzva: right ... i think the default upstream upgrade impl should properly deflate the upstream .xpi
[11:00] <Jazzva> pushed to bzr staging area :)?
[11:01] <asac> yes, something like extension.ubuntu.hardy-backports.staging branch
[11:01] <asac> if its supposed to go into the hardy-backports branch
[11:01] <Jazzva> Aha ... ok
[11:02] <Jazzva> We would need to provide a code in rules for jarring chrome dir, if it was unjarred.
[11:02] <asac> Jazzva: right. i think the ubufox build.sh script should work for most cases
[11:02] <Jazzva> Same here :)...
[11:02] <asac> Jazzva: actually we don't need that imo ... the current BUILD_CMD also delas with jarring up
[11:03] <asac> i think we just need to figure how to unjar them in a way that the build script still likes it
[11:03] <asac> hmm
[11:03] <Jazzva> What's the current BUILD_CMD?
[11:03] <asac> Jazzva: each extension specifies that
[11:03] <asac> for instance ubufox specifies  "build.sh"
[11:03] <asac> others use ant XXXX
[11:03] <Jazzva> Oh... What if the extension doesn't? ;)
[11:04] <asac> Jazzva: if it doesn't then its shipping a .xpi in source
[11:04] <asac> otherwise the xpi.mk won't work
[11:04] <asac> or its not using xpi.mk ;)
[11:05] <Jazzva> Hmm ... I'm using xpi.mk for some, don't issue BUILD_CMD, and manually provide a rule for jarring/unjarring ;)
[11:06] <asac> Jazzva: thats bad practice for sure ;)
[11:07] <Jazzva> hmm ... Didn't know about ant :)
[11:07] <asac> he?
[11:07] <asac> you can use anything you want
[11:07] <Jazzva> If the upstream doesn't provide a build script?
[11:08] <asac> we add one in that case. you can also provide a rule in rules and call that fro CMD
[11:08] <Jazzva> That's what I did... although, I left xpi.mk to call it :)
[11:08] <asac> like $(MAKE) -f $(CURDIR)/debian/rules RULENAME
[11:09] <asac> Jazzva: in any case ... the rules file should be capable of jarring up
[11:09] <asac> if there is no .jar
[11:10] <Jazzva> Ok
[11:10] <asac> i don' think it matters for us
[11:11] <asac> even if .upstream branch ships a .jar the merge should succeed unless we edit the .jar in ubuntu branch
[11:11] <asac> its just important that the build matches the extract part
[11:11] <Jazzva> Yep :). After the testbuild... If it's ok, then it should be just tested; else, notify a maintainer to check the code?
[11:12] <asac> Jazzva: right ... i think we need a tool that displays what .staging branches have updates
[11:12] <asac> so a maintainer with power to merge and release can do that job
[11:12] <asac> Jazzva: let me think about the error case :/
[11:12] <asac> hmm
[11:12] <Jazzva> Well, we could just modify fta's script to include check for staging branches
[11:13] <asac> yes, but maybe we should not punch everything into a single script
[11:13] <asac> but not sure what can go into a single script
[11:14] <Jazzva> Hmm, ok. We could make initial staging branches from current upstream, and then just check them
[11:14] <asac> right
[11:14] <Jazzva> At the end of updataing cycle, if everything is ok, just push it to the upstream branch, and there we have it :)
[11:15] <asac> bzr diff +  a check for changelog version maybe
[11:15] <asac> to the upstream branch?
[11:15] <asac> you mean ubuntu branch?
[11:15] <Jazzva> Right :)
[11:15] <Jazzva> and *updating
[11:15] <asac> ok, so how does changeing the packaging work?
[11:16] <Jazzva> Changing the packaging?
[11:16] <asac> how does the script detect that a staging branch might be outdated?
[11:16] <asac> Jazzva: well. in a perfect world we won't need to edit the .ubuntu branch
[11:16] <asac> but maybe there are improvements to be done
[11:17] <asac> now i do 0.2-0ubuntu2 in the .ubuntu branch ... but staging has 0.3-0ubuntu1 ... based on 0.2-0ubuntu1
[11:17] <Jazzva> Check it's version ... check amo version ... if amo version > staging version, then it's outdated :)
[11:17] <Jazzva> (that's for the outdated)
[11:17] <Jazzva> Right, upstream could change the build script, or include some other directories, or change the package layout, or ...
[11:18] <asac> hmm ... its not about the upstream version, but about the -packaging revision
[11:18] <asac> 0.3-0ubuntu1 on top of 0.2-0ubuntu1 would still be higher than 0.2-0ubuntu2, but it would have an outdated packaging
[11:18] <asac> but i have an idea
[11:18] <Jazzva> Hmm... why would we use 0.2-0ubuntu1 packaging, if we have 0.2-0ubuntu2?
[11:19] <Jazzva> Shouldn't the ubuntu branch contain 0.2-0ubuntu2 already
[11:19] <Jazzva> ?
[11:19] <asac> Jazzva: because that might be what the auto upgrade script did for us
[11:19] <asac> Jazzva: its probably not instantaneous
[11:19] <asac> e.g. there might be time where its out of sync (for a day or so)
[11:19] <asac> we should be able to detect it
[11:19] <asac> but i think its easy
[11:19] <asac> branch the .ubuntu branch
[11:20] <asac> try to _pull_ the staging branch
[11:20] <asac> if that hsa *diverged* we are out-of-sync and should wait for the next merge to happen
[11:20] <asac> but still the script would need to recognize that it should trash the current .staging and remerge the latest upstream to the latest ubuntu branch
[11:21] <Jazzva> Sounds good ...
[11:21] <Jazzva> And not too complicated :)
[11:23] <Jazzva> So, we have the process done, but without the error cases, right?
[11:23] <asac> dholbach: thanks.
[11:23] <dholbach> hi asac
[11:24] <asac> Jazzva: i think so yes
[11:25] <Jazzva> Yay :). Just to think of all the possible error cases...
[11:25] <Jazzva> *Now just ...
[11:26] <asac> Jazzva: so rehab: auto upgrade upstream branch
[11:26] <asac> how?
[11:26] <Jazzva> I'll have to go in 5-10 minutes ... School from 14:00. I think I will be back around 18, 18:30...
[11:27] <asac> ok fine
[11:27] <asac> lets talk then later
[11:27] <Jazzva> Auto upgrade upstream :)
[11:28] <Jazzva> so... if we're doing everything in staging branch, then we can check the if amoversion > staging version. If it is, then download the source from amo, use it in staging branch, and at the end, push the clean source to the upstream branch...
[11:28] <Jazzva> I think...
[11:29] <Jazzva> asac ^
[11:30] <asac> Jazzva: yes. that sounds sane
[11:30] <asac> Jazzva: so we only support a default source layout?
[11:30] <geser> I've a problem that ff 3.0b5 segfaults for me (hardy amd64) during startup. the interesting thing is that if I remove extensions.cache from my profile or start firefox -safe-mode once (and quit it immediately), I can start firefox without problems (but only once) and second start segfaults again
[11:30] <geser> what could that be?
[11:31] <Jazzva> geser: Bad extension(s)?
[11:31] <asac> geser: what locale are you using?
[11:31] <geser> LANG=en_IE.UTF-8
[11:31] <asac> what is IE?
[11:32] <geser> ireland
[11:32] <asac> geser: what language pack is that?
[11:32] <asac> is that any?
[11:32] <Jazzva> asac: "default source" as in "chrome with contant, locale, skin dirs and stuff"? Hmm, if the upstream doesn't change the source layout, then we could handle all :).
[11:33] <asac> Jazzva: i just wonder about the jar thing now ;)
[11:33] <asac> but maybe we can always extract any jar to a dir like $JARNAME!/
[11:33] <geser> asac: the addons window listen en-GB (for firefox and xulrunner) at languages
[11:34] <Jazzva> asac: I think I handled it ok in rules files ... even if it's a bit "wrong" ;)
[11:34] <Jazzva> Let me paste how I did it :)
[11:35] <asac> geser: hmm i doubt that its due to the locale. we don't have a gnome-en-gb language pack
[11:35] <asac> geser: does moving away your profile help?
[11:36] <asac> e.g. fresh profile?
[11:36] <Jazzva> asac: it's not the prettiest zip commands ever, those should be changed :)... http://paste.ubuntu.com/7755/
[11:37] <geser> asac: fresh profile works
[11:37] <asac> geser: try to disable extensions one by one and see which causes this crash
[11:37] <asac> geser: firebug?
[11:38] <Jazzva> asac: As far for the xpi zip, I think the main point is to exclude debian/ and temp-xpi-*/ dirs.
[11:38] <asac> Jazzva: i think the layout is too specific
[11:38] <geser> asac: firebug was a good guess. Known issue?
[11:39] <asac> geser: yes. do you have adblock as well?
[11:39] <asac> i think the combo is pretty painful
[11:39] <Jazzva> asac: Ok, I'll think about producing jar and xpi files today :). Off to school now...
[11:40] <geser> adblock plus 0.7.5.4 and firebug 1.1.0b12
[11:40] <asac> we will push a new upstream version to -proposed once jetsaredim comes around ... maybe stay here so we can ask you to verify that its gone
[11:40] <Jazzva> See you later
[11:40] <asac> geser: yes, thats a known thing then
[11:40] <asac> Jazzva: good. cu later
[11:41] <asac> geser: ill try to remember to ask you to verified the -propsed update
[11:41] <geser> ok
[11:41] <asac> geser: you could try the latest firebug upstream release (1.2.0) that came out two days ago or so
[11:43] <geser> asac: where? www.getfirebug.com lists 1.0 and 1.1beta
[11:44] <asac> geser: not 100% sure, jetsaredim would know better. what i find is http://getfirebug.com/releases/firebug/1.2/firebug-1.2.0a21X.xpi
[11:45] <asac> geser: https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firebug.ubuntu
[11:45] <asac> try tat
[11:46] <asac> that
[11:46] <asac> just debuild -b it
[11:46] <asac> thats the suggested update for -proposed afaict
[11:47] <geser> asac: I tried the xpi and firefox doesn't crash anymore (and firebug seems to work again)
[11:47] <asac> geser: could you uninstall that xpi and try that branch as well?
[11:47] <asac> should be just a minute or so to build and install and would help me to get confidence about it ;)
[11:48] <geser> yes, wanted to do that just now
[11:48] <asac> thanks
[11:48] <asac> maybe open a bug against https://bugs.edge.launchpad.net/ubuntu/+source/firebug which we can name in changelog
[11:48] <asac> to gather feedback in -proposed
[11:49] <asac> let me open a bug
[11:50] <asac> geser: bug 220562
[11:50] <ubotu> Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [Undecided,New] https://launchpad.net/bugs/220562
[11:51] <asac> maybe confirm it ;)
[11:52] <asac> ok i added the branch to the bug as well
[11:53] <asac> ok subscribed you geser ;)
[11:58] <geser> asac: I tried to build the firebug package in a uptodate hardy pbuilder -> FBTFS http://paste.ubuntu.com/7757/
[12:00] <asac> geser: please comment on bug then. jetsaredim will fix it i guess
[12:00] <asac> thanks
[12:01] <asac> i updated the branch whiteboard on the bug already -> * FTBFS
[12:01] <asac> but  comment won't hurt ;)
[12:02] <asac> the archive is now locked down anyway, so i guess we have another two days before we need a real fix
[12:02] <asac> but good to know that upstream xpi at least fixes it
[12:03] <asac> jetsaredim: remember to look at bug 220562
[12:03] <ubotu> Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [High,New] https://launchpad.net/bugs/220562
[12:08] <geser> bug commented, anything still missing?
[12:11] <asac> geser: i think thats all for now. stay tuned ... the bug will surely have some activity soon.
[12:19] <jetsaredim> asac: I think there is some sort of disconnect in their build system
[12:20] <asac> jetsaredim: disconnect?
[12:20] <asac> what does that mean?
[12:20] <asac> broken?
[12:21] <jetsaredim> eh - looks like they updated the svn since yesterday
[12:21] <jetsaredim> which would account for the version differences
[12:22] <asac> jetsaredim: the build failure is in the bzr branch.
[12:22] <jetsaredim> the package that i built was 1.2b20
[12:22] <asac> no sure that i understand why thats related to upstream svn
[12:23] <jetsaredim> build failure?
[12:23] <asac> yeah :-P
[12:23] <asac> jetsaredim: read bug 220562
[12:23] <ubotu> Launchpad bug 220562 in firebug "frequent crashes with firebug 1.1.0" [High,Confirmed] https://launchpad.net/bugs/220562
[12:23] <jetsaredim> i just read it a minute ago - must not have sunk in though i guess
[12:24] <asac> hehe ... yeah, i frequently fail to believe what i see too ;)
[12:24] <jetsaredim> lemmie try in a clean dir
[12:36] <jetsaredim> wow - something's screwy
[12:36] <jetsaredim> must have missed a commit somewhere
[12:37] <jetsaredim> cause what's in the dir I was using builds
[12:37] <jetsaredim> but when I branch from my branch - it doesn't
[12:44] <asac> jetsaredim: no worries ... we have 2 days to fix :)
[12:58] <jetsaredim> hmm
[12:58] <jetsaredim> helps when you add all new files
[12:59] <jetsaredim> i thought I had done that - but apparently not
[12:59] <asac> ;)
[12:59] <asac> in .upstream or ubuntu?
[12:59] <asac> if .upstream pleaes update .upstream and merge over again
[13:02] <asac> jetsaredim: ^^
[13:02]  * asac prepares for lunch ;)
[13:16] <jetsaredim> ok - i've updated the ubuntu branch
[13:17] <asac> jetsaredim: ill look after lunch. thanks
[13:17]  * asac out for lunch
[13:26] <jetsaredim> geser: have a look at the new branch and let me know
[13:31] <geser> jetsaredim: rev23 builds and works fine
[14:15] <jetsaredim> geser: excellent
[15:03] <asac> jtv: there?
[15:03] <asac> jtv: i think we need a midbrowser template enabled. what would be the steps to get this?
[15:03] <jtv> asac: here
[15:03] <asac> hi!
[15:04] <jtv> asac: "midbrowser"...  as in MID browser?
[15:04] <asac> yeah
[15:04] <asac> its basically firefox + a few strings
[15:04] <jtv> And by "enabled," you mean "imported?
[15:05] <asac> jtv: well. no clue ;) ... if there is nothing to be done up-front we can directly go and import the template, right.
[15:05] <asac> thought maybe there is something needed to enable midbrowser template.
[15:05] <jtv> Probably.  It's probably a bit of an exceptional situation, so some hackery may be in order.
[15:05] <jtv> I have _no_ _idea_ what a midbrowser template involves.
[15:06] <asac> jtv: its en-US.xpi
[15:06] <asac> like what we have for firefox and xulrunner
[15:06] <jtv> Plus extra strings...  different translations as well?
[15:07] <asac> we don't have translations for the strings that came on top of firefox
[15:07] <asac> thats what we want to do in launchpad
[15:07] <asac> the midbrowser en-US.xpi is firefox en-US.xpi + a few more strings in there
[15:07] <jtv> asac: if that is more or less guaranteed, could you treat it simply as a superset of Firefox?
[15:08] <jtv> In other words, pretend like all firefox is firefox-mid, and let the regular firefox ignore some strings it doesn't know about?
[15:08] <Kamping_Kaiser> hi all. i'm rebuilding firefox 3 from the hardy repo with some changes. its finishing after ~2 or 3 minutes. is this how it should be? firefox 1.5 took an hour. i do notice that xul is gone, but even so i'm worried Stuff Is Wrong.
[15:08] <asac> jtv: no, we shouldn't couple those too tightly. the releases might diverge
[15:08] <jtv> :(
[15:08] <asac> further it needs a special en-US.xpi
[15:08]  * jtv thought he was soo smart
[15:09] <asac> otherwise we cannot produce value midbrowser langpacks as the install.rdf is different
[15:09] <jtv> asac: right now, Launchpad doesn't give a hoot about the install.rdf
[15:10] <jtv> so your scripts could replace it in the template that's copied into the exports.
[15:10] <asac> jtv: we use the en-US.xpi we get from midbrowser
[15:10] <jtv> grumble
[15:10] <asac> jtv: whats the problem of making midbrowser has its own template?
[15:11] <jtv> Shouldn't be a problem, really, except I don't know off the top of my head how the auto-approval logic will deal with it.
[15:11] <jtv> You should be able to have two templates in the same product/package, but it'd be a pain if each upload required a manual approval.
[15:12] <asac> jtv: why would i need two templates in the same product?
[15:12] <asac> jtv: i just want to have midbrowser as its own application
[15:13] <asac> approval is something intel has to do
[15:13] <jtv> asac: oh, I assumed that was what you wanted.  Are you talking about two separate products/packages?  That's easy.
[15:13] <asac> no ... its completely separate
[15:13] <jtv> asac: in that case, forget what I said.  :)
[15:13] <asac> its just that we could use the firefox translations to get initial translations
[15:13] <asac> for most of the strings
[15:13] <asac> :)
[15:13] <jtv> That should be a doddle, yes.
[15:13] <asac> approval is not a big problem because we can push this to intel folks
[15:14] <asac> i just want to provide them the infrastructure to do the translations :)
[15:14] <jtv> Well, approvals on the translations import queue go through Yours Truly
[15:15] <asac> oh ... me?
[15:15] <jtv> But after the first approval, if the templates live on separate products/packages, auto-approval should just work.
[15:15] <asac> jtv: ok. so what would be required to enable midbrowser being a project that supports en-US.xpi templates?
[15:15] <jtv> asac: no, Yours Truly means "the person writing this."  It's a joke about the traditional way to finish a letter.
[15:15] <asac> ah ;)
[15:16] <jtv> asac: just set up a regular product and upload the XPI.
[15:16] <asac> jtv: ok. www.launchpad.net/midbrowser thats the project i have
[15:16] <asac> can i just enable translations there?
[15:16] <jtv> asac: sure, or you can do the uploads first.
[15:17] <asac> jtv: ok, you pointed me to tools that help to upload. are those required?
[15:17] <jtv> asac: no, not at all.  Just there to help, but they're built on top of the http[s] UI.
[15:18] <asac> jtv: ok, so i basically can just go to https://translations.edge.launchpad.net/midbrowser/trunk/+translations-upload and upload the en-US.xpi ?
[15:18] <jtv> asac: exactly
[15:19] <jtv> asac: there won't be any automatic cross-pollination of translations, except of course that the translations from the one will show up as suggestions for the other.
[15:19] <asac> jtv: ok, i think i understand. only thing i am uncertain about is that the exports from that project page have a different structure to the exports done for ubuntu
[15:19] <asac> for instance the en-US.xpi is not included i think
[15:19] <jtv> asac: yes, they're very different things.
[15:19] <asac> and the po names are in a different folder and have an application prefixed name
[15:20] <jtv> asac: (phone)
[15:20] <asac> ok, i think we can manually deal with that for now. in the long run we should try to get the en-US.xpi exported everywhere
[15:23] <asac> and the structure should be somewhat similar
[15:23] <asac> no essential be the same, but at least having the LANG.po files in a directory that matches the application would make sense
[15:23] <asac> jtv: will you be in prague?
[15:24] <jtv> asac: (off phone)
[15:24] <asac> sry
[15:24] <jtv> I have no plans to be in Prague, no.
[15:25] <jtv> asac: there is a very different issue with using products that we need to consider.
[15:26] <asac> ok. anything i should be aware of?
[15:26] <jtv> asac: users can come in on pretty much any page of this product, and not know that it's not upstream.
[15:26] <jtv> asac: so they may translate in the mistaken impression that they're contributing directly to upstream.
[15:26] <asac> jtv: for midbrowser thats true
[15:26] <asac> we are upstream translation wise
[15:27] <jtv> asac: in that case, splendid!
[15:27] <asac> at least thats the idea
[15:27] <asac> however, that issue is true for firefox
[15:27] <asac> and i want to work on procedure how we can contribute back
[15:27] <asac> mostly for locales that are not translated upstream i'd like to see something like that
[15:27] <jtv> Right, so make sure it's assigned to a translation group where this is well-understood, and ideally, close it off to others so people don't throw their effort into a black hole.
[15:28] <asac> thats why i asked about UDS attendance, because i think it would have been beneficial to discuss this process in depth
[15:28] <jtv> asac: it's likely that such contribution would be very much appreciated.
[15:28] <jtv> asac: if you like, we could have some voice calls about this later.
[15:28] <jtv> asac: (my working day is just about done)
[15:28] <asac> yeah surely. i have to get some more ideas first, but Ill surely come back to that
[15:28] <asac> jtv: no not right now ;)
[15:29] <asac> within the next two weeks i can surely come back
[15:29] <jtv> I'm sure it will be beneficial to both of us.
[15:29] <asac> jtv: not sure if carlos communicated that to you, but i did some work on chrome.manifest intepretation and i think i could come up with a path to chrome:// url mapping script
[15:30] <asac> which should provide a perfect context
[15:30] <asac> not sure if you could make use of that
[15:30] <asac> to improve the fuzziness of translation imports
[15:30] <jtv> asac: I was just looking at it in the code... doesn't look all that hard, tbh
[15:30] <asac> yes its simple
[15:31] <jtv> asac: experience so far suggests that assumptions are our greatest enemy.
[15:32] <asac> its basically: if you find the path on the right, chop it off and append the rest to a chrome url that starts with chrome://2ndCOLUMN/1stCOLUMN/rest
[15:32] <asac> jtv: thats a defined thing
[15:32] <asac> thats not an assumption
[15:32] <asac> e.g. chrome://global/locale/RESTOFTHEPATH
[15:36] <jtv> asac: that part was clear.  I'm thinking more of things like: what if someone puts a file instead of a directory there?  Can a file occur in multiple chrome paths?  What if a jar file is nested inside another jar file?  Do we deal well with two locales in one jar file, one locale in two jar files, two locales in two jar files but mixed up?
[15:36] <jtv> Most of it seems easy to deal with, as long a we think of it in time.  :)
[15:39] <asac> jtv: we could eliminate most "mixed-up" corner cases by mangling xpis before the actual import happens.
[15:40] <asac> jtv: howver, agreed, we should note down any question that might arise and evaluate them properly
[15:40] <asac> in advance
[15:41] <jtv> I think low-level unit testing will play an important role there.  I'm implementing a separate class for manifest files that figures out chrome paths.
[15:41] <jtv> We can test that for weird cases regardless of whether we can reproduce them in actual input.
[15:42] <asac> jtv: sure.
[15:42] <asac> sounds good
[15:42] <asac> i agree that we should go for the big fish in this cycle and get it right
[15:43] <jtv> asac: fish?  Were we talking about fish?
[15:44] <asac> yeah :)
[15:44] <asac> meaning: no half-baked solution
[15:47] <jtv> ah, okay, you want your fish well-fried.  Personally I like raw herring, but there you go.
[15:47] <asac> :)
[15:47] <asac> didn't know that you have herring at all in your town :-P
[15:51] <jtv> Tragically, no.  But I am Dutch after all.
[15:52] <asac> i know ;)
[16:05] <jtv> asac: another cute case...  do paths in the manifest absolutely _have_ to start with "jar:"?
[16:07] <asac> jtv: no
[16:07] <asac> if they don't they refer to non jarred directories
[16:08] <jtv> So another nice corner case is when they do start with jar: but don't have to
[16:18] <asac> jtv: i am pretty sure that mozilla will choke on that ... but could verify. did you encounter any such case?
[16:19] <jtv> asac: no, but I've already written the code to handle it.
[16:21] <asac> sounds scary. i think you should fail hard if such a case is encountered :)
[16:22] <jtv> asac: I'll call that policy rather than mechanism though.  :-)  I normalize paths so I can match them reliably.
[16:22] <jtv> So "//" becomes "/" etc.
[16:24] <asac> jtv: right ... but happens during export later :)
[16:24] <asac> *brain twists*
[16:25] <asac> should work to export them without jar:  ... but hairy enough ;)
[16:25] <jtv> asac: have to do it on import as well, just to make sure I find the manifest entry that matches a file.
[16:25] <jtv> But if the code turns out to be reusable on export, so much the better.
[16:25] <asac> jtv: personally i would think that launchpad should also be able to refuse .xpis that have bogus format
[16:25] <asac> having a jar: path that refers to a directory not in a jar would certainly be a bogus xpi imo
[16:27] <asac> jtv: sure we have to do that on import. i just stated that the idea to export something properly from a broken xpi makes my brain twist :)
[16:27] <asac> jtv: do you need more corner cases?
[16:28] <asac> jtv: there are SYSTEM entities in the .dtd files ... that basically include a separate dtd.
[16:28] <asac> do you have a solution for that?
[16:28] <asac> further there are other files than .dtd and .properties accessible with locale/ chrome path. those should probably be imported as one single big entity each
[16:29] <asac> e.g. .../about.xhtml
[16:29] <asac> same goes for images ... but i guess figuring out how to translate images is pretty hairy ;)
[16:29] <asac> and might need some hard work we probably won't be able to do
[16:30] <jtv> (Sorry, had to deal with onsetting rain here)
[16:30] <asac> but thats a rare case i haven't seen since old thunderbird releases (1.0.x)
[16:30] <asac> and even back there those images were not translated ... just copied.
[16:30] <asac> so our current po2xpi code would catch that
[16:31] <asac> however, same could be true for sound and video ... and what not :)
[16:31] <asac> :-P
[16:31] <jtv> I don't think we should try to to import and translate everything...
[16:31] <jtv> Gotta go now!
[16:31] <asac> jtv: talk to you later
[16:31] <jtv> bye
[16:31] <asac> have a nice evening
[16:31] <jtv> Thanks, same to you
[16:33] <jetsaredim> asac: is there anything else you need me to do for that firebug package?
[16:55] <asac> jetsaredim: currently trying to figure out if there is a slot to push this into hardy still
[16:56] <jetsaredim> k
[17:48] <asac> bug 217815
[17:48] <ubotu> Launchpad bug 217815 in kvm "Installation stalls randomly until a key is pressed" [High,In progress] https://launchpad.net/bugs/217815
[17:50] <armin76> gentoo bug 100001
[17:50] <ubotu> Launchpad bug 100001 in pidgin "[apport] gaim crashed with SIGSEGV in exit()" [Medium,Invalid] https://launchpad.net/bugs/100001
[17:50] <armin76> bah
[17:53] <asac> hehe
[17:53] <asac> gentoo not integrated ;) ?
[17:53] <asac> are you using bugzilla?
[17:54] <armin76> yup
[18:19] <Jazzva> asac, back from school. Just tell me when you have time for auto-upgrade discussion...
[18:28] <asac> Jazzva: let me finish quick-dinner :)
[18:28] <Jazzva> Ok, I might have a quick-nap as well :)
[18:47] <skwashd> hi all
[18:47] <skwashd> are there any fixes for firefox in the pipeline for hardy?
[18:48] <skwashd> i am finding it almost unusable for any serious work
[18:51] <asac> skwashd: most likely its extensions that bust you
[18:52] <skwashd> asac: 3b3 on hardy worked a treat
[18:52] <skwashd> and it has been going down hill each time i install a new firefox deb since then
[18:54] <asac> most likely because each and every release more extensions got enabled?
[18:54] <asac> as i said. most likely you are seeing issues because of extensions
[18:54] <asac> what extensions are you using?
[18:55] <asac> skwashd: ?
[18:56] <skwashd> editcss, firebug, flashblock, foxclocks (Which can go), operaview, scrapbook, tamperdata, ubuntu hacks, webdev
[18:56] <skwashd> asac: it takes some time to type them all out
[18:57] <asac> jetsaredim: the upstream branch is gone
[18:57] <asac> skwashd: disable firebug for now
[18:57] <asac> that causes instability
[18:57] <skwashd> asac: lmao
[18:57] <skwashd> it will be easier to go back to firefox2
[18:58] <asac> whatever you like. but its not firefox ... it surely is firebug ... which we are about to fix
[18:58] <jetsaredim> skwashd: get it from my ppa....
[18:58] <skwashd> i really think ubuntu is making a serious mistake shipping a flakey beta for a LTS release
[18:58] <jetsaredim> https://edge.launchpad.net/~jetsaredim/+archive
[18:58] <skwashd> jetsaredim: get what?
[18:58] <asac> jetsaredim: where is the upstream branch?
[18:58] <jetsaredim> skwashd: there's a new firebug package there
[18:59] <jetsaredim> 1.2b21
[19:00] <jetsaredim> asac: I didn't
[19:00] <jetsaredim> i just updated in place
[19:00] <skwashd> jetsaredim: xpi is for firefox extensions ... it is insane to use 3rd party debs from unknown sources for firefox extensions
[19:00] <jetsaredim> there was so damned many changes to the code base
[19:00] <asac> jetsaredim: but where is our upstream branch?
[19:01] <asac> jetsaredim: this should have been done by merging from the updated upstream branch for sure ... in anycase the upstream branch is gone now
[19:01] <jetsaredim> it should still be around
[19:01] <jetsaredim> in my bzr area - just i didn't use it
[19:01] <asac> why?
[19:01] <jetsaredim> cause it was 5 billion times easier to just do it this way
[19:02] <jetsaredim> i can re-do it if you want
[19:02] <asac> yeah, but its hard to maintain things in that way
[19:02] <asac> jetsaredim: please push the upstream branch again and don't remove it ever :)
[19:02] <jetsaredim> but where wasn't anything worth saving from the old code other than debian, which i did save
[19:02] <jetsaredim> its not gone
[19:02] <skwashd> lol ... the debs aren't even official releases ... they are svn snapshots
[19:02] <skwashd> thanks guys
[19:02] <jetsaredim> there is no official release that works with ff3
[19:02] <jetsaredim> ass
[19:03] <asac> don't mind ... hes is a troll
[19:03] <jetsaredim> so yea - there was nothing worth keeping in the old branch except the debian dir - which i did keep and added to the changelog
[19:03] <asac> jetsaredim: the upstream branch is important
[19:03] <asac> we cannot produce an orig.tar.gz anymore now
[19:04] <asac> jetsaredim: and i cannot find the old upstream branch anywhere on launchpad :/
[19:04] <jetsaredim> hmm
[19:04] <asac> jetsaredim: the upstream branch shouldn't have any debian/ directory anyway
[19:04] <jetsaredim> i must've cleaned it out
[19:04] <asac> just upstream sources.
[19:04] <jetsaredim> yea
[19:04] <asac> plese push it again
[19:04] <asac> apply the svn snapshot on top of that
[19:05] <asac> commit ... and then merge that over to the .ubuntu branch
[19:05] <asac> otherwise things become really unmaintainable in the long run. i promiss
[19:05] <jetsaredim> going to need to re-gen it from the package then
[19:05] <jetsaredim> i don't keep things around locally
[19:06] <asac> you can branch the initial revision
[19:06] <asac> push that as .upstream
[19:06] <jetsaredim> o right
[19:06] <jetsaredim> 19 or whatever
[19:06] <asac> bzr branch -r 1 PATH/to/UBNUTU
[19:07] <jetsaredim> ok - so here's a question then
[19:07] <jetsaredim> i had done all that
[19:07] <jetsaredim> then when I went to merge the upstream onto the ubuntu it removed my debian dir
[19:07] <jetsaredim> to which i was like - w t f
[19:08] <asac> jetsaredim: you probably tried to convert the .ubuntu branch to upstream branch ... which would remove the debian/ dir
[19:08] <asac> jetsaredim: it won't do that for sure if the upstream branch doesn't have debian/ dir
[19:10] <asac> yeah. nevermind. branh out revision 1 ... commit new upstream on top ... and merge that to the .ubuntu branch of .core-dev
[19:10] <jetsaredim> ?
[19:10] <asac> aeh the ~ubuntu-dev branch i mean
[19:10] <fta> hm, my box reloaded by itself 2h ago
[19:11] <asac> jetsaredim: all clear?
[19:11] <jetsaredim> bzr branch http://bazaar.launchpad.net/~ubuntu-dev/firefox-extensions/firebug.ubuntu
[19:11] <asac> jetsaredim: use bzr branch -r 1 ....
[19:11] <asac> to get the initial revision only
[19:11] <jetsaredim> r1?
[19:12] <asac> yes
[19:12] <asac> revision 1
[19:12] <fta> asac, Universe Freeze Imminent... do we still need to push something ?
[19:12] <asac> yes ... we need to push firebug now
[19:15] <jetsaredim> i must be totally fucking dense or something cause i'm confused as batshit
[19:15] <asac> hehe
[19:15] <asac> jetsaredim: ok ... take a breath. whats not clear?
[19:15] <jetsaredim> ok - why am i branching r1 of ubuntu-dev firebug
[19:16] <jetsaredim> that is the original old as shite firebug package
[19:16] <asac> jetsaredim: you want to recover the lost .upstream branch
[19:16] <asac> jetsaredim: the lost upstream branch was basically the first revision of .ubuntu
[19:16] <asac> not more
[19:16] <jetsaredim> er ok
[19:17] <jetsaredim> so just push that to my bzr area?
[19:17] <asac> as .upstream ... yes.
[19:17] <asac> then we have hopefully recovered the lost upstream branch and can go on
[19:18] <jetsaredim> k done
[19:18] <jetsaredim> now drop in the new firebug code
[19:18] <asac> good ... now change to that directory and rm -r *
[19:18] <asac> and add the files from svn checkout
[19:18] <asac> then run bzr add .
[19:18] <asac> and bzr commit -m "* new upstream snapshot XXXX"
[19:20] <asac> jetsaredim: remember to remove the .svn dirs before you commit
[19:21] <asac> otherwise you have to re-remove them in .ubuntu
[19:22] <jetsaredim> ok - brb
[19:22] <james_w> asac: remind me to explain to you sometime how this process of packaging svn snapshots can be made easier.
[19:22] <asac> james_w: yeah :)
[19:22] <jetsaredim> james_w: /me is all ears
[19:22] <asac> james_w: hehe :) ... we are currently fighting firebug ... we can improve the procedure after we stopped this
[19:22] <asac> :)
[19:23] <james_w> yeah, I realise you need to get it in quickly, so I won't distract you
[19:23] <asac> jetsaredim: ok when done you branch the ~ubuntu-dev branch again
[19:23] <asac> switch to that directory
[19:23] <james_w> it's just that jelmer has put effort in to making this efficient, and it might help you here.
[19:23] <asac> bzr merge /path/to/upstream/branch
[19:24] <asac> then add new changelog entry ... and commit
[19:24] <asac> james_w: yeah :) ... thanks. will get back to you asap on this. we certainly want a better approach :)
[19:27] <asac> james_w: i think jetsaredim is off for a few :) ... go ahead :)
[19:28] <asac> whats the idea? start with synching svn to bzr?
[19:28] <james_w> asac: sorry, I'm leaving in a few, can it wait until another time?
[19:28] <asac> sure
[19:28] <james_w> the basic idea is to use bzr-svn to grab the branch you want as upstream, and use builddeb's export upstream mode to turn that in to tarball for you.
[19:29] <james_w> then you do something magic that I've forgotten, and to update to a new snapshot you just change the version number in debian/changelog.
[19:29] <james_w> unfortunately you may have to abandon existing branches, I need to think about it.
[19:31] <asac> james_w: yeah. i understand i use builddeb to produce origs, but for now we maintain the upstream branch manually
[19:31] <asac> james_w: is there a way to tell builddeb to use a specific upstream revision/or tag?
[19:31] <asac> for export?
[19:31] <asac> james_w: well ... we might be able to rebase maybe?
[19:32] <asac> james_w: but tough task to migrate existing ones.
[19:40] <jetsaredim> asac: ok back
[19:40] <asac> cool
[19:40] <jetsaredim> so now - checkout the latest ubuntu-dev as local .ubuntu
[19:40] <asac> yep
[19:41] <asac> then merge the new .upstream onto it
[19:41] <asac> and add a new changelog entry for this release before you commit
[19:41] <asac> if you need to resolve a conflict let me know
[19:41] <asac> if any it should be install.rdf that has a conflict i guess
[19:42] <jetsaredim> which is odd since there's no install.rdf in the new branch
[19:42] <asac> jetsaredim: welll whatever the file is called
[19:42] <asac> install.rdf.xml or something
[19:42] <jetsaredim> Text conflict in build.xml
[19:42] <jetsaredim> Contents conflict in install.rdf
[19:43] <asac> jetsaredim: is install.rdf not in new branch?
[19:43] <asac> jetsaredim: ok edit build.xml and resolve the conflict
[19:43] <jetsaredim> yea gone
[19:43] <asac> ok then it was accidentially added to the initial revision i guess
[19:43] <asac> lets seal with that later
[19:43] <asac> deal
[19:44] <asac> jetsaredim: fix buld.xml ... you should be able to see the conflict by its markers: <<<<<<< ... [19:45] <jetsaredim> i'm just going to copy the new version from the existing .ubuntu in my code area
[19:46] <asac> hmm ... how does the conflict look like?
[19:46] <asac> you can probably do that ... but usually resolving conflicts should do the right thing and ensure that you don't forget anything ;)
[19:46] <jetsaredim> they restructured the build.xml file a bunch
[19:46] <asac> ok
[19:47] <jetsaredim> for the branch that is up there in my code area working for people
[19:47] <jetsaredim> i had taken the new build.xml and patched it to work
[19:47] <jetsaredim> so - now just commit that as "new upstream merged" or something
[19:47] <asac> name the version you merged ... and maybe the bzr revision from upstream branch (2)
[19:47] <asac> jetsaredim: remember to open a new changelog entry
[19:47] <asac> before you commit
[19:48] <asac> with the proper upstream version and so on
[19:48] <asac> maybe use UNRELEASED instead of hardy in the header of that entry
[19:48] <asac> jetsaredim: ^^
[19:48] <jetsaredim> does it really matter?
[19:48] <asac> jetsaredim: what? using UNRELEASED? its best-practice. otherwise no.
[19:49] <jetsaredim> unreleased vs hardy?
[19:49] <asac> jetsaredim: it matters in that in case things need to be fixed after the merge
[19:49] <jetsaredim> no i mean - its going to mean that i'm going to have to change it anyway right?
[19:49] <asac> jetsaredim: well ... you don't. i'll add a commit on top when i release it ... flipping it to hardy
[19:50] <jetsaredim> can't build it without the "hardy" though
[19:50] <asac> you can do this "release commit" as well. but usually we have a single empty commit before we upload that flips it
[19:50] <asac> jetsaredim: you can build ... you just cannot upload... which is intended
[19:50] <asac> jetsaredim: for now ... just do as you like
[19:50] <asac> UNRELEASED is good ... hardy is not bad ;)
[19:52] <asac> jetsaredim: ok ... build.xml resolved?
[20:01] <jetsaredim> how can I push this new .ubuntu on top of my old .ubuntu that I had there
[20:01] <james_w> asac: sorry, I was eating. There is "export-upstream-revision", and some magic jelmer put in on top of that so you can do +svn25 to use revision 25.
[20:02] <asac> jetsaredim: did you manage to commit locally?
[20:02] <asac> jetsaredim: you can use bzr push --overwrite YOURURL.ubuntu
[20:05] <jetsaredim> odd
[20:05] <jetsaredim> dch seems to have changed firebug to fire bug
[20:06] <jetsaredim> anyway - its pushed to .ubuntu
[20:07] <jetsaredim> just taking a moment to propagate
[20:07] <jetsaredim> ok - its there
[20:08] <asac> ok let me check this out
[20:08] <asac> jetsaredim: ouch you updated to a new upstream release :(
[20:08] <asac> we had tests on the other.
[20:08] <mdke> asac: the links should be the only substantive changes. Otherwise, the only changes I've made since the previous upload are to po files, which aren't used in the build or the binary package
[20:08] <jetsaredim> ??
[20:09] <jetsaredim> i'm just doing what you told me
[20:09] <asac> mdke: we figured why that happened. however i cherry-picked just the link patch
[20:09] <asac> jetsaredim: he? we had svn572 tested
[20:09] <mdke> asac: ok, thanks
[20:09] <asac> now we have svn573
[20:09] <jetsaredim> o
[20:09] <jetsaredim> i can revert that
[20:09] <jetsaredim> they updated the svn since last night
[20:09] <asac> jetsaredim: well ... you already merged it and so on :)
[20:10] <asac> jetsaredim: yes, but we have testers on the other revision
[20:10] <jetsaredim> ok no biggie
[20:10] <asac> geser: still there?
[20:10] <asac> jetsaredim: wait lets see if we can get tests on the latest
[20:10] <asac> jetsaredim: did you try to build and all?
[20:11] <asac> jetsaredim: otherwise this merge looks good.
[20:11] <asac> lets see if we can get testers for the new version
[20:12] <jetsaredim> yea build is fine
[20:12] <jetsaredim> i can put another build in my ppa
[20:12] <jetsaredim> lemmie update the bug
[20:13] <asac> jetsaredim: not needed ill send the deb directly to matt and hopefully geser can test
[20:13] <jetsaredim> ok
[20:14] <asac> jetsaredim: please fix the upstream version in changelog :)
[20:14] <jetsaredim> damnit
[20:15] <jetsaredim> its not right
[20:15] <jetsaredim> the version in the addons window is reporting 1.2a20X
[20:15] <jetsaredim> this is dumb
[20:15] <jetsaredim> i have to go bitch out a mechanic for damaging my wheels
[20:16] <asac> jetsaredim: hehe ... please just change the upstream versio nin changelog to read 573
[20:16] <asac> its out of sync with what is in changelog
[20:16] <asac> jetsaredim: 1.2~b21+573 vs 1.2~b21+572
[20:16] <mdke> asac: is there a way to test localisations without relogging in?
[20:16] <asac> mdke: online/offline?
[20:16] <mdke> LANG=X firefox doesn't seem to work
[20:17] <mdke> asac: sorry, I mean to switch language
[20:17] <asac> mdke: for the UI or the startpage?
[20:17] <geser> asac: yes. I'm still here
[20:17] <mdke> asac: they should go together, right?
[20:17] <mdke> but I'm interested in the startpage
[20:17] <jetsaredim> geser: can you test a new version
[20:17] <asac> geser: can you test the latest firebug branch one more time?
[20:17] <geser> sure
[20:18] <asac> geser: we had to resolve some branch issues ;) ... but now it should be more or less right :)
[20:18] <jetsaredim> i just refreshed the svn cause I had to repackage the deb
[20:18] <jetsaredim> heh - the new branch rev is 21
[20:18] <asac> jetsaredim: i can fix the upstream versio nin changelog if you want
[20:18] <jetsaredim> just did
[20:18] <asac> otherwise please use 1.2~b21+svn573
[20:18] <jetsaredim> and pushed it
[20:18] <asac> did you add svn?
[20:18] <asac> i just saw that you dropped that ;)
[20:18] <jetsaredim> ?
[20:18] <asac> svn573
[20:18] <asac> vs
[20:18] <asac> 573
[20:19] <jetsaredim> omfg - i am going to kill someone
[20:19] <asac> hehe
[20:19] <asac> all cool. we are ---><--- that close
[20:19] <jetsaredim> pushing again
[20:19] <jetsaredim> geser: make that rev 22
[20:20] <asac> geser: if you have done the testing, please comment on bug again as i need some positive input for this upload
[20:21] <asac> hmm m... waiting for LP to sync ;)
[20:22] <jetsaredim> the changelog should be marked as version 1.2~b21+svn573
[20:22] <geser> how long will it take till rev 22 will be available?
[20:23] <asac> yeah launchpad sucks again
[20:23] <asac> ha i have it :)
[20:23] <asac> its there
[20:23] <asac> geser: ^^
[20:24] <jetsaredim> so you can get it by branch - but its not listed on the site
[20:25] <asac> probably soon as well
[20:26] <geser> my pbuilder is already running
[20:26] <geser> package successfully build, now installing
[20:28] <geser> hmm, firefox doesn't crash but firebug doesn't work
[20:28] <jetsaredim> ?
[20:29]  * jetsaredim gives up
[20:29] <jetsaredim> I have t run
[20:29] <geser> forget my last comment, I had a firefox still running on an other workspace
[20:29] <geser> firefox doesn't crash and firebug works fine
[20:30] <jetsaredim> phew
[20:30] <jetsaredim> ok - really have to run now
[20:30] <asac> jetsaredim: thanks a lt
[20:30] <geser> jetsaredim: thanks
[20:31] <asac> jetsaredim: and sorry for the pressure on this :)
[20:33] <asac> jetsaredim: uploaded
[20:33] <asac> geser: can you comment on bug
[20:33] <asac> ?
[20:33] <geser> asac: already done
[20:33] <asac> geser: about the latest version?
[20:33] <asac> i only see "rev23 builds and works fine (firebug 1.2~b21+svn572-0ubuntu1)."
[20:34] <asac> which is about the other version
[20:34] <asac> ah ok
[20:34] <asac> i see
[20:38] <asac> fta: Jazzva: where to put our upstream extension branches?
[20:39] <asac> i think we should push them somewhere where nobody removes them :/
[20:42] <asac> Jazzva: was bug 156714 resolved by latest app-install data update?
[20:42] <ubotu> Launchpad bug 156714 in firefox-extensions "Installing Sage from Ubufox does not add extension" [Undecided,Confirmed] https://launchpad.net/bugs/156714
[20:42] <asac> speaking about ... i think i missed to get that merged :/
[20:42] <asac> *argh*
[20:44] <asac> mdke: ok ... how can we fix the ubuntu-docs branch. i'd suggest that i upload a branch with the cherry pick on top and you could merge it in the main branch?
[20:44] <asac> mdke: sorry i dropped the ball on your question. for LANG=XX to work you need the XX langpack
[20:45] <asac> mdke: if you just wnat to test startpage you change change preferred display language in the preferences dialog
[20:52] <Jazzva> asac: Sage doesn't work for FF3
[20:52] <asac> Jazzva: ok
[20:52] <Jazzva> So, its FF2-only for app-data
[20:52] <asac> Jazzva: but we moved it to firefox-2 mimetype right?
[20:52] <Jazzva> Ye
[20:52] <Jazzva> Yes
[20:53] <Jazzva> I think we even uploaded the fix for debian/control
[20:53] <Jazzva> Umm ... just to see if you merged the latest app-install-data which I submitted
[20:54] <asac> Jazzva: i think i didn't ... which i found out above
[20:54] <asac> Jazzva: ill take care that this goes to -updates asap
[20:54] <asac> Jazzva: maybe bug me daily about this ... i sometimes need to be kicked apparently
[20:54] <Jazzva> hmm ... Maybe it was changed in some later submission :)
[20:55] <asac> Jazzva: sage is definitly not in the extensions dialog we have now in hardy. so i closed this bug for now
[20:55] <asac> Jazzva: however, the list is unfortunately really not the latest.
[20:55] <asac> at least firebug is missing :)
[20:55] <Jazzva> Then it was changed in the earlier submission :)
[20:56] <Jazzva> I'll take a look at the branches :)
[20:56] <asac> good thing is that i can argue that firebug was too crashy ... and tell mvo that thats the reason why we need it in -updates as its now sorted out
[20:56] <Jazzva> (sorry for not replying ... I forgot to wake up when the alarm started ringing)
[20:56] <Jazzva> heh, there's a reason :)
[20:57] <Jazzva> Yep... It was merged with rev544, while the lates I pushed is 548
[21:01] <asac> yeah ... wel'll figure
[21:01] <Jazzva> Member of the Mozilla team? Yaaay. Thanks :). (just noticed the mail)
[21:01] <asac> Jazzva: thought it was time :)
[21:02] <asac> welcome!
[21:02] <Jazzva> And I think I skipped bzr add . for one revision so, I think we don't have torbutton.desktop in current rev :). Good think it wasn't merged :)
[21:02] <Jazzva> Thanks :)
[21:02] <asac> Jazzva: ok cool. maybe fix it then ;)
[21:03] <Jazzva> Sure...
[21:08] <mdke> asac: got it, thanks. For ubuntu-docs, i'm happy to merge any changes manually. It's a shame that the branch doesn't represent the current source package though
[21:09] <mdke> asac: we'll tidy that up after release I guess
[21:10] <asac> Accepted: firebug 1.2~b21+svn573-0ubuntu1 (source)
[21:10] <asac> jetsaredim: ^^
[21:10] <asac> ok we are done
[21:10] <asac> no more uploads from the mozillateam
[21:11] <asac> mdke: i couldn't because i wanted just the top most commit
[21:11] <asac> mdke: ill commit that commit on top of the version that was previously uploaded (i think 12 apr)
[21:11] <asac> then we can merge that into the -docs branch and everything should still be fine
[21:12] <asac> (again) :)
[21:13] <asac> fta: i just wanted to give you heads up that we have a victory ;)
[21:13] <asac> fta: http://paste.ubuntu.com/7793/
[21:13] <asac> fta: "Don't build the standalone glue as a
[21:13] <asac> #    dynamic library. This is actually not maintenable without being a PITA.
[21:13] <asac> "
[21:17] <mdke> asac: :)
[21:18] <Jazzva> asac: Everything was added ... I thought it wasn't. So, a-i-d rev 548 is the final for now
[21:19] <asac> Jazzva: good. can you remind me right when the release is out of the door? i don't want to bug mvo right now about this ... i think he is still looking into something
[21:19] <asac> i am sure ill rememember now that i forgot once, but better safe than sorry
[21:19] <Jazzva> Oke :).
[21:27] <asac> ok off for 30 minutes or so getting some fresh-air :)
[21:28] <Jazzva> ok... We might talk about the auto-upgrade when you come back, to see if we have covered all...
[21:40] <fta> !info xulrunner sid
[21:40] <ubotu> xulrunner (source: xulrunner): XUL + XPCOM application runner. In component main, is optional. Version 1.8.1.14-1 (sid), package size 271 kB, installed size 892 kB
[21:40] <fta> !info xulrunner experimental
[21:40] <ubotu> xulrunner (source: xulrunner): XUL + XPCOM application runner. In component universe, is optional. Version 1.8.1.4-2ubuntu5 (gutsy), package size 273 kB, installed size 980 kB
[21:41] <fta> bah
[21:41] <armin76> plop :)
[21:41] <fta> !info xulrunner hardy
[21:41] <armin76> go debian? :P
[21:41] <ubotu> xulrunner (source: xulrunner): XUL + XPCOM application runner. In component universe, is optional. Version 1.8.1.13+nobinonly-0ubuntu1 (hardy), package size 275 kB, installed size 980 kB
[21:41] <fta> oh
[21:41] <fta> asac, what about this one ? too late ?
[21:42] <armin76> !info libc6 hardy
[21:42] <ubotu> libc6 (source: glibc): GNU C Library: Shared libraries. In component main, is required. Version 2.7-10ubuntu3 (hardy), package size 4206 kB, installed size 10436 kB
[21:42] <armin76> !info debootstrap hardy
[21:42] <ubotu> debootstrap (source: debootstrap): Bootstrap a basic Debian system. In component main, is extra. Version 1.0.8 (hardy), package size 49 kB, installed size 260 kB
[21:52] <asac> fta: about xul 1.8?
[21:52] <fta> .14
[21:52] <fta> the security fix i guess
[21:52] <asac> yeah
[21:53] <fta> I can do a quick merge
[21:53] <asac> we should push that through the security team
[21:53] <asac> fta: is that good enough? the release team currently is completely overloaded. we should remember to do it in sync with next firefox i guess
[21:55] <asac> fta: whats the state of xulrunner in < hardy?
[21:55] <asac> was that updated anywhere?
[21:55] <asac> !info xulrunner
[21:55] <ubotu> xulrunner (source: xulrunner): XUL + XPCOM application runner. In component universe, is optional. Version 1.8.1.4-2ubuntu5 (gutsy), package size 273 kB, installed size 980 kB
[21:55] <fta> old
[21:55] <asac> !info xulrunner gutsy-security
[21:55] <asac> !info xulrunner gutsy-updates
[21:56] <fta> we should ask Fujitsu
[21:56] <asac> yep
[21:56] <asac> fta: wanna give him a ping?
[21:56] <asac> maybe he is up already
[21:57] <fta> please ping him, i'm doing xul
[21:57] <asac> fta: i think we should push this through security on release day.
[21:57] <fta> universe is not frozen yet
[21:57] <asac> for gutsy we should do an SRU because it means a pretty big version bump and we need testing
[21:57] <fta> it's still possible
[21:58] <asac> yeah ;)
[21:58] <asac> however, release team is pretty busted and this qualifies for security
[21:58] <asac> so imo there is no need for getting this in right now.
[21:59] <asac> speaking: they will hate me :/
[22:01] <mdke> asac: https://bugs.launchpad.net/bugs/220762 <-- any idea what that is?
[22:01] <ubotu> Launchpad bug 220762 in ubuntu-docs "package ubuntu-docs 8.04.2~hardy failed to install/upgrade: subprocess post-installation script returned error exit status 139" [Undecided,New]
[22:01] <asac> argh
[22:01] <mdke> yeah
[22:02] <mdke> I can't see anything in the log that explains things, but then again I don't know much about dpkg
[22:03] <asac> hmm that upgrade appears to be completely busted
[22:03] <asac> there are other issues before
[22:03] <asac> segfaults
[22:03] <asac> update-manager failed to upgrade
[22:03] <asac> and so on
[22:03] <mdke> yeah, I saw those too
[22:03] <mdke> shall we cross our fingers and hope it's just his system?
[22:04] <asac> ill show that our QA team
[22:04] <mdke> btw, why is the version not 8.04.2?
[22:04] <mdke> that's the format we've always used in the past
[22:15] <asac> mdke: because your bzr release is ahead :) ... i skipped the .po updates so i kept the version below that
[22:16] <asac> mdke: and i couldn't get feedback from you in time :)
[22:16] <asac> (not your fault obviously)
[22:17] <mdke> asac: ok, I see. thanks for clarifying
[22:17] <mdke> asac: and thanks for all your hard work recently with the startpage, you've done marvels
[22:17] <mdke> the new solution is very elegant
[22:18] <asac> thanks. sorry for this kind of change so short before release
[22:18] <mdke> not your fault
[22:18] <mdke> I can't wait to clear out the old system for intrepid
[22:18] <asac> we will certainly find good ways to make it better than before to contribute
[22:18] <asac> yes, what a joy :)
[22:23] <Jazzva> asac, busy?
[22:24] <asac> Jazzva: not more than normal :)
[22:24] <jetsaredim> geser: yea - thanks for the help testing
[22:24] <asac> Jazzva: but we can discuss now :)
[22:24] <asac> fta: are you available too?
[22:24] <Jazzva> asac: Good :)
[22:25] <Jazzva> fta2 maybe? :)
[22:26] <asac> fta2: there?
[22:26] <asac> mdke: could you keep your eyes for a bit on that pseudo ubuntu-bugs bug please
[22:26] <asac> mvo asked for crash files so if he sends them we could go on
[22:26] <fta> i'm here
[22:26] <asac> but we have to miss it ;)
[22:26] <Jazzva> fta: yay :)
[22:26] <asac> fta: we wanted to talk about how to maintain extensions ;)
[22:27] <fta> k
[22:27] <asac> not the final thing, but the basics
[22:27] <asac> let me recap what we had so far.
[22:28] <asac> upstream branch: auto tracked if the package is based on AMO .xpis
[22:28] <asac> with the help of the script we have
[22:29] <asac> thats simple.
[22:29] <fta> yep
[22:29] <asac> then we need something that tries automerge for those branches that can be updated
[22:29] <asac> those are 1) current development release (aka .dev)
[22:29] <asac> 2) backports
[22:30] <asac> if the automerge succeeds it should go to a $BRANCH.staging branch
[22:30] <asac> and we have a script that shows which extensions updates are available on staging branches
[22:30] <asac> makes sense?
[22:31] <fta> yes
[22:31] <Jazzva> agree...
[22:31] <asac> ok ... so usually the QA contact would review the .staging branch and if god sign-off
[22:32] <asac> no idea fi we have some technical mean to show that a branch is signed off ... however if its signed-off we probably want to push it to the .release branch
[22:32] <asac> e.g. the .dev branch or the .hardy.backports branch and so on
[22:33] <fta> someone has to test the backports too. not sure the QA contacts will be able to do so
[22:33] <asac> fta: the idea is that we have a .staging branch for any release branch ... e.g. also the backports branch
[22:34] <Jazzva> well, we can do it, while we're on hardy... and maybe look for testers (something like Mozilla QA tracker in the topic)
[22:34] <asac> its important that we blog about this and gather a healthy community. for backports we can entangle with the ubuntu-backports team i guess
[22:36] <asac> well... anyway.
[22:36] <asac> ther was a corner case for the .staging branch i cannot remember right now
[22:37] <mdke> asac: will do
[22:37] <asac> Jazzva: you remember?
[22:37] <Jazzva> Umm ... no. We can look at the log, it will be on the Internet :)
[22:37] <Jazzva> (or it is already)
[22:38] <Jazzva> It is...
[22:38] <Jazzva> http://irclogs.ubuntu.com/2008/04/22/%23ubuntu-mozillateam.txt
[22:38] <Jazzva> change in source dirs layout?
[22:39] <asac> 12:17 < asac> now i do 0.2-0ubuntu2 in the .ubuntu branch ... but staging has 0.3-0ubuntu1 ...  based on 0.2-0ubuntu1
[22:39] <asac> ok i think i remember
[22:39] <asac> this doesn't apply to backport branches i guess ... as thos are unlikely to get packaging changes
[22:40] <asac> however if you work on a better packaging e.g. 0.2-0ubuntu2 and commit that after the auto merger has kicked in and updated .staging to 0.3-0ubuntu1 based on 0.2-0ubuntu2
[22:40] <asac> we have to get the auto merger redo that .staging branch
[22:40] <asac> fta: ^^
[22:41] <asac> is that a comprehensible description?
[22:41] <Jazzva> you mean, 0.2-0ubuntu1...
[22:42] <asac> i mean ... .ubuntu branch has version X-1 ... merger kicks in and creates X+1-1 from it
[22:42] <asac> then i am finished and commit X-2 to .ubuntu branch
[22:42] <asac> now we cannot push X+1-1 to .ubuntu branc because it diverged
[22:42] <Jazzva> Right... Sounds good
[22:42] <asac> so we have to either do that manually or make auto merger detect that and redo the merge
[22:43] <fta> or we could merge
[22:43] <asac> yes. my idea was to detect diverged branches by trying a local push regularly and if .staging branch cannot be pused on .ubuntu branch, throw it away and redo the merge
[22:44] <asac> fta: no idea if thats too complicated or if there are better solutions to support us in maintaining those
[22:44] <asac> redo the merge == redo the upstream merge and push --overwrite to .staging if that works without conflict
[22:45] <fta> sounds ok.
[22:45] <fta> we should try that and see if it works
[22:45] <asac> well ;) ... its probably rare. but still a case and i don't want to get a stale lock somewhere that we cannot resolve :)
[22:46] <fta> btw, i'm not in ubuntu-dev so i cannot touch any of those branches
[22:46] <asac> fta: we should change that asap
[22:47] <asac> imo you should just send a mail to the motu council and CC anyone you worked with and see what happens
[22:47] <fta> what does it take to be in ubuntu-dev ?
[22:48] <fta> ubuntu-dev == motu ?
[22:48] <asac> fta: mailing motu council telling that you want to apply ... giving a short outline of what you did and gathering good feedback from people you worked with
[22:48] <asac> i am sure there will be enough that vouch for you
[22:48] <asac> yes its motu
[22:49] <asac> fta: i would even propose you, but i think the way it works is that you propose yourself
[22:50] <asac> imo you should actually apply for core-dev shortly after that.
[22:50] <Jazzva> https://wiki.ubuntu.com/MOTU#head-ec7a97d5af67e96747b4f36993232ff434f4486c
[22:51] <Jazzva> fta ^
[22:52] <asac> anyway, back to topic
[22:52] <asac> there are a few things i am not really sure of. first: where to maintain those branches
[22:52] <asac> a) where to put the .upstream branches
[22:52] <asac> b) where to put the .dev branch
[22:52] <asac> c) where to put the .backport branches
[22:52] <Jazzva> mozillateam/maintainer?
[22:52] <asac> d) where to put the .release branches
[22:53] <Jazzva> mozillateam, if we make the script that will run for all extensions
[22:53] <Jazzva> maintainer, if maintainer needs to run the script...
[22:53] <asac> i think the question is: who should be able to commit where
[22:54] <Jazzva> Well, depends on how we make the script :)...
[22:54] <Jazzva> First way, if the maintainer runs, then someone should merge his/her branches with mozillateam's/ubuntu-dev's
[22:54] <asac> i would be fine to add the .upstream branches to mozillateam
[22:54] <asac> we could also create subteams
[22:55] <asac> indeed. we probably have two cases here: automatic upstream branches and manual upstream branches
[22:55] <Jazzva> Second way, if the script is run automatically ... maybe mozillateams, and when everything is done, the branches should be merged with ubuntu-dev's
[22:56] <Jazzva> Hmm... this might be one solution. Automatically run for mozillateam's upstream. If there is new upstream version, then mail the maintainer to run the update-extension script (if we're doing the first way), and then just merge with his/her branches when they're done.
[22:58] <asac> ok. so upstream branches in mozillateam are ok?
[22:58] <asac> fta: ?
[22:58] <asac> won't this clutter our branch list?
[22:59] <Jazzva> If it will, we can do subteaming...
[23:00] <asac> ok lets assume we have a place for upstream branches. we could do auto merging for those that get from AMO ... and maybe autopull from a configured bzr branch that the QA contact runs?
[23:02] <Jazzva> From his ubuntu branch?
[23:02] <Jazzva> Wow ... just noticed it's less than two days till release :). (offtopic)
[23:03] <asac> 1 day ;)
[23:03] <Jazzva> well ... more than 1, less than 2 :P
[23:05]  * asac phone
[23:07] <asac> back
[23:07] <asac> Jazzva: no ubuntu branch, but .upstream branch
[23:07] <Jazzva> Why would we do that? :)
[23:07] <asac> Jazzva: i think if we cannot update from AMO the QA contact should drive the .upstream branch
[23:07] <asac> just an idea
[23:08] <Jazzva> Ok ... but I just don't see the point of autopull :)
[23:08] <asac> what would you suggest instead?
[23:08] <Jazzva> What do you want to do with autopull?
[23:09] <asac> i want to ensure that the .upstream branches we cannot maintain automatically are still getting pulled to our area
[23:09] <asac> if those cases are rare, we can do that manual. granted
[23:09] <Jazzva> Oh... Sorry, I misread your line. :)
[23:09] <Jazzva> Yeah, that's good...
[23:09] <asac> what i want to prevent is that the .upstream branch just lives in the QA contact area
[23:10] <asac> we have no control and if he trashes it, it just disappears
[23:10] <Jazzva> I thought you want to autopull after automerge and I was confused :)... Nevermind.
[23:10] <asac> and we are screwed
[23:10] <asac> fta: what are your idea about these kind of corner cases?
[23:10] <asac> e.g. AMO is behind like for firebug right now?
[23:11] <asac> or the .xpi distributed through AMO doesn't have a license file, while the svn/cvs had
[23:11] <asac> has
[23:12] <asac> i think it would be fine if we maintain those manually ... we just have to know how we maintain/update those. however, integrating those into the auto process would allow us to maintain backports and so on as well
[23:12] <asac> which might be cumbersome to do manually
[23:13] <asac> hairy question ;)
[23:14] <Jazzva> Download automatically from cvs... Just add moz_source or something in rules/some other file, which the script is gonna look at if it's not on amo
[23:14] <Jazzva> :)
[23:14] <fta> I don't see what the QA could do for the upstream branch that a script cannot do.
[23:14] <Jazzva> (and maybe type of cvs, so the script can use right command)
[23:15] <asac> fta: i think a script can do everything, but the package would probably need to provide an interface for the script to gather data ... which might be beyond the capabilities of the QA contacts
[23:16] <asac> i guess watch files would be the right thing for tarballs?
[23:16] <asac> whatelse would we need? a branch url?
[23:16] <asac> (e.g. svn, git, bzr, hg) ?
[23:16] <Jazzva> yep...
[23:17] <asac> and it can be tricky to guess which snapshot to take from svn. we could track every single checkin, but i don't think its a wise thing to push every single committ to backports and so on
[23:17] <fta> sure not
[23:17] <asac> thats why i thought that the QA contact should update the .upstream branch whenever he thinks its a good revision to bake a release from
[23:17] <fta> (is there a bug on lp for 2.0.0.14 ?)
[23:18] <asac> if we have other ideas how to figure when to bake a release, i am all for it.
[23:18] <asac> fta: probably not. i don't document these that way. what do you need?
[23:18] <asac> we have an ubuntu advisory
[23:18] <asac> its 602-1
[23:18] <fta> a bug to close, i remember there was a bug for ff/xul/sm recently
[23:18] <asac> http://www.ubuntu.com/usn/usn-602-1
[23:19] <asac> hmm
[23:19] <asac> if there is non we can surely open one
[23:19] <asac> for security the short description i provide in changelog is usually good enough.
[23:20] <asac> if you open a bug i can provide a description and add the content needed to review this
[23:20] <asac> let me look
[23:21] <fta> bug 218534
[23:21] <ubotu> Launchpad bug 218534 in firefox "[Needs Packaging] JavaScript vulnerability in Firefox/Thunderbird/SeaMonkey before 2.0.0.13/1.1.9" [Undecided,Fix released] https://launchpad.net/bugs/218534
[23:21] <asac> let me check if every info is public
[23:22] <asac> mozilla bug 411025
[23:22] <ubotu> Mozilla bug 411025 in JavaScript Engine "GC hazard in JS_CompileUCFunctionForPrincipals" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=411025
[23:22] <asac> mozilla bug 425576
[23:22] <ubotu> Mozilla bug 425576 in JavaScript Engine "Crash on login to Excite Japan Blog (exblog.jp) after updating to Firefox 2.0.0.13 [@ js_MarkGCThing]" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=425576
[23:22] <asac> mozilla bug 421622
[23:22] <ubotu> Mozilla bug 421622 in XML "XMLHttpRequest from chrome content clears Referer header" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=421622
[23:22] <asac> mozilla bug 378132
[23:22] <ubotu> Mozilla bug 378132 in Phishing Protection "table update requests once per minute on http 4xx response" [Normal,Resolved: duplicate] http://bugzilla.mozilla.org/show_bug.cgi?id=378132
[23:22] <asac> fta: http://paste.ubuntu.com/7803/
[23:23] <asac> thats the text that describes this release
[23:23] <fta> where ?
[23:25] <asac> fat i updated bug https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/21853
[23:25] <ubotu> Launchpad bug 21853 in gnome-volume-manager "Cannot unmount iPod (dup-of: 11517)" [Medium,Invalid]
[23:25] <ubotu> Launchpad bug 11517 in linux-source-2.6.15 "Can not eject removable devices" [Medium,Fix released]
[23:25] <asac> damn
[23:25] <asac> bug 218534
[23:25] <ubotu> Launchpad bug 218534 in firefox "[Needs Packaging] JavaScript vulnerability in Firefox/Thunderbird/SeaMonkey/Xulrunner before 2.0.0.14/1.1.10/1.8.1.14" [Undecided,Fix released] https://launchpad.net/bugs/218534
[23:25] <asac> fta: in the paste
[23:25] <asac> http://paste.ubuntu.com/7803/
[23:26] <asac> and add that it fixes the issues disclosed in usn-602-1
[23:26] <fta> this bug mentions CVE-2008-1237 but debian says CVE-2008-1380
[23:26] <ubotu> Multiple unspecified vulnerabilities in Mozilla Firefox before 2.0.0.13, Thunderbird before 2.0.0.13, and SeaMonkey before 1.1.9 allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via unknown vectors related to the JavaScript engine. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1237)
[23:26] <ubotu> The JavaScript engine in Mozilla Firefox before 2.0.0.14, Thunderbird before 2.0.0.14, and SeaMonkey before 1.1.10 allows remote attackers to cause a denial of service (garbage collector crash) and possibly have other impacts via a crafted web page.  NOTE: this is due to an incorrect fix for CVE-2008-1237. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1380)
[23:27] <asac> fta: that bug is bogus
[23:27] <asac> use the cve in the usn
[23:27] <asac> fta: i fixed the summary :)
[23:29] <fta> http://paste.ubuntu.com/7805/  looks ok ?
[23:30] <asac> fta: maybe add the USN-602-1 id somewhere in changelog
[23:31] <fta> USN-602-1 =? mfsa-2008-20 == CVE-2008-1380 ?
[23:31] <ubotu> The JavaScript engine in Mozilla Firefox before 2.0.0.14, Thunderbird before 2.0.0.14, and SeaMonkey before 1.1.10 allows remote attackers to cause a denial of service (garbage collector crash) and possibly have other impacts via a crafted web page.  NOTE: this is due to an incorrect fix for CVE-2008-1237. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1380)
[23:33] <fta> damn, pa is bogus once again. after a pause
[23:36] <fta> asac, ^^ (usn)
[23:42] <fta> god i hate dpatch
[23:42] <asac> sorry ... there was yet another fire :(
[23:42] <asac> i am more or less back
[23:43] <asac> fta: right
[23:43] <asac> this usn just comprises one advisory
[23:43] <asac> and the two bugs mentioned in paste are added on top in this release
[23:47] <fta> ok
[23:47] <fta> rebuilding from scratch to be sure
[23:50] <asac> yes, please be double sure and test some rdepends we still have
[23:51] <asac> though i think its pretty safe upgrade ... but usualyl those are the ones most dangerous
[23:52] <asac> Jazzva: fta: ok, ill try to write this extension thoughts down so we can continue discussion from there
[23:52] <Jazzva> asac, k... Do we have the deadline? :)
[23:52] <Jazzva> UDS?
[23:52] <asac> for what?
[23:52] <Jazzva> for autoupgrade thingy...
[23:53] <fta> then I'll write a prototype
[23:53] <asac> getting a basic draft written and a prototype before UDS would be really helpful
[23:53] <asac> we could then finalize it during UDS based on the experiences we had
[23:54] <asac> i hoped to have an idea for next weeks extension packaging session at ubuntu developer week
[23:54] <asac> but i know buried that idea ;)
[23:54] <asac> s/know/now/
[23:54] <Jazzva> I can help with the draft, if you need it... and maybe with scripting (but I'm at the very basic level for that, though willing to learn)
[23:54] <fta> i would probably go with perl, not shell this time
[23:54] <asac> Jazzva: ill outline the basics we discussed in wiki. anyone can add comments, imprve text and so on
[23:54]  * Jazzva knows nothing about perl
[23:55] <Jazzva> Ok
[23:55] <asac> *oooo* there we go. technical detail discussion about languages to use :/
[23:55] <Jazzva> hmm ... visual basic
[23:55] <Jazzva> (kidding)
[23:55] <asac> lets do it in C
[23:55] <asac> thats the greatest common demoninator these days ;)
[23:55] <fta> shell is good with me but i fear it will soon be a monster
[23:55] <asac> like our po2xpi transformer ;)
[23:56] <asac> bloody ugly C code ;)
[23:56] <Jazzva> C is ok :).
[23:56] <fta> c for this is like reinventing the wheel
[23:56] <asac> fta: perl will definitly be a monster for anyone ;)
[23:56] <asac> except those that are perl fetish ;)
[23:57] <asac> perl is fine with me ... as long as its not trying to compress things into as few lines as possible
[23:57] <asac> and not using all those implicit nifty operators
[23:57] <asac> e.g. perl can be readable for outsiders if you code things explicitly ;)
[23:57] <asac> fta: do you understand what i mean?
[23:57] <asac> :)
[23:58] <fta> yes
[23:58] <asac> ok ;)
[23:58] <asac> fta: probably you don't like python?
[23:59] <fta> i've never done anything real in python.
[23:59] <fta> opposed to millions of lines of perl, shell, C
[23:59] <fta> Is this readable for you: http://www.sofaraway.org/ubuntu/tmp/sync-ppa.pl.txt