Re: Bug#949187: transition: python3.8
On Wed, Feb 05, 2020 at 01:26:31PM +, Simon McVittie wrote: > On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote: > > Thanks, yes, that prevents the install of the "old" > > gobject-introspection with the new python3 from experimental. > > Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That > isn't actually what you need if you want to port to python3.8 Actually, no, I just wanted to prevent it FTBFSing when the default changes and gobject-introspection wasn't yet rebuilt. LibreOffice also only builds dor the default. (With a shitload of hackery it is possible to build pyuno twice/thrice etc. but given there*s a LO part of it this will not be coinstallable, defeating the purpose.) Regards, Rene
Re: Bug#949187: transition: python3.8
On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote: > Thanks, yes, that prevents the install of the "old" > gobject-introspection with the new python3 from experimental. Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That isn't actually what you need if you want to port to python3.8 - it won't support python3.8 until the binNMUs for this transition happen. If you need a python3.8 version of gobject-introspection before then, you could maybe NMU it into experimental? I *think* Build-Depends: python3-dev (>= 3.8) should do what you'd need, but don't necessarily trust my technical judgement right now! smcv
Re: Bug#949187: transition: python3.8
Hi, Am 4. Februar 2020 23:27:13 MEZ schrieb Simon McVittie : >On Tue, 04 Feb 2020 at 21:20:07 +0100, Rene Engelhard wrote: >> root@frodo:/# g-ir-scanner >... >> ModuleNotFoundError: No module named 'giscanner._giscanner' > >This is fixed in 1.62.0-5 (#950267). Thanks, yes, that prevents the install of the "old" gobject-introspection with the new python3 from experimental. Regards, René -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#949187: transition: python3.8
On Tue, 04 Feb 2020 at 21:20:07 +0100, Rene Engelhard wrote: > root@frodo:/# g-ir-scanner ... > ModuleNotFoundError: No module named 'giscanner._giscanner' This is fixed in 1.62.0-5 (#950267). Upload was delayed by FOSDEM, needing a glib2.0 upload to be built first (to have the right Breaks for the libffi7 transition to avoid autopkgtest regressions), and me being unwell. smcv
Re: Bug#949187: transition: python3.8
Hi, On Mon, Feb 03, 2020 at 08:24:50PM +0100, Matthias Klose wrote: > 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. Yeah, gobject-introspection was actually what I meant when I wrote "fontforge". My bad, bad memory in a sid chroot with python 3.8 as default: root@frodo:/# python3 --version Python 3.8.1 root@frodo:/# g-ir-scanner Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in from giscanner.scannermain import scanner_main File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", line 35, in from giscanner.ast import Include, Namespace File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", line 29, in from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", line 33, in from giscanner._giscanner import SourceScanner as CSourceScanner ModuleNotFoundError: No module named 'giscanner._giscanner' and thus stuff building introspection will FTBFS (right now) (Thus I needed to disable it in my testbuild and thus libreoffice (1:6.4.0~beta1-4) experimental; urgency=medium * re-enable introspection which was accidentially kept disabled after a python3.8 test rebuild... * re-enable building of the "test packages" (-smoketest-data, -subsequentcheckbase) -- Rene Engelhard Sun, 15 Dec 2019 10:29:19 + happened.) Regards, Rene
Re: libgcc_s breakage Re: Bug#949187: transition: python3.8
good - I am working as a network technician .very passionate to learn new technologies. every new updates are very interesting to learn.this is the tech place to know about new things Field Services Technician -- Sent from: http://debian.2.n7.nabble.com/debian-python-f2042993.html
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: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 06:12:08PM +0100, Rene Engelhard wrote: > Hi, > > On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > > e.g. fontforge is still red in > > > https://release.debian.org/transitions/html/python3.8.html. > > > > > > That means that a rebuild of stuff using fontforge in the build will > > > just FTBFS since it will be called with python3.8 and that has no module > > > for 3.8 (yet). > > > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > > ago.) > > > > you are wrong. fontforge just builds for the default python version. > > OK, maybe. But that also means that when python3.8 is default and > fontforge isn't yet rebuilt for python3.8-as-default but some package > from my list is rebuilt the same problem happens. OK; inded it seems to just work. Maybe I even misremembered an it was graphite2 and python3-fonttools. (Reused the chroot for multiple tests.) But I *had* a module import failure when I tried some months ago. Regards, Rene
Re: Bug#949187: transition: python3.8
Hi, On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > e.g. fontforge is still red in > > https://release.debian.org/transitions/html/python3.8.html. > > > > That means that a rebuild of stuff using fontforge in the build will > > just FTBFS since it will be called with python3.8 and that has no module > > for 3.8 (yet). > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > ago.) > > you are wrong. fontforge just builds for the default python version. OK, maybe. But that also means that when python3.8 is default and fontforge isn't yet rebuilt for python3.8-as-default but some package from my list is rebuilt the same problem happens. Then fontforge (which is not in the list below!) needs to be rebuilt before https://release.debian.org/transitions/html/python3.8-default.html is worked on. Didn't see it there so wanted to go sure. Regards, Rene
Re: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 05:53:37PM +0100, Rene Engelhard wrote: > On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > > On 17-01-2020 23:28, Matthias Klose wrote: > > >> Please add a transition tracker to switch the python3 default to 3.8. > > >> It's not > > >> yet ready, however it would be good to see affected packages. Please > > >> copy it > > >> from the 3.7 defaults change if possible. > > > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > > > I think this is now in shape to be started. bug reports have been filed for > > I don't think so. > > e.g. fontforge is still red in > https://release.debian.org/transitions/html/python3.8.html. > > That means that a rebuild of stuff using fontforge in the build will > just FTBFS since it will be called with python3.8 and that has no module > for 3.8 (yet). $ grep-dctrl fontforge -FBuild-Depends /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources | grep-dctrl python3 -FBuild-Depends -sPackage Package: diffoscope Package: fonts-allerta Package: fonts-courier-prime Package: fonts-gotico-antiqua Package: fonts-junicode Package: fonts-karmilla Package: fonts-le-murmure Package: fonts-rit-sundar Package: fonts-smc-anjalioldlipi Package: fonts-smc-dyuthi Package: fonts-smc-karumbi Package: fonts-smc-keraleeyam Package: fonts-smc-meera Package: fonts-smc-rachana Package: fonts-smc-raghumalayalamsans Package: fonts-smc-uroob Package: fonts-solide-mirage Package: libreoffice Package: mftrace Package: searx Regards, Rene
Re: Bug#949187: transition: python3.8
On 2/2/20 5:53 PM, Rene Engelhard wrote: > On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: >>> On 17-01-2020 23:28, Matthias Klose wrote: Please add a transition tracker to switch the python3 default to 3.8. It's not yet ready, however it would be good to see affected packages. Please copy it from the 3.7 defaults change if possible. >>> >>> Tracker is in place. Please remove the moreinfo tag when you're ready. >> >> I think this is now in shape to be started. bug reports have been filed for > > I don't think so. > > e.g. fontforge is still red in > https://release.debian.org/transitions/html/python3.8.html. > > That means that a rebuild of stuff using fontforge in the build will > just FTBFS since it will be called with python3.8 and that has no module > for 3.8 (yet). > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > ago.) you are wrong. fontforge just builds for the default python version.
Re: Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > On 17-01-2020 23:28, Matthias Klose wrote: > >> Please add a transition tracker to switch the python3 default to 3.8. > >> It's not > >> yet ready, however it would be good to see affected packages. Please copy > >> it > >> from the 3.7 defaults change if possible. > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > I think this is now in shape to be started. bug reports have been filed for I don't think so. e.g. fontforge is still red in https://release.debian.org/transitions/html/python3.8.html. That means that a rebuild of stuff using fontforge in the build will just FTBFS since it will be called with python3.8 and that has no module for 3.8 (yet). (Seen in a python-3.8-as-default testbuild for libreoffice some time ago.) Regards, Rene
Re: Bug#949187: transition: python3.8
Control: tags -1 - moreinfo On 1/18/20 9:30 PM, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Matthias, > > On 17-01-2020 23:28, Matthias Klose wrote: >> Please add a transition tracker to switch the python3 default to 3.8. It's >> not >> yet ready, however it would be good to see affected packages. Please copy it >> from the 3.7 defaults change if possible. > > Tracker is in place. Please remove the moreinfo tag when you're ready. I think this is now in shape to be started. bug reports have been filed for issues with 3.8 in [1], and there may be some which are missing the proper tagging. I also filed bug reports for a dozen missing dh-python build dependencies. I would prefer a transition slot with less activity with transitions in the science area, like opencv, openmpi, gnuradio, ros*, and others which only build extensions for the default python3 version. Matthias [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.8;users=debian-python@lists.debian.org
