[00:03] fta: thats a new patch [00:03] we still have the review+ one [00:03] sunil is the spicebird guy iirc [00:06] fta: do you log every channel you join? [00:06] yes [00:06] fta: do you have the workshop logs? [00:06] at UDS? [00:06] hmm ... maybe that was here? [00:06] when was that? [00:06] it was here [00:07] 11th dec? [00:07] or 12th? [00:07] 11&12 dec [00:11] hmm [00:11] :) [00:40] asac, http://paste.ubuntu.com/100681/ [00:43] GRE_VERSION=@XULVER@ [00:44] what woud that be? [00:44] 1.9.1b3pre [00:44] 's/\+nobin.*//' ? [00:45] no need, already covered [00:45] fta@ix:~ $ echo 1.9.1~b3~hg20090103r22626+nobinonly-0ubuntu1~fta2 | sed -e 's/\+.*//' -e 's/~$[^~]*$.*/\1pre/' [00:45] 1.9.1b3pre [00:45] fta@ix:~ $ echo 1.9.0.5+nobinonly-0ubuntu1 | sed -e 's/\+.*//' -e 's/~$[^~]*$.*/\1pre/' [00:45] 1.9.0.5 [00:45] if i have to do 1.9.1+1+nobinonly? [00:45] oh [00:46] not sure if its an issue ;) ... or if we want what is before first + anyway [00:46] but at least we should think a minute ;) [00:46] it's fine, we want 1.9.1, not 1.9.1+1 [00:47] yes ... and main use case for +1 would be later fixup of tarball ... in which case upstreawm version still is 1.9.1 [00:48] fta: why not just do this on upgrade [00:48] nm [00:48] on upgrade can we see files of old package or not? [00:49] yes [00:50] then just do that on upgrade [00:50] and dig the accurate gre version from the "old" files [00:54] fta: hmm ... actually this all reminds me that we should consider to add a new location in /usr/share/gre.d or something [00:54] maybe such a location exists? [00:54] what for? [00:55] for the "in package" shipped conf files [00:55] /etc is ment for admins ... not for packages [00:56] as we can see with all the troubles we have [00:56] so in perfect world, xul would look at ~/.gre.d/ /etc/gre.d/ /usr/share/gre.d/ [00:56] in that order [00:56] ah of course the env MOZ_GRE=/... is first [00:58] /etc/gre.d/ is not our choice in the 1st place, it comes from upstream [00:58] but you're right, it's ugly [00:59] yes i know ... thats why we need an upstream patch [01:00] but issues with /etc management are only debian based. we'll have to convince benjamin that it's wanted for everyone [01:01] i can smell the r- from here :P [01:01] GRE_HOME [01:02] is first [01:02] hmm [01:03] MOZ_GRE_CONF [01:03] seems to be on UNIX [01:03] then ~/.gre.config [01:03] then ~/.gre.d/*.conf [01:03] /etc/gre.conf [01:03] /etc/gre.d/ [01:04] aren't the files only legacy? [01:04] probably [01:04] i dont suggest /usr/share/gre.conf ;) ... just gre.d [01:10] Hi [01:11] hi [01:11] I'm uploading adblock-plus 1.0 to Jaunty right now. Would be good if someone could test it once it has built :) [01:11] fta: http://paste.ubuntu.com/100698/ ;) [01:11] review- [01:12] err, more like http://paste.ubuntu.com/100699/ [01:12] still - [01:12] fta: what does redhat/suse do about /etc stuff? [01:12] just wipe everything on upgrade? [01:15] RainCT: i guess a bunch of people use it :) [01:15] i think i use it too [01:15] so will just take bit ;) [01:18] asac, no idea [01:19] fta: (sorry to cut in; themuso and i are working on getting nightlies built of pulseaudio, alsa-lib, and alsa-plugins so it'll be easier to test for regressions) [01:22] nice [01:24] well, I'm off now. Good night! [01:25] me too, not enough sleep last night === rzr is now known as rZr [09:32] asac, http://paste.ubuntu.com/100931/ [09:36] obviously, it should be simpler [09:47] fta: how about shipping the test_harness? [09:47] e.g. the test_all.sh === asac_ is now known as asac [10:18] fta: Bug 312353 seems fixed according to bug [10:18] Launchpad bug 312353 in xorg-server "improper mouse hover behavior with links" [High,Fix released] https://launchpad.net/bugs/312353 [10:20] asac: pop/imap ssl, pop, smtp, smtp/ssl, dragging messages within imap and into it, encryption/decryption/signing with enigmail works [10:20] preference tabs look ok to me [10:21] now i just need to find the config switch to change the language :) [10:29] white: install a langpack and export LANG=you_LANG [10:29] then start [10:29] asac: one minor thing [10:29] asac: when i install all packages (except -dev and -dbg) i got a bit of an ugly gui part [10:29] in one of the preference tabs [10:29] but it doesn't exist, if i only have icedove installed [10:32] asac: language pack works, tested with German [10:35] good [10:35] open all preference tabs and so on [10:35] if thats good, you are ready to go i guess [10:35] fta: how about shipping the test_harness? <= hm, i think i do ship test_harness [10:35] asac: so far so good, i'll do my debdiffing now over the binary packages [10:35] asac: do you want to have a last look over the advisory? [10:36] white: no. looked good yesterday [10:36] ok :) [10:36] i'll do last checks and then upload, it will take a few days to get all archs i guess :/ [10:50] asac: uploaded [11:08] white: iceape also there now [11:08] (uploaded) [11:08] asac: FTBFS on s390 :/ [11:10] asac: http://paste.debian.net/25356/ [11:16] asac: also i think we still should get a CVE id for mfsa2008-59, what do you think? [11:17] white: s390 is known to be broken [11:17] white: the porters replaced the machine that was initially used for etch with something new [11:17] since then some s390 guy does binary uploads for security [11:18] read the team@ archive or ask jmm what to do [11:18] ok [11:18] (background: etch was released with s390 ... now security builder is s390x arch) [11:18] bah [11:19] ah got the thread on team@, thanks [11:19] yeah ... thats what i thought too [11:19] especially since they thought "thats probably 100% compatible" and didnt even tell the security team [11:19] pfff [11:19] until icedove and friends blew up ;) [11:20] asac: 12:16 < white> asac: also i think we still should get a CVE id for mfsa2008-59, what do you think? [11:20] :) [11:20] let me check my data again [11:23] asac: re s390: wow, i mean wooooooow. I didn't read it carefully enough back then, but now i am somehow shocked [11:24] white: ok i asked [11:24] (on advisory) [11:24] on sec list it was confirmed twice that -59 is the CVE ... asked if -47 is the same now [11:24] probably get back an answer in a few hours [11:25] white: yeah. s390 is a mess [11:25] we should not allow archs for which the builders are not under physical control most likely [11:25] at least not official [11:27] ack [11:30] asac: yeah, in my notes I had MFSA 2008-59 and MFSA 2008-47 as the same issue, for both CVE-2008-4582 is valid [11:30] asac: although the description of CVE-2008-4582 is missleading as it reads like only windows is affected [11:31] yeah [11:31] lets see [11:31] the redhat advisory guy is super responsive [11:31] who is it? [11:31] <[reed]> B-something another? [11:32] <[reed]> something like Brussels, but that's not it [11:32] <[reed]> can't remember his name [11:32] <[reed]> Josh Bressers [11:32] <[reed]> that's it [11:32] ah yeah, he's great :) [11:33] Josh Bressers [11:33] yeah ;) [11:33] great guy [11:33] never sticks his head in the grounds ;) [11:33] <[reed]> go him :) [11:34] <[reed]> hmm, I was going to do something [11:34] <[reed]> I can't remember what [11:34] <[reed]> hmm [11:34] [reed]: wade through the wealth sg: bugs ;) [11:34] (not through the backdoor ;)) [11:34] <[reed]> hehe [11:36] <[reed]> ah, now I remember [11:36] <[reed]> I was going to land a patch [11:36] delicious [11:37] <[reed]> yeah, something I wrote [11:37] <[reed]> modifying default bookmarks [11:37] <[reed]> all boring [11:37] <[reed]> but needed to be done :) [11:52] bumb quick! [12:05] asac_the_bumber: what piece? [13:50] asac: ok, it looks like I'll do the iceape DSA as well [13:57] heh [13:57] nice ;) [13:58] thats how it is ... once someone new wants to help out, the old crew - burned out as it is - leaves the ship :) [13:58] asac: this will be a shared adventure in the future, i can assure you ;) [13:59] asac: but for this round, I'll do it :) [13:59] asac: i wouldn't want to exclude all the other sec members from ice* fun :) [14:05] yeah ... try to be hard about it :) [14:06] history shows that i burn out sec members rather quickly ;) [14:06] white: has eric uploaded iceweasel yet? [14:07] mozilla bug 394610 [14:08] Mozilla bug 394610 in Password Manager "Content can corrupt stored passwords by injecting line breaks" [Critical,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=394610 [14:08] does it have a CVE id? [14:09] asac: don't think so, but i am thinking about icedove/iceape now first :) [14:09] sure [14:09] the bug above? [14:09] yes ... but its fixed long time [14:09] dolske: ;) can you rubber stamp 394610 please [14:09] (1.8.0) [14:11] asac: any news regarding CVE-2008-4582 aka MFSA 2008-47/MFSA 2008-59 yet? [14:12] white: i will let you know once we know ;) [14:12] since CVE-2008-4582 was already marked fixed [14:12] in -47 [14:12] we can probably leave it out of this adivory (just anme the MFSA for now) [14:12] or lets wait till builds have finished to decide [14:12] i am quite sure i get an answer soon [14:14] ok [14:14] asac: now to the iceape advisory text :) [14:15] asac: i can probably just use the changelog as an indication, right? [14:16] white: yes. the changelog is done with care [14:17] so the CVEs/MFSAs are ok (except the one in question for -59 of course) [14:19] :) [14:33] @time [14:33] Current time in Etc/UTC: January 06 2009, 14:35:56 - Next meeting: Server Team in 1 hour 24 minutes [14:56] Bug 310126 [14:57] Bug 310126 on http://launchpad.net/bugs/310126 is private [15:19] fta2: ok fennec now gets LICENSE file in upstream hg [16:58] asac: have to go offline now, will finish the iceape advisory tomorrow and get back to you about the DSAs [16:58] sure. thanks! [17:53] asac: ping [17:54] a quick question about UIDs .. the chance that two extensions/programs get very similar UID are really low, right? [17:54] very similar == differ in one character [17:55] well [17:55] i think its many times more likely to get a collision if you remove one char [17:56] the growth is somehow exponential i would say [17:56] but thats just a guess ;) ... complexity theory is long ago [17:58] I'm asking because the guy that mailed us on the mailing list uses the ID that is very similar to FF's ID. So, I think that maybe he has the wrong FF ID in install.rdf, and that he is using it as the ID for his own extension in debian/rules. I'll just ask for a full paste of install.rdf. Thanks :) [17:59] Jazzva: oh. well if thats the case it shoudlnt matter [17:59] though people manually starting with ff id more likely end up with collision [17:59] but well [17:59] if he has a chance to change that tell him to use the new syntax [17:59] product@project.tld [17:59] well, if he uses the wrong ID for FF, FF won't recognize the extension (that's at least my guess) [17:59] this gives him a good namespace and will prevent him from getting collisions [18:00] thanks, I will... [18:18] [reed]: so who is best for js/ build system related superreview? [18:19] <[reed]> js doesn't require sr [18:19] <[reed]> r is enough [18:19] 471359 [18:20] <[reed]> jim's not technically a peer... let me double-check that his review is sufficient [18:20] [reed]: ted forwarded to him [18:20] its a fall out from 467583 [18:20] <[reed]> ah, then probably so [18:20] <[reed]> I just asked crowder [18:21] [reed]: why is brendan listed as js superreveiwer if js doesnt require it ;) ... http://www.mozilla.org/hacking/reviewers.html [18:21] <[reed]> look under Exceptions [18:21] <[reed]> "The JavaScript engine, like NSPR, is a closed CVS partition containing mature code, with dependencies only on another closed CVS partition (NSPR). Module owner review suffices to change JS code." [18:21] interesting ... yeah. was tricked by the "js" in the superreviewers list [18:23] [reed]: module owner review ... but ted isnt module owner i guess ;)? [18:24] <[reed]> normal module-based review [18:24] <[reed]> is what that means [18:25] <[reed]> doesn't mean you have to get mo review [18:26] ok ;) ... but it reads different [18:26] <[reed]> yeah, I know [18:29] <[reed]> asac: you're go for landing [18:29] <[reed]> either land it yourself or add checkin-needed keyword [18:29] <[reed]> make sure you follow proper tree rules when landing if you do it yourself [18:32] asac: do you know what's the name of the new of this new kompozer replacement things? [18:32] argh [18:32] weird sentence xD [18:32] sebner: heh? [18:32] i actually thought kompozer was the new one ;) [18:32] asac: nah, it's outdated (2007) [18:33] asac: fta found something new [18:33] but nothing stable yet [18:33] i know its outdated ;) still i thought it was the "newer" one [18:33] asac: newer als nvu [18:33] probably a resurrection as a xulapp [18:33] but there is something new in work [18:33] newer or better than nvu? [18:33] asac: well, not stable yet but definately new [18:33] ^^ [18:34] besides .. nvu is 2005 [18:34] so everything is newer [18:34] ^^ [18:34] probably not seamonkey-composer ;) [18:35] technically newer, but didnt really get new features for ages [18:35] nope, AFAIK something else [18:35] fta will know when he is back [18:37] asac: might be http://www.bluegriffon.org/ [18:38] maybe ;) [18:38] i am happy if i dont need to touch any HTML ;) [18:40] mozilla Bug 460548 [18:40] Mozilla bug 460548 in Build Config "Port |Bug 450983 - use leakThreshold for SeaMonkey testers| to Firefox" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=460548 [18:40] lol [18:53] sebner, yes, bluegriffon [18:53] \o/ [18:57] i didn't touch that in a while [18:58] last time i did, i posted 4 patches upstream, they rejected them as dupe because someone was already working on that [18:59] ..for about a year [19:00] yet, not a single patch was ever produced [19:00] *sigh* [19:03] grrr [19:03] fta: but upstream is still active? [19:04] i suppose so, yes [19:04] i can update my package but now, they finally produce some code to replace mine, but i need to patch it again [19:04] +d [19:05] fta: thats a joy ;) ... but there is also good new ... at least we got a r+ on the libxul patch ;) [19:05] asac, yep, told you yesterday ;) [19:05] i mean 471359 ... that was today [19:06] also 471474 seems to move after i proddec mfinkle [19:06] mozilla bug 471359 [19:06] Mozilla bug 471359 in Build Config "trunk build broken with "libxul.so: hidden symbol `deflate' isn't defined"" [Major,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=471359 [19:06] mozilla bug 471474 [19:06] Mozilla bug 471474 in General "fennec/mobile-browser hg tree lacks LICENSE file in top-level directory" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=471474 [19:07] oh, ok. \o/ [19:07] \ / [19:07] \O/ [19:07] | [19:07] hehe [19:07] / \ [19:07] wow ... thats art ;) [19:07] ah, you cut me in half [19:08] but not that bad :) [19:08] at least here on the screen [19:12] outside of the build tree, all my tests complain with uncaught exception: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.normalize]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: ./_tests/xpcshell-simple/test_update/unit/head_update.js :: :: line 320" data: no] [19:12] http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/test/unit/head_update.js#186 [19:13] [pid 9663] lstat64("/usr/_tests", 0xbf9625dc) = -1 ENOENT (No such file or directory) [19:14] where does that /usr come from? === Jazzva_ is now known as Jazzva [19:15] * asac_the_bumber waves [19:15] asac: bumb, testing new xul patch for the sigbus [19:15] * asac waves at armin [19:15] am i subscribed to the bug with the new patch? [19:16] asac_the_bumber: also better track ffox 3.2 from central trunk ;) [19:16] yeah but i haven't posted it yet [19:16] good [19:16] thought i missed a bugzilla mail again (which i would find bad) [19:16] besides its not mine, its from other of the gentoo devs of the sparc team :) [19:18] fta: you once said that project.mk files can be included in the debain dir itself outside mozilla-descripts, does that have a build dependency on 0.12~fta2 or will 0.10 also support that? [19:18] it's > 0.11 [19:18] sorry [19:19] wikz: where do you need it? [19:19] so >= 0.12~fta1 [19:19] fta: isnt that in intrepid? [19:19] no [19:19] k [19:19] i need you to sponsor it [19:19] for intrepid? [19:20] it's in main [19:20] so you want me to upload to jaunty? [19:20] when did you ask me last time ;)? [19:20] yes, but it's not closed yet [19:20] never [19:20] :) [19:20] hah [19:21] not nice to omit details that make me feel guilty/lacking behind ;) [19:21] asac to have a get-orig target and the binonly.sh stuff and all [19:21] wikz: to make your own package without touching it, right? [19:21] asac: I decided to create a no bin only pkg like you guys do [19:22] yeah [19:22] we don't have the bandwidth to support extra stuff :( [19:22] wikz: i would suggest that you include it, but dont use other features then the orig stuff ... in that way you can produce orig on jaunty and all is fine [19:25] i have a few packages already hosting their own mozclient files, ff 3.1 & 3.2, xul 1.9.1 & 1.9.2, fennec, xul-explorer, instantbird and bluegriffon [19:25] asac: but reviewers ask for a get-orig target and all that stuff and since we only host the spicebird code and not the entire TB trunk, I dunno how to create a get-orig target even with moz devscripts. [19:25] ff anx xul could serve as examples [19:27] fta: I modified the tb3.conf files but the problem is we don't host the entire code. One needs to checkout mozilla_TAG_THUNDERBIRD_3_0a2_RELEASE ,then our trunk, merge them both. run a patch script. is it possible to do this with 0.10 ? [19:28] i think thats what m-d-s is designed to do ... plumbering sources from many trees together [19:28] and stirring around ;) [19:28] our ff fetches does something like that already, the 2nd branch is for the branding [19:28] later multi-multi-patchsets on the fly and taking over the world from there [19:28] :) [19:29] -fetches [19:29] yep [19:29] that should be a good start ;) [19:29] fta: I will look into ff3.conf, right ? [19:29] yes [19:29] look for 3.1 or 3.2 [19:29] directly in the ff branches, not in m-d [19:30] asac: lol, I am a python dev here and switching from python to perl to bash confuses the hell out of me [19:30] fta: alright [19:30] fta: we don't host any non free code, if you may want to host our conf files too at a later stage :P [19:32] you mean, your conf/mk files inside m-d ? [19:32] the plan is to remove them all from m-d [19:32] fta: oh and ...? [19:32] host them in each package [19:33] ok ok [19:33] so when you want to update them, no need to update m-d [19:33] fta: MOZCLIENT_POSTCOCMD is the one right ? [19:33] http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.2.head/files/head%3A/debian/mozclient/ [19:33] wikz: you probably need a bunch of vars [19:34] + 2 variables in debian/rules [19:34] http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.2.head/annotate/head%3A/debian/rules [19:34] MOZCLIENT_PROJECTNAME := $(DEBIAN_NAME) [19:34] fta: done those [19:34] MOZCLIENT_PROJECTDIR := $(CURDIR)/debian/mozclient [19:34] that it [19:35] +'s [19:35] :) I read your readme [19:35] great ;) [19:36] yes MOZCLIENT_POSTCOCMD. it's a shell script. [19:36] asac: sunil was asking me if so many DEB_CONFIGURE_USER_FLAGS are really required. He generally doesn't like them. [19:42] fta: after installing, sb doesn't come up in the default mail apps or in the right click>send to menu! what could be the fix? [19:50] wikz: we need speicific configure flags. a general statement doesnt help ;) [19:53] fta: will m-d 0.12 make it to debian testing also because I will eventually have to pursue that too? [19:55] lenny? probably not [19:55] we should upload it once its released though [19:55] you never know when debian releases ;) [19:57] asac: lol [20:01] asac: if 0.12 has not made it to jaunty and I have a build dep on 0.12 it will essentially mean I'm stuck up till then? [20:04] wikz: as i said: dont make it a build depend; just include it optionally in rules [20:04] then you just need to produce tarballs in jaunty [20:04] but can build everywhere [20:04] asac: okie dokie [20:10] wikz, did it work? [20:11] still dloading sources :) [20:11] ok [20:11] fta: will let you know :) [20:11] ok [20:15] damn ... experiencing long nfs hangs [20:16] fta: earlier in the day, I ran lintian against my binary pkgs, http://paste.ubuntu.com/101260/ Can you suggest which ones I need to fix and which ones I can ignore [20:18] debian-changelog-file-is-a-symlink => i'd say ignore for ubuntu. *If* it was for main, we would care about every single byte for the CD. For universe, it doesn't matter much. [20:18] The tree is OPEN.However, 1 box is orange and 5 are burning, so this might not be a good time to check in -- check with the sheriff. [20:18] :) [20:18] http://tinderbox.mozilla.org/Firefox/ [20:18] spelling-error-in-description: i usually fix that [20:19] image-file-in-usr-lib: we don't care in ubuntu. it's too pedantic and too much work for the maintainer. [20:20] in ubuntu we have a shaking automagic to replace equal files with symlinks [20:20] so this debian-changelog- thing probably doesnt happen if built on debian [20:20] <[reed]> [02:18:52PM] spelling-error-in-description: i usually fix that <-- error in what? [20:20] [reed]: package description ;) [20:20] executable-not-elf-or-script: bad; fix absolutely. look at my xul 1.9.1 branch for an example [20:20] <[reed]> ah, whose fault? [20:20] [reed], go back to sleep [20:20] [reed]: lintian is a policy check tool that you can run against package binaries and sources [20:20] ;) [20:21] <[reed]> it's 2:20pm! [20:21] <[reed]> ah, lintian [20:21] [reed]: and it spits out more or less sensible warnings/errors [20:21] <[reed]> ok [20:21] * [reed] goes back to work [20:21] http://paste.ubuntu.com/101260/ [20:21] [reed]: ^^ [20:21] like those ;) [20:21] wikz: you can override the lintian warnings [20:21] postinst-has-useless-call-to-ldconfig: well, somewhat obscure. cdbs fault i would say, there's not much you can do [20:22] yes [20:22] hmm [20:22] you have to include the #DEBHELPER# placeholder i think [20:22] at the end of the file [20:22] but i think i already looked and that doesnt fix it [20:22] menu-icon-not-in-xpm-format: fix it [20:22] done [20:22] fta: definitely [20:22] do we ship .xpm for official branding? [20:22] i think you can ignore it [20:22] not anymore [20:22] at best ship it in .svg format ;) [20:22] xpm is deprecated upstream [20:23]