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