Bug#801667: git-dpm offers no way to merge between different packaging branches
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
On Tue, Oct 13, 2015 at 3:30 PM, Stefano Riverawrote: > 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
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
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
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
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
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
On Wed, 14 Oct 2015 at 01:31 Stefano Riverawrote: > 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?)
[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
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
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
[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