=== RainCT is now known as RainCT_ [11:44] fta2: hrm? [12:16] hi [12:16] *sigh* ... my 1.8.0 branch tree is gone [12:16] wtf [12:16] asac: \o/ [12:16] what did i do with that? [12:18] ok ... i think i have to accept that its gone :( [12:19] O_o [12:19] asac: do you have any news when flash 10 final comes? otherwise quickly update to RC as we are past FF!? [12:20] sebner: I dont think there will be a problem with a FFe [12:20] sebner: can you try? [12:20] sebner: are you on amd64? [12:20] we have wierd issues with the new pluginwrapper there [12:21] which i wondered whether flash 10 bumps could cure [12:21] asac: sry, i386 only === fta_ is now known as fta [12:51] hm, the FIREFOX_3_1a2_RELEASE in hg didn't work, i got 3.1b1pre [12:52] +tag [12:57] bug in m-d, most probably [13:26] fixed === asac_ is now known as asac === BobChao_ is now known as BobChao [15:21] pfft ... nwo fortify even strikes me on 1.8.0 backports ;) [16:51] asac: did you read what i said about that bugreport? [16:59] https://launchpad.net/bugs/85147 [16:59] Launchpad bug 85147 in libcairo "SVG crashes Mozilla Firefox" [Wishlist,Fix released] [16:59] illl look at that once i have figured something out ;) [17:50] fta: Just reviewing the tutorial now. [17:52] persia, cool. as I said, it's a draft. ideas for improvement are welcome [17:52] I think the ISC and WTFPL are probably safe licenses also, although I don't know if any xul apps use them. [17:53] i don't know of any either [17:56] it's a cut-n-paste tutorial for fennec (at least, it was for 0.3), prism is almost like that now but it's not trivial to generalize to any xulapp. [17:56] How does get-orig-source get constructed? It sounds like there's a bit of a manual process to create the right orig.tar.gz [17:57] right, it's not covered, i need to add a few lines, it's just about adding an include with some vars for mozilla-devscripts' mozclient module [17:59] That makes sense. Something like what the GNOME folk have done? [18:00] like this: http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/src/mozclient/fennec.conf [18:00] based on this: http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/README [18:07] Oh my. [18:07] :) [18:07] Firstly, I think it ought make your life easier if you can get fennec.conf to live in the fennec package, rather than in mozilla-devscripts. [18:08] it's possible, that's even how we do it before we merge it into m-d [18:08] Beyond that, it's a heap of specialisation. I'm sure it makes your life considerably easier, but I wonder if it doesn't make it harder for new people to understand. [18:09] Why have it in m-d then? Wouldn't having it only exist per-package scale better? [18:11] Anyway, I must head to sleep. Thanks for showing me that: it's interesting to see other means of automation. So much of what I do tries to be simple and apply to *every* package that I don't often encounter this sort of thing. [18:12] initially, it was on a .conf file but a .mk with much more magic than get-orig-source, now it could possible to move that .conf back to the package. I need to think about it [18:13] Oh, yeah, having it .mk explains why it needed to be in m-d. [18:15] right. it was supposed to do more magic then it now does [18:15] we could introduce a generic .mk that sources debian/mozclient.conf [18:15] persia, there's still a .mk though, browse http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/files to have an idea [18:16] fta: what purpose do those have? [18:16] arent they mostly for setting default variables (which mostly shoujld live in .conf) [18:16] no, calling other scripts [18:17] well ... most include mozclient.mk [18:17] which the packages could do on their own (if they want to use that) [18:17] and compare.mk [18:17] which the packages could source on their own [18:17] too [18:18] it was just a matter of including 1 m-d file in each package, not several [18:30] yeah ... but since its a 1:1 relation it would provide more flexibility [18:30] but well. [18:30] i dont mind as long as you can also provide the .conf and .mk in package [18:47] http://www.sofaraway.org/ubuntu/tmp/shiretoko.png [21:35] hi ! [23:26] asac, is it still possible to push ff3.1 to universe despite the freeze ? [23:31] depends [23:31] on what ? [23:31] not sure yet ;) [23:32] but probably on support promisses [23:32] i think motu-release has to agree [23:32] and they are probably unhappy about how we updated gutsy ;) [23:32] but maybe not :-D [23:33] fta: lets rephrase: if i were motu-release, I would make it dependent on whether we do support that after release or not ;) [23:34] you mean backports ? [23:36] it is meant to replace ff3 in a few months so i don't see the problem [23:36] where is it ment to replace ff3 in a few month? [23:37] yes, backports [23:37] gutsy hasnt seen many too [23:37] we had nspr/nss issues, then the backporter skipped doing it when hardy was released [23:38] never heard of this issues [23:38] so most likely we will find someone that does that during intrepid+1 cycle, but then when everybody has upgraded to intrepid+1 and demand drops, nobody will care [23:38] fta: of course you had [23:38] refresh me [23:38] thats why we have the system-nss/nspr business [23:38] in rules [23:38] so one can just respin in gutsy [23:38] which ships lower nspr/nss [23:38] same for cairo [23:39] so we should stay at the stone age ? [23:39] stone age? [23:40] we will be in the middle of the dev cycle when we release [23:40] never upgrade because some old stuff will break ? [23:40] he? [23:40] no ... we dont want to introduce branches that nobody cares about [23:40] and that stay unmaintained [23:41] and i dont see where you read "never upgrade because some old stuff will break" [23:41] my question was about 3.1 in or not, now, we are talking about gutsy and the lack of backports [23:41] we are talking about learning from the past ;) [23:41] ffox 3.0 snapshot was shipped in gutsy and is now unmaintained [23:42] put 3.1 snapshot in intrepid and it will be unmaintained just in the same way [23:42] thats all i am saying [23:43] if there is any reason to believe that this will work better, then i certainly want to upload it ;) [23:43] ok then. i will keep doing it in my ppa only, i don't care. [23:47] sorry but that doesn't make any sense. [23:47] ? [23:48] that would mean that we can't use universe at all because we cannot commit on doing the backports forever, it's bullsh*t [23:49] fta: well. we dont need to do them forever, just for whatever period universe is supported [23:49] maybe thats just for 6 month [23:49] maybe its the same timeframe that main is supported ... which is 1.5 years [23:49] and 3 for LTS ... [23:50] actually, what we should ask MOTU is what there support promisses are [23:50] and why motus are not doing that ? [23:50] yep [23:50] if they have none and dont care (in praxis), then i dont see a reason why we should care - except for being nice [23:50] fta: thats the point. they could argue that we bring those packages in, thus we should take of them here [23:51] i really dont know about motu attitude. but debian definitly has the attitude, that whatever package you bring into the archive [23:52] its your obligation to keep it maintained for the period where the release is officially maintained [23:52] i personally cannot commit on that [23:56] reco [23:56] didnt say anything ;) [23:57] how can we get more contributors? [23:57] from motu ;) [23:57] helping us to do backports for instance ;)