libgcc_s breakage Re: Bug#949187: transition: python3.8
Matthias Klose wrote: On 2/3/20 8:22 PM, Simon McVittie wrote: >> Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s (I've just opened the bug for that, so no bug number known yet), which is going to limit the ability to get things into testing. please retry your package builds. it's fixed in unstable. Do you mean #950525? If so, you might need to wait a few hours because the fix (gcc-9 9.2.1-28) is still being built. When it is ready, please retry pandas and statsmodels in experimental. (DMs can't do self-service give-backs.)
Re: Bug#949187: transition: python3.8
On 2/3/20 8:22 PM, Simon McVittie wrote: > On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: >> I think this is now in shape to be started. > > Please can this wait until the remaining bits of the libffi7 transition > and the restructuring of the libgcc_s packaging have settled down? > > I'm still trying to sort out the missing Breaks around > gobject-introspection, as highlighted by autopkgtest failures: this has > been delayed by needing coordinated action between multiple packages, > some of them quite big (glib2.0), and by Paul and I being at FOSDEM. > This is entangled with python3.8 via pygobject (which will fail tests > with python3.8 as default - an upload is pending to fix that). fine. I'm happy to see that fixed. > Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s > (I've just opened the bug for that, so no bug number known yet), which is > going to limit the ability to get things into testing. please retry your package builds. it's fixed in unstable.
Re: Bug#949187: transition: python3.8
On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: > I think this is now in shape to be started. Please can this wait until the remaining bits of the libffi7 transition and the restructuring of the libgcc_s packaging have settled down? I'm still trying to sort out the missing Breaks around gobject-introspection, as highlighted by autopkgtest failures: this has been delayed by needing coordinated action between multiple packages, some of them quite big (glib2.0), and by Paul and I being at FOSDEM. This is entangled with python3.8 via pygobject (which will fail tests with python3.8 as default - an upload is pending to fix that). Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s (I've just opened the bug for that, so no bug number known yet), which is going to limit the ability to get things into testing. Thanks, smcv
RE:application and private module extension
Indded sorry for the noise Fredric
Re: application and private module extension
On Mon, Feb 03, 2020 at 02:32:22PM +, PICCA Frederic-Emmanuel wrote: > Hello, > > I am packaging a python application . So I dediced to put the module under > the private directory > > /usr/share/ > > but this software contain a cython extension. > > So at the end I have a lintian Error due to binary file under /usr/share. > > What is the best soltuion when we need to package a softare with this kind of > extension. /usr/lib of course. See also https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs -- WBR, wRAR signature.asc Description: PGP signature
application and private module extension
Hello, I am packaging a python application . So I dediced to put the module under the private directory /usr/share/ but this software contain a cython extension. So at the end I have a lintian Error due to binary file under /usr/share. What is the best soltuion when we need to package a softare with this kind of extension. thanks for your time Frederic
