[00:01] I'd be happy to. Oh, wait, is this a failure on linux? meh, don't care. [00:04] :-) [00:06] It would be helpful if you could post you mozconfig and detailed output from the failure. [00:08] http://paste.ubuntu.com/99221/ [00:08] http://paste.ubuntu.com/99264/ [00:08] i have several like those [00:11] 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] 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] with --enable-tests --enable-mochitest now [00:12] fta: strange ... i get something else ,) [00:12] http://paste.ubuntu.com/99312/ [00:12] http://paste.ubuntu.com/99313/ [00:12] i get that error for both: outr package ... and pristine mozilla-central build (3.2pre) [00:12] maybe i have this one too. I didn't capture everything yet [00:12] fta: make check bails out on first error [00:12] thats the idea of unit testing [00:13] i do. I have a flag now [00:13] k [00:14] mine is definitly a regression. it does exactly what it shouldnt do [00:14] remember i fixed a bashism [00:14] fta: thats a javascript testcase [00:15] also it happens with 1.9.1.head branch too [00:15] the bashism was in the caller, not in the test itself [00:15] so you didnt commit that to branch? [00:17] http://paste.ubuntu.com/99316/ [00:17] i did [00:19] line 77-79, it's a broken symlink [00:20] and i'm testing xul right now, not browser (yet) [00:21] "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] me too [00:21] err, Waldo [00:22] in http://paste.ubuntu.com/99264/, it froze after the last line, waiting for something. i let it run for ~1h, nada [00:23] the corresponding log: http://paste.ubuntu.com/99261/ [00:23] fta: i am testing xul too ... do you run that in a chroot? [00:23] yes [00:23] e.g. because my test gets further than you (and both branches fail on the same) [00:23] fta: maybe you are missing some package then [00:24] 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] 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] we already saw that [00:25] my idea was that maybe it uses/not uses gconf to get http handler? [00:25] are we sure its actually running mozilla builds? [00:26] i mean is make check what is run on tinderboxes [00:26] ? [00:26] s/running/ running on/ [00:26] my configure flags are really really close to official flags i think and still it fails [00:41] test_bug407303.js | 2152398922 == 2152398878.... the 2152398922 is the unexpected value, which is NS_ERROR_UNSAFE_CONTENT_TYPE [00:41] right [00:41] interesting as its exactly the value the bug tried to "not"-get [00:44] 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] dolske: what i pasted is with stock mozilla-central [00:45] and i get the same in our package build tree (which is why i tried mozilla-central) [00:45] dolske: and yes. its definitly in ;) i checked the nsJARChannel.cpp code [00:46] hmm. I don't really know that code. [00:46] i backed out the last patch that touched nsJARChannel.cpp now [00:46] (there was just one commit [00:46] ) [00:46] lets see [00:46] http://hg.mozilla.org/mozilla-central/raw-rev/3b4a3bfc99a7 [00:47] http://hg.mozilla.org/mozilla-central/rev/3b4a3bfc99a7 [00:47] doesnt really look promissing [00:47] from the diff i see there [00:48] heh [00:48] ok [00:49] dolske: all fine ... i think my provider is too dump and returns an IP for anything [00:49] probably should setup a chroot for tests [00:50] oh, heh, it's resolving test.invalid? nice. [00:51] yeah i hate them ;) [00:51] ping test.invalid [00:51] PING test.invalid (64.236.172.120) 56(84) bytes of data. [00:51] hm,i doubt that will work in our builders [00:53] We can probably fix that in the test suite, though. I think all the network requests are proxied through httpd.js [00:53] That should be able to enfore a never-resolves hostname. [00:53] hopefully [00:54] (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] yes. i think that makes most sense. not really sure though if builders allow to open ports at all though ;) [00:55] but we will see [00:56] lets see how far i get now [00:56] the tests shouldn't requite that, and if there are any tests doing that it's a bug. [00:57] hmm ... but httpd.js opens a port doesnt it? [00:58] on localhost. [00:58] yeah thats what i wondered about ;) [01:04] fta: ok, i think i have a test case + fix for that error, but i need to test [01:04] fta: ^ RE: pulseaudio [01:05] these locking issues are nasty :/ [01:05] yay. so make check finished here ;) [01:05] crimsun, it seems luke updated pa in jaunty [01:06] asac, what did you change? and does it work with our package? [01:06] not yet with our package. in pristine tree i dumped the testcase from above [01:06] that was everything that failed [01:06] btw, i also ended up with a httpd.js bug [01:06] i think that happens if the port is in use [01:07] for me that happened when i ran two testsuites at the same time [01:08] so now it failsin autocomplete ... quite late in build (e.g. toolkit/) [01:08] http://paste.ubuntu.com/99328/ [01:09] fta: hmm, really? i only see my update that i asked jordan (laserjock) to upload. [01:09] let me recheck [01:10] sorry, my bad. i have 0.9.13-2ubuntu4 [01:11] you keep hitting a race; i think i have worked around it [01:11] need to take a break for a few hours, will return to it [01:11] :) [01:12] 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] yeah [01:45] fta: fails right in xpcom [01:46] build seems not to fail when tests fail [01:49] http://paste.ubuntu.com/99339/ [01:51] so we cannot write to TEMP dirs ;) [01:51] fta: setup a tmp/ dir in build trree and set TEMP env before running test i guess [01:55] grrr, missing files. [01:55] i wanted the build to continue even if check failed [01:56] fta: heh [01:56] i can reproduce that error [01:56] if i unset LANG [01:56] so maybe set LANG=en_US [01:57] hmmm only export LANG=en_US.UTF-8 works [01:57] is that a testrunner issue? [01:57] /usr/bin/make -C build-tree/mozilla check || exit 0 [01:58] i mean xul shouldnt have issues with utf if ystem doesnt have utf [01:59] you mean here http://paste.ubuntu.com/99346/ ? [02:00] yes thats the issue [02:00] looks a bit like the second string has a whitespace [02:00] CAA:89 == CAA:89 [02:00] but well [02:00] my guess is that the .js file goes through shell and that mangels utf? [02:01] can that be? [02:01] unlikely i guess [02:09] strange, only amd64 failed [02:25] asac, can't reproduce locally [02:26] even with no env at all [03:23] for some reason, TraceTreeDrawer.h is not installed on amd64 [03:25] hm, no ENABLE_JIT on 64bit??? [10:45] 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 === asac_ is now known as asac === asac_ is now known as asac [12:41] * asac yawns [13:15] asac: my source build fails but binary builds fine. http://paste.ubuntu.com/99609/ what could be wrong? [13:15] this is my first release, so I used dpkg-buildpackage -rfakeroot -S -kABE512E9 [13:28] fta: http://bugs.freedesktop.org/show_bug.cgi?id=19086 (for Bug 312353) [13:28] Launchpad bug 312353 in xorg-server "improper mouse hover behavior with links" [Unknown,In progress] https://launchpad.net/bugs/312353 [13:28] Freedesktop bug 19086 in Input/Core "Enter/Leave model sends wrong events" [Normal,Assigned] [13:28] there is a patch [13:29] wikz: dpkg-source: unrepresentable changes to source [13:29] wikz: you should ahve used bzr so you can run bzr clean-tree [13:29] 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] could also be a "vi" .swp file if you still have it open [13:30] to build source your tree must be 100% clean [13:30] of course debian/rules clean should be fixed to make that happen [13:30] (so its in your hands :)) [13:34] 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] so I guess debian/rules would have no role in this, right? [13:35] wikz: your paste isnt complete [13:35] wikz: it spits out which files it cannot represent in diff.gz [13:35] just look carefully at what it prints [13:36] wikz: not sure what you mean. what file is it that causes the troubles? [13:36] It's an enormous list. more than 15000 lines. Should I paste the whole thing [13:37] wikz: warning: arent a problem [13:37] look for errors (non-warnings) [13:37] (well, warnings arent nice either, but should break the source build) [13:38] yes there were lots of errors. I will paste them now. [13:39] wikz: just paste a bunch of them [13:40] most likely they show the problem quite nice [13:40] sure, also It tried importing into lp but https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/310283 [13:40] Ubuntu bug 310283 in launchpad-cscvs "svn import fails due to unsigned cert" [Undecided,New] [13:41] yeah [13:41] let me know if nobody triages that in lets say 1-2 weeks [13:41] it's been so for months [13:42] asac: http://paste.ubuntu.com/99622/ [13:42] as you can see, there are .exes in the orig [13:57] dpkg-source: error: cannot represent change to spicebird-0.7/mozilla/js/src/js.mdp: binary file contents changed [13:57] error: cannot represent change to spicebird-0.7/mozilla/js/src/fdlibm/fdlibm.mdp: binary file contents changed [13:57] what the heck are mbp files?` [13:57] err mdp [13:57] lol no idea! [13:58] wikz: so lets focus on something we know:; [13:58] spicebird-0.7/mozilla/config/makedep.exe [13:58] why has that content changed? [13:58] wikz: how does your orig tarball look like? [13:58] I untarred the tar and put it in spicebird-0.7 [13:58] please paste the output of tar tzf ORIG.tar.gz | head -n 100 [13:59] wikz: did you use any of our packages as a blueprint ` [13:59] =? [13:59] http://files.spicebird.org/pub/spicebird.org/spicebird/releases/0.7/source/spicebird-beta-0.7.full_source.tar.bz2 [13:59] yes I used fta's tbea build [13:59] TB3a [14:00] wikz: i think that is "embedded" tarball layout [14:00] yes [14:00] try to put just the tar.bz2 in the orig.tar.gz [14:00] I used dh_make -f [14:00] no thats bogus [14:00] and it created a tar.gz [14:00] that will unpack stuff for your [14:00] which is not embedded tarball layout [14:00] you mean I rename the bz2 to tar.gz [14:01] 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] no [14:01] like that [14:01] ok [14:01] spicebird? [14:01] Nafallo: yes [14:02] haha. kewl! what is it? :-) [14:04] yet another mozilla based app ;) [14:04] does it replace thunderbird and add the extra hotness I can see on their homepage? :-) [14:04] Nafallo: TB+telepathy+gstreamer [14:05] * Nafallo looks suspiously at it [14:05] wikz: are you working for synovel? [14:05] asac: yes [14:05] cool ;) [14:05] I took up packaging as we are short of manpower [14:05] yeah ;) [14:05] thats definitly good [14:06] wikz: do you have anyone who knows about inner gecko guts? [14:06] actually 2 of them [14:06] prasad and sunil [14:06] do they know about layout/content/javascript engine stuff? [14:06] ;) [14:06] or more about the lower-middletier apis in side xul/gecko? [14:07] well prasad is well known in mozilla circle [14:07] I am sure he know [14:07] knows [14:07] wikz: is spicebird based on 1.9 branch? [14:07] or 1.8` [14:07] asac: TB3a [14:07] ? [14:07] ah [14:07] ok [14:07] asac: sunil has ported enigmail to spicebird [14:07] so 1.9.1 [14:08] he has submitted patches for review [14:08] wikz: please try to get that upstreawm to enigmail [14:08] ah cool [14:08] also he has a fix for the intrepid fortify issue [14:08] the gcc4.3 workaround [14:09] wikz: we have a fix for that ;) [14:09] CPPFLAGS=-U_FORTIFY_SOURCE ? [14:09] wikz: no. we use a real code fix in multiple places [14:09] not sure why fta hasnt added that to tb3a [14:09] b [14:09] ;) [14:09] i guess he added it to tb3b1 [14:09] maybe [14:09] but cool [14:10] unfortunately you are not on 1.8 ;)= [14:10] even sunil said disabling fortify is bad and has submitted a patch to mozilla for review [14:10] 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] wikz: the patch definitly has landed upstream [14:11] i think they disapproved landing on 1.9.0 branch [14:11] asac: prasad and sunil are trying to get spicebird officially on addons.mozilla site [14:11] addons? as an addon or as a featured app? [14:12] fetaured app on addons.mozilla.org [14:12] dunno if they would approve of it [14:13] asac: sunil has extensive knowledge on gstreamer and dbus if you need any [14:14] mozilla bug 412610 [14:14] Mozilla bug 412610 in Startup and Profile System "MAXPATHLEN too small for glibc's realpath()" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=412610 [14:14] cool [14:14] so it was your patch ;) [14:14] oh it wasnt [14:14] you added more? [14:15] well it didn't help spicebird, I guess he added more [14:16] asac: you package enigmal also right? [14:17] enigmail needs a severe face-lifting ;) ... but yes. [14:17] https://www.mozdev.org/bugs/show_bug.cgi?id=20397 [14:17] www.mozdev.org bug 20397 in GUI "Support Spicebird Collaboration Suite" [Normal,Assigned] [14:17] asac: sunil said the same :) [14:18] well ... it was high-hack-art because i supported rotten old mozilla suite too in the beginning [14:18] but when i decided to drop that it now is complete crap ;) [14:20] wikz: seems like patch requires one more round, but then should be ready to go [14:21] wikz: so did the tarball-in-tarball thing work out for you? [14:21] did you use a bzr branch for that packaging work?= [14:21] wikz: does spicebird provide twitter/identi.ca integration? [14:22] is that plannedß [14:28] asac: I did what you said http://paste.ubuntu.com/99637/ [14:28] asac: metablog api [14:28] for integrating with blogs [14:28] wikz: well thats the _new_ tarball right? [14:28] that should work i guess [14:28] yeah [14:29] wikz: are you using bzr? [14:29] no svn [14:29] probably a bad idea as we have all the packaging in bztr [14:29] is there a svn to bzr import other than lp [14:29] (i asked for packaging not sources) [14:30] bzr-svn [14:30] is a package [14:30] ok [14:30] you can just say bzr branch http://path/to/svn/trunk [14:30] wikz: but what i asked for is the branch you use for packaging [14:30] you say you based it on tbird 3a [14:31] anyway ...debian/ dir in there should work [14:32] asac: bz2 has better compression than gz, so why does debian ask for tar.gz [14:34] wikz: thats probably unrelated ;) [14:34] asac: ok :) [14:34] no reason ... historic i think [14:35] fta's pkg tb3a2 has standards version set to 3.7.3. can I change it to 3.8.0 ? [14:36] do I need to check or run some tool [14:36] if you have used bzr you could have regularly bzr merged from our packaging branch ;) [14:36] i think he already bumped it to 3.8.0 [14:36] i never really care much about standards version ;) [14:38] as you say :) [14:39] so does the package build now? [14:41] it created the diff.gz and .dsc files fine and I could create it back using dpkg-source -x [14:42] it was always building properly [14:44] yeah [14:44] try to upload to PPA [14:46] I will up to revu now. Just glance through it [14:46] wikz: na ... push to PPA ;) [14:46] asac: ok [14:51] hi [14:52] welcome fta [14:52] asac, any idea how i can make my *.install arch specific? [14:52] yesterday, i came across some .h files that are not installed on amd64, hence my ftbfs [14:53] fta: http://paste.ubuntu.com/99647/ [14:54] hm, reading dh_install source, there's nothing to support that [14:55] trying.. [14:55] fta: its probably in a more general file shared amongst debhelper tools [14:56] i think there was also a syntax to include "non-arch" stuff [14:56] e.g. @include package.install.indep [14:56] or something [14:56] i claim to remember that i saw that in some of doko's packages (jdk, etc.) [14:57] for the lib symbols files, i used #include "blabla.symbol" [15:00] the arch stuff is in Dh_Lib.pm [15:00] asac, btw, i still have no idea why that test is failing in my ppa [15:00] dontsee anything about include though [15:00] probably not available then [15:01] fta: GetTempDir obviously is the crux there [15:01] well not obviously, but i thought its a problem ;) [15:01] if it's #include, maybe they pre-process the files [15:01] fta: i dont see any preprocesssing ... but you are the perl master here ;) [15:07] nope, no include :( [15:15] fta: do you have a list of files that are not on amd64? [15:16] smells a bit like a bug that there are missing files imo [15:16] for some reason, TraceTreeDrawer.h is not installed on amd64 [15:16] hm, no ENABLE_JIT on 64bit??? [15:16] fta: did you ever had any issues with the re-SONAMed nss? [15:17] kk [15:17] i'm unsure which nss is used today [15:17] fta: in your ppa? [15:17] * asac checks [15:18] http://mxr.mozilla.org/mozilla-central/source/js/src/Makefile.in#242 [15:18] seems like you are using it ;) [15:19] yeah makes sense [15:19] fta: move those to a i386 only package xulrunner-1.9-jit-dev or something ;) [15:20] god no, not another package [15:21] i really think its the right thing to do here ;) [15:21] but well i understand the package burden [15:21] for me keeping two .install files in sync is more evil ;) [15:21] or we need to generate the .i386 on the fly [15:23] that's what i'm doing. [16:06] asac, http://paste.ubuntu.com/99676/ [16:10] heh ;) [16:11] so preprocessor should be punched into debhelper ;) [16:15] pushed [16:15] a lot of stuff should be in debhelper [17:03] fta: pushed to ppa? [17:03] branch [17:04] i just found some dups in res/, fixing [17:06] good [17:06] now just the tests would have to work ;) [17:06] i have the feeling there is a bunch of work left ;) [17:08] yep, that's why i didn't want the pkg to ftbfs because of those tests, it's too early [17:10] ok ... on the bus for a while [17:10] bbl [17:11] i think i need to package _tests and _profile too. they contain logs and useful data to troubleshoot test failures [17:11] not sure *where* i should store them [17:40] asac, ^^ [18:06] hmm [18:07] interesting point [18:07] cant we make all logs dump in the build log? isnt that happening anyway? [18:07] oh he isnt here [18:18] asac: now he is [18:20] did i miss something? [18:24] 18:06 < asac> hmm [18:24] 18:07 < asac> interesting point [18:24] 18:07 < asac> cant we make all logs dump in the build log? isnt that happening anyway? [18:24] 18:07 < asac> oh he isnt here [18:24] thx [18:25] asac, for now, i went with /usr/lib/xulrunner-devel-1.9.1b3pre/test-results.tar.gz [18:25] in the -testsuite package [18:26] asac, pushed to my ppa [18:26] jaunty only, my stats are already bad :( [18:42] fta: i dont feel really good about putting logs there ... but well ;) === asac_ is now known as asac [18:45] where then? [18:46] debian bug 510764 [18:46] debian bug 510765 [18:46] Debian bug 510764 in liferea-xulrunner "epiphany-webkit: Crashes at startup whenever I go to a site." [Grave,Open] http://bugs.debian.org/510764 [18:46] debian bug 510766 [18:46] Debian bug 510765 in liferea-xulrunner "epiphany-webkit: Crashes at startup whenever I go to a site." [Grave,Open] http://bugs.debian.org/510765 [18:46] Debian bug 510766 in liferea-xulrunner "epiphany-webkit: Crashes at startup whenever I go to a site." [Grave,Open] http://bugs.debian.org/510766 [18:47] hmm [18:47] retitle didnt work apparently ;) [18:47] liferea-webkit: Liferea should not provide webkit in a stable release [18:47] lol [18:48] Removing libwebkit-1.0-1 from lenny is also somewhat reasonable, if [18:48] somewhat tragic. [18:49] Anyways, I think libwebkit-1.0-1 is one of these few packages that it [18:49] would be good to have in the release, yet we can't guarantee it works [18:49] properly. Maybe we should have a special "unsupported" section for [18:49] stable, or we should allow packages to ship with some of their [18:50] dependencies only fulfilled from unstable, which would state their [18:50] unsupported status. [18:50] sounds like universe ;) [18:50] i have the feeling that this is the result of upstream abandoning epiphany completely [18:50] i mean: they announced EOL of gecko without having a viable replacement [18:51] so as a matter of fact the gnome desktop is without a browser atm [18:51]