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