Bug#801667: git-dpm offers no way to merge between different packaging branches

2015-10-13 Thread Raphaël Hertzog
Package: git-dpm
Version: 0.9.1-1
Severity: normal

Still discovering git-dpm, I tried to do something basic:
- make a packaging change in debian/sid (adding debian/README.source)
- switch to debian/experimental
- merge debian/sid into it to get the latest packaging changes

But this doesn't work at all because debian/sid contains all the upstream
patches applied and it generates lots of conflicts.  When the patches are
not applied, I might have to cleanup debian/patches after the merge but at
least the merge worked fine and I can make sure that I have integrated all my
packaging changes... (I have dpkg-mergechangelogs configured too)

So the only solution that I have right now is to cherry pick packaging
changes from one version to the other and hope to not forget something...
and this will not work easily either if my changes contain a one-line
modification to debian/changelog (describing the change) as what you
usually get when you're used to use "dch && debcommit".

So "git-dpm" should offer a way to merge packaging branches:
- avoiding conflict on upstream files
- avoiding conflict on unchanged patches in debian/patches (right now the
  commit id and and the blob ids differ and generate conflicts)

I'm not sure how to best achieve this though.

-- System Information:
Debian Release: stretch/sid
  APT prefers squeeze-lts
  APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-dpm depends on:
ii  dpkg-dev  1.18.3
ii  git   1:2.6.1-1

Versions of packages git-dpm recommends:
ii  bzip2   1.0.6-8
ii  devscripts  2.15.9
ii  sensible-utils  0.0.9
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages git-dpm suggests:
ii  pristine-tar  1.33
ii  sharutils 1:4.15.2-1

-- no debconf information



Re: git repo lint tool

2015-10-13 Thread Sandro Tosi
On Tue, Oct 13, 2015 at 3:30 PM, Stefano Rivera  wrote:
> Many of the non-migrated git repos are a bit of a mess. I've written a
> tool that looks for common problems.

thanks! could it also emit a hint on how to address the problem? like
canonical vcs should be easy to just print also the url to stick into
the d/control file (cut vs rewrite and add a typo); how to
initialize git-dpm (a link to the wiki would do if there are not more
specific docs) etc

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi



Re: git repo lint tool

2015-10-13 Thread Barry Warsaw
On Oct 13, 2015, at 04:30 PM, Stefano Rivera wrote:

>Many of the non-migrated git repos are a bit of a mess. I've written a
>tool that looks for common problems.
>
>It's on alioth:
>$ cd /git/python-modules
>$ ./check-repositories

Nice, thanks.

>codespeak-lib: Non-Canonical Vcs fields

I think the codespeak-lib source package is obsolete.

>python-pex: Non-Canonical Vcs fields

I guess this means that the Vcs-* headers are not of the format defined in
https://wiki.debian.org/Python/GitPackaging right?  I fixed python-pex (not
yet uploaded).

>Barry Warsaw 
>   lazr.config
>   lazr.delegates
>   lazr.smtptest
>   pycurl
>   python-cachecontrol
>   python-future (U)
>   python-iso8601 (U)
>   python-pex
>   python-pip (U)
>   python-pluggy
>   tox

Barry is a bad person.

Cheers,
-Barry, not really evil



Re: git repo lint tool

2015-10-13 Thread Sebastian Ramacher
On 2015-10-13 16:30:53, Stefano Rivera wrote:
> codespeak-lib: Non-Canonical Vcs fields

codespeak-lib is no longer in the archive.

> Sebastian Ramacher 
>breathe
>flask-openid
>python-libdiscid (U)

They are no longer maintained under the DPMT umbrella.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Re: git repo lint tool

2015-10-13 Thread Daniel Stender
On 13.10.2015 16:30, Stefano Rivera wrote:
> Daniel Stender 
>deap
>gamera
>greekocr4gamera
>ocr4gamera
>pep8-naming
>pylint-celery
>pylint-common
>pytest-catchlog
>pytest-localserver
>pytest-tornado
>python-djvulibre
>python-requirements-detector
>python-setoptconf
>python-subprocess32
>python-xmp-toolkit
>vcr.py

All of these packages were in /git/python-modules/packages/ already before the 
migration,
a couple have been migrated manually from SVN to Git some months before, for 
the other
part (new packages) the packaging have been started already on/in Git.

I've now restored the repos like suggested in the GitPackaging wiki page 
(Post-migration
clean up), and there are all going to be configured for git-dpm patching in the 
course of
the next days.

