Multiarch-renamed python extensions not found during autopkgtest testing
Hi, debian-python, For Debian Med's python packages that have compiled extensions, I noticed that test suites run via autopkgtest fail because the package cannot find those extensions, as they've been renamed with the multiarch triplet. It seems to only be a problem with autopkgtest because I have in one case manually installed such a package and successfully ran its test suite. I therefore reported #798066 [1] against autopkgtest, but quite some time has elapsed since then and I'd like to get this resolved. Does anyone know why this might be the case? Autopkgtest for these packages is currently not very helpful because there are many spurious failures due to this issue. There are more details in my original bug report [1]. Many thanks and regards Afif 1. http://bugs.debian.org/798066 -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Rebuild for packages with entry points?
Nikolaus Rath writes: > Would it make sense to do a no-change rebuild for all Python packages > that use setuptool's entry point functionality? Not that I even pretent to understand what this bug is about. Why are tests even using these wrappers? They aren't intended to be imported. However this isn't automatically going to fix all packages. There are some packages (e.g. python-django-common provides django-admin) that replace the wrapper with a Debian specific copy of the file that can automatically choose the Python2.7 or Python3 interpreter as required. This particular example is not a good one, django-admin looks like it is already fine. celery does something similar, and it looks fine to. So rebuilding these packages won't do anything, because they are already OK. My point being however that just rebuilding the package is not a guarantee that this problem will be solved. -- Brian May
Re: Rebuild for packages with entry points?
On 08/12/15 16:50, Nikolaus Rath wrote: > On Dec 07 2015, Simon McVittie wrote: >> This looks like a job for Lintian, assuming setuptools entry points are >> easy to detect with a regex. > > Well, yes, but what's the point? New uploads will not be affected by > this bug anyway, and if you just want the warnings for old packages, > wouldn't the time consumed by writing a Lintian check be better spent > writing a script that triggers rebuilds directly? If you already know a complete set of packages that have entry points, sure, rebuild away. For binNMUs of arch:any packages the thing to do is to ask the release team; for arch:all packages, it needs to be done as individual sourceful uploads, unfortunately. If you don't already know a complete set of affected packages, a Lintian check + a bit of waiting would tell you, with progress tracking. I've found that very useful for various issues with dbus policy files. S
Re: Rebuild for packages with entry points?
On Dec 08 2015, Barry Warsaw wrote: > On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote: > >>Aeh, you know about a bug and you want to delay fixing it until someone >>has reporeds it for every affected package? This seems like a pretty >>inconsiderate waste of time for both users and maintainers. > > There are always lots of bugs that affect people. True - but I have to admit that I don't get the connection to what we (or at least I) were discussing until now..? > But hey, don't let me stop you if you want to fix this particular one. Well, my proposal is to just do a mass rebuild. It will be redundant for a lot of packages, but computer time is much cheaper than developer time (which would be required for Lintian checks, or writing, reacting to, and closing per-package bugreports). However, I don't know how to trigger such a rebuild, and I think if I knew it I'd still be unable to actually do it because I'm only a DM. Thus my mail to this list :-). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Rebuild for packages with entry points?
On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote: >Aeh, you know about a bug and you want to delay fixing it until someone >has reporeds it for every affected package? This seems like a pretty >inconsiderate waste of time for both users and maintainers. There are always lots of bugs that affect people. But hey, don't let me stop you if you want to fix this particular one. Cheers, -Barry
Re: Rebuild for packages with entry points?
On Dec 07 2015, Simon McVittie wrote: > On 07/12/15 19:00, Barry Warsaw wrote: >> On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote: >>> It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/ >>> fixed in stretch. >> >> I'm also not sure how many packages it affects in practice. We could also >> let >> rebuilds be bug-driven. > > This looks like a job for Lintian, assuming setuptools entry points are > easy to detect with a regex. Well, yes, but what's the point? New uploads will not be affected by this bug anyway, and if you just want the warnings for old packages, wouldn't the time consumed by writing a Lintian check be better spent writing a script that triggers rebuilds directly? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Rebuild for packages with entry points?
On Dec 07 2015, Barry Warsaw wrote: > On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote: > >>Would it make sense to do a no-change rebuild for all Python packages >>that use setuptool's entry point functionality? >> >>It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/ >>fixed in stretch. I believe most packages will see new releases anyway >>(and thus get the change), but I believe there are at least some >>packages that are rarely touched... > > I'm also not sure how many packages it affects in practice. We could also let > rebuilds be bug-driven. Aeh, you know about a bug and you want to delay fixing it until someone has reporeds it for every affected package? This seems like a pretty inconsiderate waste of time for both users and maintainers. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Joining DPMT / PAPT
Hello! I've been working on packaging and maintaining Checkbox [1] packages. I would like to join the Debian Python Modules Team and the Python Applications Packaging Team in order to maintain the Checkbox-related packages on Debian. My Alioth login is pierre-equoy-guest. I have read and accept the policy if this team: https://python-modules.alioth.debian.org/policy.html Regards, [1]: https://launchpad.net/checkbox -- Pierre Equoy QA & Certification Engineer | Canonical www.canonical.com | www.ubuntu.com
