Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #12259 > unrolled thread

Bug#949187: transition: python3.8

Started bySimon McVittie <smcv@debian.org>
First post2020-02-03 20:30 +0100
Last post2020-02-05 22:10 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#949187: transition: python3.8 Simon McVittie <smcv@debian.org> - 2020-02-03 20:30 +0100
    Bug#949187: transition: python3.8 Rene Engelhard <rene@debian.org> - 2020-02-04 22:10 +0100
      Bug#949187: transition: python3.8 Simon McVittie <smcv@debian.org> - 2020-02-04 23:40 +0100
        Bug#949187: transition: python3.8 rene.engelhard@mailbox.org - 2020-02-05 08:30 +0100
          Bug#949187: transition: python3.8 Simon McVittie <smcv@debian.org> - 2020-02-05 14:40 +0100
            Bug#949187: transition: python3.8 Rene Engelhard <rene@debian.org> - 2020-02-05 22:10 +0100

#12259 — Bug#949187: transition: python3.8

FromSimon McVittie <smcv@debian.org>
Date2020-02-03 20:30 +0100
SubjectBug#949187: transition: python3.8
Message-ID<zvPzY-2tQ-3@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#12263

FromRene Engelhard <rene@debian.org>
Date2020-02-04 22:10 +0100
Message-ID<zwdCh-8p3-7@gated-at.bofh.it>
In reply to#12259
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 <module>
    from giscanner.scannermain import scanner_main
  File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", line 35, in <module>
    from giscanner.ast import Include, Namespace
  File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", line 29, in <module>
    from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
  File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", line 33, in <module>
    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 <rene@debian.org>  Sun, 15 Dec 2019 10:29:19 +0000

happened.)

Regards,

Rene

[toc] | [prev] | [next] | [standalone]


#12264

FromSimon McVittie <smcv@debian.org>
Date2020-02-04 23:40 +0100
Message-ID<zweRI-Cn-3@gated-at.bofh.it>
In reply to#12263
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

[toc] | [prev] | [next] | [standalone]


#12266

Fromrene.engelhard@mailbox.org
Date2020-02-05 08:30 +0100
Message-ID<zwnih-5NG-1@gated-at.bofh.it>
In reply to#12264
Hi,

Am 4. Februar 2020 23:27:13 MEZ schrieb Simon McVittie <smcv@debian.org>:
>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.

[toc] | [prev] | [next] | [standalone]


#12268

FromSimon McVittie <smcv@debian.org>
Date2020-02-05 14:40 +0100
Message-ID<zwsUG-Gw-17@gated-at.bofh.it>
In reply to#12266
On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelhard@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

[toc] | [prev] | [next] | [standalone]


#12269

FromRene Engelhard <rene@debian.org>
Date2020-02-05 22:10 +0100
Message-ID<zwzWa-4Xw-5@gated-at.bofh.it>
In reply to#12268
On Wed, Feb 05, 2020 at 01:26:31PM +0000, Simon McVittie wrote:
> On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelhard@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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.maint.python


csiph-web