[00:10] http://twinturbo.org/firefox/removing-the-firefox-3-eula/ [00:13] [reed], do you have jit on now ? [00:14] <[reed]> on one of my laptops [00:14] usable ? [00:14] = are the crashes gone ? [00:14] <[reed]> not all [00:14] <[reed]> but most [00:16] [reed], both chrome and content or just one ? [00:16] <[reed]> both [00:16] hm, ok, trying [00:35] ok. i am giving up [00:35] debian upload queue doesnt like me [00:36] it always claims that my upload was already uploaded [06:26] Jazzva: are you here? i cant remember your time zone [06:41] how the hell do you post a comment on debian's bug tracker? [06:42] gnomefreak: email bugnumer@ [06:43] vk5foss: you mean like bug#@bugs.debian.org [06:45] gnomefreak: yeah. [06:49] asac: sorry, didnt see your comments 7 hours ago ... i see it says its fixed ... whys that? [06:52] asac: not sure i follow, tbh :/ [07:08] this guy is a real moron :( [07:19] 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] is there a site that has instructions to get a sponser for Debian? [07:27] * gnomefreak taking a break maybe sleep [07:28] later maet [07:28] *mate [08:28] vk5foss: ? [08:28] gnomefreak: thanks [08:29] oh, the nick === vk5foss is now known as kgoetz [08:30] * kgoetz is Kamping_Kaiser [08:30] kgoetz: you are really a camelino ;) [08:31] kgoetz: sorry its early and didnt have coffee yet. what are you referring to? [08:32] asac: sorry, i dont bother to reset my nicks when the 'net drops [08:32] asac: i was replying to what you said to Kamping_Kaiser ~9 hours ago [08:35] 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] asac: if you don't have time to help out with this, let me know, and I'll ask around [08:54] asac: i have to go to work now from where no irc, but I'll be on email if you can discuss [09:18] 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] mdke: ok. got the mail [09:21] asac: ah, ok. [09:59] bug 269010 [09:59] Bug 269010 on http://launchpad.net/bugs/269010 is private [10:10] asac: just got the emails re: ca-certs. i'll re-read it tomorrow when i'm a bit awake and clueful [10:14] kgoetz: right if you wnat more clarification feel free to ask [10:15] asac: will do. [10:15] * kgoetz gone [11:52] @now new_york [11:52] Current time in America/New_York: September 16 2008, 06:52:04 - Next meeting: QA Team in 1 day [11:53] thats odd [11:56] 11:00 UTC, 3rd Tuesday of the month [11:56] im not crazy :( [11:59] hehe [12:00] "crazy" is hard to define [12:01] in this case i wish i was crazy i only got 3 hours of sleep so i can be at the meeting [12:02] ouch [12:02] ill go back to sleep after meeting or in a few hours [12:03] 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] gnomefreak: better rest first ... then work ... the other way around isnt productive ;) [12:04] thats true [12:26] * gnomefreak doesnt remember why i needed Jazzva yesterday :( [12:26] gnomefreak, I remember you asked how to send a comment on debian's BTS [12:27] but someone already answered... [12:27] 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] 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] Jazzva: me too im only up for CC meeting that seems to not be happening [12:33] asac: is there a site explaining the process to getting a new or fixed package into debian? [12:35] i can at least add this extension to the wiki if its not already there [12:38] Jazzva: how do you feel about dropping mozilla-bookmarksftp for placesync? PlaceSync appeared (which is a cut version of Sync and Sort) [12:38] https://addons.mozilla.org/en-US/firefox/addon/8379 [12:39] wait on that [12:40] gnomefreak: the process is to submit a debdiff to the debian bug or open a new one [12:40] then hope that the maintainer includes it [12:40] unless its release-critical there is no way to "just" upload it without the maintainer taking the patch [12:40] how do i get a debdiff for a new package? [12:41] theres nothing to get a diff from [12:42] Jazzva: imleaning towards foxmarks for a replacement for mozilla-bookmarksftp [12:47] bug 227711 [12:47] Launchpad bug 227711 in hunspell-en-us "hunspell-en-us conflicts with thunderbird (unversioned)" [High,Fix released] https://launchpad.net/bugs/227711 === ma10 is now known as ma10-NOeULA [13:11] there sent email to firemarks people about licenses now i can feel better to go back to bed. [13:18] ok bed time ive done enough for now. damn i have one more fast thing to do [13:18] there all done ;) [15:12] asac, fta (fta2): is there anyone already working on addons to add abrowser and/or test some large maintenance script? [15:14] 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] (abrowser depends transition that is) [15:15] 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] Volans: have you tried to implement the scripts i mentioned? [15:17] 1- can I help you working on abrowser depends transition or you have already planned to do this? [15:17] 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] 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] in such a way we can use tools like uscan and uupdate like standard packages [15:20] 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] Volans: ad 3. i dont think that "script" is really important which language we use [16:17] Volans: i think as long as we really need a real scripting language, using basic sh should be fine [16:18] s/need/don't need/ [16:18] ok, so I go ahead with my tests [16:18] you agree to add a watch file to all extension packages in the long run? [16:18] Volans: adding a watch file would be one way to do it [16:19] Volans: the other way would be that we maintain the watch files for the upstream branches in the "bot config" tree [16:19] 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] Volans: let me show you something (which would be fine to completely dump and start from scratch ;)) [16:21] ok, thanks [16:21] https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT.TASKS [16:21] https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT [16:22] * Volans downloading the code [16:23] the BOT.TASKS is a directory structure that has the idea to allow bot tasks to be configured [16:23] and in BOT there is a generic runtask script [16:24] which is supposed to load the config for a certain task ;) [16:24] e.g. runtask BOT.TASKS/upstream/amo/flashblock.ubuntu.HEAD [16:25] the idea is that the TASKS tree is a hiearchy of config files that allow to overload values ;) [16:25] 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] 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] asac: so you want to manage both new AMO versions and upstream versions? [16:26] Volans: later. the idea is that this will be extensible. [16:27] great [16:27] 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] (and complex) [16:27] Volans: might be. but ... [16:28] _all_ the logic to parse the config in the above way is already in the "runtask" script [16:28] so we would just need to refactor that to a functions script [16:28] so the "complex" partis probably mostly done [16:29] 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] and AMO would then just implement the watching like it would be done in a normal script [16:29] Volans: but well. i think its fine to do it different ... e.g. simpler [16:29] to get things started [16:30] if not sure to understand all the details so far, but go ahead [16:30] Volans: thats why i ment that its easier to start to write the scripts we discussed [16:30] we can use them now to hack something that works [16:30] and later hopefully reuse them in the complete system [16:31] though that is of course not guaranteed ;) [16:31] is exactly what I am doing.. something that works now :) [16:31] right. but i would like to maintain the watchfiles in a config branch i think ;) [16:31] everything else you can do as you want :) [16:32] unless you see a reason why maintaining them outside the package is bad [16:32] so, don't add the watch file to the source package? [16:32] right [16:33] you already have a tool/script that can download the latest version from AMO directory? [16:33] Volans: for instance we could ahve a config branch: upstream-syncs/amo/ [16:33] and put all watch files in there [16:34] Volans: what we want is to download a specific version if possible [16:37] 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] why specific and not the latest? [16:39] Volans: i just assumed that we know the new version through the check-extensions script [16:39] however, that isnt really necessary [16:39] at best we would pull down everything _new_ and import everything up to the last release [16:39] e.g. if there have been two releases in between we probably want to import both [16:39] 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] for the many releases in between you are right, we have to import all, one at time in the branches [16:40] 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] also write a dump script that upgrades an existing branch from a given .xpi [16:41] dumb [16:41] all separately? [16:41] and when we have all pieces together write one top level script that orchestrates those "small" tools [16:41] for a higher purpose use-case [16:42] ok, more clear now [16:42] like upgrade-upstream-branch-and-attempt-merges ;) [16:42] but here: i dont care ;) ... if everything just works i am fine with a monolithic script to get things started [16:43] but otoh, i have the feeling that this might block us from doing long term changes through incremental improvements [16:43] I agree, many small scripts are easy to maintain and imporve [16:43] yes. the code would be much mroe stable [16:44] and also we should always try that whatever we do, something doesnt get completely blocked because one team member doesnt have time [16:44] and a monolithic script sounds like it might end up in that kind of lock [16:45] at least after a bunch of upstream methos have been added ;) [16:45] Volans: anyway. i think i managed to use uscan without a debian package [16:46] oh, sounds good [16:46] but maybe thats not news for you ;) [16:46] but it has been quite a while and i cannot really say what i did [16:46] maybe i didnt manage to do that and create a spoof debian tree in a mktemp directory [16:47] 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] Volans: well. i think we still need watch files [16:48] because its not easy to guess the .xpi filename for all extensions [16:49] but i think using uscan --upstream-version=... --download ... --watchfile=... ... should work [16:49] maybe there is still a aparamter missing [16:49] 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] if I can use uscan "externally" will be better, I will read more in depth it's manpage [16:50] good [16:50] Volans: if you need different parameters let me know [16:50] parameters? [16:51] 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] Volans: well. the contract of the download script [16:51] i think i suggested download-amo-xpi

