On 14.12.2010 17:07, Martin Pitt wrote:
>> did I say that?
>
> You didn't; as you didn't explain what the solution _is_, I was trying
> to infer it from the diff.
citation out of context. there are three questions, not just the last
one.
>> the changelog is quiet explicit about the changes.
>
> The changelog doesn't attribute any particular change entry with this
> bug, and most changes apply to the pycompile program, and the changelog
> doesn't specify which part of it (function name or so), it's also hard
> to say. It seems to me that the entire second block in the changelog are
> extra changes which are unrelated to this bug.
fine. I'll retitle the bug.
> This would go a lot faster if this update would actually follow the SRU
> procedure..
All changes are appropriate for a SRU, and were made in natty before filing
this
issue. And I think it is not appropriate to insist on untested
dependency/breaks changes, which I did tell you were no solution, and delay the
fix for real issues, and which did cause new issues in natty.
> The changes to public_modules.rtinstall and public_modules.rt remove
> seem irrelevant for this SRU, as we don't support 2.4/2.5 in maverick,
> right?
please re-read the patch and the changelog:
* Don't touch the standard python library in rtupdate scripts.
even maverick has a site directory.
the change for the particular upgrade problem is
* pycompile:
- if installed Python is requested via -V option, use it even if
it's not in a list of supported Python versions
Yes, having this fix in maverick doesn't solve the upgrade problem for
installations with disabled -updates, but it will avoid us tons of bug reports
for installations with enabled -updates.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/689615
Title:
pycompile fixes needed for maverick
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
