[00:10] <fta> http://twinturbo.org/firefox/removing-the-firefox-3-eula/
[00:13] <fta> [reed], do you have jit on now ?
[00:14] <[reed]> on one of my laptops
[00:14] <fta> usable ?
[00:14] <fta> = are the crashes gone ?
[00:14] <[reed]> not all
[00:14] <[reed]> but most
[00:16] <fta> [reed], both chrome and content or just one ?
[00:16] <[reed]> both
[00:16] <fta> hm, ok, trying
[00:35] <asac> ok. i am giving up
[00:35] <asac> debian upload queue doesnt like me
[00:36] <asac> it always claims that my upload was already uploaded
[06:26] <gnomefreak> Jazzva: are you here? i cant remember your time zone
[06:41] <gnomefreak> how the hell do you post a comment on debian's bug tracker?
[06:42] <vk5foss> gnomefreak: email bugnumer@
[06:43] <gnomefreak> vk5foss: you mean like bug#@bugs.debian.org
[06:45] <vk5foss> gnomefreak: yeah.
[06:49] <vk5foss> asac: sorry, didnt see your comments 7 hours ago ... i see it says its fixed ... whys that?
[06:52] <vk5foss> asac: not sure i follow, tbh :/
[07:08] <gnomefreak> this guy is a real moron :(
[07:19] <gnomefreak> asac: its after 0200 and im going to leave irssi open if you comment and im in bed :( how did review go on firegpg and chatzilla. both work on firefoxc 3 and abrowser on this pc
[07:26] <gnomefreak> is there  a site that has instructions to get a sponser for Debian?
[07:27]  * gnomefreak taking a break maybe sleep
[07:28] <vk5foss> later maet
[07:28] <vk5foss> *mate
[08:28] <asac> vk5foss: ?
[08:28] <asac> gnomefreak: thanks
[08:29] <vk5foss> oh, the nick
[08:30]  * kgoetz is Kamping_Kaiser 
[08:30] <asac> kgoetz: you are really a camelino ;)
[08:31] <asac> kgoetz: sorry its early and didnt have coffee yet. what are you referring to?
[08:32] <kgoetz> asac: sorry, i dont bother to reset my nicks when the 'net drops
[08:32] <kgoetz> asac: i was replying to what you said to Kamping_Kaiser ~9 hours ago
[08:35] <mdke> asac: I asked dholbach for some help with removing the alternatives, as he's the guy who has previously helped quite a bit with ubuntu-docs, but he's referred me to you, as you'll see from you mail :)
[08:36] <mdke> asac: if you don't have time to help out with this, let me know, and I'll ask around
[08:54] <mdke> asac: i have to go to work now from where no irc, but I'll be on email if you can discuss
[09:18] <asac> kgoetz: ah. ok no it appears to be fixed for ubuntu-dev-tools. the debdiff for devscripts is still pending from what i see
[09:21] <asac> mdke: ok. got the mail
[09:21] <kgoetz> asac: ah, ok.
[09:59] <asac> bug 269010
[10:10] <kgoetz> asac: just got the emails re: ca-certs. i'll re-read it tomorrow when i'm a bit awake and clueful
[10:14] <asac> kgoetz: right if you wnat more clarification feel free to ask
[10:15] <kgoetz> asac: will do.
[10:15]  * kgoetz gone
[11:52] <gnomefreak> @now new_york
[11:53] <gnomefreak> thats odd
[11:56] <gnomefreak> 11:00 UTC, 3rd Tuesday of the month
[11:56] <gnomefreak> im not crazy :(
[11:59] <asac> hehe
[12:00] <asac> "crazy" is hard to define
[12:01] <gnomefreak> in this case i wish i was crazy i only got 3 hours of sleep so i can be at the meeting
[12:02] <asac> ouch
[12:02] <gnomefreak> ill go back to sleep after meeting or in a few hours
[12:03] <gnomefreak> this extension was pissing me off last night because i couldnt think so i will get to it after nap and i have to add it to our extensions page as well
[12:04] <asac> gnomefreak: better rest first ... then work ... the other way around isnt productive ;)
[12:04] <gnomefreak> thats true
[12:26]  * gnomefreak doesnt remember why i needed Jazzva yesterday :(
[12:26] <Jazzva> gnomefreak, I remember you asked how to send a comment on debian's BTS
[12:27] <Jazzva> but someone already answered...
[12:27] <gnomefreak> Jazzva: yeah found that one out. this was about one of the extensions i was working on but dont remember what it was
[12:27] <Jazzva> gnomefreak, in case you remember, feel free to ask :). I'll be off for next 2-3 hours, need to get some sleep
[12:33] <gnomefreak> Jazzva: me too im only up for CC meeting that seems to not be happening
[12:33] <gnomefreak> asac: is there a site explaining the process to getting a new or fixed package into debian?
[12:35] <gnomefreak> i can at least add this extension to the wiki if its not already there
[12:38] <gnomefreak> Jazzva: how do you feel about dropping mozilla-bookmarksftp for placesync? PlaceSync appeared (which is a cut version of Sync and Sort)
[12:38] <gnomefreak> https://addons.mozilla.org/en-US/firefox/addon/8379
[12:39] <gnomefreak> wait on that
[12:40] <asac> gnomefreak: the process is to submit a debdiff to the debian bug or open a new one
[12:40] <asac> then hope that the maintainer includes it
[12:40] <asac> unless its release-critical there is no way to "just" upload it without the maintainer taking the patch
[12:40] <gnomefreak> how do i get a debdiff for a new package?
[12:41] <gnomefreak> theres nothing to get a diff from
[12:42] <gnomefreak> Jazzva: imleaning towards foxmarks for a replacement for mozilla-bookmarksftp
[12:47] <asac> bug 227711
[13:11] <gnomefreak> there sent email to firemarks people about licenses now i can feel better to go back to bed.
[13:18] <gnomefreak> ok bed time ive done enough for now. damn i have one more fast thing to do
[13:18] <gnomefreak> there all done ;)
[15:12] <Volans> asac, fta (fta2): is there anyone already working on addons to add abrowser and/or test some large maintenance script?
[15:14] <asac> Volans: no. we havent started. but i think we shouldnt be blocked by alpha-6 freeze much no extension is on the CD
[15:14] <asac> (abrowser depends transition that is)
[15:15] <asac> Volans: for the large maintainer scripts i would suggest that we go on as suggested ... its unlikely that we get the perl framework this cycle ... and blocking because of this shouldnt be required imo
[15:15] <asac> Volans: have you tried to implement the scripts i mentioned?
[15:17] <Volans> 1- can I help you working on abrowser depends transition or you have already planned to do this?
[15:17] <Volans> 3-(script) I'm working testing some script to do so but I don't knew that you want to do it in PERL... I'm doing it in bash atm
[15:19] <Volans> I think that for large maintenance a way to do all automatically can be to add a debian/watch file to the extension's branches with the url of the mozilla watchable folder
[15:19] <Volans> in such a way we can use tools like uscan and uupdate like standard packages
[15:20] <Volans> I have checked now all the packages in the Wiki list that have the "Repo" = "yes" and only two of them already have a debian/watch file
[16:17] <asac> Volans: ad 3. i dont think that "script" is really important which language we use
[16:17] <asac> Volans: i think as long as we really need a real scripting language, using basic sh should be fine
[16:18] <asac> s/need/don't need/
[16:18] <Volans> ok, so I go ahead with my tests
[16:18] <Volans> you agree to add a watch file to all extension packages in the long run?
[16:18] <asac> Volans: adding a watch file would be one way to do it
[16:19] <asac> Volans: the other way would be that we maintain the watch files for the upstream branches in the "bot config" tree
[16:19] <asac> Volans: this would solve the bootstrap problem. people could ask someone authoritive to enable a new extension ... which would then create a new upstream branch in the next batch, which the user can base its .ubuntu tree on
[16:20] <asac> Volans: let me show you something (which would be fine to completely dump and start from scratch ;))
[16:21] <Volans> ok, thanks
[16:21] <asac> https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT.TASKS
[16:21] <asac> https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT
[16:22]  * Volans downloading the code
[16:23] <asac> the BOT.TASKS is a directory structure that has the idea to allow bot tasks to be configured
[16:23] <asac> and in BOT there is a generic runtask script
[16:24] <asac> which is supposed to load the config for a certain task ;)
[16:24] <asac> e.g. runtask BOT.TASKS/upstream/amo/flashblock.ubuntu.HEAD
[16:25] <asac> the idea is that the TASKS tree is a hiearchy of config files that allow to overload values ;)
[16:25] <asac> so first config loaded would be: upstream/config , that would be supplemented/overloaded by upstream/amo/config and that would get its final shape by the specific task: upstream/amo/flashblock.ubuntu.HEAD
[16:26] <asac> anyway. this is all not set in stone and for me it looks suspicious that we reinvent the wheel in some way here ;)
[16:26] <Volans> asac: so you want to manage both new AMO versions and upstream versions?
[16:26] <asac> Volans: later. the idea is that this will be extensible.
[16:27] <Volans> great
[16:27] <asac> e.g. we write a UPSTREAM task script ... that can then hook in a AMO script and later something else for another upstream task
[16:27] <Volans> (and complex)
[16:27] <asac> Volans: might be. but ...
[16:28] <asac> _all_ the logic to parse the config in the above way is already in the "runtask" script
[16:28] <asac> so we would just need to refactor that to a functions script
[16:28] <asac> so the "complex" partis probably mostly done
[16:29] <asac> the only tricky thing is to teach the UPSTREAM script to honour the UPSTREAM_TYPE config and run that script in the same way runtask runs UPSTREAM
[16:29] <asac> and AMO would then just implement the watching like it would be done in a normal script
[16:29] <asac> Volans: but well. i think its fine to do it different ... e.g. simpler
[16:29] <asac> to get things started
[16:30] <Volans> if not sure to understand all the details so far, but go ahead
[16:30] <asac> Volans: thats why i ment that its easier to start to write the scripts we discussed
[16:30] <asac> we can use them now to hack something that works
[16:30] <asac> and later hopefully reuse them in the complete system
[16:31] <asac> though that is of course not guaranteed ;)
[16:31] <Volans> is exactly what I am doing.. something that works now :)
[16:31] <asac> right. but i would like to maintain the watchfiles in a config branch i think ;)
[16:31] <asac> everything else you can do as you want :)
[16:32] <asac> unless you see a reason why maintaining them outside the package is bad
[16:32] <Volans> so, don't add the watch file to the source package?
[16:32] <asac> right
[16:33] <Volans> you already have a tool/script that can download the latest version from AMO directory?
[16:33] <asac> Volans: for instance we could ahve a config branch: upstream-syncs/amo/
[16:33] <asac> and put all watch files in there
[16:34] <asac> Volans: what we want is to download a specific version if possible
[16:37] <asac> Volans: but well. in the end i dont really mind how it is done. i would just like to have all releases in upstream bzr somehow and being able to identify which commit was which version
[16:38] <Volans> why specific and not the latest?
[16:39] <asac> Volans: i just assumed that we know the new version through the check-extensions script
[16:39] <asac> however, that isnt really necessary
[16:39] <asac> at best we would pull down everything _new_ and import everything up to the last release
[16:39] <asac> e.g. if there  have been two releases in between we probably want to import both
[16:39] <Volans> asac: let me understand a thing.. you want that the script update the bzr branch AND/OR make the changes to the source package?
[16:40] <Volans> for the many releases in between you are right, we have to import all, one at time in the branches
[16:40] <asac> Volans: what i suggested was to write a dumb script that just knows how to download a specific version of a .xpi from amo
[16:41] <asac> also write a dump script that upgrades an existing branch from a given .xpi
[16:41] <asac> dumb
[16:41] <Volans> all separately?
[16:41] <asac> and when we have all pieces together write one top level script that orchestrates those "small" tools
[16:41] <asac> for a higher purpose use-case
[16:42] <Volans> ok, more clear now
[16:42] <asac> like upgrade-upstream-branch-and-attempt-merges ;)
[16:42] <asac> but here: i dont care ;) ... if everything just works i am fine with a monolithic script to get things started
[16:43] <asac> but otoh, i have the feeling that this might block us from doing long term changes through incremental improvements
[16:43] <Volans> I agree, many small scripts are easy to maintain and imporve
[16:43] <asac> yes. the code would be much mroe stable
[16:44] <asac> and also we should always try that whatever we do, something doesnt get completely blocked because one team member doesnt have time
[16:44] <asac> and a monolithic script sounds like it might end up in that kind of lock
[16:45] <asac> at least after a bunch of upstream methos have been added ;)
[16:45] <asac> Volans: anyway. i think i managed to use uscan without a debian package
[16:46] <Volans> oh, sounds good
[16:46] <asac> but maybe thats not news for you ;)
[16:46] <asac> but it has been quite a while and i cannot really say what i did
[16:46] <asac> maybe i didnt manage to do that and create a spoof debian tree in a mktemp directory
[16:47] <Volans> is not a problem, I can leave it out at the moment assuming that the version to be downloaded will be a parameter given by the fta's script
[16:48] <asac> Volans: well. i think we still need watch files
[16:48] <asac> because its not easy to guess the .xpi filename for all extensions
[16:49] <asac> but i think using uscan --upstream-version=... --download ... --watchfile=...  ... should work
[16:49] <asac> maybe there is still a aparamter missing
[16:49] <Volans> ok, I will try, or we can manage the watch file externally and at runtime copy the watch file in the debian dir, make uscan and remove the watch file
[16:50] <Volans> if I can use uscan "externally" will be better, I will read more in depth it's manpage
[16:50] <asac> good
[16:50] <asac> Volans: if you need different parameters let me know
[16:50] <Volans> parameters?
[16:51] <asac> i think its save to assume that we either have a config file with watch expressions (which we could then make a watchfile on the fly from)
[16:51] <asac> Volans: well. the contract of the download script
[16:51] <asac> i think i suggested download-amo-xpi <amoid> <upstream-version>
[16:51] <asac> not sure if that is enough
[16:51] <asac> thats just what i ment
[16:52] <Volans> depends on what <upstream-version> is
[16:52] <Volans> if is only version number, no it will not work
[16:52] <Volans> maybe complete xpi name will be better, this can be done saving in the config file the "master" xpi filename
[16:52] <asac> Volans: would it work better that you always download all that are older than a known xpi name?
[16:52] <Volans> that AMO uses
[16:53] <asac> like ... last time you uploaded chatzilla-0.1.x.xpi
[16:53] <asac> err downloaded
[16:53] <asac> then get everything that came after that?
[16:53] <Volans> older or newer?
[16:53] <asac> newer
[16:54] <asac> after - on the time scale
[16:54] <asac> Volans: but well. actually why doesnt <upstream-version> help?
[16:54] <asac> because we dont know if the filename includes the same upstream version that is in install.rdf?
[16:55] <Volans> no I hope it's the same, but sometimes AMO use strange name, or the extension change name and I don't know if downloading a file *<upstream-version>*.xpi will be sage
[16:55] <Volans> err... safe
[16:55] <asac> hmm
[16:56] <asac> ok. so maybe watchfiles arent really that helpful?
[16:56] <asac> so could we say we dont care how .xpi's are named (except a basic regex pattern?)
[16:56] <asac> and just find the "last processed" and download/import everything made after that?
[16:57] <asac> (given that we remember the filename of "last processed")
[16:57] <asac> or what is your idea?
[16:57] <Volans> I think that watch file are helpful if they are manually created with the correct name and if they fails raise an alert to manually check the situation
[16:57] <Volans> some changes I see in the AMO filenames
[16:58] <Volans> are strange
[16:58] <asac> Volans: yes. i think we should provide two regexp: 1. regexp-active, 2. regexp-ignored ... we only download active obviously
[16:58] <asac> and we provide an error/warning when there is a file that doesnt match any of 1. or 2.
[16:59] <asac> so we can detect in case the filename has changed to something new :(
[16:59] <asac> at least one idea ;)
[16:59] <Volans> yes, something like that
[16:59] <asac> but imo only practice will show what is relevant
[16:59] <asac> we shouldnt bother too much with corner cases before starting
[17:00] <Volans> for example the actually watch for all-in-one-sidebar is: http://ftp.mozilla.org/pub/mozilla.org/addons/1027/all-in-one_sidebar-([\d\.]*)-fx\.xpi
[17:00] <asac> Volans: i think we could use watchfiles. those are basically just downloads with regexps
[17:01] <asac> hmm
[17:01] <asac> but we probably cannot download all right?
[17:02] <Volans> all the newer from the latest merge?
[17:02] <asac> Volans: well. upstream branch is independent from merging. so to be more accurate i would say "newer from last xpi processed"
[17:02] <Volans> yes
[17:02] <asac> or "newer than last xpi imported"
[17:02] <asac> ;)
[17:03] <asac> but if its really simpler to "just" download the last
[17:03] <asac> then fine
[17:03] <asac> why not
[17:03] <asac> this shouldnt block all this
[17:04] <Volans> ok, I make a simple test with uscan and then go ahead with latest if it fails
[17:04] <asac> but i am not sure if that is really easier ;)
[17:04] <asac> if uscan fails?
[17:04] <Volans> if I fails to use uscan to download all newer versions in a simple way
[17:05] <Volans> the other way is to download the index.html page of the directory and parse it to give the complete list of the files
[17:05] <asac> Volans: we could use simple ftp maybe?
[17:05] <Volans> but surely is not quick
[17:05] <asac> e.g. mget <simpleexpression>
[17:06] <Volans> yes the archive is both ftp and http
[17:06] <asac> e.g. chatzilla-*.xpi
[17:06] <asac> we could do a ls and find the last processed file
[17:06] <asac> and download all files that come after tht
[17:06] <asac> that
[17:06] <Volans> good idea
[17:06] <asac> Volans: maybe wget can even do real regexps on ftp
[17:08] <asac> Volans: but in the end i think that if we cannot rely on the version number to somehow encoded in a way that allows us to sort them in a strict order we wont have a chance but to download all
[17:08] <asac> Volans: can we assume that the version number is available in a sortable fashion for nowß
[17:08] <asac> ?
[17:08] <asac> even if its not the same version number that is in installr.df (which is the actual upstream version)
[17:09] <asac> i think we can. so a ls in ftp, then sorting them by version number should be fine
[17:09] <Volans> yes, I think so, I have a firefox page with 15 tabs on those directories on AMO and all have sortable version num,ber
[17:09] <asac> Volans: ok. would ftp on its own show them properly sorted?
[17:10] <asac> usually that becomes an issue if version are like:
[17:10] <asac> 0.8
[17:10] <asac> 0.9
[17:10] <asac> 0.10
[17:10] <asac> instead of 0.08 0.09 0.10
[17:10] <asac> Volans: hmm. maybe we should really download all
[17:10] <asac> everything seems too complicated
[17:11] <asac> not sure how much data that is
[17:11] <Volans> they seems to be sorted on ls on ftp
[17:11] <asac> is there a ftp sync tool that does smart things?
[17:11] <asac> Volans: yes. but i think there will certainly be too many versioning schemes that might break the "basic" ls
[17:12] <Volans> every extension have it's own version scheme but if we save it in a "watchable" regexp we can use it, and all seems to be ordered
[17:13] <Volans> download all for older extensions can be very useless
[17:14] <Volans> downloading 20 versions to upgrade just one :)
[17:15] <asac> Volans: ordered by the uscan tool?
[17:15] <asac> or by plain ls?
[17:15] <asac> does ls order by timestamp?
[17:16] <Volans> by plain ls on ftp
[17:16] <Volans> the timestamp problem is that all version prior  Mar 25  2007 have the same date
[17:16] <Volans> maybe is the creation time of the archive
[17:17] <asac> Volans: yeah. what is the ftp address?
[17:17] <Volans>  ftp ftp.mozilla.org
[17:17] <Volans> login anonymous
[17:17] <Volans> cd /pub/mozilla.org/addons/AMOID
[17:17] <Volans> for example 39
[17:17] <Volans> (mouse gestures)
[17:18] <asac> Volans: have you found any extension with lots of releases?
[17:19] <Volans> AMOID=138
[17:19] <Volans> stumbleupon
[17:19] <Volans> also 427  scrapbook
[17:21] <asac> Volans: ok. so how big is amo?
[17:21] <asac> is mirroring too much?
[17:22] <Volans> I think they have the whole history
[17:22] <asac> let me try ;)
[17:22] <Volans> what?
[17:23] <asac> mirror AMO ;)
[17:23] <asac> just to see how big it is
[17:23] <Volans> ah.... :)
[17:23] <Volans> we have only some 15-30 extension at the moment
[17:24] <asac> yeah. that make things even better
[17:25] <Volans> asac: you want to mirror AMOID directories of our packages?
[17:25] <asac> yes
[17:26] <asac> wget -m --recursive ftp:/...AMOID/
[17:26] <asac> works nicely ;)
[17:26] <asac> Volans: so i think we can just do:
[17:26] <Volans> you have a server where all those script and work will be done?
[17:26] <asac> for i in $AMOIDs; do
[17:27] <asac>  wget -m --recursive ftp://..../$i/
[17:27] <asac> done
[17:27] <asac> and then process all .xpi's and introspect them for the upstream version
[17:27] <Volans> with zgrep for example
[17:27] <asac> Volans: i could put that onto something if it works
[17:27] <asac> e.g. something that branches the CONFIG branch on every run
[17:27] <asac> and then processes
[17:28] <asac> Volans: yes. zgrep appears to be available everywhere
[17:29] <Volans> ok
[17:31]  * Volans doing some schema to organise (hoping with some logic) the script and tasks
[17:32] <asac> sure feeel free to innovate
[17:54] <Volans> asac: what are the steps between an updated bzr branch and an updated package? i.e. just download the source package and replace/merge the content with the updated branch?
[17:54] <Volans> (not to mention packaging stuff like debuild, etc...)
[17:54] <asac> Volans: "updated bzr branch" .. meaning "updated upstream bzr branch" ?
[17:55] <asac> "updated package" == " updated package bzr branch"
[17:55] <Volans> 1: yes
[17:56] <Volans> 2: I was forgotting the .ubuntu branches... sorry, I was meaning the dsc, debdiff, etc...
[18:02] <Volans> asac: I change my question... if we have 3 newer versions, you want in the upstream branch 3 commits, right?
[18:03] <Volans> and in the .ubuntu branch? only the final one?
[18:05] <asac> Volans: you dont need to care for dsc and such anymore
[18:05] <asac> all that matters here is ubuntu and upstream branches
[18:05] <asac> (for now)
[18:05] <Volans> ok
[18:06] <asac> Volans: so we have a cronjob that runs and updates upstream branches
[18:07] <Volans> this is already done?
[18:07] <asac> Volans: no thats what i think you should implement
[18:07] <asac> the rest is indpendent ;)
[18:07] <Volans> ah ok :)
[18:08] <asac> once we ahve that we can do the "auto-merging" and "propose for merging" quite easily i think
[18:08] <asac> do you need al the details now?
[18:09] <asac> the algo is simple (might have rough edges):
[18:09] <asac> for all BRANCHES:
[18:09] <asac> err
[18:09] <asac> for all UBUNTUBRANCHES:
[18:10] <asac>     try to push ubuntu branch U to U.merge
[18:11] <Volans> ok
[18:14] <asac>   if that fails we just trash U.merge and push U there anyway
[18:14] <asac>   then we merge upstream onto if
[18:14] <asac> done
[18:14] <asac> hmm
[18:14] <asac> forget it ;)
[18:14] <asac> i think i forgot something important ;)
[18:14] <asac> i think i documented it on the wiki
[18:14] <asac> but for now upstream branches are important to auto produce ;)
[18:14] <Volans> for extension there are added in future?
[18:15] <Volans> asac: I have done a simple schema to be sure to do useful things... http://pastebin.com/d589a1056
[18:15] <Volans> can you see if there is something relly wrong?
[18:16] <Volans> s/relly/really/
[18:17] <asac> Volans: i think download.sh shouldnt checkout the branches
[18:17] <asac> we could introduce a script initbranches.sh or something
[18:17] <Volans> ok
[18:17] <asac> checkoutorupdatebranches.sh
[18:18] <asac> Volans: i think download.sh is actually mirror.sh <amoid1> [<amoid2> ...]
[18:18] <asac> or maybe even
[18:19] <asac> mirros.sh <mirror-dir> <amoid1> ...
[18:19] <asac> so it doesnt have to assume that any particular directory structure exists
[18:19] <Volans> right
[18:19] <asac> mirror.sh that is ;)
[18:21] <asac> newer.sh could be
[18:21] <fta> hi
[18:21] <fta> what a day!
[18:22] <asac> get-import-jobs.sh <mirror-dir> <last-version> <amoid>
[18:22] <asac> get-import-jobs.sh <mirror-dir> <amoid> <current-version>
[18:22] <Volans> Hi fta
[18:22] <asac> fta: what happened?
[18:24] <fta> bah, another though day
[18:30] <asac_> reconnect
[18:30] <asac_> 19:22 < asac> fta: what happened?
[18:30] <asac_> 19:29 < asac> Volans: and 3rd. update.sh would then get a .upstream branch name and the .xpi file to import
[18:30] <asac_> 19:29 < asac> so maybe import-xpi.sh
[18:31] <Volans> ok
[18:31] <Volans> you have lost only: (19:24:59) fta: bah, another though day
[19:12] <[reed]> asac: note that we're not shipping tomorrow
[19:12] <[reed]> or today
[19:12] <[reed]> or whatever
[19:12] <[reed]> it'll be next week at the earlier
[19:12] <[reed]> earliest
[19:12] <[reed]> build6 coming up
[19:13] <asac> [reed]: shipping == shipping beta you mean?
[19:13] <[reed]> we shipped beta last week
[19:13] <[reed]> heh
[19:13] <asac> urgh
[19:13] <asac> thats fun
[19:13] <[reed]> final was supposed to go out today
[19:13] <asac> tse
[19:14] <[reed]> then got moved to tomorrow
[19:14] <[reed]> and now it's next week
[19:14] <[reed]> because we have to respin
[19:14] <asac> good luck then
[19:14] <jcastro> wow, this bug just never ends
[19:14] <asac> again an information problem
[19:14] <[reed]> (this is for 3.0.2 / 2.0.0.17)
[19:14] <asac> i know
[19:14] <fta> final of what ?
[19:14] <[reed]> are you on release-drivers@/
[19:14] <[reed]> if not, you should be
[19:14] <asac> [reed]: silence on the security list on anything ... at least not a few days ago
[19:15] <[reed]> caillon is on there
[19:15] <asac> great. that explains a bit
[19:15] <asac> thanks for the info
[19:16] <[reed]> I'll get you added to release-drivers, if you want
[19:16] <[reed]> if so, what address should be used?
[19:16] <asac> [reed]: if that is low traffic then that would be great
[19:16] <asac> [reed]: my bugzilla address
[19:17] <[reed]> which is what again without me looking?
[19:17] <[reed]> it's low traffic except for when a release is about to happen
[19:17] <asac> @jwsdot.com
[19:17] <[reed]> and then it becomes high traffic
[19:17] <asac> yeah. thats exactly what i am looking for ;)
[19:17] <asac> finally i can see by graphical visualization of the inflow of messages what is going on ;)
[19:17] <asac> like staring at the matrix ;)
[19:18] <fta> http://hg.mozilla.org/mozilla-central/rev/da539de11534af7950027f741ddc72d4afa7496e
[19:19] <asac> fta: yeah. maybe a good sign :)
[19:19] <[reed]> Successfully subscribed:
[19:19] <[reed]>     * asac@jwsdot.com
[19:20] <asac> [reed]: rock ;)
[19:20] <[reed]> fta: that just means things that aren't named Firefox don't see the EULA :)
[19:20] <[reed]> if it's Firefox, EULA still applies
[19:29] <asac> [reed]: ok ml is working. thanks. got my first "live-mail" ;)
[19:30] <[reed]> hehe
[19:31] <Volans> asac:  mirror.sh script done, you want to take a look or that I put it somewhere?
[19:32] <asac> Volans: just push it to a branch
[19:32] <Volans> alone?
[19:33] <asac> why not ... the first script of a series  ;)
[19:33] <Volans> LOL... I have to put some license statement?
[19:34] <asac> Volans: maybe push to lp:~volans/firefox-extensions/med-auto-scripts
[19:34] <Volans> ok
[19:34] <asac> Volans: usually we use GPL v3 or later
[19:34] <Volans> ok
[19:35] <fta> damn, i updated the wrong branch
[19:35] <asac> urgh
[19:35] <[reed]> asac: I prefer GPL v5.5
[19:35] <fta> asac, plz ignore the last ff3.head commit
[19:35] <[reed]> ;)
[19:35] <asac> [reed]: you never know ;)
[19:36] <asac> fta: did you overwrite something?
[19:36] <fta> no
[19:36] <asac> then there shouldnt be a big problem
[19:36] <Volans> asac: putting also the standard GPL preamble? is a simple script :)
[19:36] <fta> -firefox-3.0 (3.0.2+build3+nobinonly-0ubuntu3) UNRELEASED; urgency=low
[19:36] <fta> +firefox-3.0 (3.0.3~cvs20080916t0411+nobinonly-0ubuntu1) UNRELEASED; urgency=low
[19:37] <asac> yeah
[19:37] <asac> fta: feel free to bump to build6 ;)
[19:37] <fta> ok
[19:37] <fta> new src tarball then
[19:38] <[reed]> stuff hasn't landed yet
[19:38] <asac> fta: sure. not sure if the tag is set yet
[19:38] <[reed]> so, don't go pulling build6 just yet :p
[19:38] <asac> but it surely will soon
[19:38] <asac> [reed]: is the tag set?
[19:38] <[reed]> no
[19:38] <asac> good
[19:38] <asac> :)
[19:38] <[reed]> patches haven't landed yet
[19:38] <fta> i monitor the tags, there's not 6 yet.
[19:38] <asac> yeah. thats why i thought we could directly go to build6 and wait with the respin until its tagged
[19:40] <asac> fta: if you want to do a tarball just now go to build5 then.
[19:41] <fta> i wanted to update 1.9.1/3.1 as i'm interested by some new cool features
[19:41] <fta> my tired brain updated 1.9.1/3.0 instead
[19:42] <fta> new cool features or cool new features??
[19:42] <fta> hmm
[19:42] <[reed]> hah
[19:42] <[reed]> cool new features
[19:42] <fta> still no sign of linux patches for chrome... only tons of bug/crasher fixes for windows
[19:43] <[reed]> Google doesn't care about Linux, obviously.
[19:43] <[reed]> :)
[19:43] <fta> most of their apps are win only
[19:43] <fta> there's only Google Earth for linux
[19:44] <fta> that's sad
[19:49] <fta> asac, http://hg.mozilla.org/mozilla-central/rev/4b9f9c1f7e1deb1d2c5b566c538dfe200dbdded6
[19:54] <Jazzva> fta, there's google picasa for linux, but that's still running on wine.
[19:55] <fta> if it's with wine, it's not a linux app
[19:55] <fta> i would love to the see the new version of picasa under linux
[19:55] <fta> or a clone
[19:55] <fta> free clone
[19:56] <Jazzva> i would live to see picasa in gtk
[19:56] <fta> sure
[19:58] <fta> [reed], i hate to see commits without descriptions
[19:58] <fta> such as "Bug 430394, r+sr=roc"
[19:58] <fta> (http://hg.mozilla.org/mozilla-central/rev/f5c472568bf38d3936a570df1a30e8abe1002e7a)
[20:00]  * fta wiping a 350G build-area directory...
[20:26] <fta> i can't stop laughing since i read "If ubuntu drop firefox, I will drop ubuntu and tell anybody near me : don't use ubuntu, it is a bunch of blind zealots."
[20:29] <asac> fta: huh?
[20:29] <fta> https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656/comments/371
[20:30] <asac> 371
[20:30] <asac> nice
[20:30] <fta> 382 now
[20:31] <asac> haha
[20:31] <asac> good laugh
[20:31] <asac> i laugh when i read: "I'm disgusted by all these people, these fanatics. Sorry, I have to go outside and puke."
[20:40] <asac> http://lockshot.wordpress.com/2008/09/15/firefox-eula-in-linux-distributions/
[20:42] <fta> load average: 13.11, 5.83, 2.54
[20:43] <fta> pa/alsa are killing me, locking every apps using sound
[20:45] <fta> boom ff3.1 crashed
[20:46] <fta> with a 110M crash file
[20:49] <fta> seems ff3.1 is leaking fds for /tmp/jemalloc.XXXXXX
[20:49] <fta> a lot
[20:50] <fta> 241 in my crash file
[20:51] <asac> fta: why jemalloc?
[20:51] <asac> is that in-process flash?
[20:51] <fta> donno, i got a lot of :
[20:51] <fta>  9a900000-9aa00000 rw-p 00000000 08:01 28476919   /tmp/jemalloc.gIo6eB (deleted)
[20:51] <fta>  9ac00000-9ae00000 rw-p 00000000 08:01 28476948   /tmp/jemalloc.0Xetwg (deleted)
[20:51] <fta>  9ae00000-9af00000 rw-p 00000000 08:01 28476947   /tmp/jemalloc.C192GX (deleted)
[20:52] <asac> fta: you dont know if you are using in-process flash?
[20:52] <fta> i crashed with 70+ tabs open
[20:52] <fta> some probably had flash in them but not 241
[20:52] <asac> if so its likely that flash doesnt like jemalloc. most likely in combination with alsa
[20:53] <asac> ah ... ok thought you said its related to pa issues ;)
[20:55] <fta> well, difficult to say, sound regressed a lot for me in intrepid
[20:55] <fta> i'm not using the alsalib patch from crimson and the pa from luke's ppa, it seemed better but it's not
[20:56] <fta> -i'm not+i'm now
[20:56] <fta> s/crimson/crimsun/
[21:00] <fta> ok, a zombie of prism was holding the dsp
[21:01] <fta> so it was xul 1.9
[21:01] <fta> sound is back, and load is dropping
[21:04] <fta> [reed], seems trunk is leaking fds of /tmp/jemalloc.XXXXXX
  9a900000-9aa00000 rw-p 00000000 08:01 28476919   /tmp/jemalloc.gIo6eB (deleted)
  9ac00000-9ae00000 rw-p 00000000 08:01 28476948   /tmp/jemalloc.0Xetwg (deleted)
  9ae00000-9af00000 rw-p 00000000 08:01 28476947   /tmp/jemalloc.C192GX (deleted)
 241 in my crash file