[16:51] not sure if that is enough [16:51] thats just what i ment [16:52] depends on what is [16:52] if is only version number, no it will not work [16:52] maybe complete xpi name will be better, this can be done saving in the config file the "master" xpi filename [16:52] Volans: would it work better that you always download all that are older than a known xpi name? [16:52] that AMO uses [16:53] like ... last time you uploaded chatzilla-0.1.x.xpi [16:53] err downloaded [16:53] then get everything that came after that? [16:53] older or newer? [16:53] newer [16:54] after - on the time scale [16:54] Volans: but well. actually why doesnt help? [16:54] because we dont know if the filename includes the same upstream version that is in install.rdf? [16:55] 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 **.xpi will be sage [16:55] err... safe [16:55] hmm [16:56] ok. so maybe watchfiles arent really that helpful? [16:56] so could we say we dont care how .xpi's are named (except a basic regex pattern?) [16:56] and just find the "last processed" and download/import everything made after that? [16:57] (given that we remember the filename of "last processed") [16:57] or what is your idea? [16:57] 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] some changes I see in the AMO filenames [16:58] are strange [16:58] Volans: yes. i think we should provide two regexp: 1. regexp-active, 2. regexp-ignored ... we only download active obviously [16:58] and we provide an error/warning when there is a file that doesnt match any of 1. or 2. [16:59] so we can detect in case the filename has changed to something new :( [16:59] at least one idea ;) [16:59] yes, something like that [16:59] but imo only practice will show what is relevant [16:59] we shouldnt bother too much with corner cases before starting [17:00] 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] Volans: i think we could use watchfiles. those are basically just downloads with regexps [17:01] hmm [17:01] but we probably cannot download all right? [17:02] all the newer from the latest merge? [17:02] Volans: well. upstream branch is independent from merging. so to be more accurate i would say "newer from last xpi processed" [17:02] yes [17:02] or "newer than last xpi imported" [17:02] ;) [17:03] but if its really simpler to "just" download the last [17:03] then fine [17:03] why not [17:03] this shouldnt block all this [17:04] ok, I make a simple test with uscan and then go ahead with latest if it fails [17:04] but i am not sure if that is really easier ;) [17:04] if uscan fails? [17:04] if I fails to use uscan to download all newer versions in a simple way [17:05] 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] Volans: we could use simple ftp maybe? [17:05] but surely is not quick [17:05] e.g. mget [17:06] yes the archive is both ftp and http [17:06] e.g. chatzilla-*.xpi [17:06] we could do a ls and find the last processed file [17:06] and download all files that come after tht [17:06] that [17:06] good idea [17:06] Volans: maybe wget can even do real regexps on ftp [17:08] 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] Volans: can we assume that the version number is available in a sortable fashion for nowß [17:08] ? [17:08] even if its not the same version number that is in installr.df (which is the actual upstream version) [17:09] i think we can. so a ls in ftp, then sorting them by version number should be fine [17:09] 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] Volans: ok. would ftp on its own show them properly sorted? [17:10] usually that becomes an issue if version are like: [17:10] 0.8 [17:10] 0.9 [17:10] 0.10 [17:10] instead of 0.08 0.09 0.10 [17:10] Volans: hmm. maybe we should really download all [17:10] everything seems too complicated [17:11] not sure how much data that is [17:11] they seems to be sorted on ls on ftp [17:11] is there a ftp sync tool that does smart things? [17:11] Volans: yes. but i think there will certainly be too many versioning schemes that might break the "basic" ls [17:12] 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] download all for older extensions can be very useless [17:14] downloading 20 versions to upgrade just one :) [17:15] Volans: ordered by the uscan tool? [17:15] or by plain ls? [17:15] does ls order by timestamp? [17:16] by plain ls on ftp [17:16] the timestamp problem is that all version prior Mar 25 2007 have the same date [17:16] maybe is the creation time of the archive [17:17] Volans: yeah. what is the ftp address? [17:17] ftp ftp.mozilla.org [17:17] login anonymous [17:17] cd /pub/mozilla.org/addons/AMOID [17:17] for example 39 [17:17] (mouse gestures) [17:18] Volans: have you found any extension with lots of releases? [17:19] AMOID=138 [17:19] stumbleupon [17:19] also 427 scrapbook [17:21] Volans: ok. so how big is amo? [17:21] is mirroring too much? [17:22] I think they have the whole history [17:22] let me try ;) [17:22] what? [17:23] mirror AMO ;) [17:23] just to see how big it is [17:23] ah.... :) [17:23] we have only some 15-30 extension at the moment [17:24] yeah. that make things even better [17:25] asac: you want to mirror AMOID directories of our packages? [17:25] yes [17:26] wget -m --recursive ftp:/...AMOID/ [17:26] works nicely ;) [17:26] Volans: so i think we can just do: [17:26] you have a server where all those script and work will be done? [17:26] for i in $AMOIDs; do [17:27] wget -m --recursive ftp://..../$i/ [17:27] done [17:27] and then process all .xpi's and introspect them for the upstream version [17:27] with zgrep for example [17:27] Volans: i could put that onto something if it works [17:27] e.g. something that branches the CONFIG branch on every run [17:27] and then processes [17:28] Volans: yes. zgrep appears to be available everywhere [17:29] ok [17:31] * Volans doing some schema to organise (hoping with some logic) the script and tasks [17:32] sure feeel free to innovate [17:54] 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] (not to mention packaging stuff like debuild, etc...) [17:54] Volans: "updated bzr branch" .. meaning "updated upstream bzr branch" ? [17:55] "updated package" == " updated package bzr branch" [17:55] 1: yes [17:56] 2: I was forgotting the .ubuntu branches... sorry, I was meaning the dsc, debdiff, etc... [18:02] asac: I change my question... if we have 3 newer versions, you want in the upstream branch 3 commits, right? [18:03] and in the .ubuntu branch? only the final one? [18:05] Volans: you dont need to care for dsc and such anymore [18:05] all that matters here is ubuntu and upstream branches [18:05] (for now) [18:05] ok [18:06] Volans: so we have a cronjob that runs and updates upstream branches [18:07] this is already done? [18:07] Volans: no thats what i think you should implement [18:07] the rest is indpendent ;) [18:07] ah ok :) [18:08] once we ahve that we can do the "auto-merging" and "propose for merging" quite easily i think [18:08] do you need al the details now? [18:09] the algo is simple (might have rough edges): [18:09] for all BRANCHES: [18:09] err [18:09] for all UBUNTUBRANCHES: [18:10] try to push ubuntu branch U to U.merge [18:11] ok [18:14] if that fails we just trash U.merge and push U there anyway [18:14] then we merge upstream onto if [18:14] done [18:14] hmm [18:14] forget it ;) [18:14] i think i forgot something important ;) [18:14] i think i documented it on the wiki [18:14] but for now upstream branches are important to auto produce ;) [18:14] for extension there are added in future? [18:15] asac: I have done a simple schema to be sure to do useful things... http://pastebin.com/d589a1056 [18:15] can you see if there is something relly wrong? [18:16] s/relly/really/ [18:17] Volans: i think download.sh shouldnt checkout the branches [18:17] we could introduce a script initbranches.sh or something [18:17] ok [18:17] checkoutorupdatebranches.sh [18:18] Volans: i think download.sh is actually mirror.sh [ ...] [18:18] or maybe even [18:19] mirros.sh ... [18:19] so it doesnt have to assume that any particular directory structure exists [18:19] right [18:19] mirror.sh that is ;) [18:21] newer.sh could be [18:21] hi [18:21] what a day! [18:22] get-import-jobs.sh

