[00:46] <mdeslaur> Unit193: sure we can, ask chad to do it, or file a bug perhaps
[00:56] <Unit193> Alrighty, got a recommended room or PM OK?
[00:58] <mdeslaur> Unit193: he's "qengho"...perhaps in #ubuntu-devel?
[00:59] <Unit193> mdeslaur: OK, saw on LP, thanks.
[01:02] <Unit193> Hopefully that's good. :)
[08:17] <dholbach> good morning
[14:24] <ngaio> Can someone please tell me what the deadline is for a package in Debian testing to be automatically included in Ubuntu Universe? Is it the date of the feature freeze?
[14:27] <Zhenech> https://wiki.ubuntu.com/DebianImportFreeze
[14:27] <Zhenech> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule - 16th feb
[14:28] <ogra_> you will always be able to request a sync though ... it just wont happen automatically after that freeze
[14:30] <ngaio> Oh okay thanks! I have a package in Debian and I finally managed to fix an important bug and I want to be sure the fix will make it into trusty
[14:31] <ngaio> I mean to say, I am the developer of an application which is packaged by someone else in Debian
[14:32] <cjwatson> testing doesn't matter anyway
[14:32] <cjwatson> we sync from unstable
[14:33] <ngaio> I'll request the packager if he can have it into unstable before the 16th, thanks again!
[15:03] <michagogo|cloud> 16:32:13 <cjwatson> we sync from unstable
[15:04] <michagogo|cloud> Why is that?
[15:06] <michagogo|cloud> I mean, why pull packages that are labelled unstable and updatable, and freeze that version, setting it in stone as part of the release?
[15:06] <cjwatson> because that's not what unstable means.
[15:07] <cjwatson> it basically just means "changing".  but so is testing - just at a slower rate and the extra gating there doesn't really help us because we do our own very similar version of the unstable->testing process.
[15:08] <cjwatson> we tried syncing from testing and a large part of the effect was simply that it was more cumbersome and slower to get bug-fixes.
[15:09] <cjwatson> and some of the benefits of testing in Debian didn't actually end up helping us because of effects caused by rebuilding.
[15:09] <cjwatson> I am very supportive of Debian testing, but I also know exactly what that process consists of and how it does/doesn't help Ubuntu
[15:10] <cjwatson> packages that are fundamentally not in a state that might be releaseable in practice normally go into experimental, not unstable
[18:03] <michagogo|cloud> cjwatson: I wonder if it would be
[18:03] <michagogo|cloud> Er
[18:03] <michagogo|cloud> Meant to hit backspace, not enter
[18:04] <michagogo|cloud> I wonder if it would make sense to only auto-pull from unstable if an older version of the package exists in stable or testing
[18:05] <cjwatson> I don't think so.  New packages rarely do much harm.  (I realise that you care about a particular exception or two, but those are definitely the exception and not the rule.)
[18:06] <cjwatson> The vast bulk of new packages are things like new libraries needed for other things to build.  Holding them back until they reach testing would be cumbersome for very little gain.
[18:06] <michagogo|cloud> I know that some packages, e.g. Bitcoin, are unstable-only in Debian because it is/can be important to keep them updated
[18:06] <cjwatson> And those we can handle as exceptions.
[18:06] <cjwatson> It doesn't make sense to change the general rule for those very few cases.
[18:07] <michagogo|cloud> New libraries that are only in unstable that things that are in testing or stable need to build?
[18:07] <cjwatson> Varies.
[18:07] <cjwatson> And it doesn't make sense to introduce extra multi-day delays when it doesn't buy us much.
[18:08] <cjwatson> Honestly, we've gone over this a lot.
[18:08] <cjwatson> bitcoind was an anomalous and unusual case, not representative.
[18:08] <michagogo|cloud> Also, I haven't been able to find an answer to te question of what needs to be done to propose an update to the bitcoin packages that essentially disables them
[18:09] <cjwatson> I guess I don't understand how to answer that question without restating it.
[18:10] <michagogo|cloud> One thing that someone mentioned as a solution for the problem of the ancient versions being shipped in older releases was the possibility of an SRU (I think) that would essentially remove the functionality of the software
[18:11] <michagogo|cloud> Making it inert
[18:11] <cjwatson> Indeed.  But I don't understand what clarification to that might be useful to you.
[18:11] <michagogo|cloud> What form such an upgrade might take
[18:12] <michagogo|cloud> What the change would consist of
[18:12] <cjwatson> Wouldn't it basically delete the substantive package contents and insert some documentation of why the package was removed and what its users should do instead?
[18:12] <michagogo|cloud> That's my question.
[18:12] <cjwatson> s/removed/disabled/
[18:12] <cjwatson> Well, that's the best answer I can give.
[18:12] <cjwatson> (Without actually doing the work.)
[18:13] <michagogo|cloud> Do you know of any precedent, something that I could look at as a reference?
[18:13] <cjwatson> owncloud was the last example I can think of that called for something similar, although I don't remember whether the disablement was actually executed.
[18:14] <michagogo|cloud> Where would I find the relevant discussion?
[18:14] <cjwatson> https://launchpad.net/ubuntu/+source/owncloud/1.1+git20110209-0ubuntu1.1 looks promising.
[18:34] <teward> Is it safe for me to make the assertion that the version of PCRE in Precise is not going to be updated, and therefore I can mark this nginx bug as "Won't Fix" in precise because the required PRCE libraries aren't going to be updated to 8.20 or greater?
[18:34] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/915344
[18:35] <teward> related pcre bug: https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/909109  (fixed in quantal and later)