[21:14] <fta> http://paste.ubuntu.com/47563/
[21:14] <fta> seems like a mmap on a deleted file
[21:31] <fta> asac, prism is no longer building fine with my xulapp build-system :(
[21:32] <fta> nsPrismStub.cpp:42:49: error: nsXPCOMPrivate.h: No such file or directory
[21:33] <asac> fta: nsXPCOMPrivate.h sounds wrong
[21:33] <fta> indeed
[21:33] <asac> if thats in nsPrismStub.cpp then either its a bug or that stub isnt supposed to be build
[21:33] <asac> i assume its the latter
[21:33] <fta> #include "nsXPCOMPrivate.h" // for XP MAXPATHLEN
[21:34] <asac> most likely its a xulrunner stub that prism tries to build ... but which we shouldnt need (e.g. just cp xulrunner-stub should be enough)
[21:34] <asac> fta: try to not build that stub
[21:34] <asac> e.g. fix prism makefiles
[21:34] <asac> and see if that works better
[21:34] <asac> and maybe replace for libxul sdk builds that stub building with cp xulrunner-stub ...
[21:35] <asac> of course take a look at the nsPrismStub.cpp thing
[21:36] <fta> http://paste.ubuntu.com/47571/
[21:37] <asac> fta: so yes. as i guess. just a copy of nsXulStub
[21:37] <asac> prism wants to use copy in libxul-sdk builds
[21:37] <asac> and dont build it on its own
[21:38] <Lns> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=453704#c8 - for my debugging yesterday. I'm also in irc.mozilla.org/#firefox w/mzz right now trying to hone in, if you're interested
[21:41] <fta> asac, there's a stub.rc now: http://paste.ubuntu.com/47572/
[21:43] <asac> fta: i think you dont need to build the client at all
[21:43] <asac> it should just be a copy
[21:43] <asac> or are you saying that that doesnt work on 1.9.1 anymore?
[21:43] <fta> before, it was copying the stub from xul
[21:44] <fta> make[5]: Entering directory `/build/buildd/prism-0.9+svn20080610r15085/prism/client'
[21:44] <fta> cp /usr/lib/xulrunner-devel-1.9/bin/xulrunner-stub ../../dist/bin/prism
[21:44] <fta> make[5]: Leaving directory `/build/buildd/prism-0.9+svn20080610r15085/prism/client'
[21:44] <fta> now it builds its own
[21:44] <fta> no, it's not 1.9.1, i'm still using 1.9
[21:44] <fta> for prism
[21:44] <asac> fta: yes. i think thats really just for in-source builds
[21:44] <asac> plasticmillion probably got that wrong
[21:45] <asac> most likely he tried to speed up the build by not requiring complete xulrunner build
[21:45] <asac> or something similar
[21:46] <asac> but if you are unsure, ask him before patching.
[21:47] <fta> http://paste.ubuntu.com/47573/
[21:48] <fta> bouhh, a dll
[21:52] <asac> fta: yeah
[21:52] <asac> probably
[21:53] <asac> if not XULSDK
[21:53] <asac> DIRS=stub
[21:53] <fta> it's not my patch, but the diff between my last and the current
[21:53] <asac> else
[21:53] <asac> cp .... ;)
[21:53] <asac> fta: yeah
[22:00] <Volans> asac: sorry I was dinning ... lp:~volans/+junk/med-auto-scripts for the first script, I can make the second tomorrow
[22:00] <asac> Volans: why do you use +junk? (just curious)
[22:01] <Volans> because LP was refusing my push :)
[22:01] <asac> where did you try to push?
[22:01] <Volans>  bzr push bzr+ssh://volans@bazaar.launchpad.net/~volans/med-auto-scripts/trunk
[22:01] <asac> the idea was lp:~volans/firefox-extensions/med-auto-scripts
[22:01] <Volans> and also without /trunk
[22:01] <asac> na
[22:02] <asac> there is no project med-auto-scripts ... so it wont work
[22:02] <asac> use what i suggested ;)
[22:03] <Volans> sorry, I have remeber that path... pushing now
[22:03] <Volans> done
[22:15] <asac> Volans: ok. so what do we need next? ;)
[22:15] <asac> an example config file
[22:16] <asac> maybe a amo-upstream-branches.txt file ;)
[22:16] <asac> with
[22:16] <asac> AMOID .upstream branch ?
[22:16] <asac> mappings
[22:17] <Volans> yes, if you don't want to use the actual structure you have already done
[22:18] <asac> hmm
[22:18] <asac> not sure ;)
[22:18] <asac> you can decide. in the end is the config format used by the top level script i think
[22:18] <asac> so it doesnt matter what we use to test that ;)
[22:19] <Volans> as discussed I'm trying to do scripts that can be used in a simplies way, whatever the "master script" will be structured
[22:19] <asac> Volans: hmm. usage might be improved for mirror.sh
[22:19] <asac> the "folder" is nowhere named
[22:19] <asac> but thats detail
[22:20] <Volans> the AMO public folder?
[22:21] <asac> no .. sh mirror.sh --help ;)
[22:21] <asac> isnt really verbose ;)
[22:22] <Volans> I dont' have implemented it... and is curious the output :)
[22:23] <asac> sh mirror.sh 10 23 output
[22:23] <asac> err
[22:23] <asac> sh mirror.sh 10 23 output/
[22:23] <asac> didnt put the result into the output/ folder
[22:24] <asac> well ... it should have created it
[22:24] <asac> i
[22:24] <Volans> I have understand that you have choose the first version
[22:24] <Volans>  mirror.sh <amoid1> [<amoid2> ...]
[22:25] <Volans> without the folder, assuming that the master script will do the right cd /path/ before run the script
[22:25] <Volans> but if you want I can add it very quickly
 <amoid> ... that was the lasti posted i think
