[00:34] <infinity> slangasek: Erm, dkms doesn't depend on headers anymore.
[00:34] <slangasek> infinity: not dkms itself, the dkms packages
[00:34] <slangasek> i.e., the modules
[00:35] <slangasek> (I found this out because I had fwts installed)
[00:35] <infinity> slangasek: Oh.  Well, that's a case-by-case thing, I suppose.  I know I asked tseliot to fix that for all the ones he maintains.  Not sure how many were done.
[01:08] <knome> what's the situation with 13.04? are we releasing?
[01:17] <ScottK> Apparently.
[01:17] <ScottK> http://blogs.kde.org/2013/03/05/1304-go-ahead
[01:27] <cjwatson> Which session was that?
[01:44] <ScottK> No idea.
[01:44]  * ScottK was offline ~all of today.
[01:46] <slangasek> well, I'm pretty sure he's referring to the first "rolling release" session, but I don't think there was actually a consensus that we will go ahead with 13.04
[01:46] <slangasek> there was a consensus that, while things were being discussed, we shouldn't go off the rails with the release schedule
[01:47] <ScottK> So feature freeze on Thursday in any case.
[01:47] <ScottK> Riddell: ^^^?
[01:48] <Riddell> that's my understanding
[10:05] <xnox> I assume Riddell is misquoting.
[10:06] <Riddell> xnox: my blog on 13.04?  there's no quote in it.  there's my understanding of the consensus based on nobody saying we should stop 13.04 and everyone except rick saying we should go ahead with it
[10:07] <Riddell> xnox: planning on doing an ubiquity upload before FF?
[10:07] <seb128> Riddell, some people expressed concerns about the maintenance cost of making the release though
[10:10] <xnox> Riddell: one can believe whatever one hears. In that session there was an interesting use case proposed by System76 and we spend a lot of time pondering as to how that can be addressed.
[10:11] <xnox> Riddell: I personally would want to start bypassing quantal for SRUs, but not security and have rolling rolling out quicker.
[10:12] <xnox> Riddell: but I can see how cutting quantal short would go against what we previously promised.
[10:12] <seb128> +1 on stopping SRUs on !LTS
[10:12] <seb128> xnox, raring you mean?
[10:12] <Laney> raring?
[10:13]  * xnox re-reads my statement, and xnox believes it is typed correctly. "rolling" (as in rolling release, noun) "rolling out" (verb)
[10:14] <infinity> xnox: There would be no "cutting short".  Even if everyone+dog agrees rolling is the way to go and, further, agrees that 13.04 shouldn't happen, quantal will still be supported.  We committed to that.
[10:15] <infinity> xnox: Furthermore, if 13.04 didn't happen, quantal would probably be supported for a bit longer than we'd promised to give proper upgrade overlap to 14.04.
[10:15] <seb128> infinity, I think xnox meant "raring" when he wrote "quantal"
[10:15] <seb128> xnox, ^?
[10:15] <infinity> seb128: I don't think he did.
[10:16] <seb128> "to start bypassing quantal for SRUs" doesn't make sense
[10:16] <seb128> we usually don't both to SRU to stable-1 anyway
[10:16] <seb128> quantal SRUs already started to slow down
[10:16] <seb128> so that wouldn't be a change
[10:16] <infinity> It makes sense to someone who's uploaded a fair few Q SRUs, and xnox has. ;)
[10:16] <xnox> seb128: currently to SRU something to precise, I should be SRUing into quantal as well.
[10:16] <infinity> xnox: No, that's patently untrue.
[10:16] <infinity> xnox: You don't need to SRU to every release.
[10:16] <seb128> xnox, in theory, in practice...
[10:16] <infinity> xnox: And I actively discourage it.  It makes validation a nightmare.
[10:17] <xnox> infinity: seb128: hence "should", not "must" ;-)
[10:17] <seb128> infinity, well, if you want to ensure that precise->quantal updates have no regression, you do need to SRU to quantal
[10:17] <infinity> xnox: For critical bugs, yes, fixing them in all releases so upgrades don't see a nasty regression, that's valid.
[10:17] <infinity> seb128: Depends on the regression.  We have alot of "polish" SRUs in precise, often even for fairly cosmetic bugs.
[10:18] <xnox> infinity: "latvian" as well ;-)
[10:18] <infinity> seb128: If those cosmetic bugs reappear on an upgrade to Q (but go away in later releases), I'm not sure I deeply care.
[10:18] <infinity> xnox: Wrong reading of "polish". :P
[10:20] <xnox> My view is that we can make 12.04.3 better than 12.10. Imho precise is already better than 12.10.
[10:20] <xnox> If we identify small core packages to aggressively SRU, e.g. new unity sans indicators.
[10:20] <infinity> xnox: precise has always been better than 12.10.
[10:21] <infinity> xnox: But pushing new upstream versions to precise won't keep that situation true. :P
[10:22] <xnox> infinity: when did you join UK Conservative party?! =))))) *kidding* I see your point, it's a slippery slope. Can we pull off a unity-lts-quantal?
[10:23] <infinity> xnox: Why?
[10:23] <infinity> xnox: And no, we can't.  Not without serious abuse of unity.
[10:23] <xnox> it's the last compiz based unity, the most stable one and the one we can support for the next 4 years.
[10:23] <xnox> i don't think we will push mir/unity-next into precise.
[10:24] <infinity> I'm really confused.  Why do you want ANY new unity in precise?
[10:24] <infinity> Does the current one offend you somehow?
[10:24] <infinity> The one that's in precise is perfectly supportable.
[10:24] <infinity> The one in quantal requires many new APIs and other such things.
[10:24] <infinity> And doesn't include unity-2d.
[10:24] <xnox> infinity: it offends System76. Watch the video from the rolling release session from yesterday. They shipped 70/30 quantal/precise on the (pro)consumer laptops/desktops.
[10:25] <xnox> and conclude that they like 6-montly releases as they are always faster/better.
[10:25] <infinity> Did they give reasons?
[10:25] <infinity> I mean, real reasons?
[10:25] <seb128> infinity, did you listen to the rolling release discussion yesterday? the system76 guys says most their users want the new features/version
[10:25] <infinity> Not "we like this more" reasons.
[10:25] <seb128> yeah, performances are better
[10:25] <seb128> and it has nice features
[10:25] <seb128> better look
[10:25] <xnox> infinity: performance & stability from UX.
[10:26] <infinity> Well, performance and stability can probably be identifiable cherry-picks.
[10:26] <xnox> infinity: on the other hand their server offering had a scew towards lts, as one would expect.
[10:26] <infinity> Backporting it wholesale breaks various worlds.
[10:26] <infinity> xnox: "skew".
[10:26]  * xnox almost typped screw, so I almost got it right ;-))))))
[10:28] <infinity> I dunno.  I get their point (and I should watch the video), but "enthusiast desktop users always want the latest thing" isn't really news.
[10:29] <infinity> And if that latest thing didn't exist in that form, they'd either use the LTS, or become crazy bleeding edge dev/rolling users.
[10:29] <infinity> And if you can argue that people ordering from system76 are anything other than enthusiasts, I'd be curious to hear your arguments.
[10:30] <infinity> Given that almost no one knows who they are, unless you're part of a few small Linux communities.
[10:31] <infinity> I guess what I'm saying is that their numbers don't prove that quantal is, in itself, desirable, just that enthusiast users like bigger version numbers.
[10:32] <xnox> infinity: sure, but for example I was considering system76 machines as a present to my close friends and relatives. And I don't consider them enthusiasts. I keep their machines on non-lts, although I might go vorlon-style and keep them on lts from now on.
[10:32] <infinity> xnox: Yeah, see, that would be *you* making that choice, not *them*.
[10:33] <infinity> xnox: You said "I keep their...", not that they do. :P
[10:33] <xnox> infinity: speaking of version numbers, if we go with rolling/2y release cycles next version should be just simply "14"
[10:33] <xnox> infinity: touche.
[10:34] <infinity> xnox: Yeah, I could be down with an odd/even unstable/stable version scheme or something if we swap to a 2y cadence.  Call raring "13" in development, and "14" leading up to release.
[10:34] <xnox> infinity: yeah, canonical offices have enough of awards for the "Excellent Ubuntu 7.6 release"
[10:34] <infinity> Though, maybe not.  Twiddling versions may confuse the world, since everyone likes to key on them.
[10:35] <infinity> So, we could just skip version numbers. :P
[10:35] <infinity> xnox: You mean 6.6?
[10:35] <xnox> infinity: not release at all - ever =))))))
[10:35] <xnox> infinity: nope, the award was exactly for the "7.6" award. Our yy.m version numbering scheme is hard for users & media to comprehend.
[10:36] <infinity> xnox: Erm, but we had no 7.6.  Just 7.4 and 7.10
[10:36] <xnox> (s/award\./release./)
[10:36] <infinity> xnox: We did, however, have a 6.6
[10:36] <xnox> infinity: exactly. We got an award for a release that never was =)
[10:36] <xnox> version numbers are hard ;-)
[10:41] <cjwatson> so, I wouldn't support interface changes; but when people say "13.04 is so much smoother to use" [i.e. perf] then that's something we can and should fix, I'd have thought
[10:42] <infinity> cjwatson: Right.  It's decoupling those things.
[10:42] <infinity> cjwatson: If they can backport performance fixes without completely upending unity-2d, indicators, gsettings, etc, etc, sure.
[10:43] <cjwatson> (and I'm fairly sure I've heard that from sources other than system76 too)
[10:43] <infinity> I wasn't arguing that the new unity isn't faster and smoother (it is, I use it).
[10:43] <infinity> I was arguing that their numbers don't actually support that.
[10:43] <cjwatson> Sure, I wasn't actually going off the numbers :)
[10:44] <infinity> Users aren't chosing quantal because the new unity is faster, they're chosing it because it's the bigger version number, and that's what that class of user does.
[10:44] <didrocks> cjwatson: infinity: we already backported all "safe" performances fixes
[10:44] <infinity> The numbers would skew that way if quantal's unity was pink and yelled expletives at them when they logged in.
[10:44] <cjwatson> didrocks: ah :-/
[10:44] <didrocks> took a lot of time, but we did that
[10:44] <didrocks> the remaining ones are minor and more risky
[10:45] <didrocks> I feel it's more a question of perception than real numbers (that we don't have :/)
[10:45] <infinity> didrocks: To be fair, I haven't run unity on precise since around release time.  Maybe those backports paid off, and the arguments are moot?
[10:45] <didrocks> infinity: that's my feeling, more a question of either people not upgrading precise or just a biased view
[10:46] <infinity> Right.  So, can we make quantal's unity yell expletives at users when they log in, to see if it changes the bias? :P
[10:46] <infinity> I'd approve that SRU.
[10:46] <infinity> If it was fully translated.
[10:46] <didrocks> infinity: no worry as log as you approve it. I can sync with dpm for translations, I'm sure :)
[10:47] <didrocks> but who pick the words? :p
[10:47] <infinity> Get Colin drunk, he'll give you some fine ones.
[10:47] <didrocks> heh
[10:47] <didrocks> that's a plan! :-)
[10:47] <xnox> didrocks: я тоже могу добавить интересные сообщения =)
[10:48] <didrocks> xnox: at least, that can exercise our UTF8 support :)
[10:48] <xnox> didrocks: note, there are plenty of UK online off-license stores that do delivery to the door.
[10:49] <infinity> didrocks: I was thinking audio, not text, so UTF8 doesn't really factor into it.
[10:49] <didrocks> interesting… :-)
[12:05] <cjwatson> Laney: So, what's the state of the current Haskell transition, were I to want to spend some +1 maint time on unsticking it so that it's easier to see what else is going on in -proposed?
[12:06] <Laney> cjwatson: I synced a bunch of NEW stuff the other day that should have unblocked syncing some of the lower down packages
[12:08] <Laney> I haven't poked into the new armhf failures but it's likely to be at least in part the same bug we had before so possibly worth removing at least some of those
[12:09] <cjwatson> Laney: So the approved current approach is to proceed from the bottom of the stack upwards, and either (a) sync from experimental, if it builds/installs (b) no-change rebuild, if it builds/installs (c) remove armhf/powerpc binaries if necessary?
[12:10] <Laney> right
[12:10] <Laney> I just gave back haskell-monoid-extras which looked like it might have been transient
[12:10] <Laney> (armhf)
[12:11] <Laney> be aware that experimental has been a bit more of a moving target than I'd hoped - it might have shifted since some lower part of the transition was done
[12:21] <Laney> oho, it did build - should knock a chain of depwaits off
[12:21] <cjwatson> I'll leave it a bit and see what happens, then
[12:23] <Laney> that's just armhf; you can look at stuff which is red on all arches
[12:33] <Laney> oh, a small number of packages require upstream changes - you can leave those to me (most upstreams have been made aware already)
[16:18] <Riddell> I'd like to just ignore powerpc for qtwebkit-source and move it to -release, how can I do that?
[16:21] <cjwatson> 'force qtwebkit-source/VERSION' in a file named for you in lp:~ubuntu-release/britney/hints-ubuntu/
[16:22] <cjwatson> Oh, and if you're adding a new file there you need to edit britney.conf in lp:~ubuntu-release/britney/britney2-ubuntu/
[16:29] <infinity> Riddell: Is it actually unportable?  Don't tell me they've joined the long list of people embedding V8 in an unconfigurable way? :/
[16:30] <Riddell> infinity: it should be workable but without a machine to test it on it's very slow to work through
[16:30] <Riddell> even with a machine it's very slow
[16:30] <Riddell> and since we don't care about powerpc...
[16:30] <infinity> Who's we?
[16:33] <infinity> Maybe I'll look at it when I get home.  I turned off my fast build machine before I left. :/
[16:37] <infinity> Actually, looks like it should be simple enough to do blind...
[16:53] <infinity> Riddell: Should be a 1-liner, and you can back out all your other changes.
[16:53] <infinity> Oh, wait.  Maybe not.
[16:54] <infinity> Bah.  Yeah, I'll look at it when I get home on the weekend.
[17:38] <cjwatson> infinity,slangasek: FYI I believe I've reproduced the notorious overrides bug in LP's test suite now
[17:38] <slangasek> \o/
[17:38] <cjwatson> So should be able to debug a fix into place from here
[18:06] <cjwatson> dobey: Sorry, I had intended to release tomboy earlier but never quite got round to it - doing it now
[18:06] <dobey> cjwatson: no worries, it's a hectic time. thanks :)
[18:20] <cjwatson> Now all I have to do is navigate the insane overrides adapter
[18:20] <cjwatson> (s)
[19:45] <cjwatson> infinity,slangasek: http://paste.ubuntu.com/5591314/ first cut at overrides fix but will need some more work.  it at least passes the tests I've tried
[19:46] <cjwatson> logic is simply to add deleted to the list of publishing statuses we consider, on the basis that (a) there won't be many so this doesn't blow up the query too much, (b) any time we need to look up existing overrides and the last publication for the package in question was deleted, we always want to resurrect those overrides by default
[19:47] <cjwatson> (so infinity's hypothesis about the cause of this problem was AFAICT correct)
[19:54] <slangasek> \o/
[23:21] <xnox> omg, shibroken is not so broken!
[23:21] <xnox> barry: infinity: cjwatson: ^^^^^^
[23:22] <barry> xnox: \o/