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

2020-02-27 Thread Johannes Schauer
Quoting peter green (2020-02-27 22:54:19)
> > Relevant packages and bugs:
> >   943107 git-buildpackage: Python2 removal in sid/bullseye
> This bug is not marked as rc.
> 
> Nevertheless I believe that this bug report is in-fact a false positive. From
> what I can tell git-buildpackage, even in buster, does not (build-)depend on
> python 2 or any python 2 modules.

correct, but it does build-depend on packages that require python2: rpm

I was recently in a similar situation where I thought I had a false positive
for one of my package so I filed this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952523

You can always check whether you got a false positive or not by investing the
dependency relationship yourself. In this case:

dose-ceve -T grml --deb-builds-from --deb-native-arch=amd64 debsrc://Sources 
deb://Packages > /tmp/graph.xml
botch-graph-shortest-path /tmp/graph.xml /tmp/out.xml --source 
realpackage:src:git-buildpackage --target realpackage:src:python2.7

Thanks!

cheers, josch

signature.asc
Description: signature


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

2020-02-27 Thread peter green

Relevant packages and bugs:
  943107 git-buildpackage: Python2 removal in sid/bullseye

This bug is not marked as rc.

Nevertheless I believe that this bug report is in-fact a false positive. From 
what I can tell git-buildpackage, even in buster, does not (build-)depend on 
python 2 or any python 2 modules.

It does build-depend on python-pydoctor, but according to a recently entry in the 
pydoctor changelog that package "is a Python application and not used as a 
module"

It would make sense to change the build-dependency to pydoctor in the next 
upload, but it's probablly not worth making an upload just for that change.

  937132 nevow: Python2 removal in sid/bullseye

Depended on by pydoctor in testing, but not in unstable. Should stop being a 
problem for git-buildpackage when pydoctor migrates.

  938622 tahoe-lafs: Python2 removal in sid/bullseye

Listed as a "blocker" of the above bug but not currently in testing. Personally I 
advocate ignoring "blockers" that are not in testing, but I'm not sure if consensus has 
been reached on that.


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.

Builds happen in unstable, so there is no need to wait for pydoctor to migrate 
to testing before retrying the build. I just requested a retry and the package 
built succesfully. I'd expect it to migrate as soon as dak and britney process 
the binary.

  949232/948831 [pydoctor] needs to depend on cachecontrol
  952546 [pydoctor] d/copyright & DFSG issues
  937421 [pydoctor] Python2 removal in sid/bullseye

Should hopefully be fixed in a few days when pydoctor migrates to testing, i'm 
not seeing any obvious blockers for that right now.



Help needed to make pkgconfig finding just built lib

2020-02-27 Thread Andreas Tille
Control: tags -1 help

Hi,

I'm trying to drop biosig4c++ with Python3 only in Git[1].
Unfortunately I get:


make[3]: Entering directory '/build/biosig4c++-1.9.5/python'
python3 setup.py build
Traceback (most recent call last):
  File "setup.py", line 11, in 
PKG=pkgconfig.parse('libbiosig')
  File "/usr/lib/python3/dist-packages/pkgconfig/pkgconfig.py", line 248, in 
parse
_raise_if_not_exists(package)
  File "/usr/lib/python3/dist-packages/pkgconfig/pkgconfig.py", line 103, in 
_raise_if_not_exists
raise PackageNotFoundError(package)
pkgconfig.pkgconfig.PackageNotFoundError: libbiosig not found
make[3]: [Makefile:14: build] Error 1 (ignored)
make[3]: Leaving directory '/build/biosig4c++-1.9.5/python'


libbiosig.so is actually build inside the pbuilder chroot:

root:/build/biosig4c++-1.9.5# find . -name "*.so"
./libgdf.so
./libphysicalunits.so
./libbiosig.so
./debian/tmp/usr/lib/x86_64-linux-gnu/libbiosig.so
./debian/tmp/usr/lib/x86_64-linux-gnu/libbiosig2.so


Any idea how to convince pkgconfig that the library is there?

Kind regards

   Andreas.

[1] https://salsa.debian.org/neurodebian-team/biosig4c


-- 
http://fam-tille.de



