Re: git-buildpackage to be autoremoved due to python2 transition

2020-02-26 Thread Ian Jackson
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

2020-02-26 Thread Ian Jackson
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 ?

2019-09-12 Thread Ian Jackson
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

2019-07-28 Thread Ian Jackson
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

2012-06-14 Thread Ian Jackson
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?

2006-08-08 Thread Ian Jackson
(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]