[00:01] <dolske> I'd be happy to. Oh, wait, is this a failure on linux? meh, don't care.
[00:04] <dolske> :-)
[00:06] <dolske> It would be helpful if you could post you mozconfig and detailed output from the failure.
[00:08] <fta> http://paste.ubuntu.com/99221/
[00:08] <fta> http://paste.ubuntu.com/99264/
[00:08] <fta> i have several like those
[00:11] <fta> we don't use a mozconfig. our configure line looks like this: --enable-system-cairo --disable-system-sqlite --with-system-nspr --with-system-nss --disable-system-hunspell --enable-application=xulrunner --enable-extensions=default --with-default-mozilla-five-home=/usr/lib/xulrunner-1.9.2a1pre --enable-startup-notification --with-user-appdir=.mozilla --without-system-jpeg --with-system-zlib=/usr --with-system-bz2=/usr --disable-javaxpcom --disable-
[00:11] <fta> crashreporter --disable-elf-dynstr-gc --disable-installer --disable-strip --disable-strip-libs --disable-install-strip --disable-updater --enable-optimize --with-distribution-id=com.ubuntu
[00:11] <fta> with --enable-tests --enable-mochitest now
[00:12] <asac> fta: strange ... i get something else ,)
[00:12] <asac> http://paste.ubuntu.com/99312/
[00:12] <asac> http://paste.ubuntu.com/99313/
[00:12] <asac> i get that error for both: outr package ... and pristine mozilla-central build (3.2pre)
[00:12] <fta> maybe i have this one too. I didn't capture everything yet
[00:12] <asac> fta: make check bails out on first error
[00:12] <asac> thats the idea of unit testing
[00:13] <fta> i do. I have a flag now
[00:13] <asac> k
[00:14] <asac> mine is definitly a regression. it does exactly what it shouldnt do
[00:14] <fta> remember i fixed a bashism
[00:14] <asac> fta: thats a javascript testcase
[00:15] <asac> also it happens with 1.9.1.head branch too
[00:15] <fta> the bashism was in the caller, not in the test itself
[00:15] <asac> so you didnt commit that to branch?
[00:17] <fta> http://paste.ubuntu.com/99316/
[00:17] <fta> i did
[00:19] <fta> line 77-79, it's a broken symlink
[00:20] <fta> and i'm testing xul right now, not browser (yet)
[00:21] <dolske> "httpd.js:406: ReferenceError: dumpn is not defined" is something you should ask Walso about. not sure why that would be happening, since dumpn() is used all over that code.
[00:21] <asac> me too
[00:21] <dolske> err, Waldo
[00:22] <fta> in http://paste.ubuntu.com/99264/, it froze after the last line, waiting for something. i let it run for ~1h, nada
[00:23] <fta> the corresponding log: http://paste.ubuntu.com/99261/
[00:23] <asac> fta: i am testing xul too ... do you run that in a chroot?
[00:23] <fta> yes
[00:23] <asac> e.g. because my test gets further than you (and both branches fail on the same)
[00:23] <asac> fta: maybe you are missing some package then
[00:24] <dolske> the first failure in 99221 would appear to be at http://mxr.mozilla.org/mozilla1.9.1/source/uriloader/exthandler/tests/unit/test_handlerService.js#155
[00:25] <dolske> heh, I think I wrote that part of the test but have blocked that memory. content handling can be a bit ugly to work with. :/
[00:25] <asac> we already saw that
[00:25] <asac> my idea was that maybe it uses/not uses gconf to get http handler?
[00:25] <asac> are we sure its actually running mozilla builds?
[00:26] <asac> i mean is make check what is run on tinderboxes
[00:26] <fta> ?
[00:26] <asac> s/running/ running on/
[00:26] <asac> my configure flags are really really close to official flags i think and still it fails
[00:41] <dolske> test_bug407303.js | 2152398922 == 2152398878.... the 2152398922 is the unexpected value, which is NS_ERROR_UNSAFE_CONTENT_TYPE
[00:41] <asac> right
[00:41] <asac> interesting as its exactly the value the bug tried to "not"-get
[00:44] <dolske> are you sure your source tree has the patch that was applied to nsJARChannel.cpp? oh, you said you get that failure with a stock mozilla tree too?
[00:45] <asac> dolske: what i pasted is with stock mozilla-central
[00:45] <asac> and i get the same in our package build tree (which is why i tried mozilla-central)
[00:45] <asac> dolske: and yes. its definitly in ;) i checked the nsJARChannel.cpp code
[00:46] <dolske> hmm. I don't really know that code.
[00:46] <asac> i backed out the last patch that touched nsJARChannel.cpp now
[00:46] <asac> (there was just one commit
[00:46] <asac> )
[00:46] <asac> lets see
[00:46] <asac> http://hg.mozilla.org/mozilla-central/raw-rev/3b4a3bfc99a7
[00:47] <asac> http://hg.mozilla.org/mozilla-central/rev/3b4a3bfc99a7
[00:47] <asac> doesnt really look promissing
[00:47] <asac> from the diff i see there
[00:48] <asac> heh
[00:48] <asac> ok
[00:49] <asac> dolske: all fine ... i think my provider is too dump and returns an IP for anything
[00:49] <asac> probably should setup a chroot for tests
[00:50] <dolske> oh, heh, it's resolving test.invalid? nice.
[00:51] <asac> yeah i hate them ;)
[00:51] <asac>  ping test.invalid
[00:51] <asac> PING test.invalid (64.236.172.120) 56(84) bytes of data.
[00:51] <fta> hm,i doubt that will work in our builders
[00:53] <dolske> We can probably fix that in the test suite, though. I think all the network requests are proxied through httpd.js
[00:53] <dolske> That should be able to enfore a never-resolves hostname.
[00:53] <asac> hopefully
[00:54] <dolske> (We've had similar problems in the past, with tests that relied on external URLs to load something. Same fix should probably just disable all external requests?)
[00:55] <asac> yes. i think that makes most sense. not really sure though if builders allow to open ports at all though ;)
[00:55] <asac> but we will see
[00:56] <asac> lets see how far i get now
[00:56] <dolske> the tests shouldn't requite that, and if there are any tests doing that it's a bug.
[00:57] <asac> hmm ... but httpd.js opens a port doesnt it?
[00:58] <dolske> on localhost.
[00:58] <asac> yeah thats what i wondered about ;)
[01:04] <crimsun> fta: ok, i think i have a test case + fix for that error, but i need to test
[01:04] <crimsun> fta: ^ RE: pulseaudio
[01:05] <crimsun> these locking issues are nasty :/
[01:05] <asac> yay. so make check finished here ;)
[01:05] <fta> crimsun, it seems luke updated pa in jaunty
[01:06] <fta> asac, what did you change? and does it work with our package?
[01:06] <asac> not yet with our package. in pristine tree i dumped the testcase from above
[01:06] <asac> that was everything that failed
[01:06] <asac> btw, i also ended up with a httpd.js bug
[01:06] <asac> i think that happens if the port is in use
[01:07] <asac> for me that happened when i ran two testsuites at the same time
[01:08] <asac> so now it failsin autocomplete ... quite late in build (e.g. toolkit/)
[01:08] <asac> http://paste.ubuntu.com/99328/
[01:09] <crimsun> fta: hmm, really? i only see my update that i asked jordan (laserjock) to upload.
[01:09] <fta> let me recheck
[01:10] <fta> sorry, my bad. i have 0.9.13-2ubuntu4
[01:11] <crimsun> you keep hitting a race; i think i have worked around it
[01:11] <crimsun> need to take a break for a few hours, will return to it
[01:11] <fta> :)
[01:12] <fta> asac, i just pushed xul 1.9.1 to my ppa with all the new stuff in. we'll see from the logs.
[01:22] <asac> yeah
[01:45] <asac> fta: fails right in xpcom
[01:46] <asac> build seems not to fail when tests fail
[01:49] <asac> http://paste.ubuntu.com/99339/
[01:51] <asac> so we cannot write to TEMP dirs ;)
[01:51] <asac> fta: setup a tmp/ dir in build trree and set TEMP env before running test i guess
[01:55] <fta> grrr, missing files.
[01:55] <fta> i wanted the build to continue even if check failed
[01:56] <asac> fta: heh
[01:56] <asac> i can reproduce that error
[01:56] <asac> if i unset LANG
[01:56] <asac> so maybe set LANG=en_US
[01:57] <asac> hmmm only export LANG=en_US.UTF-8 works
[01:57] <asac> is that a testrunner issue?
[01:57] <fta> /usr/bin/make -C build-tree/mozilla  check || exit 0
[01:58] <asac> i mean xul shouldnt have issues with utf if ystem doesnt have utf
[01:59] <fta> you mean here http://paste.ubuntu.com/99346/ ?
[02:00] <asac> yes thats the issue
[02:00] <asac> looks a bit like the second string has a whitespace
[02:00] <asac> CAA:89 ==  CAA:89
[02:00] <asac> but well
[02:00] <asac> my guess is that the .js file goes through shell and that mangels utf?
[02:01] <asac> can that be?
[02:01] <asac> unlikely i guess
[02:09] <fta> strange, only amd64 failed
[02:25] <fta> asac, can't reproduce locally
[02:26] <fta> even with no env at all
[03:23] <fta> for some reason, TraceTreeDrawer.h is not installed on amd64
[03:25] <fta> hm, no ENABLE_JIT on 64bit???
[10:45] <wikz> fta: Hi, I upped the spicebird pkg to revu. If you have some spare time, could you just glance over it and see if I have done everything right?, before I ask someone to review it. http://revu.ubuntuwire.com/details.py?package=spicebird
[12:41]  * asac yawns
[13:15] <wikz> asac: my source build fails but binary builds fine. http://paste.ubuntu.com/99609/ what could be wrong?
[13:15] <wikz> this is my first release, so I used  dpkg-buildpackage -rfakeroot -S -kABE512E9
[13:28] <asac> fta: http://bugs.freedesktop.org/show_bug.cgi?id=19086 (for Bug 312353)
[13:28] <asac> there is a patch
[13:29] <asac> wikz: dpkg-source: unrepresentable changes to source
[13:29] <asac> wikz: you should ahve used bzr so you can run bzr clean-tree
[13:29] <asac> usually this means that you accumulated either binary or other cruft (like links etc.) during build that are not cleaned on debian/rules clean
[13:30] <asac> could also be a "vi" .swp file if you still have it open
[13:30] <asac> to build source your tree must be 100% clean
[13:30] <asac> of course debian/rules clean should be fixed to make that happen
[13:30] <asac> (so its in your hands :))
[13:34] <wikz> asac: I dload the original tarball from upstream, untar the contents in spicebird-0.7/mozilla alongside debian and do a source build. I checked the tarball and it contains .exes, zips and .cvsignore and still get the same error. All this before I try to build it.
[13:34] <wikz> so I guess debian/rules would have no role in this, right?
[13:35] <asac> wikz: your paste isnt complete
[13:35] <asac> wikz: it spits out which files it cannot represent in diff.gz
[13:35] <asac> just look carefully at what it prints
[13:36] <asac> wikz: not sure what you mean. what file is it that causes the troubles?
[13:36] <wikz> It's an enormous list. more than 15000 lines. Should I paste the whole thing
[13:37] <asac> wikz: warning: arent a problem
[13:37] <asac> look for errors (non-warnings)
[13:37] <asac> (well, warnings arent nice either, but should break the source build)
[13:38] <wikz> yes there were lots of errors. I will paste them now.
[13:39] <asac> wikz: just paste a bunch of them
[13:40] <asac> most likely they show the problem quite nice
[13:40] <wikz> sure, also It tried importing into lp but https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/310283
[13:41] <asac> yeah
[13:41] <asac> let me know if nobody triages that in lets say 1-2 weeks
[13:41] <wikz> it's been so for months
[13:42] <wikz> asac: http://paste.ubuntu.com/99622/
[13:42] <wikz> as you can see, there are .exes in the orig
[13:57] <asac> dpkg-source: error: cannot represent change to spicebird-0.7/mozilla/js/src/js.mdp: binary file contents changed
[13:57] <asac> error: cannot represent change to spicebird-0.7/mozilla/js/src/fdlibm/fdlibm.mdp: binary file contents changed
[13:57] <asac> what the heck are mbp files?`
[13:57] <asac> err mdp
[13:57] <wikz> lol no idea!
[13:58] <asac> wikz: so lets focus on something we know:;
[13:58] <asac> spicebird-0.7/mozilla/config/makedep.exe
[13:58] <asac> why has that content changed?
[13:58] <asac> wikz: how does your orig tarball look like?
[13:58] <wikz> I untarred the tar and put it in spicebird-0.7
[13:58] <asac> please paste the output of tar tzf ORIG.tar.gz | head -n 100
[13:59] <asac> wikz: did you use any of our packages as a blueprint `
[13:59] <asac> =?
[13:59] <wikz> http://files.spicebird.org/pub/spicebird.org/spicebird/releases/0.7/source/spicebird-beta-0.7.full_source.tar.bz2
[13:59] <wikz> yes I used fta's tbea build
[13:59] <wikz> TB3a
[14:00] <asac> wikz: i think that is "embedded" tarball layout
[14:00] <wikz> yes
[14:00] <asac> try to put just the tar.bz2 in the orig.tar.gz
[14:00] <wikz> I used dh_make -f
[14:00] <asac> no thats bogus
[14:00] <wikz> and it created a tar.gz
[14:00] <asac> that will unpack stuff for your
[14:00] <asac> which is not embedded tarball layout
[14:00] <wikz> you mean I rename the bz2 to tar.gz
[14:01] <asac> mkdir spicebird-0.7; cd spicebird-0.7; wget http://files.spicebird.org/pub/spicebird.org/spicebird/releases/0.7/source/spicebird-beta-0.7.full_source.tar.bz2; cd ..; tar cvzf spicebird_0.7.orig.tar.gz spicebird-0.7/
[14:01] <asac> no
[14:01] <asac> like that
[14:01] <wikz> ok
[14:01] <Nafallo> spicebird?
[14:01] <wikz> Nafallo: yes
[14:02] <Nafallo> haha. kewl! what is it? :-)
[14:04] <asac> yet another mozilla based app ;)
[14:04] <Nafallo> does it replace thunderbird and add the extra hotness I can see on their homepage? :-)
[14:04] <wikz> Nafallo: TB+telepathy+gstreamer
[14:05]  * Nafallo looks suspiously at it
[14:05] <asac> wikz: are you working for synovel?
[14:05] <wikz> asac: yes
[14:05] <asac> cool ;)
[14:05] <wikz> I took up packaging as we are short of manpower
[14:05] <asac> yeah ;)
[14:05] <asac> thats definitly good
[14:06] <asac> wikz: do you have anyone who knows about inner gecko guts?
[14:06] <wikz> actually 2 of them
[14:06] <wikz> prasad and sunil
[14:06] <asac> do they know about layout/content/javascript engine stuff?
[14:06] <asac> ;)
[14:06] <asac> or more about the lower-middletier apis in side xul/gecko?
[14:07] <wikz> well prasad is well known in mozilla circle
[14:07] <wikz> I am sure he know
[14:07] <wikz> knows
[14:07] <asac> wikz: is spicebird based on 1.9 branch?
[14:07] <asac> or 1.8`
[14:07] <wikz> asac: TB3a
[14:07] <asac> ?
[14:07] <asac> ah
[14:07] <asac> ok
[14:07] <wikz> asac: sunil has ported enigmail to spicebird
[14:07] <asac> so 1.9.1
[14:08] <wikz> he has submitted patches for review
[14:08] <asac> wikz: please try to get that upstreawm to enigmail
[14:08] <asac> ah cool
[14:08] <wikz> also he has a fix for the intrepid fortify issue
[14:08] <wikz> the gcc4.3 workaround
[14:09] <asac> wikz: we have a fix for that ;)
[14:09] <wikz> CPPFLAGS=-U_FORTIFY_SOURCE ?
[14:09] <asac> wikz: no. we use a real code fix in multiple places
[14:09] <asac> not sure why fta hasnt added that to tb3a
[14:09] <asac> b
[14:09] <asac> ;)
[14:09] <asac> i guess he added it to tb3b1
[14:09] <wikz> maybe
[14:09] <asac> but cool
[14:10] <asac> unfortunately you are not on 1.8 ;)=
[14:10] <wikz> even sunil said disabling fortify is bad and has submitted a patch to mozilla for review
[14:10] <asac> i am currently trying to get more folks involved in security maintenance for that branch ... hence looking for groups that would get a benefit ;)
[14:10] <asac> wikz: the patch definitly has landed upstream
[14:11] <asac> i think they disapproved landing on 1.9.0 branch
[14:11] <wikz> asac: prasad and sunil are trying to get spicebird officially on addons.mozilla site
[14:11] <asac> addons? as an addon or as a featured app?
[14:12] <wikz> fetaured app on addons.mozilla.org
[14:12] <wikz> dunno if they would approve of it
[14:13] <wikz> asac: sunil has extensive knowledge on gstreamer and dbus if you need any
[14:14] <asac> mozilla bug 412610
[14:14] <asac> cool
[14:14] <asac> so it was your patch ;)
[14:14] <asac> oh it wasnt
[14:14] <asac> you added more?
[14:15] <wikz> well it didn't help spicebird, I guess he added more
[14:16] <wikz> asac: you package enigmal also right?
[14:17] <asac> enigmail needs a severe face-lifting ;) ... but yes.
[14:17] <wikz> https://www.mozdev.org/bugs/show_bug.cgi?id=20397
[14:17] <wikz> asac: sunil said the same :)
[14:18] <asac> well ... it was high-hack-art because i supported rotten old mozilla suite too in the beginning
[14:18] <asac> but when i decided to drop that it now is complete crap ;)
[14:20] <asac> wikz: seems like patch requires one more round, but then should be ready to go
[14:21] <asac> wikz: so did the tarball-in-tarball thing work out for you?
[14:21] <asac> did you use a bzr branch for that packaging work?=
[14:21] <asac> wikz: does spicebird provide twitter/identi.ca integration?
[14:22] <asac> is that plannedß
[14:28] <wikz> asac: I did what you said http://paste.ubuntu.com/99637/
[14:28] <wikz> asac: metablog api
[14:28] <wikz> for integrating with blogs
[14:28] <asac> wikz: well thats the _new_ tarball right?
[14:28] <asac> that should work i guess
[14:28] <wikz> yeah
[14:29] <asac> wikz: are you using bzr?
[14:29] <wikz> no svn
[14:29] <asac> probably a bad idea as we have all the packaging in bztr
[14:29] <wikz> is there a svn to bzr import other than lp
[14:29] <asac> (i asked for packaging not sources)
[14:30] <asac> bzr-svn
[14:30] <asac> is a package
[14:30] <wikz> ok
[14:30] <asac> you can just say bzr branch http://path/to/svn/trunk
[14:30] <asac> wikz: but what i asked for is the branch you use for packaging
[14:30] <asac> you say you based it on tbird 3a
[14:31] <asac> anyway ...debian/ dir in there should work
[14:32] <wikz> asac: bz2 has better compression than gz, so why does debian ask for tar.gz
[14:34] <asac> wikz: thats probably unrelated ;)
[14:34] <wikz> asac: ok :)
[14:34] <asac> no reason ... historic i think
[14:35] <wikz> fta's pkg tb3a2 has standards version set to 3.7.3. can I change it to 3.8.0 ?
[14:36] <wikz> do I need to check or run some tool
[14:36] <asac> if you have used bzr you could have regularly bzr merged from our packaging branch ;)
[14:36] <asac> i think he already bumped it to 3.8.0
[14:36] <asac> i never really care much about standards version ;)
[14:38] <wikz> as you say :)
[14:39] <asac> so does the package build now?
[14:41] <wikz> it created the diff.gz and .dsc files fine and I could create it back using dpkg-source -x
[14:42] <wikz> it was always building properly
[14:44] <asac> yeah
[14:44] <asac> try to upload to PPA
[14:46] <wikz> I will up to revu now. Just glance through it
[14:46] <asac> wikz: na ... push to PPA ;)
[14:46] <wikz> asac: ok
[14:51] <fta> hi
[14:52] <asac> welcome fta
[14:52] <fta> asac, any idea how i can make my *.install arch specific?
[14:52] <fta> yesterday, i came across some .h files that are not installed on amd64, hence my ftbfs
[14:53] <asac> fta: http://paste.ubuntu.com/99647/
[14:54] <fta> hm, reading dh_install source, there's nothing to support that
[14:55] <fta> trying..
[14:55] <asac> fta: its probably in a more general file shared amongst debhelper tools
[14:56] <asac> i think there was also a syntax to include "non-arch" stuff
[14:56] <asac> e.g. @include package.install.indep
[14:56] <asac> or something
[14:56] <asac> i claim to remember that i saw that in some of doko's packages (jdk, etc.)
[14:57] <fta> for the lib symbols files, i used #include "blabla.symbol"
[15:00] <asac> the arch stuff is in Dh_Lib.pm
[15:00] <fta> asac, btw, i still have no idea why that test is failing in my ppa
[15:00] <asac> dontsee anything about include though
[15:00] <asac> probably not available then
[15:01] <asac> fta: GetTempDir obviously is the crux there
[15:01] <asac> well not obviously, but i thought its a problem ;)
[15:01] <fta> if it's #include, maybe they pre-process the files
[15:01] <asac> fta: i dont see any preprocesssing ... but you are the perl master here ;)
[15:07] <fta> nope, no include :(
[15:15] <asac> fta: do you have a list of files that are not on amd64?
[15:16] <asac> smells a bit like a bug that there are missing files imo
 for some reason, TraceTreeDrawer.h is not installed on amd64
 hm, no ENABLE_JIT on 64bit???
[15:16] <asac> fta: did you ever had any issues with the re-SONAMed nss?
[15:17] <asac> kk
[15:17] <fta> i'm unsure which nss is used today
[15:17] <asac> fta: in your ppa?
[15:17]  * asac checks
[15:18] <fta> http://mxr.mozilla.org/mozilla-central/source/js/src/Makefile.in#242
[15:18] <asac> seems like you are using it ;)
[15:19] <asac> yeah makes sense
[15:19] <asac> fta: move those to a i386 only package xulrunner-1.9-jit-dev or something ;)
[15:20] <fta> god no, not another package
[15:21] <asac> i really think its the right thing to do here ;)
[15:21] <asac> but well i understand the package burden
[15:21] <asac> for me keeping two .install files in sync is more evil ;)
[15:21] <asac> or we need to generate the .i386 on the fly
[15:23] <fta> that's what i'm doing.
[16:06] <fta> asac, http://paste.ubuntu.com/99676/
[16:10] <asac> heh ;)
[16:11] <asac> so preprocessor should be punched into debhelper ;)
[16:15] <fta> pushed
[16:15] <fta> a lot of stuff should be in debhelper
[17:03] <asac> fta: pushed to ppa?
[17:03] <fta> branch
[17:04] <fta> i just found some dups in res/, fixing
[17:06] <asac> good
[17:06] <asac> now just the tests would have to work ;)
[17:06] <asac> i have the feeling there is a bunch of work left ;)
[17:08] <fta> yep, that's why i didn't want the pkg to ftbfs because of those tests, it's too early
[17:10] <asac> ok ... on the bus for a while
[17:10] <asac> bbl
[17:11] <fta> i think i need to package _tests and _profile too. they contain logs and useful data to troubleshoot test failures
[17:11] <fta> not sure *where* i should store them
[17:40] <fta> asac, ^^
[18:06] <asac> hmm
[18:07] <asac> interesting point
[18:07] <asac> cant we make all logs dump in the build log? isnt that happening anyway?
[18:07] <asac> oh he isnt here
[18:18] <Nafallo> asac: now he is
[18:20] <fta> did i miss something?
[18:24] <Nafallo> 18:06 < asac> hmm
[18:24] <Nafallo> 18:07 < asac> interesting point
[18:24] <Nafallo> 18:07 < asac> cant we make all logs dump in the build log? isnt that happening anyway?
[18:24] <Nafallo> 18:07 < asac> oh he isnt here
[18:24] <fta> thx
[18:25] <fta> asac, for now, i went with /usr/lib/xulrunner-devel-1.9.1b3pre/test-results.tar.gz
[18:25] <fta> in the -testsuite package
[18:26] <fta> asac, pushed to my ppa
[18:26] <fta> jaunty only, my stats are already bad :(
[18:42] <asac_> fta: i dont feel really good about putting logs there ... but well ;)
[18:45] <fta> where then?
[18:46] <asac> debian bug 510764
[18:46] <asac> debian bug 510765
[18:46] <asac> debian bug 510766
[18:47] <asac> hmm
[18:47] <asac> retitle didnt work apparently ;)
[18:47] <asac> liferea-webkit: Liferea should not provide webkit in a stable release
[18:47] <fta> lol
[18:48] <asac> Removing libwebkit-1.0-1 from lenny is also somewhat reasonable, if
[18:48] <asac> somewhat tragic.
[18:49] <asac> Anyways, I think libwebkit-1.0-1 is one of these few packages that it
[18:49] <asac> would be good to have in the release, yet we can't guarantee it works
[18:49] <asac> properly. Maybe we should have a special "unsupported" section for
[18:49] <asac> stable, or we should allow packages to ship with some of their
[18:50] <asac> dependencies only fulfilled from unstable, which would state their
[18:50] <asac> unsupported status.
[18:50] <asac> sounds like universe ;)
[18:50] <asac> i have the feeling that this is the result of upstream abandoning epiphany completely
[18:50] <asac> i mean: they announced EOL of gecko without having a viable replacement
[18:51] <asac> so as a matter of fact the gnome desktop is without a browser atm
[18:51] <asac> not sure if that changes in this cycle
[18:51] <asac> lets hope ;)
[18:57] <fta> i never liked epiphany. or several years, i preferred galeon over firefox
[18:57] <fta> f
[19:01] <fta> Failed  	305
[19:01] <fta> Succeeded  	2286
[19:02] <fta> bad ratio :(
[19:13] <fta> "Novell's openSUSE 11.1 Linux distribution" ... "and Novell's edition of OpenOffice.org 3.0 which contains numerous enhancements over its parent product from Sun."  do we have that? i mean, the enhancements
[19:32] <white> asac: got back from my weekend trip, was the make code snippet any useful?
[19:37] <wikz> fta: running lintian gives me this warning http://paste.ubuntu.com/99760/ The first one is obviuos as I'm doing it for revu but is the other fine with debian QA?
[19:38] <fta> wikz, what are the changes not using patches?
[19:39] <fta> wikz, usually, you do either but not both
[19:40] <wikz> ok, my updstream tarball is a compressed tarball .tar.bz2. so asac suggested that I put it in a tar, which I did.
[19:40] <wikz> how do I figure out what these changes are ?
[19:41] <wikz> I mean which changes are not using patches!
[19:41] <fta> gzip -dc *.orig.gz | diffstat should give you the 1st clue
[19:41] <fta> i mean, *diff.gz
[19:42] <fta> ideally, you should see only debian/* files
[19:43] <fta> (make it diffstat -p 1)
[19:44] <wikz> http://paste.ubuntu.com/99766/
[19:44] <wikz> fta:  I think It meant the last one
[19:44] <wikz> it was created by cdbs
[19:44] <fta> oh, hm
[19:44] <wikz> do I need to clear it in rules/clean
[19:45] <wikz> icedove has the same warning
[19:45] <fta> should not matter much.
[19:46] <wikz> fta: super cool
[19:46] <fta> you can add that to the clean:: rule, see if it helps
[19:46] <wikz> I can finally up to revu once it builds fine in my ppa
[19:47] <fta> :)
[19:47] <wikz> fta: how long before jaunty is frozen
[19:47] <wikz> can I make it before that
[19:48] <fta> https://wiki.ubuntu.com/JauntyReleaseSchedule
[19:50] <wikz> april 1st week
[19:50] <wikz> hmm
[19:50] <white> hmm on a sid system I am getting "nsNSSCertificate.cpp:913: error: ‘PK11_GetAllSlotsForCert’ was not declared in this scope". How did you guys fix it for ubuntu?
[19:51] <fta> wikz, https://wiki.ubuntu.com/UniverseFreeze
[19:51] <fta> white, i don't think we ever hit that
[19:52] <white> fta: hmm, i was sure I quickly read through some IRC logs from this channel, where it was mentioned that building icedove against some wrong nspr version was the issue
[19:52] <white> i am not sure though :/
[19:55] <fta> which version are you building?
[19:55] <fta> Nov 28 19:03:48 <fta>     nsNSSCertificate.cpp:913: error: 'PK11_GetAllSlotsForCert' was not declared in this scope
[19:55] <fta> indeed :)
[19:55] <white> i think it was a checkout from last week
[19:55] <white> i can create a new one with get-orig-source and then my make stuff for icedove
[19:57] <fta> i remember. my nss was too old. i bumped the req to nspr >= 4.7.3, nss >= 3.12.2
[19:57] <white> libnspr4-0d: Candidate: 4.7.1-4
[19:58] <white> i see
[20:00] <white> asac: btw I remember when I looked at your patches last week that the one you mentioned as "needs to be enabled" was a FF3 patch according to the comment
[20:01] <white> asac: and one patch didn't apply, but I didn't investigate
[20:01] <asac> k
[20:01] <asac> what patch was that?
[20:01] <asac> (sorry cant really remember)
[20:01] <white> hold on
[20:02] <asac> wikz: spicebird-beta-0.7.full_source.tar.bz2.cdbs-config_list isnt a problem in diff.gz
[20:03] <white> asac: looks like it was 441120_attachment_328852x.patch
[20:04] <white> asac: there are quite a few open issues on http://security-tracker.debian.net/tracker/status/release/stable , but probably many minor issues
[20:06] <wikz> asac: :)
[20:09] <asac> wikz: for icedove its a skipped 2.0.0.18 and now 19
[20:09] <asac> which will happen tomorr
[20:10] <asac> iceape needs .17 as well
[20:10] <asac> mozilla bug 441120
[20:11] <fta> asac, http://launchpadlibrarian.net/20901872/buildlog_ubuntu-jaunty-i386.xulrunner-1.9.1_1.9.1~b3~hg20090103r22626%2Bnobinonly-0ubuntu1~fta2_FULLYBUILT.txt.gz
[20:11] <white> asac: ok, so you are building the icedove etch packages? Do you want me to run them on my system and test a bit?
[20:11] <asac> white: where did i say that 441120 applies for mail?
[20:11] <fta> asac, all problems introduced by the testsuite solved, now, testsuite itself needs work
[20:12] <asac> fta: good. so do we see the output in build log?
[20:12] <fta> asac, part of it, yes.
[20:12] <white> asac: afaik you mentioned that all patches are needed and therefore I was wondering, because it looks like browser stuff
[20:12] <asac> white: sorry. if you started go ahead ;)
[20:12] <fta> asac, look for TEST-UNEXPECTED-FAIL
[20:12] <white> asac: i much rather prefer you building them
[20:13] <asac> white: no. not all patches. some are browser only, but if you diff the series of the current icedove orig with the series file in the new patchset
[20:13] <white> it will be enough fun to write the advisory text :/
[20:13] <asac> you will see which were disabled
[20:13] <white> ok that explains a lot :)
[20:14] <white> asac: for lenny, do you prefer a direct upload to testing-security or do you prefer to address the remaining issues via sid (given that it migrates)?
[20:15] <asac> white: its addressed in sid already ... will sink down (we have a freeze exception)
[20:15] <white> ok, then i guess http://security-tracker.debian.net/tracker/status/release/unstable needs to be updated
[20:17] <white> I'll do that now
[20:19] <asac> i will prepare tarballs for iceape, icedove and xul
[20:20] <asac> would be cool if you could help building and testing any of those for etch
[20:20] <asac> will ping you later tonight ... once done
[20:20] <white> asac: ok, i might be going to bed, but will be looking into it tomorrow morning
[20:21] <white> also have to catch up on the iceape thread on team@
[20:24] <fta> asac, use m-d :)
[20:33] <asac> fta: well ... not cvs checkout, but take existing; add more patches, quilt push them
[20:33] <asac> problem is that not all patches are used everywhere so its not really simple to identify "which" patches to add
[20:36] <wikz> asac: our trunk is 0.8 which is not so stable but has some important fixes for 0.7 bugs. do you recommend I go for 0.8 or 0.7? We have planned 0.8 for ~jan30th,2009
[20:36] <fta> mozilla bug 442627
[21:06] <fta> mozilla bug 446527
[21:29] <fta> mozilla bug 373701
[21:42] <asac> wikz: the tarball contains all debian/ stuff?
[21:47] <fta> asac, i don't know what to do except skip the failing test. Seems Mike has/had the same issue (442627)
[23:01] <fta> asac, what about /var/cache/xulrunner-1.9.1-testsuite?
[23:01] <fta> i'd prefer it to be unpacked by default
[23:03] <fta> the thing is, scripts will want this writable, for logs, profile and stuff.
[23:07] <asac> fta: yeah ... saw the bug. we could ensure that UTF charset is set
[23:08] <fta> asac, how? install & configure the locale mess?
[23:10] <asac> i am not exactly sure what is required package wise
[23:11] <asac> when does a system have UTF-8 support?
[23:11] <fta> locale + dpkg-reconfigure iirc
[23:12] <fta> locales + locale-gen en_US.UTF-8 should do
[23:13] <fta> i mean, buildep on "locales" and run "locale-gen en_US.UTF-8", but i'm not sure we can do that
[23:14] <asac> fta: if we build dep on locales ... doesnt that automatically do the geN?
[23:15] <asac> gen
[23:15] <fta> it needs to be configured somehow
[23:15] <asac> what does locale-gen do?
[23:16] <asac> ok seems to gen /usr/lib/locale/en_US.utf8/LC_CTYPE
[23:16] <asac> and the like
[23:17] <asac> what lib uses those?
[23:18] <fta> everything, starting to glibc
[23:19] <asac> fta: so its a glibc thing?
[23:19] <fta> locales, yes
[23:25] <fta> i'll disable some of the tests in this unit for now
[23:25] <fta> let's see how farther it goes.
[23:27] <asac> fta: cant we just test that with pbuilder?
[23:28] <fta> probably
[23:28] <fta> but ppa are not based on pbuilder
[23:28] <fta> more like sbuild
[23:28] <asac> yes. but i think env should be similar
[23:28] <asac> hopefully
[23:29] <fta> even more strict
[23:55] <asac> 1.8.1 still building ... finally :/
[23:56] <asac> lets hope it works now ;)
[23:56] <asac> otherwise this becomes unproductive ;)