Re: Team upload for python-jedi

[Piotr Ożarowski]

FYI: I uploaded 0.10.0~git1+f05c071-1 (without running tests during
build for now)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Bug#851824: (ITP: python-humanfriendly -- Python library to make user friendly text interfaces)

[Gaurav Juvekar]

Hi,

Can someone tell me how a single manpage can be used in different packages?

I've written a manpage for the humanfriendly command that both the
python-humanfriendly and python3-humanfriendly versions of this package
will provide. However, lintian says binaries-have-file-conflict for the
manpage.

I've put up my work at
https://github.com/gauravjuvekar/debian-python-humanfriendly


Regards,
Gaurav Juvekar



signature.asc
Description: OpenPGP digital signature

Re: Team upload for python-jedi

[Ghislain Vaillant]

On Thu, 2017-01-19 at 20:45 +0300, Dmitry Shachnev wrote:
> Hi Ghislain,
> 
> On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote:
> > Ok, I have got a working package fixing the RC. However, whoever did
> > the migration from svn to git forgot that the source tree was made of
> > multiple tarballs (one for jedi, one for jedi-vim) and now the vim
> > plugin package cannot be produced because of the missing sources [1].
> > 
> > How I should proceed now?
> > 
> > We could just drop the vim plugin package for now (it does not work
> > anyway due to #841043), and consider introducing a new source package
> > for it later. Afterall, they are separate projects on GitHub [2, 3].
> > 
> > Otherwise, I guess the svn migration would have to be re-run? I have no
> > idea how to do it, nor setting up git-dpm to use multiple tarballs.
> 
> The SVN to Git migration was done automatically. I think the script was
> just not too smart to deal with multiple tarballs properly.

Ok.


> For now you can just forget about git-dpm, get the sources manually and
> copy the Debian directory from Git on top of them.

Just to be sure, do you mean I should leave the repository alone and
merge my work in a fresh import-dsc of the current package?


> Now it is too late to fix the DPMT migration script, but it may be not
> too late to make sure the problem does not appear with PAPT.

Possibly.


Ghis

Re: Team upload for python-jedi

[Dmitry Shachnev]

Hi Ghislain,

On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote:
> Ok, I have got a working package fixing the RC. However, whoever did
> the migration from svn to git forgot that the source tree was made of
> multiple tarballs (one for jedi, one for jedi-vim) and now the vim
> plugin package cannot be produced because of the missing sources [1].
>
> How I should proceed now?
>
> We could just drop the vim plugin package for now (it does not work
> anyway due to #841043), and consider introducing a new source package
> for it later. Afterall, they are separate projects on GitHub [2, 3].
>
> Otherwise, I guess the svn migration would have to be re-run? I have no
> idea how to do it, nor setting up git-dpm to use multiple tarballs.

The SVN to Git migration was done automatically. I think the script was
just not too smart to deal with multiple tarballs properly.

For now you can just forget about git-dpm, get the sources manually and
copy the Debian directory from Git on top of them.

Now it is too late to fix the DPMT migration script, but it may be not
too late to make sure the problem does not appear with PAPT.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Team upload for python-jedi

[Ghislain Vaillant]

I apologize for insisting here, but I need this RC fixed ASAP for
another package relying on it and have no idea what to do now.

Thanks,
Ghis


On Wed, 2017-01-18 at 17:53 +, Ghislain Vaillant wrote:
> On Wed, 2017-01-18 at 13:37 +0100, Piotr Ożarowski wrote:
> > Hi,
> > 
> > [Ghislain Vaillant, 2017-01-18]
> > > Would you be ok if I push the changes required to fix #830399 and
> > > #841043 for src:python-jedi and prepare a team-upload?
> > > 
> > > I need the RC fixed for the packaging of spyder.
> > 
> > go ahead. I have almost working package with latest changes from upstream
> > git repo but some tests still fail and I don't have time to work on it
> > right now.
> 
> Ok, I have got a working package fixing the RC. However, whoever did
> the migration from svn to git forgot that the source tree was made of
> multiple tarballs (one for jedi, one for jedi-vim) and now the vim
> plugin package cannot be produced because of the missing sources [1].
> 
> [1] 
> https://anonscm.debian.org/cgit/python-modules/packages/python-jedi.git/tree/
> 
> 
> How I should proceed now?
> 
> We could just drop the vim plugin package for now (it does not work
> anyway due to #841043), and consider introducing a new source package
> for it later. Afterall, they are separate projects on GitHub [2, 3].
> 
> Otherwise, I guess the svn migration would have to be re-run? I have no
> idea how to do it, nor setting up git-dpm to use multiple tarballs.
> 
> [2] https://github.com/davidhalter/jedi
> [3] https://github.com/davidhalter/jedi-vim
> 
> 
> Cheers,
> Ghis

Re: RFS: python-cartopy/0.14.2-2

[Ghislain Vaillant]

Forwarding to d-python, who might know of a solution to this issue.

The gist of it is that we are looking for a suitable solution to bypass
a specific test which is failing on a subset of 32-bit architectures
(i386 only).

My initial patch was quite blunt and disabled the test for any 32-bit
arch, and James proposed a different solution based on a subprocess
call to dpkg-architecture. Do you guys have any suggestion of a more
Pythonic way to achieve this?

Cheers,
Ghis


On Tue, 2017-01-17 at 23:36 +, Ghislain Vaillant wrote:
> On Tue, 2017-01-17 at 20:39 +, James Clarke wrote:
> > On Tue, Jan 17, 2017 at 07:59:25PM +, Ghislain Vaillant wrote:
> > > Hi James,
> > > 
> > > Le 17 janv. 2017 7:44 PM, "James Clarke"  a écrit :
> > > 
> > > On Tue, Jan 17, 2017 at 07:22:32PM +, Ghislain Vaillant wrote:
> > > > Dear all,
> > > > 
> > > > I am looking for a sponsor for python-cartopy:
> > > > 
> > > >   https://anonscm.debian.org/cgit/debian-science/packages/
> > > 
> > > python-cartopy.git
> > > > 
> > > > 
> > > > Changes since the last upload:
> > > > 
> > > >   [ Andreas Tille ]
> > > >   * Do not force the package maintainer to install build-dependencies 
> > > > like
> > > > geos on local machine
> > > > 
> > > >   [ Ghislain Antony Vaillant ]
> > > >   * Fix FTBFS on 32-bit architectures (Closes: #848634)
> > > > New patch 0001-Skip-tests-failing-on-32-bit-architectures.patch
> > > > 
> > > > 
> > > > The test skip patch is a result of upstream being not responsive to the
> > > > issue so far. Since the failing test is fairly minor, I see no reason
> > > > to block the package for non 32-bit architectures.
> > > 
> > > This doesn't look right; it only failed on i386 (and
> > > hurd/kfreebsd-i386), but it built on armel, armhf, mips, mipsel, hppa,
> > > m68k and powerpc. This is not a 32-bit issue, but an x86 floating-point
> > > issue, most likely because the x87 FPU uses 80-bit floats internally.
> > > 
> > > 
> > > Would you have a better patch to propose then?
> > > 
> > > If you're going to disable the test, please do so *only* if the CPU is
> > > i386.
> > > 
> > > 
> > > I only know how to test for 32-bit, not for *i386 specifically, in Python.
> > > Please advise if you do.
> > 
> > There are platform.architecture()/machine()/processor(), but processor()
> > seems to give '' on Debian, machine() will give x86_64 if using an i386
> > chroot on an amd64 host, and architecture() just gives ('32bit', '').
> 
> Not to mention that platform.architecture is notoriously unreliable to
> detect bitness from my initial reading (Python docs and SO).
> 
> > Then there's the additional complication that x32 is a 32-bit version of
> > amd64, so it shouldn't fail the test. Therefore, I would propose
> > something like the following Debian-specific hack:
> > 
> > host_cpu = subprocess.check_output(['dpkg-architecture', 
> > '-qDEB_HOST_ARCH_CPU'])
> > if host_cpu != 'i386':
> > # Do the assert
> 
> Is it really worth going to so much trouble for just one test, you
> reckon? I understand your rationales for it and appreciate the
> pointers, but my pragmatic self is wondering whether putting such hack
> in place would be worth the reward from a maintenance perspective.
> 
> > I would be interested to know if there's a way of doing this without
> > having to call dpkg-architecture.
> 
> I would prefer such a solution too, TBH.
> 
> Ghis

Bug#851851: ITP: python-pytest-flakes -- pytest plugin to check source code with pyflakes

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pytest-flakes
  Version : 1.0.1
  Upstream Author : Florian Schulze 
* URL : https://github.com/fschulze/pytest-flakes
* License : Expat
  Programming Lang: Python
  Description : pytest plugin to check source code with pyflakes

 Discover Python source files and run them through pyflakes. You may configure
 pyflakes-checking options for your project by adding an entry to your
 setup.cfg.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAliAmuERHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqMBwf+JZL/d3Fd39Nq2ffucUz+Hu4YfyA2uCFF
MnzksxfaxgL6zlZfYjf/fTkfNuKx91vKmPVubsKuzKvqibNMv/FVs3Nu9ObX57Er
DQPrqRsHuPH19YC4jYi7VRDihBg8OjsNNe3e/1LrH6k+DLSlEZ+YDFCU+BxsLCF4
QVntAYgU36vGQkVwCGaK/asK4gDNw8mhx+Ao0iqy5oDO3NrPrxUidfgqhOjFhQg+
r0zk4Y7tbrntNjSnZx18OC627XovB80wylUUg/os/Roc3lGrcTCkCVWtZh627bL/
mIdDgabQB1G0UX9BYB5jNS9XGyi9rVdt5Z0tjuLxRjFxbv/IpPTA3A==
=6VBT
-END PGP SIGNATURE-