Re: About itsdangerous

2020-02-27 Thread Dmitry Shachnev
Hi Julien!

On Thu, Feb 27, 2020 at 05:02:32PM +0100, Julien Puydt wrote:
> Le jeudi 27 février 2020 à 19:14 +0500, Andrey Rahmatullin a écrit :
>
> > https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> > 
>
> I must be going through a very bad day, but trying to follow 
> https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
> the two git checkout commands (both pristine-tar and upstream) give:
> error: pathspec 'pristine-tar' did not match any file(s) known to git
>
> Are we sure the original git repository had the correct structure
> anyway?

Looking at that repo, it did not have the correct structure, but I think
it makes sense to preserve its history anyway. I would do the following
with branches:

debian/unstable — rename to debian/master
master-dfsg — rename to upstream

Also update branch names in debian/gbp.conf accordingly. And gbp should create
a pristine-tar branch when you update to a newer release.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 05:02:32PM +0100, Julien Puydt wrote:
> > https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> > 
> 
> I must be going through a very bad day, but trying to follow 
> https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
> the two git checkout commands (both pristine-tar and upstream) give:
> error: pathspec 'pristine-tar' did not match any file(s) known to git
> 
> Are we sure the original git repository had the correct structure
> anyway?
It indeed doesn't use pristine-tar. Its upstream branch is named master
(as you can check in debian/gbp.conf) and looks like a clone of the
upstream repo master branch. OTOH the last release there repacks the
tarball and so uses the master-dfsg branch instead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Julien Puydt
Le jeudi 27 février 2020 à 19:14 +0500, Andrey Rahmatullin a écrit :

> https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> 

I must be going through a very bad day, but trying to follow 
https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
the two git checkout commands (both pristine-tar and upstream) give:
error: pathspec 'pristine-tar' did not match any file(s) known to git

Are we sure the original git repository had the correct structure
anyway?

JP



Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 12:57:49PM +0100, Julien Puydt wrote:
> Le jeudi 27 février 2020 à 15:49 +0500, Andrey Rahmatullin a écrit :
> > On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> > > Hi,
> > > 
> > > I saw python3-itsdangerous was far behind upstream, and decided to
> > > if
> > > it was easy to update : but it's not on salsa.
> > > 
> > > Should I import the last known package version (recent upload to
> > > remove
> > > the Python 2 package) to a new salsa repository and start from
> > > here?
> > I think you should import the alioth backup and import the last
> > upload on
> > top of it.
> 
> Hmmm... I searched for "itsdangerous":
> - on salsa ( 
> https://salsa.debian.org/search?utf8=%E2%9C%93=itsdangerous_id=_id=_ref=_source=navbar
> ) : nothing
> - on https://alioth-archive.debian.org/git/ : nothing
https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Julien Puydt
Le jeudi 27 février 2020 à 15:49 +0500, Andrey Rahmatullin a écrit :
> On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> > Hi,
> > 
> > I saw python3-itsdangerous was far behind upstream, and decided to
> > if
> > it was easy to update : but it's not on salsa.
> > 
> > Should I import the last known package version (recent upload to
> > remove
> > the Python 2 package) to a new salsa repository and start from
> > here?
> I think you should import the alioth backup and import the last
> upload on
> top of it.

Hmmm... I searched for "itsdangerous":
- on salsa ( 
https://salsa.debian.org/search?utf8=%E2%9C%93=itsdangerous_id=_id=_ref=_source=navbar
) : nothing
- on https://alioth-archive.debian.org/git/ : nothing

Is there some other place where I could have a look?

JP



Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> Hi,
> 
> I saw python3-itsdangerous was far behind upstream, and decided to if
> it was easy to update : but it's not on salsa.
> 
> Should I import the last known package version (recent upload to remove
> the Python 2 package) to a new salsa repository and start from here?
I think you should import the alioth backup and import the last upload on
top of it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


About itsdangerous

2020-02-27 Thread Julien Puydt
Hi,

I saw python3-itsdangerous was far behind upstream, and decided to if
it was easy to update : but it's not on salsa.

Should I import the last known package version (recent upload to remove
the Python 2 package) to a new salsa repository and start from here?

Cheers,

JP