Re: git-buildpackage to be autoremoved due to python2 transition
Andrey Rahmatullin writes ("Re: git-buildpackage to be autoremoved due to
python2 transition"):
> Yes, and as far as I can see after pydoctor migrates the only problem with
> gbp will be python-rpm in debian/tests/control, which is probably
> unneeded.
Oh.
> > the py2 rot seems wider including in gbp itself.
>
> Where exactly?
I looked again and I was looking at an old version. Sorry for the
noise. I still think we have problems with these
937132 nevow: Python2 removal in sid/bullseye
938622 tahoe-lafs: Python2 removal in sid/bullseye
which I think are brought in by pydoctor...
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
git-buildpackage to be autoremoved due to python2 transition
FYI. The widespread impact of this not so apparent because git-buildpackage is typically used ad-hoc by maintainers, rather than via (Build)-Depends. Relevant packages and bugs: 943107 git-buildpackage: Python2 removal in sid/bullseye 937132 nevow: Python2 removal in sid/bullseye 938622 tahoe-lafs: Python2 removal in sid/bullseye Bugs which you may notice which are now not so relevant any more because they have been fixed in sid (but not yet migrated): 950216 [git-buildpackage] missing xsltproc autopkg test dependency Fixed in sid; migration blocked by FTBFS due to pydoctor breakage (#949232). When pydoctor has migrated, reattempting build (eg by re-upload) should fix this. 949232/948831 [pydoctor] needs to depend on cachecontrol 952546 [pydoctor] d/copyright & DFSG issues 937421 [pydoctor] Python2 removal in sid/bullseye My personal interest in this is that dgit Depends on git-buildpackage so I am early in the firing line. However, unfortunately my python skills are very weak and I doubt my blundering efforts [1] to try to mitigate the situation would would be helpful. I can at least do the digging to see what is actually still wrong here. Thanks to Anthony Fok for fixing pydoctor but the py2 rot seems wider including in gbp itself. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: should Debian add itself to https://python3statement.org ?
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
> https://python3statement.org/ is a site documenting the projects which
> are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to drop support for python2 by the end of
2020. Have we in fact made such a pledge ? I think I may have missed
the memo that python2 would be removed from bullseye.
I did some searching and found this
https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.
FTAOD I don't have an opinion about whether bullseye *should* ship
without python2. Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Please help fix pydoctor
Hi, Python folks. I think help is needed regarding #932584 python-pydoctor: Epydoc will be removed It seems to be languishing rather. What I don't understand is why pydoctor depends on epydoc given that, in the words of the Description: [Pydoctor] was written primarily to replace epydoc ... I had a quick look through the source but I don't know enough about pydoctor to make immediate sense of the results of my grep. Maybe some person who knows more about pydoctor can help ? (I'm CCing this to the gbp maintainers because this came to my attention due to an autoremoval bug where a package of mine has a dependency chain via gbp.) Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: autopkgtest'ing against multiple Python versions
Jakub Wilk writes (Re: autopkgtest'ing against multiple Python versions): * Yaroslav Halchenko deb...@onerussian.com, 2012-04-23, 09:17: The “failures” was caused by the following misfeature of the specification: “if a test […] prints to stderr, it is considered to have failed.” But nosetests does print stuff to stderr even if everything is all right (see bug #460242). yikes -- doesn't it fail if underlying test command returns with non-0 exit code? Thankfully it does. :) s/[…]/exits nonzero, or/ - sorry for the confusion. I think it's correct to call stderr output a test failure. I wrote the spec this way because there are far too many programs which don't deal with exit statuses properly. If you need to tolerate stderr output, you can redirect it to stdout. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20442.32906.743237.706...@chiark.greenend.org.uk
Re: dpkg-repack warnings: what effect?
(Matthias drew my attention to this thread. Sorry I'm a bit late ...) Joey Hess [EMAIL PROTECTED] wrote: Matthias Klose wrote: I haven't yet seen any reasoning why people are seeing that information as cluttering the database or just as ugly. Causing unrelated programs like dpkg-repack to spew warning messages is, by definition, ugly. Using X- fields, which are intended for nonstandard extensions, in the core of Debian is also ugly. The reason the X*- fields have to be named like that in the package control file is that dpkg-source et al don't know which output control files to copy them into. I don't think there's anything inherently wrong with using X*- fields in a Debian-mandated way. The alternative would be to make the whole new mechanism depend on updated dpkg-source which seems pointless given that dpkg-source has an extension mechanism here for precisely this purpose. It would be nice if dpkg-source (and dpkg-deb) could be taught not to warn about this field. But the warning is harmless too: it's there to point out if you accidentally misspelling a field name. So ignoring the warning is fine. Modify dpkg to properly add new fields if they're going to have common usage in Debian. Using X- fields is fine for prototyping but not for final implementations. I disagree. One of the things the IETF discovered was that renaming fields (or things in other namespaces) causes a lot of trouble and is to be avoided. So in general new IETF standards don't expect you to use x-* for new standards-track activities. Existing X-* fields have in some cases been grandfathered. We have to use X- for these fields for the reasons I've explained above. So I think we should be prepared to officially bless these particular names. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
