[00:01] <asac> http://www.mozillazine.org/talkback.html?article=26135
[00:03] <asac> wtf ... http://paste.ubuntu.com/99899/
[00:04] <fta> "stray ‘\305’ in program" ?
[00:04] <fta> you edited that?
[00:05] <asac> no
[00:05] <asac> i hope its not hardware
[00:06] <asac> scary ... seemed to work on second attempt :(
[00:06] <asac> my memory is dying ... sigh
[00:07] <asac> i really feel bad now :/
[00:08] <fta> what do you have in dist/include/nspr/prio.h:301 ?
[00:09] <asac> nothing unusual
[00:09] <asac> how can i make vi show all whitespace codes?
[00:09] <asac> /home/asac/mozilla/security/1.8.1/mozilla/nsprpub/pr/include/prio.h: ASCII C program text
[00:09] <asac> typedef enum PRDescType
[00:09] <asac> { PR_DESC_FILE = 1, PR_DESC_SOCKET_TCP = 2, PR_DESC_SOCKET_UDP = 3, PR_DESC_LAYERED = 4, PR_DESC_PIPE = 5
[00:09] <asac> } PRDescType;
[00:09] <asac> PR_DESC_SOCKET_TCP = 2 is in that line
[00:10] <fta> cat -tven prio.h | grep 301
[00:10] <asac> so its really memory :(
[00:10] <asac> cat -tven /home/asac/mozilla/security/1.8.1/mozilla/nsprpub/pr/include/prio.h | grep 301 301	    PR_DESC_SOCKET_TCP = 2,$
[00:10] <asac> http://paste.ubuntu.com/99903/
[00:11] <fta> nada
[00:11] <asac> i hope its a memory corruption in gcc or some other bug there
[00:11] <asac> and not my poor system :/
[00:11] <fta> https://edge.launchpad.net/+builds/berkelium
[00:11] <fta> boom
[00:12] <fta> *** TEST-UNEXPECTED-FAIL | ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_handlerService.js | true == false
[00:12] <asac> seems still active ;)
[00:12] <asac> yeah
[00:12] <asac> probably your issue again?
[00:12] <asac> wasnt that the one with the setpref for external handler?
[00:13] <fta> i don't remember
[00:14] <fta> JS frame :: ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_handlerService.js :: run_test :: line 155
[00:15] <fta> grr, i should not tar a bunch of symlinks to ../../../../blabla :(
[00:15] <asac> yeah i think thats it
[00:16] <asac> 1.8.1 browser build working :)
[00:16] <asac> finally
[00:16] <asac> lets see if make check works
[00:17] <asac> hangs in netwerk ... of coures
[00:17] <asac> http://paste.ubuntu.com/99909/
[00:18] <fta> https://bugzilla.mozilla.org/show_bug.cgi?id=444440#c31
[00:20] <asac> yeah still broken
[00:23] <asac> @time
[00:25] <fta> Membership?
[02:24] <[reed]> asac / fta: patches accepted!
[02:25] <asac> on mailcap?
[02:59] <[reed]> asac: on anything
[02:59] <[reed]> :)
[03:18] <asac> mozilla bug 461277
[03:18] <asac> ^^
[03:18] <asac> not sure if superreview means that its ready
[03:19] <asac> then approval would make sense
[03:25] <[reed]> you don't need approval to land on mozilla-central
[03:25] <[reed]> sr is enough... bsmedberg owns embedding
[05:28] <crimsun> asac: heads up: jaunty's flashplugin-nonfree for amd64 users causes the same nondeterministic inaudible audio observed in hardy. this is due to ia32-libs and lib32asound2-plugins conflicting.
[05:29] <crimsun> so since ia32-libs is a dependency of nspluginwrapper on amd64, lib32asound2-plugins cannot be installed on Ubuntu, so pulseaudio and all audio apps using it need to be restarted after Flash attempts to grab the sound device.
[05:32] <crimsun> to resolve this issue, two things need to be done: 1) pulseaudio needs to build 32-bit libs for amd64 (similar to what alsa-lib and alsa-plugins do) so that lib32asound2-plugins can be built correctly, and afterward, 2) ia32-libs needs to be updated not to ship libasound2-plugins and instead depend on lib32asound2-plugins.
[07:42] <white> fta asac: the thunderbird tarballs I get with "get-orig-source" have an empty mozilla/mozilla dir, is that intended?
[07:48] <white> asac: i am also happy to start testing, in case you got the packages ;)
[08:52] <fta> white, obviously not
[08:53] <white> fta: well, i was just wondering, whether you hit the same problem ;)
[09:55] <asac> crimsun: thanks for the heads up
[10:41] <asac> white: finally preparing the tarballs now
[10:42] <asac> xul + sm + tbird + ffox (for 1.8.0 branch)
[10:42] <white> asac: ok, if you don't mind I'll start with icedove :)
[10:42] <white> asac: maybe Moritz will take other ice* as well
[10:43] <asac> white: ok. let me prepare the tbird tarball next then (currently tarring up sm)
[10:43] <white> nice, newer nss fails to build on i386 with: error: implicit declaration of function ‘putenv’
[10:43] <asac> white: what is "newer"?
[10:44] <white> asac: 3.12.1-1
[10:44] <asac> we are at 3.12.2~rc1
[10:44] <white> asac: the tarball i was getting with get-orig-source has an empty mozilla/mozilla dir btw :/
[10:45] <white> asac: knewer as in debian new ;)
[10:45] <asac> hehe
[10:45] <asac> white: which package? icedove 1.5?
[10:45] <white> s/knewer/newer/
[10:45] <white> asac: i am still working on an icedove for experimental
[10:46] <asac> ah
[10:46] <asac> white: you need mozilla-devscripts
[10:46] <asac> installed
[10:46] <asac> to produce orig
[10:46] <white> i have it
[10:46] <asac> interesting
[10:46] <white> it downloads a nice thunderbird orig.tar.gz
[10:46] <asac> ah ... so the icedovisation fails
[10:46] <asac> hmm
[10:47] <white> for testing here, i used another tarball with all the stuff self packed and then I get the build problem, where PK11_GetAllSlotsForCert is not declared
[10:47] <asac> white: take a look at the latest tbird 3 packaging branch ... i think fta moved logic from m-devscripts to the packages ... maybe thats the reason
[10:49] <asac> white: there is a bug in nss version checking code in debian/rules
[10:49] <asac> a)USE_SYSTEM_NSS := $(shell pkg-config --exists 'nspr >= 3.12'; a=$$?; if test $$a != 1; then echo 1; fi)
[10:49] <asac> -> that should be nss >= 3.12.1 or something i guess
[10:50] <asac> at least it should fall back to "in-source nss" if the version is not high enough
[10:50] <asac> if 3.12 is too low for a lower bound we should fix it
[10:50] <white> let me check
[10:51] <white> asac: 3.12.0 is too low as it doesn't declare PK11_GetAllSlotsForCert
[10:51] <white> so we need 3.12.1
[10:54] <asac> so debian didnt care to fix nss on i386?
[10:54] <asac> strange
[10:54] <asac> 3.12.1-1: alpha amd64 arm armel hppa ia64 kfreebsd-amd64 m68k mips mipsel powerpc s390 sparc
[10:54] <asac> 3.12.0-5: hurd-i386 i386 kfreebsd-i386
[10:55] <white> i've emailed Mike about it
[10:55] <white> there are different ways to fix it i guess
[10:55] <asac> i think we need a serious bug ;)
[10:55] <asac> nothing filed as it seems
[10:55] <white> put the declaration of putenv everywhere, set defines or maybe compile without -Werror
[10:55] <white> all are ugly ways :)
[10:55] <white> I'll file one
[10:55] <asac> package 3.12.2~rc1 ;)
[10:56] <asac> thats what is currently used for ffox 3 anyway
[10:56] <wikz> asac: Hi
[10:56] <white> asac: do you mind if I try to build it for experimental and maybe upload later today?
[10:57] <white> asac: newer nss that is
[10:57] <asac> white: give it a try. you cannot use ubuntu package unfortunately. we have reverted the soname patch from debian ... mike would hate us if we upload that to debian ;)
[10:57] <asac> white: yeah. just try the new tarball with debian packaging
[10:57] <white> ok, I'll give it a try
[10:58] <asac> white: take our orig i would suggest
[10:58] <asac> seems like upstream doesnt release .1, .2 etc.
[10:58] <white> will do
[11:02] <wikz> asac: The tar in tar trick you told me yesterday. Someone commented on why I had done it.
[11:04] <asac> wikz: your package doesnt ship debian/ dir in diff.gz
[11:04] <asac> thats the current major issue ;)
[11:04] <asac> you punched that in orig as it seems (i didnt look, but since its not in diff.gz and you say it builds I guess it is)
[11:04] <wikz> yeah
[11:04] <wikz> so where did I goof it up?
[11:05] <asac> wikz: you tarred up everything
[11:05] <wikz> asac: true
[11:05] <asac> wikz: the orig.tar.gz must only include tar.bz2
[11:05] <wikz> ok ok
[11:05] <wikz> so just create a tar.gz archive with .bz2 in it
[11:05] <asac> yes
[11:06] <wikz> I included the entire spicebird-0.7
[11:06] <asac> tar cvzf spicebird_0.7.orig.tar.gz spicebird-0.7/*.tar.bz2
[11:06] <asac> for instance
[11:06] <wikz> asac: so how come you guys have a different .orig.tar.gz which doesn't include any bz2 from mozilla. do you repack it
[11:07] <asac> wikz: don't understand the question ;)
[11:08] <asac> if you ask why we pack tarball on our own: answer is simply that mozilal doesnt release frequently enough. also we have to strip no free/binary stuff from it
[11:08] <wikz> asac: that explains it
[11:08] <asac> wikz: you should remove binary only stuff too
[11:09] <asac> look at the "remove.binonly.sh" in mozilla-devscripts
[11:09] <wikz> asac: ok will do that
[11:10] <asac> white: http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/icedove-1.5.0.13+1.5.0.15b+prepatch080614i.tar.bz2
[11:10] <asac> its based on http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/moz_1.8.0.15prepatches080614i.tar.gz
[11:11] <wikz> asac: also I am putting all my files in /usr/lib like fta did but I think debian says that images and resources should be in usr/share. should I change the .install files?
[11:12] <asac> who is debian?
[11:12] <asac> e.g. who speaks for them?
[11:13] <asac> if its "just" lintian feel free to ignore that complained
[11:14] <wikz> asac: yes lintian does for my binary packages
[11:16] <asac> thats not a problem imo ... some might disagree, but well :)
[11:28] <wikz> asac: ok , so if I just pack tarball like you guys do can I get rid of the watch file?
[11:29] <wikz> and remove all the binary stuff. we don't have any non free stuff
[11:31] <asac> wikz: you have a bunch of binary stuff in your tarball i guess
[11:32] <wikz> loads of them :)
[11:33] <asac> then yes. you just need to remove binary only stuff
[11:33] <asac> (binary stuff if sources are there is ok - though not encouraged)
[11:35] <wikz> how about if I will ask upstream to maintain a debian only source tarball so I can use a watch file too :)
[11:35] <white> asac: do you guys have a description base for the mozilla advisories somewhere?
[11:35] <white> asac: or did Moritz always search by himself through the mozilla pages?
[11:37] <asac> wikz: would work
[11:37] <asac> white: usually i put that info in the changelog
[11:38] <asac> in previous times i sent the advisory infos to the list and mike ... but since nobody cared for quite some time i stopped dong that
[11:38] <asac> white: http://www.ubuntu.com/usn/usn-690-3
[11:39] <white> asac: yeah, Moritz complained during the last sec meeting that too few of us did any work on mozilla, thus I'm trying to take at least icedove in this round :)
[11:39] <asac> those are the issues fixed in the 1.8.0 patchset
[11:39] <asac> there are no "mailnews" only advisories this time
[11:39] <asac> but you should also add the MFSAs ... look at the previous changelogs
[11:39] <asac> to get the mapping look at the icedove changelog in unstable
[11:39] <white> will do, thanks for the pointer
[11:39] <asac> that should be a superset of what is fixed in 1.8.0
[11:40] <asac> e.g. take icedove 2.0.0.19 changelog ... filter it by the CVEs from above
[11:40] <asac> hmm
[11:40] <asac> for 2.0.0.18 we need to go through them individually
[11:40] <asac> (this release contains .18 + .19 unfortunately)
[11:41] <asac> white: the starting point is usually: http://www.mozilla.org/security/known-vulnerabilities/thunderbird20.html
[11:41] <white> i'll see that i get through them, would be great, if you could give the final version a glance though :)
[11:42] <asac> white: i will for sure
[11:43] <asac> white: out of the 2.0.0.18 items listed on that page, mfsa2008-52 doesnt apply for 1.8 branches
[11:44] <asac> sorry ... the javascript part doesnt apply
[11:44] <asac> e.g. CVE-2008-5018 is ffox 2 only (e.g. not 1.5)
[11:44] <asac> but CVE-2008-5017 is valid (also 2008-52)
[11:48] <asac> white: everything else in the 2.0.0.18 section of current sid icedove applies
[11:48] <asac> for 2.0.0.19 part use the CVEs in the usn above to filter stuff
[11:49] <asac> oh mfsa2008-48 doesnt apply either
[11:49] <asac> so CVE-2008-5018 (mfsa2008-52 part 1) and mfsa2008-48 are not in 1.8.0 branches
[11:49] <asac> thanks ;)
[11:49] <white> asac: you cause me a headache ;)
[11:54] <asac> white: heh ;
[11:54] <asac> i will give it to you in a few
[11:54] <asac> white: in debian/rules you need to update TBIRD_BZ2_ARCHIVE=thunderbird_1.5.0.15pre080614i-source.tar.bz2
[11:55] <asac> that line
[11:55] <asac> to refer to the proper tar.bz2 that is in archive/
[11:55] <white> done already :)
[11:56] <white> i am test building (started 30 min ago i think)
[11:56] <asac> cool
[11:57] <asac> white: http://paste.ubuntu.com/100263/
[11:58] <asac> i added "not affected" to those entries from icedove that are not affected
[11:58] <asac> i removed  CVE 5510 as its not yet fixed on 1.8.0 (patch is a bit more complicated there) ... in case you want to add that to CVE tracker
[11:58] <asac> http://paste.ubuntu.com/100265/
[11:58] <asac> annotated with proper upstream version
[12:00] <white> asac: btw would you generally be interested in using the security tracker as the source for security overviews? (public issues only of course)
[12:06] <white> asac: older stuff like http://www.mozilla.org/security/announce/2008/mfsa2008-37.html aka CVE-2008-0016 is also fixed in this round? (It was marked as fixed for 2.0.0.17-1)
[12:11] <white> btw Mike mailed me and would rather like to fix the nss FTBFS, so i guess no new experimental version :/
[13:07] <asac> yeah was expected. not sure why he doesnt like the current nss release though ;)
[13:09] <asac> white: look at the bugs referenced in mfsa
[13:09] <asac> http://www.mozilla.org/security/announce/2008/mfsa2008-37.html
[13:09] <asac> those have approval1.8.0.next ... which means that i landed them in distro patchset
[13:10] <asac> white: do you have a bugzilla account?
[13:18] <white> nope :/
[13:20] <white> asac: good news, icedove builds on etch :)
[13:27] <asac> white: yay ;)
[13:27] <asac> does it work?
[13:27] <asac> also test enigmail ;)
[13:28] <asac> basic testing would be: imap with ssl/tls, pop with ssl/tls; dragging messages around, checking that all preferences tabs are functional (e.g. not broken); testing a langpack; testing enigmail (sign/enc); testing sending mail through SMTP and SMTP/SSL
[13:29] <asac> also maybe blog subscription/rss
[13:29] <asac> but well ;)
[13:30] <white> i'm still busy with the advisory, but i'll get to it :)
[13:30] <asac> http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/seamonkey_1.5.0.15pre080614i-source.tar.bz2
[13:30] <white> asac: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4070
[13:30] <asac> if you are brave you would also look at that ... seamonkey doesnt have embedded tarball
[13:31] <asac> you can just use that and after that run ./debian/rules source (which will do the iceapisation :))
[13:31] <asac> white: again, look at the bug ;)
[13:31] <asac> also you can see if the patch is in the "patches" directory of the tarball
[13:32] <asac> it always starts with the bugnumber ;)
[13:32] <asac> in this case its in the patchset ... yes.
[13:32] <asac> asac: approval1.8.0.next+
[13:32] <asac> mozilla$ ls patches/425152_attachment_334030.patch
[13:32] <asac> patches/425152_attachment_334030.patch
[13:33] <asac> (just to clarify: i am happy to dig up everything for you ;) ... just want to teach you how you can find info on your own)
[13:34] <asac> its http://www.mozilla.org/security/announce/2008/mfsa2008-46.html ... which has https://bugzilla.mozilla.org/show_bug.cgi?id=425152
[13:34] <asac> 13:00 < white> asac: btw would you generally be interested in using the security tracker as the source for  security overviews? (public issues only of course)
[13:34] <white> don't worry, it's good to go through it with you and it helps me a lot. I'll get familiar with the stuff, sometimes i just need a little longer :)
[13:34] <asac> what do you mean by that exatly ;)
[13:35] <asac> white: you should really get a bugzilla account ;) ... in future you probably want to be able to see embargoed bugs and i can CC you if you have an account ;)
[13:35] <asac> not really urgent for this round ... but ;)
[13:36] <white> asac: i mean that if you want i could give you access to the tracker and you could track issues there as well, if it helps you (it would of course help us heaps ;) )
[13:38] <asac> i will think about it ... what features does it provide? just adding info where what is fixed?
[13:38] <asac> or can i also add comments (like this is MFSA-2008-XX - javascript part)
[13:38] <asac> ?
[13:38] <white> you can also add NOTEs or TODOs
[13:38] <white> it could even be extended to track ubuntu versions
[13:38] <white> but that might be a different topic
[13:38] <asac> i think we have our own tracker here ;)
[13:39] <asac> (which i dont use ... just push that documentation stuff to sec team)
[13:39] <asac> i will ask them ... maybe there already is a sync or something?
[13:39] <asac> jdstrand: ??
[13:39] <asac> ^^
[13:40] <asac> jdstrand: white is from debian security team ... white: jdstrand is ubuntu security team ;)
[13:40] <white> asac: i've discussed the tracker issue with kees. It seems that ubuntu wants to keep their own tracker
[13:41] <white> asac: however, it would be great for us to have you using our tracker for mozilla stuff and maybe it can be useful for you in several ways
[13:41] <asac> yeah most likely launchpad
[13:43] <asac> white: i would definitly be willing to try that. however, i am really bad at remembering to document stuff ... so better dont rely on me - but i think as soon as i am not alone anymore this tracker thing will just resolve
[13:43] <white> asac: what's the best way to find information about issues like http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4068, where there is no bugnumber :/
[13:43] <asac> white: if there is a mfsa link then you are lucky
[13:43] <asac> click on that
[13:43] <asac> and there you will find the bug
[13:44] <white> no bug there
[13:44] <asac> white: if there is not an mfsa link then its either unfixed or (usually) mitre was on crack and assigned stuff to non-issues
[13:44] <asac> white: https://bugzilla.mozilla.org/buglist.cgi?bug_id=380994,394075,416318
[13:44] <asac> white: there is the link
[13:44] <white> asac: there is a mfa link
[13:44] <asac> its on http://www.mozilla.org/security/announce/2008/mfsa2008-44.html
[13:44] <white> ah damn
[13:44] <asac> above the CVE links
[13:44] <asac> its just a "multi" bug CVE
[13:44] <white> nevermind :)
[13:45] <asac> white: if you cannot see any of those then its embargoed and i would have to CC you
[13:45] <asac> but all seem to be opened up
[13:45] <white> i'm just checking whether they are fixed or not
[13:45] <asac> white: yeah ... look in patches/series
[13:46] <asac> if they are not in there look in bug ... as if they dont apply i usually comment on that in the bug
[13:46] <white> asac: only one of the bugnnumbers is mentioned there
[13:46] <asac> white: yeah. look at the bugs in bugzilla ... the one bug has all the patches
[13:46] <white> ah ok
[13:46] <asac> the other is just testcase/documentation bugs
[13:47] <asac> its frequent that there are a bunch of bugs (even with patches) and then one wrap up bug which contains the accumulated branch patches
[13:47] <asac> (sorry, to throw all this at you ... its quite a lot of implicit knowledge there ... feel free to ask if you are uncertain :))
[13:49] <white> no problem, i might have to do something else for a while now, but will try to send the advisory draft to you tonight and test the packages
[13:50] <asac> white: sure
[13:50] <asac> thanks so much
[14:13] <white> asac: do you know where the "compare" target comes from? icedove-3.0 fails to build for me, because the rule doesn't exist
[14:13] <white> i am curious what it does or did
[14:17] <asac> white: mozilla-devscripts
[14:17] <asac> white: which version are you using?
[14:19] <white> 0.12
[14:19] <white> can i live without the target?
[14:20] <asac> white: is there no /usr/share/mozilla-devscripts/compare.mk ?
[14:20] <white> yes there is
[14:21] <white> maybe it's not included for some reason
[14:21] <white> nah it's not included
[14:21] <white> -include /usr/share/mozilla-devscripts/$(DEB_MOZ_APPLICATION).mk
[14:21] <white> my DEB_MOZ_APPLICATION is icedove-3.0
[14:22] <asac> bummer
[14:22] <asac> white: you probably know how to fix that ;)
[14:22] <asac> we should talk with fta bout that
[14:22] <white> asac: i just wanted to remark it :)
[14:23] <asac> valid
[14:24] <asac> i think debhelper should get the ability to use debian/control.SOURCEPACKAGE name in preference to debian/control
[14:24] <asac> in that way we could more easily maintain both in one tree
[14:24] <asac> assuming that i hate templates for control ;)
[14:39] <asac> white: i think i refer to the patchset in changelog usually ... the one used for this is: http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/moz_1.8.0.15prepatches080614i.tar.gz
[14:40] <asac> maybe also give the tarball location
[14:49] <asac> white: now i remember why iceape is soooo outdated in etch. its glandium kept calendar, so one cannot even use the upstream tarball directly
[14:49] <asac> damn
[14:49] <asac> thats really bad
[14:59] <white> asac: you have mail
[14:59] <white> i'll be relocating home soon, later i'll produce a nice changelog entry, rebuild and start testing
[14:59] <white> please check the draft i sent to you :)
[15:01] <asac> white: thanks. try to keep the current changelog form if possible ;)
[15:03] <white> asac: ignore the formatting issues in the draft, i'll fix them up later, just tell me, if you are satisfied with the rest :)
[15:07] <asac> white: s/Iceweasel/Icedove/
[15:08] <asac> white: did you do the CVE list like i said?
[15:08] <asac> or are you also naming stuff that is fixed in sid?
[15:08] <white> asac: i went through the list from http://security-tracker.debian.net/tracker/status/release/stable
[15:09] <white> asac: and i added the MFSAs
[15:09] <asac> (not all apply in both places)
[15:09] <white> asac: well they should apply for etch and all are fixed in sid (it doesn't matter, if some were fixed earlier)
[15:10] <white> or am i missing something?
[15:11] <asac> white: have oyu checked whether those CVEs have been named in the changelog before?
[15:11] <asac> i think most of them are already mentioned
[15:11] <asac> so they are not fixed in this upload, but in the ones before
[15:12] <asac> hmm
[15:12] <asac> ok
[15:13] <asac> so 2.0.0.17 never made it to security hmm
[15:13] <asac> i was quite sure i uploaded that
[15:13] <asac> but well ... maybe i just did xulrunner considering hits higher impact
[15:14] <asac> hmm
[15:15] <asac> i think there is one MFSA missing
[15:16] <asac> white:     * MFSA 2008-59 aka CVE-2008-4582 - Script access to .documentURI and
[15:16] <asac>       .textContent in mail
[15:17] <asac> that one is also fixed everywhere else ... (its probably not in the tracker because the upstream MFSA doesnt provide the CVE)
[15:17] <asac> well ... everywhere where the 1.8.1.18 backports have been released to
[15:29] <white> asac: have to relocate now, will answer later
[16:48] <white> asac: does CVE-2008-4582 affect icedove? I though it's only for the browsers
[16:48] <white> asac: apart from that one, any other points?
[16:48] <white> i'll write the changelog now
[17:02] <asac> white: is the patch in there?
[17:02] <asac> white: it doesnt apply to 1.8.0 branches
[17:02] <asac> https://bugzilla.mozilla.org/show_bug.cgi?id=455311#c78
[17:03] <asac> but maybe i took https://bugzilla.mozilla.org/show_bug.cgi?id=455311#c80 anyway
[17:03] <asac> in case some embedders use .desktop files
[17:11] <white> hold on, i am just finishing the changelog
[17:16] <asac> yeah
[17:16] <asac> i am still here ;)
[17:17] <asac> iceape killed me again ... calendar/ has binary files, so no luck with diff ;)
[17:17] <asac> so now uue tarball ;)
[17:18] <white> asac: does that look ok to you? http://paste.debian.net/25288/
[17:18] <white> asac: i am a bit unsure about http://www.mozilla.org/security/announce/2008/mfsa2008-61.html aka CVE-2008-5503
[17:18] <white> i'll check whether there is a patch in the tarball
[17:19] <asac> white: please point to the tarball/patchset download source
[17:19] <asac> i think i did that in previous uploads?
[17:19] <asac> like:
[17:19] <asac> * backports for thunderbird 2.0.0.17 stability/security update
[17:20] <asac> i have in dapper:
[17:20] <asac>   * RELEASE security/stability backports for tbird 1.5 as of 2.0.0.19
[17:20] <asac>     (USN-701-2)
[17:20] <asac>     - http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/moz_1.8.0.15prepatches080614i.tar.gz
[17:20] <asac> white: btw, the upload we are looking at is 2.0.0.17 + 18 + 19
[17:21] <asac> also mention the tarball maybe: http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/icedove-1.5.0.13+1.5.0.15b+prepatch080614i.tar.bz2
[17:21] <white> it's quite a nice number of issues :)
[17:21] <white> ok, step by step
[17:21] <asac> white: look at the patches/series file ;)
[17:21] <white> so i have the *backports ... lines
[17:21] <asac> those are all issues we backported since 1.5 went eol
[17:21] <asac> those commented out are alreawdy committed
[17:23] <white> asac: then you want me to add three tarball lines pointing to patchsets?
[17:24] <asac> white: no ... just to the .19 patchset + tar.bz2
[17:24] <asac> they contain the rest
[17:26] <white> can you quickly post the URLs plz?
[17:33] <asac> patchset: calendar-1.0.9.tar.bz2.uue
[17:33] <asac> tarball: http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/icedove-1.5.0.13+1.5.0.15b+prepatch080614i.tar.bz2
[17:33] <asac> patchset: http://people.ubuntu.com/~asac/mozilla-security/1.8.1.19/moz_1.8.0.15prepatches080614i.tar.gz
[17:36] <white> asac: what's calendar-1.0.9.tar.bz2.uue
[17:38] <asac> white: thats a paste error ;)
[17:38] <white> :)
[17:38] <asac> i am trying to push calendar parts to iceape diff.gz
[17:38] <asac> so we can use tarballs again
[17:38] <white> ok anything else or can i start a nice build in cowbuilder?
[17:38] <asac> mike apparently shuffled the upstream tarballs without a repro instruction ;)
[17:39] <asac> white: yes, why do you say "non-maintainer upload"?
[17:39] <asac> imo its not really unusual that security team does security uploads for packages they dont maintain ;)
[17:39] <white> asac: common practise by most sec members
[17:40] <white> asac: i don't really maintain many packages anymore and do more uploads of packages i don't maintain ;)
[17:40] <asac> yeah ... but isnt really informative ;)
[17:40] <asac> why would anybody want to know that its a NMU?
[17:40] <white> it informs that it is a sec upload
[17:40] <asac> if that info is good to have it shouldnt have the "top" place ;)
[17:40] <white> and performed by someone from the sec team (although that doesn't mean much)
[17:40] <asac> white: thats already said by the other line
[17:41] <white> since it's common practise I'd prefer to keep it
[17:41] <asac> i dont mind ,)
[17:41] <white> :)
[17:42] <asac> oh
[17:42] <asac> #
[17:42] <asac> * MFSA 2008-67 aka CVE-2008-5510 - Escaped null characters ignored by CSS
[17:42] <asac> #
[17:42] <asac> i think thats the one that isnt fixed
[17:42] <white> hmm, it was marked as fixed in - icedove 2.0.0.19-1
[17:42] <asac> yeah
[17:42] <white> in our tracker, which doesn't have to mean anything :)
[17:42] <asac> its low severity and patch was too intrusive to take in this round
[17:43] <white> ok, i'll take it out then
[17:43] <asac> white: its fixed in 1.8 (e.g. 2) but not in 1.8.0
[17:43] <asac> so not in the upload you are preparing right now
[17:45] <white> i've added CVE-2008-5503 to the changelog and advisory, allthough it's pretty low severity IMHO
[17:45] <asac> white: also CVE-2008-5502 doesnt affect 1.8.0 branch
[17:46] <asac> just 5501 (layout)
[17:46] <white> so it was fixed already in etch?
[17:46] <asac> white: no it doesnt apply ;)
[17:47] <white> in the tracker it reads - icedove 2.0.0.16-1
[17:47] <white> as fixed version
[17:47] <asac> huh?
[17:48] <asac> white: CVE-2008-5502 is 1.9 branch only ... so its not fixed in any 2.
[17:48] <asac> because its not an issue there
[17:48] <asac> same for 5501
[17:49] <asac> http://www.mozilla.org/security/announce/2008/mfsa2008-60.html
[17:49] <asac> look there
[17:49] <asac> it says "Firefox 3" only
[17:49] <asac> which means its 1.9 branch only
[17:50] <white> ok, so i'll just mark it as not-affecting the debian versions and take it out of the changelog
[17:50] <asac> yeah ... but 5500 applies ;)
[17:50] <asac> (so the MFSA is valid)
[17:50] <white> got ya :)
[17:51] <asac> 18:45 < white> i've added CVE-2008-5503 to the changelog and advisory, allthough it's pretty low severity IMHO
[17:51] <asac> why wasnt that in there in the first place?
[17:51] <asac> did i forget that in sid?
[17:54] <asac> white: i think you also forgot http://www.mozilla.org/security/announce/2008/mfsa2008-46.html ... 2.0.0.17
[17:55] <asac> white: you also forgot https://bugzilla.mozilla.org/show_bug.cgi?id=458883
[17:55] <white> hmm i got it in the advisory, but not in the changelog :/
[17:55] <asac> i already said all this above :/
[17:55] <asac> anyway ... let me look further ;)
[17:55] <white> i need to compare the advisory with the changelog :/
[17:56] <asac> white: no ... dont start with CVEs
[17:56] <asac> start with MFSAs ;)
[17:56] <asac> then go through the list
[17:56] <asac> thats better ;)
[17:56] <asac> i swear
[17:57] <asac> laste was http://www.mozilla.org/security/announce/2008/mfsa2008-59.html
[17:57] <asac> thats what you forgot too
[17:57] <asac> ;)
[17:57] <asac> (not the bug)
[17:58] <asac> also missing http://www.mozilla.org/security/announce/2008/mfsa2008-61.html
[17:58] <asac> (i think you added that you said)
[17:58] <asac> yeah that should be it
[17:58] <asac> thanks
[17:59] <asac> so missing in changelog (from your paste):
[17:59] <asac> http://www.mozilla.org/security/announce/2008/mfsa2008-46.html
[17:59] <white> MFSA 2008-59 doesn't even have a CVE id?
[17:59] <asac> http://www.mozilla.org/security/announce/2008/mfsa2008-59.html
[17:59] <asac> http://www.mozilla.org/security/announce/2008/mfsa2008-61.html
[17:59] <asac> 16:16 < asac> white:     * MFSA 2008-59 aka CVE-2008-4582 - Script access to .documentURI and
[17:59] <white> ah right
[17:59] <asac> you should add that everywhere
[18:00] <asac> its affecting all 1.8 branch products
[18:00] <asac> e.g. everything except xulrunner/iceweasel in lenny
[18:00] <asac> ok cool
[18:00] <asac> that should be it ;)
[18:00] <asac> thanks a bunch
[18:01] <asac> i am still fighting iceape a bit ;)
[18:01] <asac> maybe i will have something later
[18:01] <white> after the whole ice* round is over (or icedove at least), i need to fix some other stuff, like some simple integer overflow or some XSS
[18:01] <white> something small, easy and successfull ;0
[18:02] <asac> hehe
[18:02] <asac> well its a huge success if you manage to get icedove out ;)
[18:04] <asac> and also first time is always hardest ;)
[18:05] <white> building now
[18:13] <white> i have to ask again regarding CVE-2008-4582
[18:14] <white> it seems to point to http://www.mozilla.org/security/announce/2008/mfsa2008-47.html
[18:21] <white> ah CVE-2008-5024
[18:21] <white> nevermind :)
[18:35] <asac> white: hmmm indeed strange
[18:35] <asac> not sure whats that about
[18:36] <asac> thats the CVE for 59 that went over the ticker
[18:36] <asac> let me double check
[18:56] <fta> hi
[19:00] <IRCMonkey> heh
[19:00] <IRCMonkey> iceape-chatzilla to houston ;)
[19:00] <IRCMonkey> fun
[19:02]  * IRCMonkey off
[19:07] <white> asac fta: i got an icedove version build now. I'll add a small patch to remove some branding. I've called the version 3.0~b1-1.1 and the packages icedove-3.0 as you requested
[19:07] <white> asac fta: Noel wanted to know, whether we could put that to experimental with your permission?
[19:07] <white> i think he emailed asac
[19:16] <white> asac: i guess i'll give the package to noel and leave it to him :)
[19:17] <asac> you dont need permission
[19:17] <asac> just keep th eubuntu mozillateam in Maintainer field ;)
[19:17] <asac> and give the code back you did to us ;)
[19:18] <asac> white: ^^
[19:18] <asac> feel free to add all of you to Uploaders
[19:18] <white> is Mike ok with that as well or isn't he maintaining icedove?
[19:19] <asac> he isnt
[19:19] <asac> i already moved Maintainer: to ubuntu team
[19:19] <asac> it was myself before for ages
[19:19] <asac> like you can see in the etch package ;)
[19:19] <white> ok, i just wanted to make sure everything is sound :)
[19:20] <white> so should i just commit my icedove-3.0 branch to bazaar?
[19:20] <BUGabundo> asac: do you have any news from fta about FF3.1 not starting with xmlruner?
[19:20] <asac> white: if you have a branch then yes
[19:20] <white> asac: don't i need some special foo powers?
[19:20] <asac> BUGabundo: no
[19:20] <BUGabundo> bah
[19:21] <BUGabundo> can't open it for 2 weeks!
[19:21] <fta> hm
[19:21] <fta> i need context
[19:21] <asac> white: push that to your own area for now ... i will shove it over. we can add you to team on next meeting ... which is in 10 days or so ;)
[19:21] <BUGabundo> need to downgrad again
[19:21] <BUGabundo> fta don't you remember me telling you that that it segfault?
[19:21] <BUGabundo> when I had both 3.0 and 3.1 PPA ?
[19:21] <fta> oh, 2 != versions at the same time
[19:21] <BUGabundo> found that it was related to the PPA version of xlrunner
[19:22] <BUGabundo> 1.9.1 or something
[19:22] <fta> well, i wanted to find the root cause last week but got busy with something else
[19:22] <BUGabundo> $ firefox-3.1 Could not find compatible GRE between version 1.9.1b3pre and 1.9.1b3pre.
[19:22] <fta> this is different
[19:22] <fta> please, show me your /etc/gre.d
[19:22] <BUGabundo> from POV it's the same!
[19:22] <BUGabundo> lol
[19:23] <BUGabundo> 1.9.0.4.system.conf
[19:23] <BUGabundo> 1.9.0.5.system.conf
[19:23] <BUGabundo> 1.9.2a1pre.system.conf
[19:24] <fta> you don't have xulrunner-1.9.1 installed ?
[19:24] <BUGabundo> I think I have
[19:24] <fta> apparently not
[19:24] <BUGabundo> xulrunner-1.9.1:
[19:24] <BUGabundo>   Installed: 1.9.1~b3~hg20090103r22626+nobinonly-0ubuntu1~fta3
[19:24] <BUGabundo>   Candidate: 1.9.1~b3~hg20090103r22626+nobinonly-0ubuntu1~fta3
[19:24] <BUGabundo>   Version table:
[19:24] <BUGabundo>  *** 1.9.1~b3~hg20090103r22626+nobinonly-0ubuntu1~fta3 0
[19:24] <BUGabundo>         500 http://ppa.launchpad.net jaunty/main Packages
[19:24] <BUGabundo>         100 /var/lib/dpkg/status
[19:24] <BUGabundo>      1.9.1~b2+build1+nobinonly-0ubuntu3 0
[19:24] <BUGabundo>         500 ftp://darkstar.ist.utl.pt jaunty/universe Packages
[19:24] <BUGabundo>         500 ftp://archive.ubuntu.com jaunty/universe Packages
[19:24] <BUGabundo> I seems I do have it!
[19:24] <BUGabundo> your PPA version
[19:25] <fta> you should have a /etc/gre.d/1.9.1b3pre.system.conf file then
[19:25] <fta> strange
[19:25] <BUGabundo> yeah
[19:25] <asac> fta: yes. i think there is a bug in migration
[19:25] <BUGabundo> --reinstall ?
[19:25] <asac> fta: i had some more complains that the gre file was gone
[19:25] <asac> BUGabundo: give it a try
[19:25] <asac> BUGabundo: --reinstalll xulrunner-1.9
[19:25] <asac> (not ffox)
[19:25] <BUGabundo> thanks
[19:26] <BUGabundo> I know ... just looking for the correct package
[19:26] <fta> dpkg-query -W -f='${Conffiles}' xulrunner-1.9.1 | grep gre.d
[19:26] <BUGabundo> bah... one 'l' too many
[19:26] <BUGabundo> /etc/gre.d/1.9.1b3pre.system.conf 9284295b58639184f779e138babb9ee3
[19:27] <BUGabundo> do you want the md5sums too?
[19:27] <BUGabundo> FYI I did change gconf to use the latest cul
[19:27] <fta> is that before or after --reinstall
[19:27] <BUGabundo> *xul
[19:27] <fta> ?
[19:27] <BUGabundo> before
[19:27] <BUGabundo> reinstall running now
[19:27] <BUGabundo> If you wish to add some of these files, please add them by name.
[19:27] <BUGabundo> Committing to: /etc/
[19:27] <BUGabundo> modified alternatives/xulrunner
[19:27] <BUGabundo> missing gre.d/1.9.0.4.system.conf
[19:27] <BUGabundo> deleted gre.d/1.9.0.4.system.conf
[19:28] <BUGabundo> LOL
[19:28] <fta> wooww
[19:28] <asac> fta: i think it happens when you install 1.9.1 for first time. at lesat the complains couldnt reproduce, after they fixed it
[19:28] <BUGabundo> something changed according to my bzr backup of /etc
[19:29] <BUGabundo> $ firefox-3.1 Could not find compatible GRE between version 1.9.1b3pre and 1.9.1b3pre.
[19:29] <asac> fta: dont you use rm_conffile?
[19:29] <fta> no
[19:29] <asac> why not?
[19:29] <BUGabundo> /etc/gre.d/1.9.1b3pre.system.conf 9284295b58639184f779e138babb9ee3
[19:29] <BUGabundo> after reinstall
[19:29] <fta> well, yes
[19:29] <asac> thats actually quite important ;)
[19:29] <asac> ah ok
[19:29] <BUGabundo> look the same to me
[19:30] <asac> BUGabundo: md5sum /etc/gre.d/1.9.1b3pre.system.conf gives you?
[19:30] <fta> asac, http://paste.ubuntu.com/100515/
[19:30] <asac> fta: in preinst?
[19:30] <BUGabundo> $ md5sum /etc/gre.d/1.9.1b3pre.system.conf
[19:30] <BUGabundo> md5sum: /etc/gre.d/1.9.1b3pre.system.conf: No such file or directory
[19:30] <fta> asac, yes
[19:31] <BUGabundo> 1.9.0.5.system.conf
[19:31] <BUGabundo> 1.9.2a1pre.system.conf
[19:31] <asac> fta: maybe in preinst everything is obsolete or something ... hmm
[19:32] <asac> fta: @XULBRANCH@? who cares about 1.9.0? is that supposed to be done by 1.9.0?
[19:33] <fta> asac, what i experienced a few times is that when you upgrade for v1 to v2, the gre-v1.conf file is not removed, if you upgrade again (ie v2 to v3 or v2 to another v2), it v1 is removed
[19:33] <fta> -for+from
[19:33] <asac> well ... in this case the new config is removed right?
[19:33] <asac> maybe we should take care that we dont remove stuff from the same gre version
[19:33] <fta> it seems so but i never experienced that
[19:33] <fta> i'll have a closer look after diner
[19:34] <asac> conffiles are a real pita
[19:34] <BUGabundo> so now good news for me?»
[19:34] <asac> sometimes they are not replaced with new files even though they were never touched :(
[19:34] <asac> BUGabundo: so did you reinstall?
[19:34] <BUGabundo> yep
[19:34] <asac> which package verison of xulrunner was installed?
[19:34]  * fta blames dpkg
[19:35] <BUGabundo> Removing obsolete conffile /etc/gre.d/1.9.0.4.system.conf ...
[19:35] <BUGabundo> Unpacking replacement xulrunner-1.9 ...
[19:35] <BUGabundo> Setting up xulrunner-1.9 (1.9.0.5+nobinonly-0ubuntu1) ...
[19:35] <BUGabundo> I have from 1.9.0,1.9.1 and 1.9.2
[19:35] <fta> apt-cache madison xulrunner-1.9 xulrunner-1.9.1 xulrunner-1.9.2 | grep -v Source
[19:36] <BUGabundo> xulrunner-1.9 | 1.9.0.5+nobinonly-0ubuntu1 | ftp://darkstar.ist.utl.pt jaunty/main Packages
[19:36] <BUGabundo> xulrunner-1.9 | 1.9.0.5+nobinonly-0ubuntu1 | ftp://archive.ubuntu.com jaunty/main Packages
[19:36] <BUGabundo> xulrunner-1.9.1 | 1.9.1~b3~hg20090103r22626+nobinonly-0ubuntu1~fta3 | http://ppa.launchpad.net jaunty/main Packages
[19:36] <BUGabundo> xulrunner-1.9.1 | 1.9.1~b2+build1+nobinonly-0ubuntu3 | ftp://darkstar.ist.utl.pt jaunty/universe Packages
[19:36] <BUGabundo> xulrunner-1.9.1 | 1.9.1~b2+build1+nobinonly-0ubuntu3 | ftp://archive.ubuntu.com jaunty/universe Packages
[19:36] <BUGabundo> xulrunner-1.9.2 | 1.9.2~a1~hg20090102r23257+nobinonly-0ubuntu1~fta2 | http://ppa.launchpad.net jaunty/main Packages
[19:36] <fta> ok
[19:36] <fta> bug in my preinst then
[19:36]  * BUGabundo blames stable,beta & alpha all together!
[19:37] <fta> but this is different from running != versions at the same time
 missing gre.d/1.9.0.4.system.conf
 deleted gre.d/1.9.0.4.system.conf
[19:37] <fta> when did that happen?
[19:37] <BUGabundo> after the reinstall
[19:38] <BUGabundo> its the bzr log
[19:38] <BUGabundo> that is attached to apt
[19:38] <BUGabundo> humm how is it called!!?
[19:38] <BUGabundo> etckeeper
[19:39] <fta> could you please pastebin me your traces (apt)
[19:39] <BUGabundo> full command please!
[19:39] <BUGabundo> of the reinstall?
[19:40] <BUGabundo> http://paste.ubuntu.com/100527/
[19:40] <fta> maybe from /var/log/apt/term.log if your xul upgrades are in there
[19:42] <BUGabundo> http://paste.ubuntu.com/100528/
[19:42] <fta> http://paste.ubuntu.com/100527/ <= this is correct, 1.9.0.5 removes the old 1.9.0.4 gre file, but it happened at reinstall not when 1.9.0.5 was first installed, so this is sub-optimal
[19:43] <fta> asac, do you have a bug # on lp for this bug?
[19:45] <fta> BUGabundo, what happens when you --reinstall 1.9.1 ?
[19:45] <BUGabundo> again??
[19:45] <BUGabundo> lol
[19:45] <BUGabundo> have a look at the log above fta
[19:45] <fta> hmm, you pasted 1.9 several times
[19:46] <fta> did i mis-read?
[19:46] <BUGabundo> don't know!
[19:46] <BUGabundo> but I can always redo it to be sure
[19:46] <BUGabundo> so its 1.9.1 correct?
[19:46] <fta> hold on, reading your long log file
[19:47] <fta> Preparing to replace xulrunner-1.9.1 1.9.1~b2+build1+nobinonly-0ubuntu3 (using .../xulrunner-1.9.1_1.9.1~b3~hg20081227r22500+nobinonly-0ubuntu1~fta1_amd64.deb) ...
[19:47] <fta> Removing obsolete conffile /etc/gre.d/1.9.1b3pre.system.conf ...
[19:47] <fta> Unpacking replacement xulrunner-1.9.1 ...
[19:47] <fta> not good
[19:47] <BUGabundo> fta tail it!! last lines all you need
[19:48] <BUGabundo> yeah so now I have no 1.9.1 on gre.d
[19:48] <fta> nope, i need history, the cause is just this
[19:48] <BUGabundo> humm
[19:48] <BUGabundo> I did downgrade from FF3.1b3 PPA to 3.1 archive
[19:48] <BUGabundo> and xul too!
[19:48] <fta> if the clean-up happens one step too late and you keep reverting to b2, bingo, you loose your gre file
[19:49] <BUGabundo> but I enable it again to check if you fixed it and got into this
[19:51] <fta> what i already know: b2-1 -> b2-2 -> b2-3 -> b3-1 (nada, while gre/b2 should be removed) -> b3-2 (gre/b2 removed, all fine) -> b3-3 ...
[19:52] <fta> you seems to be doing: b2-3 -> b3-1 -> b2-3 -> b3-2 -> b2-3 -> b3-3 (no b3 gre file??)
[19:53] <fta> is that correct?
[19:53]  * BUGabundo is confused (and hungry)
[19:53] <fta> don't :)
[19:53] <fta> i'm trying to understand your upgrade path
[19:53] <BUGabundo> humm
[19:54] <BUGabundo> ok... ibex -> jaunty pre-alpha1, with PPA always enabled AFAIR
[19:54] <fta> (bear with me..)
[19:54] <BUGabundo> last week FF3.1 started segfaulting
[19:54] <BUGabundo> so I posted it here
[19:54] <BUGabundo> installed 3.2 and it also failed
[19:54] <BUGabundo> when FF3.0 was opened
[19:55] <BUGabundo> removed PPA and downgrade just FF3.1 to archive
[19:55] <BUGabundo> no go, so I donwgraded xul too!
[19:55] <BUGabundo> it worked ! enabled PPA again and got here today to ask what's up!
[19:56] <fta> you're mixing 2 issues: a/ gre file disappearing & causing ff-x to fail on startup and b/ concurrent versions no longer running but showing a segfault and opening a window from the other version
[19:57] <fta> for b/ i know what is causing that, i could revert my changes but i would prefer fix the bug (needs work)
[19:57] <BUGabundo> ok
[19:57] <BUGabundo> about a/?
[19:58] <fta> for a/ it seems to be caused by my preinstall script but it still not clear to me how you could end up there. yet, i see did it.
[19:58] <fta> and asac said some other guys filed bugs about that very same thing
[19:59] <BUGabundo> asac: any luck getting the ML moderate pass? mail still in queue
[19:59] <BUGabundo> fta: should I remove it all
[19:59] <BUGabundo> with purge?
[19:59] <BUGabundo> and start again?
[19:59] <fta> to fix a/ i need to understand the situation, i'll study your logs after dinner, this bug is more critical than b/
[20:00] <BUGabundo> thanks
[20:00] <BUGabundo> Dinner time
[20:00] <BUGabundo> brbr
[20:00] <fta> to work-around a/, you can just re-create that file manually, it's easy.
[20:01] <BUGabundo> send me yours
[20:01] <BUGabundo> LOL
[20:01] <fta> fta@ix:~ $ cat /etc/gre.d/1.9.1b3pre.system.conf
[20:01] <fta> [1.9.1b3pre]
[20:01] <fta> GRE_PATH=/usr/lib/xulrunner-1.9.1b3pre
[20:01] <fta> xulrunner=true
[20:01] <fta> abi=x86-gcc3
[20:03] <fta> if you are on amd64, the last line is "abi=x86_64-gcc3"
[20:03] <BUGabundo> I am
[20:03] <BUGabundo> I'll create it after dinner
[20:03] <BUGabundo> [[]]
[20:04] <fta> ok, cu then
[20:09] <directhex> i hate that
[20:09] <directhex> that's cocked me up before when buiding .xpi files
[20:30] <asac> BUGabundo: we have to wait for gnomefreak ;)
[20:30] <asac> directhex: ?
[20:31] <directhex> asac, ABI stuff being read from the running cpu when compilling plugins, not the compiler arch
[20:31] <asac> white: CVE-2008-4066
[20:31] <asac> i think thats not fixed in our 1.8.0 branches
[20:31] <asac> can you note that in tracker so i get to it? (its http://www.mozilla.org/security/announce/2008/mfsa2008-43.html part 2 ... if you could add that as comment)
[20:32] <asac> directhex: ah ok. can be itchy ;) ... i think BUGabundo didnt have any line though ;)
[20:39] <white> asac: taken out of the advisory and the changelog
[20:39] <fta> BUGabundo, sudo zgrep -hE '(xulrunner-1.9.1 |gre.d/1.9.1)' /var/log/apt/term.log.{2,1}.gz /var/log/apt/term.log | grep -vE '^(Setting up|Unpacking)'
[20:39] <white> asac: it's fixed in sid though right?
[20:48] <asac> white: not sure right now
[20:48] <asac> white: sory for confusion. seems i messed up my own iceape tarball by using the wrong patchset version ;) so not all was in there
[20:48] <asac> let me check
[20:49] <asac> white: ok what i said was correct. its missing ... its in 2 though
[20:55] <white> asac: new icedove package seems to work, at least i can reach my pop/imap accounts and use smtp on my relay host :)
[20:57] <white> asac: CVE-2008-4066: - icedove 2.0.0.17-1 (that is the fixed icedove entry)
[21:25] <asac> white: http://paste.ubuntu.com/100583/ ;)
[21:25] <asac> white: you know whether i need to build depend on sharutils and bzip2?
[21:27] <fta> woww, that's a lot of MFSAs
[21:27] <asac> that was even more work
[21:27] <asac> i went through all MFSAs and checked that we have it
[21:27] <asac> i found three bugs that i somehow dont have in the patchsets
[21:28] <asac> have to investigate now and patch them next time if it turns out to be forgotten
[21:28] <asac> most likely i just forgot to document in bug why i didnt take it though
[21:28] <white> asac: nice work
[21:28] <white> asac: but back to icedove, one step at a time ;)
[21:29] <white> asac: CVE-2008-4066: - icedove 2.0.0.17-1
[21:29] <white> is that still correct?
[21:29] <white> icedove etch packages seem to work by the way as already said :)
[21:30] <asac> white: good. you hav a mfsa for that?=
[21:30] <white> 21:31 < asac> can you note that in tracker so i get to it? (its http://www.mozilla.org/security/announce/2008/mfsa2008-43.html part 2 ... if you could add that as comment)
[21:30] <asac> yes
[21:30] <asac> thats fixed in 2.0.0.17
[21:30] <white> asac: i was wondering, if it is fixed in sid and if so, which version it was fixed :)
[21:30] <white> ah great :)
[21:30] <asac> ts just that the second part is not in 1.8.0
[21:31] <white> so is the CVE fixed in sid? (like the second part)
[21:31] <asac> white: for upstream tarballs you can check whether bugs are fixed by going to the bug and look for the fixed1.8.1.17 (for 2.0.0.17) ;)
[21:31] <white> sorry, but i need to get through the CVEs :)
[21:31] <asac> or verified1.8.1.17
[21:31] <asac> which is even saying that QA has verified that its fixed
[21:32] <asac> white: for outstanding CVEs we discuss at best add the MFSA ;)
[21:32] <asac> so we dont need to hunt it down ;)
[21:32] <white> i'll try my best :)
[21:32] <asac> sure
[21:32] <asac> if not ... we wil survive it ;)
[21:32] <asac> though scratching heads again
[21:32] <fta> did you guys use m-d ?
[21:32] <white> :)
[21:33] <asac> fta: for what?
[21:33] <asac> fta: for patchset management?
[21:33] <asac> i think thats a missing feature as of now ;)
[21:33] <white> asac: ok, at the moment, the etch packages are rebuilding without the CVE id in it
[21:33] <fta> explain
[21:33] <white> asac: but with the MFSA included
[21:33] <asac> would be cool if i could tell it: also add patchset "url-to-patches/tarball" and "url-to-patches/tarball2"
[21:33] <white> asac: were there any other objections?
[21:33] <asac> and apply ;)
[21:34] <asac> white: post the changelog again ;) ... my brain is out of sync again ;)
[21:34] <white> sure
[21:35] <white> asac: http://paste.debian.net/25323/
[21:36]  * asac just noticed that he is using ffox 1.5 for the last 5 hours ;)
[21:36] <asac> thought it was broken ;) ... but now i see
[21:37] <white> asac: should i resend the advisory draft as well?
[21:37] <white> ill just do it anyway :)
[21:37] <asac> * MFSA 2008-37 aka CVE-2008-0016 -  UTF-8 URL stack buffer overflow
[21:37] <asac> there are two whitespaces
[21:37] <asac> 16 -  UTF-8 URL
[21:37] <asac>   ^^
[21:38] <white> :)
[21:39] <asac> white: maybe use the same i used for -41
[21:39] <fta> [11:47] <asac> white: take a look at the latest tbird 3 packaging branch ... i think fta moved logic from m-devscripts to the packages ... maybe thats the reason
[21:39] <asac> http://paste.ubuntu.com/100583/
[21:39] <fta> i'm not done with that yet
[21:39] <asac> fta: ah
[21:39] <asac> ok
[21:39] <fta> jsut a few packages moved
[21:39] <asac> was just a blind guess
[21:39] <asac> we found it actually
[21:39] <asac> its DEB_MOZ_APPLICATION=icedove-3.0
[21:39] <asac> which kills the thing
[21:39] <asac> fta: ^^
[21:40] <fta> ?
[21:40] <asac> probably icedove-3.0 needs to ship a debian/icedove-3.0.mk and include the thunderbirc-3.0.mk?
[21:40] <asac> fta: compare isnt included
[21:40] <asac> because $(DEB_MOZ_APPLICATION).mk doesnt exist
[21:41] <fta> compare is included in $(project).mk usually, but could be included directly
[21:41] <white> doesn't matter much for as long as mozilla-devscripts isn't uploaded to debian :)
[21:41] <fta> but then you need to add your own filters
[21:41] <asac> white: please take my text for -41, -42 (http://paste.ubuntu.com/100583/)
[21:42] <white> asac: you mean http://paste.debian.net/25324/ ?
[21:43] <asac> yes
[21:43] <asac> white:  * MFSA 2008-45 aka CVE-2008-4069 - [1.8 branch] XBM appears to draw
[21:43] <white> ok
[21:43] <asac>     uninitialized memory
[21:43] <asac> is that not tbird?
[21:43] <asac> seems like
[21:43] <asac> ok
[21:45] <asac> white: same for the other multi advisories: -52, -60 -68
[21:46] <asac> i'd say that http://www.mozilla.org/security/announce/2008/mfsa2008-54.html is also in thunderbird
[21:46] <asac> tbird does http stuff
[21:47] <asac> e.g. rss feed and so on
[21:47] <asac> but well
[21:47] <asac> its ok to not name it
[21:47] <asac> or name it ;)
[21:47] <white> asac: so i guess there are two or three minor issues we don't have in the current round
[21:47] <white> but all major ones should be there
[21:48] <white> so we could build the final version now :)
[21:48] <asac> nice ... i forgot -59 in iceape ;)
[21:49] <white> asac: should i restart the build for icedove now? :)
[21:49] <asac> white: yes if you changed the other multi things.
[21:49] <asac> in changelog ... go ahead
[21:50] <asac> if you have the builds staged somewhere i can also take a look and test
[21:50] <white> asac: i am building them on a sec host, but can make them available after build
[22:03] <white> asac fta: I have added a bzr branch to https://code.launchpad.net/~steffen-joeris/+junk/icedove-3.0, which appears to build here. There are some concerning warnings, but it starts and seems to run
[22:04] <white> asac fta: i've packed the -source.tar.bz2 into a icedove-3.0_3.0~b1.orig.tar.gz locally (wasn't sure how you wanted it in bzr, if at all)
[22:05] <white> hope it helps somehow
[22:05] <asac> white: why junk?
[22:05] <asac> you can use the "thunderbird" project
[22:06] <asac> but doesnt matter
[22:06] <asac> i can take a look at it as its now
[22:06] <white> asac: well, you said somewhere on launchpad ;)
[22:06] <asac> hehe ;)
[22:06] <asac> white: oh
[22:06] <asac> white: you have to start with the thunderbird branch
[22:06] <asac> and then do the changes on top
[22:06] <asac> otherwise you cannot merge in future
[22:07] <asac> and dont add the tar ;)
[22:07] <asac> just debian/ in bzr
[22:07] <white> asac: well i obviously had to rename all the stuff in /debian
[22:07] <asac> white: thats ok
[22:07] <asac> you can use bzr mv
[22:07] <asac> to rename files
[22:07] <asac> we do most things in debian/rules anyway
[22:08] <asac> so conflicts should be more or less bearable in future ;)
[22:08] <asac> fta: what do you think?
[22:08] <white> the tarball was kind of important for me as i couldn't get a complete tarball out of mozilla-devscripts :/
[22:09] <asac> white: yes. but not in the bzr branch ;)
[22:09] <white> asac: either way, I'll send Noel a mail with some information and a remark to contact you for further cooperation, if he continues to work on it :)
[22:09] <asac> yep
[22:10] <fta> asac, sure. i do that quite a lot with all the xul 1.9/1.9.1/1.9.2 branches. bzr mv once then bzr merge
[22:11] <asac> fta: yeah. but i mean the filenames in .install will have a different path ... so conflicts will happen for sure
[22:11] <asac> debhelper needs more features ;)
[22:11] <asac> (again)
[22:11] <fta> bzr seems to remember the mv
[22:11] <asac> yes the mv is no problem
[22:11] <asac> but you s/thunderbird/icedove/ in files
[22:11] <asac> and then next time you touch them in tbird they conflict (rightfully)
[22:12] <fta> yep, some conflicts are expected but it's usually easy to solve
[22:12] <asac> do we need debhelper files at all?
[22:12] <asac> ;)
[22:12] <asac> i am more and more getting a fan of making all paths generic by punching stuff in debian/rules
[22:12] <fta> i'm afraid we do need them, too many files
[22:12] <asac> that would help a bunch in rebranding and being downstream and so on
[22:13] <asac> yeah ... i think we should do mozhelper though
[22:13] <fta> especially the splits between several debs
[22:13] <asac> and add the generic features required to it
[22:13] <asac> what i want is easy variables in .install/link/dirs
[22:13] <asac> and also .sourcepackage extensions ;)
[22:14] <fta> we could also make all those .in and subst filenames and paths
[22:14] <asac> yeah. its just that i get a bad feeling when thinking about templates ;)
[22:14] <asac> but true
[22:15] <asac> fta: ah ... but we definitly would need debian/control.sourcepackage
[22:15] <asac> its not that easy to replace description and stuff generically
[22:15] <asac> well maybe not "definitly" :)
[22:15] <asac> control doesnt change often so branches will have rare conflicts there
[22:16] <asac> so no mozhelper, but everything .in :)
[22:16] <fta> changing control is tricky as it's easy to confuse cdbs
[22:23] <asac> iceape building ... what a mess :)
[22:55] <fta> mmmmm, tricky. when I upgrade from X to Y, what is run is "preinst(from-X) upgrade X", so the preinst script knows nothing about Y and doesn't have access to any file of Y
[22:55] <fta> so preinst is not the good candidate
[23:03] <fta> asac, ^^
[23:06] <asac> fta: why do you need to know Y from arguments?
[23:07] <asac> you have access to the maintainer scripts
[23:07] <fta> think about X -> Y -> X
[23:07] <asac> so you probably have to do templating
[23:07] <asac> if you need the version number
[23:07] <asac> fta: you mean if Y upgrade is rolled back ? or if you downgrade?
[23:08] <fta> downgraded, like BUGabundo
[23:09] <asac> why would there be a problem when downgrading?
[23:13] <fta> you start from X, stable, providing /etc/greX
[23:13] <fta> you upgrade to Y, providing /etc/greY
[23:13] <fta>   -> preinst install X
[23:13] <fta>      -> look for gre files => only /etc/greX, not obsolete, do nothing
[23:13] <fta>   -> install /etc/greY => we have 2 gre files
[23:13] <fta> you downgrade to X, providing /etc/greX
[23:13] <fta>   -> preinst install Y
[23:13] <fta>      -> look for gre files => /etc/greY is obsolete => removed
[23:13] <fta>                            => /etc/greX is not obsolete => do nothing
[23:13] <fta>   -> install /etc/greY fails as is has been removed by preinst => BINGO
[23:14] <fta> eh
[23:15] <fta> the last 3 lines are reversed X<->Y
[23:17] <fta> asac, http://paste.ubuntu.com/100643/
[23:17] <asac> 00:13 < fta>   -> preinst install X
[23:17] <asac> this means
[23:17] <asac> 00:13 < fta>   -> Y.preinst install X
[23:17] <fta> no, it's the old preinst
[23:17] <asac>       -> look for gre files => only /etc/greX, not obsolete, do nothing
[23:18] <asac> thats wrong
[23:18] <asac> why old preinst?
[23:18] <asac> that isnt called on upgrade at all
[23:18] <fta> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
[23:18] <fta>    1.
[23:18] <fta>       If the package is being upgraded, call
[23:18] <fta>            old-postrm upgrade new-version
[23:18] <fta>    2.
[23:18] <fta>       If this fails, dpkg will attempt:
[23:18] <fta>            new-postrm failed-upgrade old-version
[23:18] <asac> thats postrm ;)
[23:18] <asac> not preinst
[23:18] <fta> oops
[23:18] <asac> so the problem here is that
[23:19] <asac>        -> look for gre files => only /etc/greX, not obsolete, do nothing
[23:19] <asac> should do:
[23:19] <fta> at that point, the new gre file is not there yet
[23:19] <asac>        -> look for gre files => remove all not /etc/greY
[23:19] <asac> hmm
[23:19] <fta> there's only the old one
[23:20] <asac> you should just remove /etc/greX and all obsolete ;)
[23:20] <asac> yes. the new gre file is /etc/greY
[23:20] <asac> thats not needed at that point
[23:20] <asac> we remove "previous" + all obsolete
[23:20] <asac> that should be right
[23:21] <fta> but pkg version != gre version
[23:21] <asac> thats for Y.new-preinst upgrade X
[23:23] <fta> i can add gre-version in the template and rm obsolete iif != (new) gre-version
[23:25] <fta> asac, who else complain?
[23:25] <asac> lool
[23:25] <asac> but that was "just" upgrade/install
[23:25] <fta> hm
[23:26] <asac> he couldnt start after upgrade ... gre missing
[23:26] <asac> we couldnt investigate unfortunately
[23:26] <fta> which version? 3.0 ?
[23:26] <asac> not sure
[23:27] <fta> where was that? here?
[23:27] <asac> it was before holiday
[23:27] <asac> i think in #ubuntu-mobile
[23:28] <fta> Dec 17 15:54:51 <lool> Could not find compatible GRE between version 1.9.0.1 and 1.9.0.*.
[23:30] <asac> did we land anything in 1.9 yet at all?
[23:30] <fta> Dec 17 15:55:36 <lool>  I'm doing a jaunty dist-upgrade, and it's been 20 minutes that firefox is broken during the upgrade with this message; I wonder why the dep isn't < 1.9.1 as well?
[23:30] <fta> Dec 17 16:07:15 <lool>  asac: Working again now; I wonder what broke it
[23:30] <fta> so just during the dist-upgrade
[23:31] <asac> oh ;)
[23:31] <asac> thanks for being my memory
[23:41] <fta> asac, http://paste.ubuntu.com/100653/ this should fix the bug, but we still have two gre just after a gre bump
[23:44] <fta> asac, got a r+ for mozilla bug 460913 \o/
[23:46] <fta> asac, r- for mozilla bug 412610