On Tue, May 21, 2013 at 05:55:58PM +0200, Matthias Klose wrote:
> >> | dpkg -L | grep \.py$ | while read file | do | echo "${file}"
> >> >> /var/lib/python/pyX.Ycompile.todo | echo "${file}" >>
> >> /var/lib/python/pyX.Zcompile.todo | done
> > The disadvantage is that the more logic is inclu
* Matthias Klose , 2013-05-21, 17:55:
namespace packages aren't an issue anymore in python3, and for python2
it would be better to ship these files into separate binary packages.
these aren't that many, and it would be much better for the robustness.
nothing to do anymore about these in maintai
* Matthias Klose , 2013-05-21, 17:55:
The dependency of python2.7-minimal on libpython2.7-minimal looks safe
to me,
At least in theory, it's not safe. If python2.7-minimal is unpacked, but
libpython2.7-minimal is not (yet) unpacked, then all pyclean can do is:
Could not find platform indepen
Am 13.05.2013 19:21, schrieb Steve Langasek:
> On Sat, May 11, 2013 at 12:29:07AM +0200, Piotr Ożarowski wrote:
>> [Jakub Wilk, 2013-05-10]
>>> postinst
>> [...]
>>> Proposed solution: 1) Wait until #671711 is fixed. 3) Make pycompile a
>>> shell script that does only two simple things: -
* Jakub Wilk , 2013-05-10, 00:41:
prerm
=
[...]
Real-world failure: #706758
Also #708831.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013
* Steve Langasek , 2013-05-13, 12:21:
why not generate maintainer scripts without pycompile at all? I wanted
to delegate as much as possible to interpreter packages, but your idea
with temp. files is even better - maintainer scripts can look like this:
| touch /usr/lib/pythonX.Y/dist-packages
* Jakub Wilk , 2013-05-10, 00:41:
postinst
[...]
Test-case (in a squeeze chroot, with wheezy added to sources.lists):
# dpkg --unpack cpuset_1.5.6-2_all.deb
# apt-get install -t squeeze python2.6
# apt-get install -t wheezy python gcc-4.4
# dpkg --force-depends -r libssl0.9.8
# dpkg -i
On Sat, May 11, 2013 at 12:29:07AM +0200, Piotr Ożarowski wrote:
> [Jakub Wilk, 2013-05-10]
> > postinst
> >
> [...]
> > Proposed solution:
> > 1) Wait until #671711 is fixed.
> > 3) Make pycompile a shell script that does only two simple things:
> > - write options it was called with to a
[Jakub Wilk, 2013-05-12]
> * Piotr Ożarowski , 2013-05-11, 00:29:
> >why not generate maintainer scripts without pycompile at all?
>
> - There are hundreds of packages that use py{compile,clean} in the
> maintainer script. The script needs to continue to exist at least
> until jessie is released.
* PICCA Frédéric-Emmanuel ,
2013-05-12, 08:22:
prerm
=
...
Real-world failure: #706758
should I reassign this bug to python ?
I think so. (But maybe there's flaw a in my reasoning. Please shout you
if this is the case. :P)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ
* Piotr Ożarowski , 2013-05-11, 00:29:
postinst
[...]
Proposed solution:
1) Wait until #671711 is fixed.
3) Make pycompile a shell script that does only two simple things:
- write options it was called with to a file, say,
/var/lib/python/pyX.Ycompile.todo;
- use dpkg-trigger to trig
Hello Jackub
> prerm
> =
> ...
> Real-world failure: #706758
should I reassign this bug to python ?
If I understand well, all this, python should be fixed then a rebuild of all
python packages should be done.
right ?
which bug of python should I track to know when a rebuild of the packag
[Piotr Ożarowski, 2013-05-11]
> | dpkg -L | grep \.py$ | while read file
> | do
> | echo "${file}" >> /var/lib/python/pyX.Ycompile.todo
> | echo "${file}" >> /var/lib/python/pyX.Zcompile.todo
> | done
with some "grep .../pythonX.Y/dist-packages" of course
--
Piotr Ożarowski
[Jakub Wilk, 2013-05-10]
> postinst
>
[...]
> Proposed solution:
> 1) Wait until #671711 is fixed.
> 3) Make pycompile a shell script that does only two simple things:
> - write options it was called with to a file, say,
> /var/lib/python/pyX.Ycompile.todo;
> - use dpkg-trigger to trigger
Maintainer scripts generated by our Python helper assume more about
consistency of installed packages that dpkg can actually guarantee. This
leads to upgrade failures in some scenarios (not only purely
theoretical, but also observed by piuparts, and by our users). Here's my
analysis what is wro
15 matches
Mail list logo
