/srv/irclogs.ubuntu.com/2014/01/20/#ubuntu-motu.txt

mdeslaurUnit193: sure we can, ask chad to do it, or file a bug perhaps00:46
Unit193Alrighty, got a recommended room or PM OK?00:56
mdeslaurUnit193: he's "qengho"...perhaps in #ubuntu-devel?00:58
Unit193mdeslaur: OK, saw on LP, thanks.00:59
Unit193Hopefully that's good. :)01:02
dholbachgood morning08:17
=== jpds_ is now known as jpds
ngaioCan 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:24
Zhenechhttps://wiki.ubuntu.com/DebianImportFreeze14:27
Zhenechhttps://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule - 16th feb14:27
ogra_you will always be able to request a sync though ... it just wont happen automatically after that freeze14:28
ngaioOh 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 trusty14:30
ngaioI mean to say, I am the developer of an application which is packaged by someone else in Debian14:31
cjwatsontesting doesn't matter anyway14:32
cjwatsonwe sync from unstable14:32
ngaioI'll request the packager if he can have it into unstable before the 16th, thanks again!14:33
=== freeflying is now known as freeflying_away
michagogo|cloud16:32:13 <cjwatson> we sync from unstable15:03
michagogo|cloudWhy is that?15:04
michagogo|cloudI 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
cjwatsonbecause that's not what unstable means.15:06
cjwatsonit 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:07
cjwatsonwe 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:08
cjwatsonand some of the benefits of testing in Debian didn't actually end up helping us because of effects caused by rebuilding.15:09
cjwatsonI am very supportive of Debian testing, but I also know exactly what that process consists of and how it does/doesn't help Ubuntu15:09
cjwatsonpackages that are fundamentally not in a state that might be releaseable in practice normally go into experimental, not unstable15:10
michagogo|cloudcjwatson: I wonder if it would be18:03
michagogo|cloudEr18:03
michagogo|cloudMeant to hit backspace, not enter18:03
michagogo|cloudI wonder if it would make sense to only auto-pull from unstable if an older version of the package exists in stable or testing18:04
cjwatsonI 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:05
cjwatsonThe 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|cloudI know that some packages, e.g. Bitcoin, are unstable-only in Debian because it is/can be important to keep them updated18:06
cjwatsonAnd those we can handle as exceptions.18:06
cjwatsonIt doesn't make sense to change the general rule for those very few cases.18:06
michagogo|cloudNew libraries that are only in unstable that things that are in testing or stable need to build?18:07
cjwatsonVaries.18:07
cjwatsonAnd it doesn't make sense to introduce extra multi-day delays when it doesn't buy us much.18:07
cjwatsonHonestly, we've gone over this a lot.18:08
cjwatsonbitcoind was an anomalous and unusual case, not representative.18:08
michagogo|cloudAlso, 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 them18:08
cjwatsonI guess I don't understand how to answer that question without restating it.18:09
michagogo|cloudOne 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 software18:10
michagogo|cloudMaking it inert18:11
cjwatsonIndeed.  But I don't understand what clarification to that might be useful to you.18:11
michagogo|cloudWhat form such an upgrade might take18:11
michagogo|cloudWhat the change would consist of18:12
cjwatsonWouldn'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|cloudThat's my question.18:12
cjwatsons/removed/disabled/18:12
cjwatsonWell, that's the best answer I can give.18:12
cjwatson(Without actually doing the work.)18:12
michagogo|cloudDo you know of any precedent, something that I could look at as a reference?18:13
cjwatsonowncloud 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:13
michagogo|cloudWhere would I find the relevant discussion?18:14
cjwatsonhttps://launchpad.net/ubuntu/+source/owncloud/1.1+git20110209-0ubuntu1.1 looks promising.18:14
tewardIs 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
tewardhttps://bugs.launchpad.net/ubuntu/+source/nginx/+bug/91534418:34
ubottuUbuntu bug 915344 in nginx (Ubuntu) "enable PCRE JIT support in nginx 1.1 on precise" [Wishlist,Fix released]18:34
tewardrelated pcre bug: https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/909109  (fixed in quantal and later)18:35
ubottuUbuntu bug 909109 in pcre3 (Ubuntu) "upgrade to >= 8.20, enable JIT support" [Wishlist,Fix released]18:35
=== freeflying_away is now known as freeflying

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!