[00:01] hmmm, i'm building with nss/nspr cvs [00:01] i should not do that as i know it will fail [00:10] asac, DBUILD_ID=0000000000 [00:10] .. but that's no longer a merge if i start fixing things [00:14] Ubulette: thats ok ... fix it [00:14] its a minimal thing ... push the patch upstream [00:15] ( as in debian) [00:15] i already told him once ... no idea why he dropped it again ... nor when [00:15] Ubulette: its important that in the end the changelog reads liks: [00:16] Ubuntu changes: [00:16] + list [00:16] + all [00:16] + changes [00:16] + that [00:16] + currently [00:16] + exist [00:16] + in [00:16] + package [00:16] :) [00:16] i only filled the blanks [00:16] e.g. document the complete debdiff [00:17] then ... list which modifications were dropeed/applied upstream .. so nothing really particular [00:17] I did lines 4..11 [00:27] Ubulette: 61_python_py_ssize_t_detect [00:27] wasn't that applied? [00:28] no [00:28] i think we don't need that anymore as we have a patch that doesn't require modification of configure.ac anymore [00:28] which patch did mike include? [00:28] (I think he mentioned my name in changelog) [00:28] Drop debian/patches/68_python25_api_breakage.dpatch adopted by Debian as debian/patches/35_python_2.5.dpatch [00:28] Ubulette: use the one we have in xul 1.9 [00:29] instead of both [00:29] it should apply cleanly [00:29] noone will accept to review that. it already has 70 patches [00:30] i'll wait forever like for seamonkey1 [00:30] what do you mean? [00:30] Ubulette: no ... its just the debdiff that is important [00:30] if i touch more than just the merge [00:30] not the total diff [00:30] hmm .. ok [00:30] then keep it that way [00:30] even debdiff it already big [00:30] is [00:31] instructions say to keep changes to the minimum [00:31] yes [00:31] so if it's dirty, keep it dirty [00:31] then follow the instructions [00:32] bluekuja: why does sm1 take so long? [00:32] bluekuja: you waste fresh blood :) ... people that contribute and don't get sponsored ;) [00:32] I don't know, it's in a far better shape than it has ever been [00:37] http://paste.ubuntu.com/2042/ [00:37] Ubulette: well ... give him some time ... he probably has never dealt with such a huge package :) [00:37] hmm [00:37] yes thats known to debian [00:37] i saw it on ml today [00:38] and ? [00:38] http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-November/003146.html [00:38] oh thats iceape [00:38] Okay, this was broken by the latest gtk+2.0 package. [00:38] The patch at https://bugzilla.mozilla.org/attachment.cgi?id=264996 [00:38] should fix this. (If you give it a try, don't forget to run autoconf to [00:38] update configure) [00:38] (thats what mike commented) [00:40] what's the bug id ? [00:47] naturally he keeps that open :) [00:48] https://bugzilla.mozilla.org/show_bug.cgi?id=344818 [00:48] Mozilla bug 344818 in Build Config "Linking - missing library deps" [Normal,Unconfirmed] [00:49] not the same [00:51] Ubulette: yes it is [00:51] https://bugzilla.mozilla.org/attachment.cgi?id=264996 [00:51] thats the same link? [00:51] looks like ... thats from that bug [00:51] the last attachment [00:53] god i hate dpatch [00:54] too slow for such a big tree [01:31] asac, i don't get it, in the tarball i've got from the merge site, there's a debian dir in it [01:31] http://paste.ubuntu.com/2043/ [01:44] Ubulette: yes ... from what i know that is the tarball which attempted to do the merge [01:44] only conflicts are marked [01:45] and you have to fix them [01:45] thats merge-o-matic :) [01:45] problem is that tarball is not vanilla [01:46] Ubulette: which tarball= [01:46] ? [01:46] is it the one i'm supposed to push ? [01:46] http://merges.ubuntu.com/x/xulrunner/ [01:46] Ü [01:46] which? [01:46] xulrunner_1.8.1.9.orig.tar.gz [01:47] that should be the orig yes [01:47] http://paste.ubuntu.com/2043/ [01:47] like a copy from debian [01:47] Ubulette: don't bother about that [01:47] its in pristine upstream [01:47] that debian dir [01:47] it has always been there ... abandoned for agaes [01:47] ok [01:48] its pristine upstream [01:48] i think [01:48] http://merges.ubuntu.com/x/xulrunner/xulrunner_1.8.1.9-1ubuntu1.src.tar.gz [01:48] is the one that was automerged [01:48] not sure though [01:48] i am a lame merger after all [01:48] yes, it's auto unpacked as xulrunner-1.8.1.9-1ubuntu1 [01:48] Ubulette: actually there is a script you should run [01:48] which is not usual [01:48] http://merges.ubuntu.com/grab-merge.sh [01:48] i did it [01:48] run that with xulrunner [01:49] i did it [01:49] ah [01:49] ok ... yes then there should be conflicts or something in the source tree [01:49] that's why i'm slow, it's an unusual way to do everything [01:49] right :) [01:49] but its effective for that purpose [01:50] i'm tempted to mv xulrunner-1.8.1.9-1ubuntu1 xulrunner-1.8.1.9 [01:50] well ... that doesn't really matter ;) [01:51] .. except that dpkg-sources complains [01:51] yeah ... butin the end its not a problem ... its easier to debdiff later ... as you see which is which [01:51] debdiff looks clean. i'm rebuilding as i've touched configure [01:54] asac, http://paste.ubuntu.com/2045/ [01:56] Ubulette: you don't needtoadd the pysize configure.in patch [01:56] mike did it manually [01:57] like [01:57] ++#if defined(__x86_64__) || defined(__ia64__) [01:57] ++ if (PyObject_AsWriteBuffer(obBuffer, &buf, (long *)&buf_len) != 0) { [01:57] ++#else [01:57] + if (PyObject_AsWriteBuffer(obBuffer, &buf, (int *)&buf_len) != 0) { [01:57] ++#endif [01:57] looks a bit like he will miss archs with 64 bits that way [01:57] like s390 64-bit ppc64 [01:57] no idea whatelse [01:57] Ubulette: maybe resurrect the patch we had in previous version [01:58] but its your decision [01:58] if you keep mikes you don't need the other [01:59] otherwise: thumbs up [02:01] if i drop 61_python_py_ssize_t_detect i have to redo the damn 99 :( [02:02] yeah :) [02:02] not difficult, just slow [02:02] happy dpatching [02:02] tell that the other core-devs that want to fight quilt for something more simpler :/ [02:02] s/more/ [02:03] s/more// [02:03] quilt is easy if you know what a stack is [02:04] moz will use it [02:04] right ... but maybe not easy enough to grow the motu community as big as we want it to be :) [02:04] either natively or through hg [02:05] a few lines of tutorial and it's enough [02:05] push/pop, new, add, refresh, fold [02:05] that's it [02:05] right ... you don't need to convince me :) [02:05] :) [02:06] debian goes to git + merge-new-upstream-on-top approach \O/ [02:06] and i don't have a key anymore :( [02:09] merge-new-upstream-on-top ? [02:09] yeah ... just commit new upstream releases to git ... [02:09] with you patches getting melted [02:10] gasp, full tree [02:13] yeah ... merge on top :) [02:13] what's the benefit ? [02:14] no idea ... to piss at me? [02:14] lol [02:15] http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-October/003052.html [02:16] http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2007-October/003062.html [02:18] still no mention of the benefits [02:19] thats true [02:19] he references: http://blog.madduck.net/debian/2007.10.03_packaging-with-git [02:19] in fact we had various discussions before ... mike was always _for_ a patch ystem ... while eric wasn't [02:20] and funny thing is that I chatted with him about that topic before [02:21] anyway ... i cannot upload to debian anymore :( [02:22] gpg key ? [02:23] yes ... they updated gpgv and now it thinks that my key has expired ... because a subkey has expired [02:23] can't you just drop it ? [02:24] tried ... keyservers appear not to honour any delkey [02:24] e.g. maybe i need to change seomthing else so the new key is updated [02:25] looked like the keyservers just ignored it [02:36] (lady) bugs never disappear for lp/code ? [02:38] he? [02:39] https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.dev [02:39] top right and bottom [02:40] bottom is released so i expected it to disappear [02:40] no idea :) [02:40] maybe a bug in lp [02:45] is xulrunner in main in debian ? [02:45] debian only has main [02:45] everything else is non-free [02:45] and contrib ... which is non-free as well (e.g. source is free, but depends on non-free) [02:45] so everything that is free goes to main [02:46] i remember nonfree, nonus, contrib [02:46] ok, go for main [02:48] asac, same bug [02:48] ../../dist/lib/components/libgklayout.a(nsCanvasRenderingContext2D.o): In function `nsCanvasRenderingContext2D::SetDimensions(int, int)': [02:48] collect2: ld returned 1 exit status [02:49] bad [02:50] and before you ask, yes, the patch is applied [02:50] and configure updated too [02:51] yeah ... i know that you know how to do it :) [02:51] i just brought my blog back up :) [02:51] not that there is anything interesting :) ... but after being 2+ month down this is a precious moment ;) [02:52] malone is timeouting and oopsing me [02:52] a friday night update? [02:52] nice [02:53] bug 118500 [02:53] Launchpad bug 118500 in xulrunner "Please merge xulrunner (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/118500 [02:53] bug 61395 [02:53] Launchpad bug 61395 in xulrunner "please sync xulrunner 1.8.0.5-4.2 from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/61395 [02:53] bug 78587 [02:53] Launchpad bug 78587 in xulrunner "please sync xulrunner 1.8.0.9-1 from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/78587 [02:53] bug 119946 [02:53] Launchpad bug 119946 in xulrunner "Please merge xulrunner 1.8.1.4-2 from Debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/119946 [02:53] bug 89561 [02:53] Launchpad bug 89561 in xulrunner "[UVF exception] Merge xulrunner 1.8.0.10 from Debian unstable" [Medium,Fix released] https://launchpad.net/bugs/89561 [02:54] hmmm, that one is ahead of me [02:54] ahead? [02:54] oh no [02:54] i'm on 1.8.1.9 [02:55] thought it was chronological [02:56] bug 163271 [02:57] Launchpad bug 163271 in xulrunner "Please merge xulrunner 1.8.1.9-1 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/163271 [02:59] hehe [02:59] mozilla bug 368576 [03:00] Mozilla bug 368576 in Build Config "undefined reference to `XRenderFindStandardFormat' while compiling" [Normal,Resolved: duplicate] http://bugzilla.mozilla.org/show_bug.cgi?id=368576 [03:01] the patch from before didn't even contain "Xrender" [03:02] so -lXrender , nada [03:02] damn [03:04] welll its still the duplicate bug of that one [03:04] i needed the other patch [03:04] https://bugzilla.mozilla.org/attachment.cgi?id=242438 [03:04] which? [03:05] +EXTRA_DSO_LDOPTS += -lXrender [03:05] maybe you need all three ;) [03:57] mozilla bug 381216 [03:57] Mozilla bug 381216 in Places "prevent bookmarks dataloss when a user goes from Firefox 2, Firefox 3 beta, Firefox 2, and then back to Firefox 3 [was: After initial import, minefield with bookmarks-on-places throws out Firefox 2 bookmarks changes]" [Normal,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=381216 [04:07] late ... + off === asac_ is now known as asac === \sh_away is now known as \sh [13:33] is there firefox 3 beta rc in repo? [13:48] Greenery: in hardy ... yes. [13:49] oh i'm on gutsy [13:49] is there a way to get it? [13:51] hmmm ... not yet ... we wiill update gutsy once beta is final :) [13:51] cool...now if beta is out, do i have to remove current firefox 2.0 or can bothe 3.0 and 3.0 work together? [13:52] *2.0 [13:52] you can have both at the same time ... they won't share the profile though [13:52] ah nice, i would love to test firefox 3 cos its amazing one windows so far [13:53] thanks asac [13:53] you can already install it ... firefox-3.0 is the package name [13:53] but its a8 in gutsy [13:53] once the new one gets in the archive you will automatically upgrade [13:53] it will use different profile? [13:53] yes [13:53] ok gonna try it out [15:23] asac: iceape fur gutsy is done i just want to run lintian and linda on it real fast before i push [15:25] hi [15:25] ill let you know when its ready i have to go upstairs for coffee first [15:25] hi [15:25] * gnomefreak knows i need to remove .bzr :( [15:26] coffee is a nice idea, i'll do that too :) [15:27] ok ill be back after coffee [15:31] gnomefreak: you can add -i.bzr to your dpkg-buildpackage parameter list [15:49] bluekuja, hi, any eta for sm1 ? [15:49] * asac => sport [15:53] Ubulette, I've built it [15:53] and seems fine [15:53] need to check lintian and other packaging issues [15:53] but not today [15:53] it's the weekend [15:54] :) [15:54] I'm full of stuff to do on this period [15:55] that's why there is a small delay [15:55] but don't worry, for the next week it can inside [15:55] *be === \sh is now known as \sh_away === Ubulette_ is now known as Ubulette [17:11] asac, i've fixed all the ftbs with xul1.8, i just have a few concerns about the python stuff [17:13] in debian/tmp, i have usr/lib/python2.5/site-packages/xpcom while in the debs, it goes to usr/share/python-support/python-xpcom [17:13] and mike has a checker at the end of the build showing that [17:14] oh, and xulrunner-{nss,nspr}.pc are not installed at all. there's nothing to install those 2, there's just in debian/tmp [17:57] asac, i'm done. debdiff attached to bug 163271 [17:57] Launchpad bug 163271 in xulrunner "Please merge xulrunner 1.8.1.9-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163271 [18:14] asac: i do [18:15] i would say it didnt work last time but revu was broken anyway so ther eis no telling [18:16] i'm wondering who would volunteer to review the merged xul1.8 with 2*300k of debdiff [18:17] Ubulette: why are you building xulrunner-1.8 for hardy? [18:17] it's a merge [18:17] atleast thats what i got from lastnights conversation [18:17] merge for hardy you cant merge for gutsy and 1.9 is in hardy [18:17] are we planning on supporting both in hardy? [18:18] http://merges.ubuntu.com/x/xulrunner/ [18:18] i just did that pending merge [18:18] unles security only it cant be merged into gutsy [18:19] * gnomefreak waiting for browser [18:19] * gnomefreak doesnt see 1.9 there [18:19] i see 1.8.1.9 [18:20] yes [18:20] it's the old 1.8 branch [18:20] in hardy or gtusy? [18:20] hardy i guess [18:20] why would we need 2 versions of xulrunner [18:20] because they are not compatible [18:21] hardy should have everything depend on xulrunner-1.9 [18:21] that's why 1.9 uses a different package name [18:21] gnomefreak, it will take a while [18:21] so we have to have packages depend on 1.9 | 1.8? [18:21] depends [18:22] what does 1.8 do that 1.9 doesnt? [18:22] we want to be able to install 1 xul per branch at the same time, like upstream [18:23] 1.9 changed the API to much for some old projects [18:23] too [18:23] firefox 2.0 cant depend on 1.9 afaik but 3.0 should be final before we release hardy [18:23] ff2 will never use libuxl [18:24] ff3 already does for us, but 1.9 [18:24] i know but since 3.0 will be final (assuming it will be ready by jan1) we can drop 2.0 from repos when 3.0 is final [18:25] what about everything else depending on gecko/xul ? (miro, kaze, epiphany, python-moz, etc..) [18:25] they will eventually catch up with xul 1.9 but it will take time [18:26] seamonkey 2.0 wont be released in time for hardy, kaze uses 1.9 not sure about the others but i dont see why they cant. [18:26] and i know seamoney doesnt use libxul at all [18:26] so we need to continue to provide xul1.8 (merged from debian) in parallel to xul1.9 that we are maintaining here [18:26] kaze doesn't [18:27] i've tried, i've patched, it's far from obvious [18:27] right now none of the above listed apps depend on libxul at all except maybe miro [18:27] my latest kaze depends in xul 1.8 [18:27] on [18:27] so why not just keep them not depending on it, is there something that 1.8 will do that isnt done for these apps no [18:28] sno/sow [18:28] s/no/now [18:28] just the api [18:29] api doesnt do anything for epiphany ect since it depends on firefox [18:29] btw, xulrunner 1.8 is already in hardy, why won't it be upgraded like everything else ? [18:29] Ubulette: i was figuring it would be pulled [18:29] since 1.9 is there but i forgot about other apps [18:30] depending on ff-dev is a mistake, we need to get rid of that but it's only possible starting to xul 1.9 [18:30] Ubulette: no installing epiphany installs firefox [18:31] doesn't mean it's good [18:31] that is the point of adding libxul in gutsy we were gonna make use of it installing xul instead of firefox [18:31] but we couldnt due to time we got xul in [18:31] asac told upstream (epiphany) is working on supporting xul 1.9 [18:31] linda takes too damn long to run [18:33] gnomefreak, xul is also a SDK, what do we know about users of the SDK ? there are tons of xulapp that are not packaged but still need xulrunner [18:33] im assuming everything installs firefox/depends on it due to mainly depending on gecko [18:33] if they are not packaged for ubuntu it shouldnt matter at all [18:35] not to you maybe but to others maybe. difficult to know for sure [18:36] we dont support outside of our repos (we == ubuntu) [18:36] person wants to build it its on them to get build-deps [18:38] i didnt say its a bad idea i just didnt understand why 2 versions were needed [18:38] but if packages depend on 1.8 in gutsy than i see why its added in hardy [18:38] the merge was pending, i volunteered, done, period. [18:38] * gnomefreak doesnt understand why we should make apps depend on 1.8 if they didnt in gutsy [18:39] i don't care about gutsy. i'm talking about merges on mom/dad for hardy [18:40] it was in the list with other even more obscure stuff, so why not ? [18:41] at least, i'm familiar with that beast so it made sense [18:45] did we talk about moving xul to main? [18:45] i don't remember [18:45] for sure, not 1.8 [18:45] right [18:45] 1.9, maybe, could be interesting [18:45] well when ffox3.0 is released we have to move it to main afaik [18:46] i dont think main apps depend on universe but that might have changed since universe is enabled by default [18:47] but xul still maybe not needed but wanted [18:49] everything in main _must_ be xul 1.9 for hardy [18:49] otherwise it will get demoted [18:49] python mozembed is ready ... just the xul classifier issue [18:49] but that is a xul issue [18:50] epiphany will take a bit though [18:50] asac: thats what i thought so shouldnt we move it to main [18:50] (as i said) [18:50] gnomefreak: yes ... I will write a MIR as soon as we have beta and fixed the url-classifier issue [18:50] if epiphany or ff3.0 are releasedd [18:51] i think epiphany is in main [18:51] !info epiphany [18:51] epiphany: clone of Boulder Dash game. In component universe, is optional. Version 0.5.1-4 (gutsy), package size 63 kB, installed size 236 kB [18:51] yes ... yelp + devhelp + epiphany + gnome-mozembed [18:51] !info epiphany-browser [18:51] epiphany-browser: Intuitive GNOME web browser. In component main, is optional. Version 2.20.1-0ubuntu1 (gutsy), package size 3527 kB, installed size 14412 kB [18:51] those 4 should cover a good amount of main stuff we need to port [18:51] thats right yelp does need it [18:51] epiphany is probably the most tricky one [18:52] depends when upstream releases it if they can [18:52] gnome-mozembed = python-gtkmozembed [18:52] well linda isnt doing anything but checked lintian and its good [18:53] let it work for 5 more minutes than if nothing ill kill it and upload to revu for you to grab, will push to branch if linda is good if it runs on revu [18:54] * gnomefreak glad sunbird is no longer an issue TBH [18:54] brb [18:58] gnomefreak: ok ... if you have an orig it might be fine :) [19:00] i do ;) im running it in chroot ;) [19:00] will run it on gutsy partition whne i get that far [19:01] i gave up gwget todday [19:13] if i find time later im gonna work on bugs since my packages will be done for now [19:14] * gnomefreak might play catch up on sm2 since i have older version installed [19:18] ok out getting drunk :) ... german beeerr \O/ [19:18] i hate american beer [19:18] its the worst i ever had [19:21] have fun ;) [19:50] Ubulette: are you moving seamonkey to nobinonly for hardy? [19:50] we cant add it to gutsy afaik since its not security [19:54] 1 or 2 ? [19:55] Ubulette: either for hardy [19:55] * gnomefreak thinks it a "must" for all moz apps [19:55] i did coth [19:55] both [19:55] have a look at my ppa [19:56] https://edge.launchpad.net/~fta/+archive [19:56] mozclient is now producing nobinonly tarballs only [19:57] and for sm1, i've added a rule to create the nobinonly tarball from the upstream one [19:57] ah ok [19:57] no need to tar by yourself anymore [19:57] that makes life easy [19:57] indeed [19:58] needs to pull mozclient to see what apps are in there sometime after push is done [19:58] i just hate to do the samething twice, so i script everything [20:03] i agree [20:07] anyway to add sunbird and sm 1.1.x to mozclient? [20:07]