Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.python > #12259 > unrolled thread
| Started by | Simon McVittie <smcv@debian.org> |
|---|---|
| First post | 2020-02-03 20:30 +0100 |
| Last post | 2020-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.
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
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2020-02-03 20:30 +0100 |
| Subject | Bug#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]
| From | Rene Engelhard <rene@debian.org> |
|---|---|
| Date | 2020-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]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2020-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]
| From | rene.engelhard@mailbox.org |
|---|---|
| Date | 2020-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]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2020-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]
| From | Rene Engelhard <rene@debian.org> |
|---|---|
| Date | 2020-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