In all packages, Vcs points to
Vcs-Git: git://anonscm.debian.org/python-modules/packages/.git
Vcs-Browser: 
http://anonscm.debian.org/cgit/python-modules/packages/.git

Best,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/



Re: git repo lint tool

2015-10-13 Thread Stefano Rivera
Hi Daniel (2015.10.13_17:47:01_+0200)
> In all packages, Vcs points to
> Vcs-Git: git://anonscm.debian.org/python-modules/packages/.git
> Vcs-Browser: 
> http://anonscm.debian.org/cgit/python-modules/packages/.git

The linter script wants https for Vcs-Browser.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Re: git repo lint tool

2015-10-13 Thread Daniel Stender
On 13.10.2015 17:57, Stefano Rivera wrote:
> Hi Daniel (2015.10.13_17:47:01_+0200)
>> In all packages, Vcs points to
>> Vcs-Git: git://anonscm.debian.org/python-modules/packages/.git
>> Vcs-Browser: 
>> http://anonscm.debian.org/cgit/python-modules/packages/.git
> 
> The linter script wants https for Vcs-Browser.
> 
> SR

Ah, o.k.! :-)

I'll fix this, too.

Thanks,
Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/



Re: git repo lint tool

2015-10-13 Thread Brian May
On Wed, 14 Oct 2015 at 01:31 Stefano Rivera  wrote:

> python-django: No control file
> python-django: Not git-dpmmed
>

Suspect it might be getting confused with the different branch names used
here. At least there was a control file when I looked last :-)


Re: Python-pyvcf: Couldn't find index page for 'distribute' (maybe misspelled?)

2015-10-13 Thread Piotr Ożarowski
[Andreas Tille, 2015-10-13]
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:170: python2.7 setup.py test.
> running test
> Searching for distribute
> Reading https://pypi.python.org/simple/distribute/
> Download error on https://pypi.python.org/simple/distribute/: [Errno 111] 
> Connection refused -- Some packages may not be found!
> Couldn't find index page for 'distribute' (maybe misspelled?)

patch setup.py to use setuptools instead of distribute and add
python{3,}-setuptools to Build-Depends
-- 
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: git repo lint tool

2015-10-13 Thread Stefano Rivera
Hi Brian (2015.10.13_22:01:19_+0200)
> > python-django: No control file
> > python-django: Not git-dpmmed
> >
> 
> Suspect it might be getting confused with the different branch names used
> here. At least there was a control file when I looked last :-)

Yeah, I was expecting that.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Python-pyfasta: How to run nosetests and what to do with duplicated binary

2015-10-13 Thread Andreas Tille
Hi,

I'd like to package

   svn://anonscm.debian.org/debian-med/trunk/packages/python-pyfasta/trunk/

for the Debian Med team.  The package builds so far but I'm a bit
concerned about


   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: cd 
/build/python-pyfasta-0.5.2/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose.

--
Ran 0 tests in 0.041s

OK
I: pybuild base:170: cd 
/build/python-pyfasta-0.5.2/.pybuild/pythonX.Y_3.5/build; python3.5 -m nose.

--
Ran 0 tests in 0.064s

OK
I: pybuild base:170: cd 
/build/python-pyfasta-0.5.2/.pybuild/pythonX.Y_3.4/build; python3.4 -m nose.

--
Ran 0 tests in 0.057s

OK


The directory tests/ is definitely not empty.  Any idea why the tests
are not run?

I also would like to get advise what to do with /usr/bin/pyfasta which
is a simple wrapper call script.  I tend to simply drop it from
python-pyfasta and leave it in python3-pyfasta exclusively but would
like to hear opinions about this strategy.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Python-pyfasta: How to run nosetests and what to do with duplicated binary

2015-10-13 Thread Piotr Ożarowski
[Andreas Tille, 2015-10-13]
> I: pybuild base:170: cd 
> /build/python-pyfasta-0.5.2/.pybuild/pythonX.Y_3.4/build; python3.4 -m nose.
> 
> --
> Ran 0 tests in 0.057s
> 
> OK
> 
> 
> The directory tests/ is definitely not empty.  Any idea why the tests
> are not run?

because I think running tests from package's root directory does more
harm than good

try with:

export PYBUILD_TEST_ARGS={dir}/tests

if these tests do not need 2to3 or check last example on
https://wiki.debian.org/Python/Pybuild

> I also would like to get advise what to do with /usr/bin/pyfasta which
> is a simple wrapper call script.  I tend to simply drop it from
> python-pyfasta and leave it in python3-pyfasta exclusively but would
> like to hear opinions about this strategy.

I do either that or provide new binary package (f.e. if it also gets
additional dependencies)
-- 
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