[22:25] <asac> Volans: no ... please no "cd" in master script
[22:26] <Volans> ok, as you want, it's the same for me
[22:26] <asac> well. it would be ok if really needed. but i think a <output-folder> should be fine
[22:26] <asac> cool
[22:27] <asac> ok. whats next
[22:27] <asac> get-new-queue <amo-directory> <current-version>
[22:27] <asac> which then just dumps the sorted list of .xpi files ;)
[22:28] <asac> (sorted according to versions from install.rdf that are greater than current-verseion)
[22:28] <Volans> yes, where current version is upstream branch install.rdf version
[22:28] <Volans>  <amo-directory> =  <amo-id>
[22:29] <asac> Volans: right. for that we probably also want a script "get-install-rdf-version"
[22:29] <asac> not sure if we want to reuse that in the get-new-queue script
[22:29] <Volans> given a branch path?
[22:29] <asac> but maybe we do
[22:29] <asac> Volans: yeah
[22:29] <Volans> ok
[22:30] <Volans> what name?
[22:30] <asac> we could also implement med-xpi-get-upstream-version path/to/tree
[22:30] <asac> which then would look at path/to/tree/install.rdf
[22:30] <asac> but we can later decide i think
[22:30] <asac> depending on what we need/not-need in other scripts
[22:30] <Volans> ok
[22:31] <Volans> get-install-rdf-version.sh or something shorten?
[22:32] <fta> [reed], http://glandium.org/blog/?p=207
[22:38] <[reed]> fta: he's wrong again
[22:38] <[reed]> (really! this time)
[22:38] <[reed]> :p
[22:43] <Volans> sorry asac I have to go now... see you later or tomorrow
[23:24] <fta> bug 243130