[18:22] get-import-jobs.sh

[18:22] Hi fta [18:22] fta: what happened? [18:24] bah, another though day [18:30] reconnect [18:30] 19:22 < asac> fta: what happened? [18:30] 19:29 < asac> Volans: and 3rd. update.sh would then get a .upstream branch name and the .xpi file to import [18:30] 19:29 < asac> so maybe import-xpi.sh [18:31] ok [18:31] you have lost only: (19:24:59) fta: bah, another though day === asac_ is now known as asac [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] [reed]: shipping == shipping beta you mean? [19:13] <[reed]> we shipped beta last week [19:13] <[reed]> heh [19:13] urgh [19:13] thats fun [19:13] <[reed]> final was supposed to go out today [19:13] 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] good luck then [19:14] wow, this bug just never ends [19:14] again an information problem [19:14] <[reed]> (this is for 3.0.2 / 2.0.0.17) [19:14] i know [19:14] final of what ? [19:14] <[reed]> are you on release-drivers@/ [19:14] <[reed]> if not, you should be [19:14] [reed]: silence on the security list on anything ... at least not a few days ago [19:15] <[reed]> caillon is on there [19:15] great. that explains a bit [19:15] 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] [reed]: if that is low traffic then that would be great [19:16] [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] @jwsdot.com [19:17] <[reed]> and then it becomes high traffic [19:17] yeah. thats exactly what i am looking for ;) [19:17] finally i can see by graphical visualization of the inflow of messages what is going on ;) [19:17] like staring at the matrix ;) [19:18] http://hg.mozilla.org/mozilla-central/rev/da539de11534af7950027f741ddc72d4afa7496e [19:19] fta: yeah. maybe a good sign :) [19:19] <[reed]> Successfully subscribed: [19:19] <[reed]> * asac@jwsdot.com [19:20] [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] [reed]: ok ml is working. thanks. got my first "live-mail" ;) [19:30] <[reed]> hehe [19:31] asac: mirror.sh script done, you want to take a look or that I put it somewhere? [19:32] Volans: just push it to a branch [19:32] alone? [19:33] why not ... the first script of a series ;) [19:33] LOL... I have to put some license statement? [19:34]