[11:07] crimsun, users are complaining that we still provide the old beta of nonfree flash, do you know why we don't push the last RC ? i've packaged it for myself and the user experience is much better, at least on i386. [11:11] fta2: can you start midbrowser in intrepid? [11:12] i'm at work (hardy) so it can't test right now [11:13] btw, my hardy box crashed badly during the night [11:14] so much for an lts and stable updates [11:16] fta2: sure that its software and not hardware problems ;) [12:21] what is mozillas IRC server? irc.mozilla.org isnt working [12:21] Connecting to irc.mozilla.org (63.245.208.159) port 6667... [12:21] * Connected. Now logging in... [12:21] gnomefreak: ^ [12:22] armin76: thanks. let me chekc that against settings [12:24] armin76: thanks i used .net instead of org :( [12:26] fail [12:36] ;) all fixed [12:36] be back [13:30] anyone awake? [14:25] fta_: http://paste.ubuntu.com/52463/ [14:25] so we need more links ;) [14:57] anyone know anything about claws-mail? [15:01] KB1OHY: we are [15:01] some of us anyway [15:02] is it (zero)xKEYID? [15:03] or the vowel o [15:58] gnomefreak: ZERO [16:00] asac: thanks [16:02] i just intalled these packages not i get update for them? we are talking maybe 10 minutes have past [16:03] :( 6 HUNKS failed to apply [16:14] asac: you can ignore that email i sent you. its not fucking working [16:16] '/win 3 [16:46] gnomefreak: your mail wasnt signed [16:46] i know i cant get claws-mail to work with gpg [16:46] its starting to piss me off [16:47] thanks for checking [16:49] np [16:50] not saying much since i cant get sunbird to apply a patch either but i didnt work hard enough on that yet === asac_ is now known as asac [17:13] ok its lunch time and ikm still drinking coffee ill be back after lunch [17:27] k === fta_ is now known as fta [18:30] asac, i have sm 1.1.12 for intrepid as a security update with 9 MFSA. i guess i'm on myself now? [18:48] fta: yeah. if you need a helping hand let me know ;) [18:48] fta: will you push to hardy-security too? jdstrand would be happy to see that happen i guess ;) [18:49] sm is Maintainer: Ubuntu Mozilla Team, should i still ask for motu's approval? [18:50] fta: for security updates? no i wouldnt say so [18:50] fta: for hardy-security, please follow https://wiki.ubuntu.com/SecurityUpdateProcedures#Preparing%20an%20update and ping me for upload [18:51] fta: at least as long as the packaging didnt receive a major polish ;) [18:51] nope, just a bump [18:52] fta: for -security the idea is to just use the diff.gz of latest hardy with the new orig ... e.g. zero packging changes [18:52] fta: yeah that should work imo [18:52] !info seamonkey hardy [18:52] seamonkey (source: seamonkey): The Seamonkey Internet Suite. In component universe, is optional. Version 1.1.9+nobinonly-0ubuntu1 (hardy), package size 22 kB, installed size 88 kB [18:52] woo, old [18:55] fta: yeah. that nees thorough testing (not as bad as gutsy iceape though ;)) [18:55] fta: maybe push to a ppa and let me know so i can run it a bit on my hardy system [18:55] iceape is from debian, why isn't is merged like everything else? [18:55] -is+it [18:56] fta: security is never merged/synched ... main reason is that we dont have a stable target where to sync from (e.g. latest iceape might have changes that doesnt qualify for security updates) [18:56] fta: but i think we can live with iceape being outdated in gutsy for now ;) [18:57] for hardy: http://paste.ubuntu.com/52549/ [18:59] fta: looks good. maybe also reference the USNs fixed in firefox/tbird as applicable [18:59] e.g. [18:59] New security upstream release: 1.1.12 [19:00] fixes security issues also announced in USN-XXX-X (ffox) and USN-XXX-X (tbird) [19:00] we wont have our own USNs for universe updates ... so its not that important [19:00] but might give ubuntu folks that track -security a better idea how to look things up [19:03] * asac getting dinner [19:05] the USN are not public yet (reserved) [19:06] i mean cve [19:07] fta: it doesn't matter. just use what's listed in the MFSAs [19:08] (and there will be a lot of them for the big jump for hardy) [19:08] i just have the MSFAs and corresponding CVEs [19:09] fta: listing the MFSA in the changelog is up to you. listing the CVEs is a requirement for the -security updates. asac has a special case where he refers to the USN. this is acceptable, assuming the language is as he said above [19:10] fta: so you have a choice to list the CVEs that are referenced in the MFSAs, or to look through the USNs for firefox, et al and refer to those [19:11] fta: using CVEs is probably more accurate-- I don't know if there are any CVEs that are exclusively seamonkey or firefox/thunderbird [19:13] fta: if you want to run the changelog by me, feel free to ping me [19:14] jdstrand, is that enough http://paste.ubuntu.com/52552/ ? [19:16] fta: while not conforming to what we use in SecurityUpdateProcedures, I think it's acceptable. However, there are probably a bunch of others for 1.1.9->1.1.10 and 1.1.10->1.1.11 [19:17] well, this one is for intrepid, so just a small hop [19:17] fta: oh, I thought we were talking about hardy here [19:17] fta: for intrepid, that is totally fine [19:18] jdstrand, for 1.1.10, i already have the 4 USNs [19:21] fta : The last FF-3.1 in your ppa have some issues with tabs [19:21] lucypher, really, i'm using it, i didn't notice anything wrong [19:22] s/,/?/ [19:23] I've also tried to remove .mozilla/firefox-3.1 folder... [19:23] lucypher: I also don't have problems O_o [19:24] lucypher, what is the problem? [19:26] Probably I've found what was wrong [19:27] an addon? [19:27] I had a new tab icon in my toolbar [19:27] me too, it moved recently [19:28] I had to restore to default toolbar set [19:28] [reed], ^^ [19:28] And now it works [19:29] obviously not a packaging issue. maybe there's a bug upstream for that [19:30] It seems that the toolbar icons thing is WIP... [19:32] So I think isn't useful to file a bug about that at the moment. [19:32] Thanks. [19:33] i update my packages every few days so we'll see [19:37] anyway FF-3.1 is great, first of all in memory usage [19:41] * asac reboots [20:19] gnome bug 554485 [20:19] Gnome bug 554485 in Profiles "regression: open new tab using keyboard shortcut does not open new tab with profile of parent window" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=554485 [20:19] \o/ ;) [20:21] damn, animated svg has been postponed to 3.2 [20:23] asac, i'm still using xterm [20:24] fta: lucky you ... this bug annoyed me for about 3 month now ;) [20:24] nobody seems to care ... so either noone uses profiles or noone uses gnome-terminal ;) [20:24] i like xterm because of the low footprint [20:25] i gave up on low footprint when i committed to firefox ;) [20:26] this is 5 times bigger, not good when you have 30+ like i do [20:26] good side effect of fixing this is that i discovered that i can add new chars to the "select" word feature ... now i can select complete firefox package versions with double click again ;) [20:26] fta: i have a bunch of tabs instead [20:26] like two terminal windows with 6 tabs each [20:27] I have 7 workspaces, each specialized to different tasks [20:27] also multiple tabs and windows appear to live in the same process. [20:28] fta: yeah. i think you have a much better memory ... or at least willingness to remember what you do where ;) [20:28] i'd say more habits [20:28] yeah ... but its kind of investment to become used to habits like that for me [20:29] whenever i try, i forget about the idea at some point and then things become even messier [20:29] e.g. when you think you should have something in some terminal/desktop, but then you dont find it ... and later you find it somewhere else :) [21:08] fta: I also have RC2 merged locally, but I'm investigating an nspluginwrapper fix [21:08] fta: I'd rather not have to kludge nspluginwrapper just to have the latest RC [21:09] fta: in the meantime, I certainly wouldn't complain if you wanted to push RC2 into intrepid [21:10] I find RC2 far too unstable to use daily; I use swfdec-mozilla (and libswfdec-0.7-1) [21:10] i find the current one almost unusable, cpu wise, and ff crasher wise [21:11] the rc i'm using now is far better for both [21:11] 10.0.12.10ubuntu1~fta1 [21:11] fta: +1 [21:11] fta: it's a complete crasher on amd64 due to nspluginwrapper and internal Flash changes. [21:12] yeah, I've had flashplugin-nonfree_10.0.1.218+10.0.12.10ubuntu1.dsc for some time locally, but again, I don't use it. [21:12] granted, my local versioning is pooched, but whatever :) [21:12] 10.0.1.218+10.0.0.525ubuntu1 was evil on i386 [21:13] * sebner hopes that the final arrives soon :) [21:14] sebner, i wouldn't bet on it to be perfect, i expect no changes compared to the rc, unfortunately [21:14] bah [21:14] fta: anyhow. rc > beta what's in the archive [21:14] i know [21:15] that's why i packaged the rc [21:15] :) [21:15] it's not in my ppa as i didn't want to break my 64bit users [21:16] fta: well, I asked asac and we'll have final or rc definately in the archive [21:16] fta: again, if you'd like it in, by all means, please push u-u-s to sponsor an upload. Please remember to account for https://bugs.edge.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/272286 [21:16] Launchpad bug 272286 in nspluginwrapper "nspluginwrapper 1.1.0 does not support wmode correctly with Flash 10 RC2" [Wishlist,Confirmed] [21:26] anyone in here know anything about lightning calendar? [21:46] jdstrand, is that suitable http://paste.ubuntu.com/52592/ ? with all the info in bug 276437 [21:46] Bug 276437 on http://launchpad.net/bugs/276437 is private [21:46] damn [21:46] no reason to keep that bug private i guess [21:47] bug 276437 [21:47] Launchpad bug 276437 in seamonkey "security upgrade of seamonkey 1.1.12" [Undecided,Fix committed] https://launchpad.net/bugs/276437 [21:48] anyone in here know anything about lightning calendar? [21:49] KB1OHY: only packaging wise ... and code wise, but not really feature wise [21:49] mine updated from 0.8 to 0.9 and now it's completely unusable [21:49] KB1OHY: thats not our package [21:49] KB1OHY: go to irc.mozilla.org [21:50] we only can support ubuntu packages [21:59] hm, i should use 1.1.12+nobinonly-0ubuntu0.8.04.1, not 1.1.12+nobinonly-0ubuntu1.8.04.1 [22:04] asac, ^^ ? [22:19] fta: yes. hardy must be lower than intrepid. i assume intrepid gets ubuntu1 [22:19] yep [22:20] fta: I think the changelog looks good, with a couple of questions: [22:20] asac, pushed to my ppa, feel free to try the hardy one, once it's done [22:20] si [22:21] 1) you reference the CVEs in one part and USNs in another-- perhaps you could just reference USNs and not worry about the CVEs (unless there are CVEs not addressed in the USNs that are fixed/not fixed) [22:21] ops... wrong tab... sorry [22:21] 2) what does 'refresh diverged patch' mean in the context of hardy? [22:22] 3) the fontconfig patch is required to even build seamonkey on hardy correct? [22:22] jdstrand, 1/ i got the CVE from mozilla, and the USNs are from my previous (1.1.11) security upload in intrepid. [22:22] 4) can you explain the gcc comments? did gcc used need to be changed to build in hardy? [22:22] jdstrand, 2/ diverged compared to 1.1.9 in hardy [22:23] jdstrand: diverged: the same patch didnt apply anymore [22:23] asac: oh- we carried patches for security fixes that have been applied upstream? [22:24] jdstrand, 4/ we forced gcc 4.2 a long time ago, but in hardy, 4.2 is the default so we dropped it to prefer plain gcc [22:24] jdstrand: sorry. i just explained diverged. dont know which patch this is about in particular [22:24] fta: ^^ ? [22:24] 3/ correct [22:24] I wasn't clear, as both of you answered a question I didn't mean to ask :) [22:25] fta: what changed in the security patch, and why? [22:25] asac, debian/patches/80_security_build.patch [22:25] fta: the GCC change is not necessary in hardy ... though shouldnt hurt [22:25] fta: whats in that patch? [22:25] jdstrand, just the context (we use a large one) [22:25] asac, fta: I highly prefer not to make the gcc change, as it does nothing and just introduces a chance for problems [22:26] yeah. [22:26] we are *very* careful selective about -security updates [22:26] jdstrand, the gcc change has been in the branch for a long while now [22:26] careful and selective... [22:26] fta: the best way is just to start with the current hardy diff.gz on top of the orig [22:26] fta: I understand, but hardy is released [22:27] fta: if you want to get non-security fixes in, then it needs to go through SRU, and then -security can pull from -updates [22:27] i can revert that, no problem [22:27] fta: i fork the branches when the release is out and dont touch them except for updates [22:27] asac, i have 2 branches [22:27] fta: i think the .hardy branch is a backport branch and not a stable release update branch. [22:27] fta: you could create a .8.04 for the stable release updates [22:27] and .hardy for the backports [22:27] fta: oh [22:28] fta: so you already did that [22:28] yes [22:28] fta: ok, so the entirety of the 80_security_build.patch [22:28] still is needed, but just needed to be reapplied to the new codebase [22:28] fta: can you link that branch to the bug? [22:28] fta: is that accurate? [22:28] asac, sure [22:29] hmm only seamonkey-1.1.dev in ~mozillateam code [22:29] jdstrand, it's an old security patch from debian/iceape [22:29] asac, sure, as in i will [22:29] i just have 2 hands [22:30] fta: I'm confused-- it's an old security update that fixes things not already in the new upstream version? [22:30] fta: perhaps it'll become apparent when I look at the debdiff [22:31] jdstrand: is there nothing about it in changelog? [22:31] asac: the changelog says: [22:31] * Refresh diverged patch: [22:31] - update debian/patches/80_security_build.patch [22:31] that isn't chock-full of info ;) [22:31] hmm [22:31] let me look at the patch [22:32] appears to be really old (from iceape/debian times) [22:32] its introduction is not in changelog at least [22:32] yes [22:32] branch pushed [22:32] fta: lastly, I recommend rather than listing all those CVEs, that you just add usn-645-1 to your list of USNs [22:33] fta: to me, it's really an either/or thing [22:33] jdstrand: yeah. thats a patch from debian [22:33] jdstrand: its about linking the nss security libs shared instead of static [22:34] asac: ok, so it had to be massaged to apply/build [22:34] that's cool [22:34] yeah [22:34] jdstrand: http://bazaar.launchpad.net/%7Emozillateam/seamonkey/seamonkey-1.1.dev/annotate/154?file_id=svn-v2%3A1%40f4e3d8d1-d80b-0410-9133-bbc0d6b0e2e8-iceape%252ftags%252f1.0.6%252d1-debian%252fpatches%252f80_security_build.dpatch [22:35] mozilla bug 302416 [22:35] Mozilla bug 302416 in Build "NSS root cert module & fortezza should not be using NSPR static libraries" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=302416 [22:36] fta: we can probably drop that patch in intrepid [22:36] most likely its only for in-source nss/nspr [22:36] but better keep it in the hardy update [22:38] asac, well, i don't touch the branches for anything related to nspr&nss as long as your last soname changes are not either pushed or reverted. [22:39] fta: yeah [22:40] fta: anyway. the right procedure would have been just to bump changelog in .hardy branch and not merging (or only merging down essential issues) [22:41] fta: nss i really have to decide soon [22:42] fta: but in this case its ok. just backout the gcc changes and all should be fine ;) [22:42] done [22:44] jdstrand: is that kind of debdiff helpful? dont you need a new orig as well? [22:44] * asac just revealed his bad side of ignorance [22:45] asac: I'd like the whole source package-- I can do the diffing in this case [22:46] asac: I can then upload when you guys ping me on testing [22:48] the package is get-orig-source ready, it uses uscan from upstream and applies a nobin clean-up script, then repacks [22:49] you can trust me and get the tarball from my ppa, or don't trust me and redo it yourself, i won't blame you [22:50] (but it has to be same for hardy and intrepid) [22:50] fta: upload the tarball to launchpad [22:50] in the bug ? [22:51] fta: yeah [22:51] ok [22:51] all pieces: orig. diff.gz + dsc [22:51] fta: or if orig for intrepid is already in that should be good enough [22:51] but then providing a link to the orig.tar.gz would be nice [22:51] ppa link probably works as well. [22:52] ppa expires after a while [22:56] fta: does it do that still? [22:56] thought we have endless dailies now ;) [22:56] hm [22:56] at lesat celso said to me that we can use it for dailies now [22:56] not sure if he said that those expire after a year [22:56] jdstrand, better ? http://paste.ubuntu.com/52609/ [22:56] but you are right best is to put that in launchpad bug then i guess [22:57] fta: there is one MFSA in the middle ;) [22:57] nope [22:57] is that because that doesnt have a CVE? [22:57] - MFSA 2008-26: Buffer length checks in MIME processing [22:57] yep [22:57] fta: ok ... maybe use no-CVS (MFSA2008-25): .... [22:57] just an idea [22:57] http://www.mozilla.org/security/announce/2008/mfsa2008-26.html [22:58] so it's a follow-up of CVE-2008-0304 [22:59] - MFSA 2008-26 (follow-up of CVE-2008-0304): Buffer length checks in MIME processing [22:59] that's an awful lot of security fixes [23:01] jdstrand: how to document followups of CVEs that dont have a CVE on their own? [23:01] just CVE-2008-0304(b) ? [23:02] fta: looks good to me (and yes, that *is* a lot of fixes) [23:03] http://www.ubuntu.com/usn/usn-629-1 has: [23:03] "Mozilla developers audited the MIME handling code looking for similar vulnerabilities to the previously fixed CVE-2008-0304, and changed several function calls to use safer versions of string routines. " [23:03] so probably fine to document i like that [23:03] fta: is hardy built? [23:03] asac, https://edge.launchpad.net/+builds [23:04] just amd64 [23:04] hop, i386 too [23:04] ok i can pick amd64 [23:05] but i reverted gcc since [23:05] fta: in which ppa is it? fta? [23:05] fta [23:05] as 1.1.12+nobinonly-0ubuntu0.8.04.1~fta1 [23:06] yeah. this reminds me that we need a security PPA soon ;) [23:07] its hard to keep personal PPAs free from other depends [23:07] i agree [23:07] fta: is the nss in the the cluttered one? [23:07] yes [23:08] hehe [23:08] ok [23:09] fta: hmm cannot initialize security component [23:09] ? [23:10] fta: nss doesnt work :/ [23:10] e.g. visiting launchpad [23:10] no problem on intrepid [23:11] i guess you just picked sm and not nss/nspr for my ppa, right? [23:11] it's a mess [23:12] ok, let me repush that to mt, is it nss/nspr free? [23:12] fta: no ... new nss/nspr was forced in the upgrade (e.g. the proper lower bunds) [23:12] fta: i will push to asac ... which i only use for security testing [23:12] ok [23:12] mozillateam might be cluttered too (we have to clean that up) [23:12] wait, take the fta2 i just pushed, it's the final one [23:13] fta: i used the latest branch [23:13] 148 [23:13] * Improve MFSA / CVE descriptions in changelog [23:13] is that right? [23:13] ok [23:15] dum di dum (slow diff.gz) [23:16] well, just dget and dput [23:17] asac, plz decide quickly for nss, if you revert, i need to rebuild a lot of stuff now [23:18] fta: yeah. would have been an option ;) [23:18] fta: concerns me a bit that seamonkey had this issue now :/ [23:18] it was a fresh respin on top [23:19] (nss) [23:19] strange that it's fine on intrepid [23:19] indeed [23:23] fta: oops nspr has a .a file ? [23:23] -rw-r--r-- 1 root root 461752 Sep 25 19:18 /usr/lib/libnspr4.a [23:23] -rw-r--r-- 1 root root 235920 Sep 25 19:18 /usr/lib/libnspr4.so [23:23] -rw-r--r-- 1 root root 208848 2008-09-25 21:18 /usr/lib/libnspr4.so [23:23] lrwxrwxrwx 1 root root 11 2008-09-25 22:08 /usr/lib/libnspr4.so.0d -> libnspr4.so [23:24] same on hardy: [23:24] -rw-r--r-- 1 root root 202000 2008-09-25 21:18 /usr/lib/libnspr4.so [23:24] lrwxrwxrwx 1 root root 11 2008-09-29 11:46 /usr/lib/libnspr4.so.0d -> libnspr4.so [23:24] (hardy1)asac@hector:~$ dpkg -S libnspr4.a [23:24] libnspr4-dev: /usr/lib/libnspr4.a [23:24] fta@cube:~ $ dpkg -S libnspr4.a [23:24] dpkg: *libnspr4.a* not found. [23:24] -dev package installed? [23:25] upload finished :/ [23:26] oh, right, in dev [23:26] tarball in the bug too [23:26] fta: [23:26] for lib in ssl3 softokn3 smime3 nss3 nspr4 plc4 plds4; do \ [23:26] dh_link -p$(DEB_MOZ_APPLICATION)-browser usr/lib/lib$$lib.so.0d /usr/lib/$(DEB_MOZ_APPLICATION)/lib$$lib.so ; \ [23:26] done [23:27] dont see why it would hurt, but probably would need to be updated after nss transition [23:27] after, yes [23:27] so please decide [23:29] yeah. maybe that linking is the cause for the issues [23:29] actually so.1d is wrong [23:29] that means you need nss-0d installed ... which is outdated [23:30] fta: yeah ... that was it ;) [23:30] i had an old nss3-0d package installed [23:30] so its a bug in seamonkey [23:37] hm, ok. strange it didn't hurt before [23:38] in fact no, the .0d was still there as a legacy links [23:38] -s [23:40] asac, why did you have that old nss3-0d? [23:42] we have that 0d/1d since last december [23:42] fta: because nss3-0d doesnt have any .so ... so it doesnt get a lower bound for shlibs [23:42] fta: well ... i had an old one 3.12.0.3-0ubuntu0.8 [23:42] and ~rc2 for the other libs [23:42] the links didnt look that bad [23:42] but there surealy was one missing or something [23:44] so it's not a bug in sm/hardy. just a bad mix of nss on your side [23:47] fta: its a bug: sm still shps links to 0d links [23:47] that shouldnt be the case [23:47] instead the .1d whould be used [23:47] and then this bug wouldnt exist [23:47] it was just revealed by a bad mix [23:47] should i fix that in both branches ??? [23:48] fta: i think in hardy its ok. in intrepid fixing makes sense. [23:49] let me see if sm built in ppa [23:49] still spinning [23:50] at least its on CPU