Bug#908813: [PATCH] spec: user xdelta v3 for rpm builds, too
Package: pristine-tar
Version: 1.44
Tags: patch
Nowadays, it's ubiquitous and pristine-tar supports it.
Signed-off-by: Markus Lehtonen
---
pristine-tar.spec | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/pristine-tar.spec b/pristine-tar.spec
index a9e4594..5ffac18 100644
--- a/pristine-tar.spec
+++ b/pristine-tar.spec
@@ -20,11 +20,7 @@ Requires: perl-base
%else
Requires: perl
%endif
-%if 0%{?fedora} || 0%{?centos_ver} >= 7
-Requires: xdelta1
-%else
-Requires: xdelta < 3
-%endif
+Requires: xdelta >= 3
BuildRequires: pkgconfig(zlib)
BuildRequires: perl(ExtUtils::MakeMaker)
%if 0%{?suse_version}
@@ -51,10 +47,7 @@ pristine-tar is available in git at
git://git.kitenet.net/pristine-tar/
%build
-%if 0%{?fedora} || 0%{?centos_ver} >= 7
-%define makemaker_extraopts XDELTA_PROGRAM=xdelta1
-%endif
-perl Makefile.PL INSTALLDIRS=vendor PREFIX=%{_prefix} %{?makemaker_extraopts}
+perl Makefile.PL INSTALLDIRS=vendor PREFIX=%{_prefix}
make %{?_smp_mflags}
--
2.16.4
Bug#829690: [git-buildpackage/master] Command: redirect stdout/stderr to sys.stdout/stderr
tag 829690 pending thanks Date: Fri Oct 9 14:22:31 2015 +0300 Author: Markus Lehtonen <markus.lehto...@linux.intel.com> Commit ID: c6b32c81df7b5f70a339270369a12adaf0238730 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=c6b32c81df7b5f70a339270369a12adaf0238730 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=c6b32c81df7b5f70a339270369a12adaf0238730 Command: redirect stdout/stderr to sys.stdout/stderr Redirect stdout and stderr of the (child) command to sys.stdout and sys.stderr of the caller, respectively. This change is mainly for the unit tests. It makes Python nose to correctly capture the output of the child command, too, which in turn suppresses a lot of spurious output when running nosetests. Closes: #829690 Signed-off-by: Markus Lehtonen <markus.lehto...@linux.intel.com> A snapshot build including this change will be available at http://honk.sigxcpu.org:8001/job/git-buildpackage/
Bug#807597: [PATCH] Update spec file
Package: pristine-tar
Version: 1.33
Tags: patch
Update the spec file in order to make pristine-tar easily buildable in
openSUSE, Fedora and CentOS. In addition to updating build and runtime
dependencies, capitalize the Summary: text and remove unndeeded
BuildRoot: tag and %clean section.
Signed-off-by: Markus Lehtonen <markus.lehto...@linux.intel.com>
---
pristine-tar.spec | 48 +++-
1 file changed, 39 insertions(+), 9 deletions(-)
diff --git a/pristine-tar.spec b/pristine-tar.spec
index fdc95d3..58f8fbb 100644
--- a/pristine-tar.spec
+++ b/pristine-tar.spec
@@ -1,15 +1,35 @@
Name: pristine-tar
-Version: 1.32
+Version: 1.33
Release: 2%{?dist}
-Summary: regenerate pristine tarballs
+Summary: Regenerate pristine tarballs
Group: System Tools
License: GPLv2
Url: http://kitenet.net/~joey/code/pristine-tar/
Source0:
http://ftp.debian.org/debian/pool/main/p/pristine-tar/%{name}_%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: git, xdelta
+Requires: tar
+Requires: gzip
+Requires: bzip2
+%if 0%{?suse_version} || 0%{?fedora}
+Recommends: pbzip2
+%endif
+Requires: git
+%if 0%{?suse_version}
+Requires: perl-base
+%else
+Requires: perl
+%endif
+%if 0%{?fedora} || 0%{?centos_ver} >= 7
+Requires: xdelta1
+%else
+Requires: xdelta < 3
+%endif
+BuildRequires: pkgconfig(zlib)
+BuildRequires: perl(ExtUtils::MakeMaker)
+%if 0%{?suse_version}
+BuildRequires: fdupes
+%endif
%description
pristine-tar can regenerate a pristine upstream tarball using only a
@@ -31,17 +51,23 @@ pristine-tar is available in git at
git://git.kitenet.net/pristine-tar/
%build
-perl Makefile.PL INSTALLDIRS=vendor PREFIX=%{_prefix}
+%if 0%{?fedora} || 0%{?centos_ver} >= 7
+%define makemaker_extraopts XDELTA_PROGRAM=xdelta1
+%endif
+perl Makefile.PL INSTALLDIRS=vendor PREFIX=%{_prefix} %{?makemaker_extraopts}
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-make install DESTDIR=$RPM_BUILD_ROOT
+rm -rf %{buildroot}
+%make_install
+find %{buildroot}/usr/lib/pristine-tar/ -name '*.a' | xargs rm
-%clean
-rm -rf $RPM_BUILD_ROOT
+# Run fdupes if building in openSUSE
+%if 0%{?suse_version}
+%fdupes -s %{buildroot}/usr/lib/pristine-tar/
+%endif
%files
@@ -49,6 +75,10 @@ rm -rf $RPM_BUILD_ROOT
%doc GPL TODO delta-format.txt
%{_bindir}/*
%{_mandir}/*
+/usr/lib/pristine-tar
+%{perl_vendorlib}/*
+%{perl_archlib}/*
+%exclude %{perl_vendorarch}
%changelog
--
2.1.4
Bug#807585: [PATCH] pristine-gz: add XDELTA_PROGRAM build parameter
Package: pristine-tar
Version: 1.33
Tags: patch
The XDELTA_PROGRAM build parameter may be used to define the xdelta
binary to be used by pristine-tar. This patch increases compatibility
with many non-Debian systems that do ship xdelta 3 by default.
Signed-off-by: Markus Lehtonen <markus.lehto...@linux.intel.com>
---
pristine-gz | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/pristine-gz b/pristine-gz
index 5ca9f65..973c7fb 100755
--- a/pristine-gz
+++ b/pristine-gz
@@ -96,6 +96,11 @@ use File::Basename qw/basename/;
delete $ENV{GZIP};
+# The following assignment is potentially munged during the
+# build process to hold the value of XDELTA_PROGRAM
+# parameter as given to Makefile.PL.
+my $xdelta_program = "xdelta";
+
dispatch(
commands => {
usage => [\],
@@ -234,7 +239,7 @@ sub reproducegz {
else {
# generate a binary delta and see if this is the
# best variant so far
- my $ret=system("xdelta delta -0 --pristine $tempout
$orig $tempdir/tmpdelta 2>/dev/null") >> 8;
+ my $ret=system("$xdelta_program delta -0 --pristine
$tempout $orig $tempdir/tmpdelta 2>/dev/null") >> 8;
# xdelta exits 1 on success
if ($ret == 1) {
my $size=(stat("$tempdir/tmpdelta"))[7];
@@ -297,7 +302,7 @@ sub gengz {
my $tempdir=tempdir();
my $tfile="$tempdir/".basename($file).".gz";
doit_redir($file, $tfile, @zgz);
- doit("xdelta", "patch", "--pristine", $delta->{delta}, $tfile,
"$file.gz");
+ doit("$xdelta_program", "patch", "--pristine", $delta->{delta},
$tfile, "$file.gz");
}
else {
doit_redir("$file", "$file.gz", @zgz);
--
2.1.4
Bug#807586: [PATCH] Mangle PAX headers when using posix tar format
Package: pristine-tar
Version: 1.33
Tags: patch
Remove all timestamps from extended PAX headers in order to guarantee
that created tarballs are always identical so that the delta can be
applied cleanly.
The timestamps can break pristine-tar generation as they are different
every time an archive is generated from git (when using tree id
instead of commit id as the sha-1 to checkout). Git uses the current
time as the modification time of files when a tree is archived.
Change-Id: Iceba202e5b4a6a01def724b8922028dbf3e3a2b3
Signed-off-by: Markus Lehtonen <markus.lehto...@linux.intel.com>
---
pristine-tar | 5 +
1 file changed, 5 insertions(+)
diff --git a/pristine-tar b/pristine-tar
index 0bf44e8..da59de9 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -378,6 +378,11 @@ sub recreatetarball_helper {
"--files-from", "$tempdir/manifest");
if (exists $options{tar_format}) {
push @cmd, ("-H", $options{tar_format});
+ if ($options{tar_format} eq 'posix') {
+ # Mangle PAX headers so that created tarballs are
always identical
+ # so that delta can be successfully applied
+ push @cmd,
('--pax-option=exthdr.name=%d/PaxHeaders/%f,mtime:=0,atime:=0,ctime:=0');
+ }
}
doit(@cmd);
--
2.1.4
Bug#778594: git-import-orig fails to merge into packaging branch
Hi, On Fri, 2015-02-20 at 11:25 +0100, Guido Günther wrote: On Fri, Feb 20, 2015 at 09:36:52AM +0200, Markus Lehtonen wrote: There were two things I didn't like about the svn workflow for Debian packages. debian/ and upstream source not in one tree (so I can not build with a patched package easily to try fixes) and having to use an export dir (slowing down the build and not giving me a single source tree to grep through). Good to hear arguments why this is not supported. My understanding is that having source code changes is not possible in the 3.0 (quilt) format. Thus, trying out fixes requires usage of gbp-pq, anyway. Please correct me, if I'm wrong. It is supported with some configuration, basically using single-debian-patch in debian/source/options . I didn't know about this, thanks for pointing this out! In this case, it might make sense to implement something similar in buildpackage-rpm. A new command line option would be needed, --git-create-single-patch or something. I put this in my backlog so let's see... It seems that having the packaging separate brings back these two things some I'm opposed Basically, yes :( Would you oppose making this an optionally supported mode, if the maintainer so chooses? It shouldn't require too many changes, e.g. probably making pq-import to apply patches on top of the upstream version instead of the tip of the packaging branch and making gbp-buildpackage to export upstream-tree + packaging-branch instead of just packaging-branch. I'm not sure we want to support that many different workflows but if there are users for this: why not! I still do think simply writing the debian/ tree is less effort and easier since you just have to look at that single branch then. OK, I have this in my backlog, too. I'll let you know when/if I have something worth of sharing. Also, I have some ideas how to enable building without having to use a separateexport directory in this mode. I think I'd need to try it out and post a conceptual patch for comments. Great! Since building wick pbuilder/sbuild/mock creates another copy we should really try to avoid that one. Also this is in my todo-list. but maybe there are good arguments in favour of just omitting the merge and putting debian/ into the upstream tree? If we create a fake merge commit it's even easy to see where the upstream source came from. Were you thinking about 3.0(quilt) format here? IMO, this sounds better than the original idea. I've had similar ideas, but for the pq-branch, i.e. making it possible to do builds directly in the pq-branch. But again, I think I need to think about it a bit more and probably send a proof-of-concept patch for comments. That does already work. The extra steps are that you either have to sync debian/patches via gbp pq --commit export or use single-debian-patch as above. The major drawback at the moment is that you usually don't push the pq branch since it's being rebased but we could fix that too by creating fake merges into a long lifed branch. I was thinking a way without needing to do the extra step of gbp pq --commit export. But it seems that the single-debian-patch (and a possible counterpart in buildpackage-rpm) should do. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778594: git-import-orig fails to merge into packaging branch
Hi, On 18/02/15 09:43, Guido Günther a...@sigxcpu.org wrote: On Tue, Feb 17, 2015 at 10:09:16PM +0200, Markus Lehtonen wrote: Hi, On 17/02/15 20:05, Guido Günther a...@sigxcpu.org wrote: On Tue, Feb 17, 2015 at 11:39:34AM +0100, Martin Pitt wrote: Hello again, Martin Pitt [2015-02-17 9:55 +0100]: Ah indeed, most upstream updates have a Merge tag 'upstream/XXX' into experimental after Imported Upstream version XXX, but 217 doesn't. Probably I already had some trouble with this in 218, as curiously the 218 update has two identically-looking commits 99af89298 and f47781d88. So I suppose something went wrong with importing 217. Mystery resolved. This happens when you git-import-orig a new release, then hack on the branch to port patches, resolve regressions, update packaging etc., and do a git rebase -i origin to clean up your work before pushing. That drops the above Merge tag ... into ... commits, and thus they disappear from the history. Yeah, see the footnote in my initial reply. Since the commit message looked fine I assumed that this was caused by a rebase. Thanks for confirming. Nevertheless a gbp import-orig --force-overwrite that produces the new upstream tree + the debian/ tree as new content of the packaging branch should be added therefore let's move this to wishlist. How about an (additional) mode where no source is present in the packaging branch? That is, only have the content of the debian/ directory. No difficulties with merges and cleaner git history overall. We this kind of support in the still unmerged buildpackage-rpm tool. This mode might have the limitation of requiring a build in a separate build area (with --git-export-dir), or then some clever tricks could be done in the Git work tree to allow build in-place. There were two things I didn't like about the svn workflow for Debian packages. debian/ and upstream source not in one tree (so I can not build with a patched package easily to try fixes) and having to use an export dir (slowing down the build and not giving me a single source tree to grep through). Good to hear arguments why this is not supported. My understanding is that having source code changes is not possible in the 3.0 (quilt) format. Thus, trying out fixes requires usage of gbp-pq, anyway. Please correct me, if I'm wrong. It seems that having the packaging separate brings back these two things some I'm opposed Basically, yes :( Would you oppose making this an optionally supported mode, if the maintainer so chooses? It shouldn't require too many changes, e.g. probably making pq-import to apply patches on top of the upstream version instead of the tip of the packaging branch and making gbp-buildpackage to export upstream-tree + packaging-branch instead of just packaging-branch. Also, I have some ideas how to enable building without having to use a separateexport directory in this mode. I think I'd need to try it out and post a conceptual patch for comments. but maybe there are good arguments in favour of just omitting the merge and putting debian/ into the upstream tree? If we create a fake merge commit it's even easy to see where the upstream source came from. Were you thinking about 3.0(quilt) format here? IMO, this sounds better than the original idea. I've had similar ideas, but for the pq-branch, i.e. making it possible to do builds directly in the pq-branch. But again, I think I need to think about it a bit more and probably send a proof-of-concept patch for comments. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778594: git-import-orig fails to merge into packaging branch
Hi, On 17/02/15 20:05, Guido Günther a...@sigxcpu.org wrote: retitle 778594 gbp import-orig: allow to ignore changes outside of debian/ severity 778594 wishlist thanks On Tue, Feb 17, 2015 at 11:39:34AM +0100, Martin Pitt wrote: Hello again, Martin Pitt [2015-02-17 9:55 +0100]: Ah indeed, most upstream updates have a Merge tag 'upstream/XXX' into experimental after Imported Upstream version XXX, but 217 doesn't. Probably I already had some trouble with this in 218, as curiously the 218 update has two identically-looking commits 99af89298 and f47781d88. So I suppose something went wrong with importing 217. Mystery resolved. This happens when you git-import-orig a new release, then hack on the branch to port patches, resolve regressions, update packaging etc., and do a git rebase -i origin to clean up your work before pushing. That drops the above Merge tag ... into ... commits, and thus they disappear from the history. Yeah, see the footnote in my initial reply. Since the commit message looked fine I assumed that this was caused by a rebase. Thanks for confirming. Nevertheless a gbp import-orig --force-overwrite that produces the new upstream tree + the debian/ tree as new content of the packaging branch should be added therefore let's move this to wishlist. How about an (additional) mode where no source is present in the packaging branch? That is, only have the content of the debian/ directory. No difficulties with merges and cleaner git history overall. We this kind of support in the still unmerged buildpackage-rpm tool. This mode might have the limitation of requiring a build in a separate build area (with --git-export-dir), or then some clever tricks could be done in the Git work tree to allow build in-place. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752503: [PATCH] Implement gbp-buildpackage-rpm
Hi,
The attached patch series implements initial version of the
gbp-buildpackage-rpm tool.
The patches modifying gbp.command_wrappers:Command (patches 0011 and
0012) are not strictly required but they make the output from nosetests
much cleaner.
These patches, plus some additional features extending gbp-buildpackage
and gbp-buildpackage-rpm, can also be found on the
feature/buildpackage-rpm branch in my Github repository:
https://github.com/marquiz/git-buildpackage-rpm
Best Regards,
Markus Lehtonen
From ff5911b46a6ed16084cdd6d50580e2d22c9e1991 Mon Sep 17 00:00:00 2001
From: Markus Lehtonen markus.lehto...@linux.intel.com
Date: Fri, 27 Jun 2014 08:36:29 +0300
Subject: [PATCH 01/14] GitRepository/has_submodules: add treeish argument
For defining a Git treeish which to look into, instead of the current
working copy.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
gbp/git/repository.py | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index c261e40..a0995b7 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1735,18 +1735,23 @@ class GitRepository(object):
#{ Submodules
-def has_submodules(self):
+def has_submodules(self, treeish=None):
Does the repo have any submodules?
+@param treeish: look into treeish
+@type treeish: C{str}
@return: C{True} if the repository has any submodules, C{False}
otherwise
@rtype: C{bool}
-if os.path.exists(os.path.join(self.path, '.gitmodules')):
+if treeish:
+try:
+self.show('%s:.gitmodules' % treeish)
+except GitRepositoryError:
+return False
return True
-else:
-return False
+return os.path.exists(os.path.join(self.path, '.gitmodules'))
def add_submodule(self, repo_path):
--
1.8.4.5
From 0bb43cf3ab3be6ba5085a014b42ea0b946a5e291 Mon Sep 17 00:00:00 2001
From: Markus Lehtonen markus.lehto...@linux.intel.com
Date: Tue, 15 May 2012 16:37:33 +0300
Subject: [PATCH 02/14] common/buildpackage: support for different archive
formats
Adds support for defining the archive format of the output of
git_archive_single(), e.g. 'zip'. Defaults to 'tar', as before.
Signed-off-by: Ed Bartosh eduard.bart...@intel.com
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
debian/control | 2 +-
gbp/command_wrappers.py| 10
gbp/scripts/common/buildpackage.py | 48 ++
3 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/debian/control b/debian/control
index 3e42326..4992af4 100644
--- a/debian/control
+++ b/debian/control
@@ -45,7 +45,7 @@ Depends: ${python:Depends},
python-dateutil,
python-pkg-resources,
Recommends: pristine-tar (= 0.5), cowbuilder, python-requests
-Suggests: python-notify, unzip
+Suggests: python-notify, unzip, zipmerge
Description: Suite to help with Debian packages in Git repositories
This package contains the following tools:
* gbp import-{dsc,dscs}: import existing Debian source packages into a git
diff --git a/gbp/command_wrappers.py b/gbp/command_wrappers.py
index b8bd21f..f1312e4 100644
--- a/gbp/command_wrappers.py
+++ b/gbp/command_wrappers.py
@@ -233,6 +233,16 @@ class UnpackZipArchive(Command):
self.run_error = 'Couldn\'t unpack %s' % self.archive
+class CatenateZipArchive(Command):
+Wrap zipmerge tool to catenate a zip file with the next
+def __init__(self, archive, **kwargs):
+self.archive = archive
+Command.__init__(self, 'zipmerge', [archive], **kwargs)
+
+def __call__(self, target):
+Command.__call__(self, [target])
+
+
class GitCommand(Command):
Mother/Father of all git commands
def __init__(self, cmd, args=[], **kwargs):
diff --git a/gbp/scripts/common/buildpackage.py b/gbp/scripts/common/buildpackage.py
index 2e53b78..f95147e 100644
--- a/gbp/scripts/common/buildpackage.py
+++ b/gbp/scripts/common/buildpackage.py
@@ -22,7 +22,7 @@ import os, os.path
import pipes
import tempfile
import shutil
-from gbp.command_wrappers import (CatenateTarArchive)
+from gbp.command_wrappers import (CatenateTarArchive, CatenateZipArchive)
from gbp.errors import GbpError
import gbp.log
@@ -50,51 +50,59 @@ def sanitize_prefix(prefix):
return '/'
-def git_archive_submodules(repo, treeish, output, prefix, comp_type, comp_level, comp_opts):
+def git_archive_submodules(repo, treeish, output, prefix, comp_type, comp_level,
+ comp_opts, format='tar'):
-Create tar.gz of an archive with submodules
+Create a source tree archive with submodules.
-since git-archive always writes an end of tarfile trailer we concatenate
+Since git-archive always writes an end of tarfile trailer we concatenate
the generated archives using tar
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
Hi, On 28/12/14 14:22, Guido Günther a...@sigxcpu.org wrote: On Tue, Dec 16, 2014 at 10:09:15AM +0200, Markus Lehtonen wrote: On Fri, 2014-12-05 at 15:50 +0100, Guido Günther wrote: Hi Markus, On Tue, Dec 02, 2014 at 04:47:58PM +0200, Markus Lehtonen wrote: Hello, On Fri, 2014-11-28 at 14:55 +0100, Guido Günther wrote: On Fri, Nov 28, 2014 at 12:11:01PM +0200, Markus Lehtonen wrote: [..snip..] If you're willing to wait for few days I could look into this and provide a patchset with minimal pq-rpm implementation (i.e. all the new cmdline options, even configurable branch names, removed). What I'd like to have there are the unit tests. That would be awesome! I'd be great to have a second tool merged. The attached series implements an initial version of the pq-rpm tool. The first four patches (0001-0004) are required to make the actual pq-rpm tool to work correctly. The next four patches (0005-0008) are requirements for the unit tests. The last patch finally implements gbp-pq-rpm tool itself. This series (plus some additional features) is also available in feature/pq-rpm branch in my Github repository: git clone git://github.com/marquiz/git-buildpackage-rpm.git -b feature/pq-rpm I had a look at this branch an it looks great. I'd feel more comfortable if we'd had a unit test for dump_tree with recursive though (af39e32692ebedb4316b28851e10f737bf176105) - can you add that, I can pull in the rest then. You can find a patch with updated unit tests attached. I also updated and rebased my feature/pq-rpm branch in Github. I've pulled in the patches up to but the tests fail with: == ERROR: test suite for class 'tests.component.rpm.test_pq_rpm.TestPqRpm' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 209, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 292, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 315, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 470, in try_run return func() File /var/scratch/src/git-buildpackage/git-buildpackage/tests/component/rpm/__ init__.py, line 93, in setup_class repo.create_branch(branch, rev) File /var/scratch/src/git-buildpackage/git-buildpackage/gbp/git/repository.py , line 311, in create_branch self._git_command(branch, args.args) File /var/scratch/src/git-buildpackage/git-buildpackage/gbp/git/repository.py , line 207, in _git_command raise GitRepositoryError(Error running git %s: %s % (command, stderr)) GitRepositoryError: Error running git branch: fatal: Not a valid branch point: 'b82fd1a61db4221263b2c110f60c6d07cb0203df'. I assume that the subproject commit of tests/component/rpm/data in 63a5a1aedb5e14e6d32a942b2a4c6de42b14a8f2 is incorrect? The pq-rpm unit tests utilize many refs (refs/gbp-test*/*) from the submodule repository. The problem probably is that my testdata repo was in inconsistent state at the time you ran git-submodule update and some refs in your local copy are out-of-date. Re-running git-submodule update now won't fetch them as the submodule HEAD is already up-to-date. Try doing git submodule foreach git fetch origin and re-running the tests. I didn't want to clone/fetch from the remote repo inside the tests in order to not depend on network connection. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
On Fri, 2014-12-05 at 15:50 +0100, Guido Günther wrote:
Hi Markus,
On Tue, Dec 02, 2014 at 04:47:58PM +0200, Markus Lehtonen wrote:
Hello,
On Fri, 2014-11-28 at 14:55 +0100, Guido Günther wrote:
On Fri, Nov 28, 2014 at 12:11:01PM +0200, Markus Lehtonen wrote:
[..snip..]
If you're willing to wait for few days I could look into this and
provide
a patchset with minimal pq-rpm implementation (i.e. all the new cmdline
options, even configurable branch names, removed). What I'd like to have
there are the unit tests.
That would be awesome! I'd be great to have a second tool merged.
The attached series implements an initial version of the pq-rpm tool.
The first four patches (0001-0004) are required to make the actual
pq-rpm tool to work correctly. The next four patches (0005-0008) are
requirements for the unit tests. The last patch finally implements
gbp-pq-rpm tool itself.
This series (plus some additional features) is also available in
feature/pq-rpm branch in my Github repository:
git clone git://github.com/marquiz/git-buildpackage-rpm.git -b
feature/pq-rpm
I had a look at this branch an it looks great. I'd feel more
comfortable if we'd had a unit test for dump_tree with recursive
though (af39e32692ebedb4316b28851e10f737bf176105) - can you add that,
I can pull in the rest then.
You can find a patch with updated unit tests attached. I also updated
and rebased my feature/pq-rpm branch in Github.
Thanks,
Markus
From 3f19f417727004ce1d3f8a800451201b528efe77 Mon Sep 17 00:00:00 2001
From: Markus Lehtonen markus.lehto...@linux.intel.com
Date: Tue, 17 Sep 2013 15:13:40 +0300
Subject: [PATCH] buildpackage/dump_tree: add 'recursive' option
For selecting whether to dump all the files recursively or just the top
level directory of the tree.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
gbp/scripts/common/buildpackage.py | 12 +---
tests/04_test_submodules.py| 15 +--
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/gbp/scripts/common/buildpackage.py b/gbp/scripts/common/buildpackage.py
index 0522cd6..2e53b78 100644
--- a/gbp/scripts/common/buildpackage.py
+++ b/gbp/scripts/common/buildpackage.py
@@ -101,13 +101,19 @@ def git_archive_single(treeish, output, prefix, comp_type, comp_level, comp_opts
#{ Functions to handle export-dir
-def dump_tree(repo, export_dir, treeish, with_submodules):
+def dump_tree(repo, export_dir, treeish, with_submodules, recursive=True):
dump a tree to output_dir
output_dir = os.path.dirname(export_dir)
prefix = sanitize_prefix(os.path.basename(export_dir))
+if recursive:
+paths = []
+else:
+paths = ['%s' % nam for _mod, typ, _sha, nam in
+repo.list_tree(treeish) if typ == 'blob']
pipe = pipes.Template()
-pipe.prepend('git archive --format=tar --prefix=%s %s' % (prefix, treeish), '.-')
+pipe.prepend('git archive --format=tar --prefix=%s %s -- %s' %
+ (prefix, treeish, ' '.join(paths)), '.-')
pipe.append('tar -C %s -xf -' % output_dir, '-.')
top = os.path.abspath(os.path.curdir)
try:
@@ -115,7 +121,7 @@ def dump_tree(repo, export_dir, treeish, with_submodules):
if ret:
raise GbpError(Error in dump_tree archive pipe)
-if with_submodules:
+if recursive and with_submodules:
if repo.has_submodules():
repo.update_submodules()
for (subdir, commit) in repo.get_submodules(treeish):
diff --git a/tests/04_test_submodules.py b/tests/04_test_submodules.py
index 4b07220..a18f8b5 100644
--- a/tests/04_test_submodules.py
+++ b/tests/04_test_submodules.py
@@ -22,6 +22,7 @@ SUBMODULES = []
SUBMODULE_NAMES = [test_submodule, sub module]
TMPDIR = None
TESTFILE_NAME = testfile
+TESTDIR_NAME = testdir
class Submodule(object):
Class representing remote repo for Git submodule
@@ -57,6 +58,8 @@ def test_empty_has_submodules():
def _add_dummy_data(repo, msg):
Commit dummy data to a Git repository
shutil.copy(.git/HEAD, TESTFILE_NAME)
+os.mkdir(TESTDIR_NAME)
+shutil.copy(TESTFILE_NAME, os.path.join(TESTDIR_NAME, TESTFILE_NAME))
repo.add_files('.', force=True)
repo.commit_all(msg)
@@ -99,8 +102,16 @@ def test_dump_tree():
os.mkdir(dumpdir)
ok_(buildpackage.dump_tree(REPO, dumpdir, master, True))
ok_(os.path.exists(os.path.join(dumpdir, TESTFILE_NAME)))
+ok_(os.path.exists(os.path.join(dumpdir, TESTDIR_NAME, TESTFILE_NAME)))
ok_(os.path.exists(os.path.join(dumpdir, SUBMODULES[0].name,
TESTFILE_NAME)))
+# No submodules or subdirs if recursive is False
+dumpdir = TMPDIR.join(dump2)
+os.mkdir(dumpdir)
+ok_(buildpackage.dump_tree(REPO, dumpdir, master, True, False))
+ok_(os.path.exists(os.path.join(dumpdir, TESTFILE_NAME)))
+ok_(not os.path.exists(os.path.join(dumpdir
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
Hello,
On Fri, 2014-11-28 at 14:55 +0100, Guido Günther wrote:
On Fri, Nov 28, 2014 at 12:11:01PM +0200, Markus Lehtonen wrote:
[..snip..]
If you're willing to wait for few days I could look into this and provide
a patchset with minimal pq-rpm implementation (i.e. all the new cmdline
options, even configurable branch names, removed). What I'd like to have
there are the unit tests.
That would be awesome! I'd be great to have a second tool merged.
The attached series implements an initial version of the pq-rpm tool.
The first four patches (0001-0004) are required to make the actual
pq-rpm tool to work correctly. The next four patches (0005-0008) are
requirements for the unit tests. The last patch finally implements
gbp-pq-rpm tool itself.
This series (plus some additional features) is also available in
feature/pq-rpm branch in my Github repository:
git clone git://github.com/marquiz/git-buildpackage-rpm.git -b
feature/pq-rpm
Best Regards,
Markus Lehtonen
From 4ce789c8b761e5f08f293df8a6b8879673722d93 Mon Sep 17 00:00:00 2001
From: Markus Lehtonen markus.lehto...@linux.intel.com
Date: Fri, 28 Nov 2014 18:28:51 +0200
Subject: [PATCH 1/9] pq: move switch_pq() to common
So that it can be re-used by the upcoming pq-rpm tool.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
gbp/scripts/common/pq.py | 10 ++
gbp/scripts/pq.py| 12 +---
tests/13_test_gbp_pq.py | 12 ++--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/gbp/scripts/common/pq.py b/gbp/scripts/common/pq.py
index d3c07d1..f7bae23 100644
--- a/gbp/scripts/common/pq.py
+++ b/gbp/scripts/common/pq.py
@@ -304,3 +304,13 @@ def drop_pq(repo, branch):
gbp.log.info(Dropped branch '%s'. % pq_branch)
else:
gbp.log.info(No patch queue branch found - doing nothing.)
+
+
+def switch_pq(repo, current):
+Switch to patch-queue branch if on base branch and vice versa
+if is_pq_branch(current):
+base = pq_branch_base(current)
+gbp.log.info(Switching to %s % base)
+repo.checkout(base)
+else:
+switch_to_pq_branch(repo, current)
diff --git a/gbp/scripts/pq.py b/gbp/scripts/pq.py
index 194145e..c32a36f 100755
--- a/gbp/scripts/pq.py
+++ b/gbp/scripts/pq.py
@@ -33,7 +33,7 @@ from gbp.patch_series import (PatchSeries, Patch)
from gbp.scripts.common.pq import (is_pq_branch, pq_branch_name, pq_branch_base,
parse_gbp_commands, format_patch,
switch_to_pq_branch, apply_single_patch,
- apply_and_commit_patch,
+ apply_and_commit_patch, switch_pq,
drop_pq, get_maintainer_from_control)
from gbp.dch import extract_bts_cmds
@@ -279,16 +279,6 @@ def rebase_pq(repo, branch):
GitCommand(rebase)([base])
-def switch_pq(repo, current):
-Switch to patch-queue branch if on base branch and vice versa
-if is_pq_branch(current):
-base = pq_branch_base(current)
-gbp.log.info(Switching to %s % base)
-repo.checkout(base)
-else:
-switch_to_pq_branch(repo, current)
-
-
def build_parser(name):
try:
parser = GbpOptionParserDebian(command=os.path.basename(name),
diff --git a/tests/13_test_gbp_pq.py b/tests/13_test_gbp_pq.py
index 910ce20..d88f7ae 100644
--- a/tests/13_test_gbp_pq.py
+++ b/tests/13_test_gbp_pq.py
@@ -21,7 +21,7 @@ import os
import logging
import unittest
-from gbp.scripts.pq import generate_patches, switch_pq, export_patches
+from gbp.scripts.pq import generate_patches, export_patches
import gbp.scripts.common.pq as pq
import gbp.patch_series
import tests.testutils as testutils
@@ -145,12 +145,12 @@ class TestExport(testutils.DebianGitTestRepo):
Test if we drop the patch-queue branch with --drop
repo = self.repo
start = repo.get_branch()
-pq = os.path.join('patch-queue', start)
-switch_pq(repo, start)
-self.assertEqual(repo.get_branch(), pq)
-export_patches(repo, pq, TestExport.Options)
+pq_branch = os.path.join('patch-queue', start)
+pq.switch_pq(repo, start)
+self.assertEqual(repo.get_branch(), pq_branch)
+export_patches(repo, pq_branch, TestExport.Options)
self.assertEqual(repo.get_branch(), start)
-self.assertFalse(repo.has_branch(pq))
+self.assertFalse(repo.has_branch(pq_branch))
def _patch_path(name):
--
1.8.4.5
From f153c5676cbd9f57310e97da67c1cb4ddb6bed4a Mon Sep 17 00:00:00 2001
From: Markus Lehtonen markus.lehto...@linux.intel.com
Date: Fri, 14 Sep 2012 13:40:14 +0300
Subject: [PATCH 2/9] GitRepository: add diff_status method
This is a method of getting the filename and status information of a
diff. That is, a list of files that changed and their status, added,
modified etc.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
gbp/git/repository.py
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
Hi, On 28/11/14 11:18, Guido Günther a...@sigxcpu.org wrote: On Thu, Nov 27, 2014 at 11:56:17PM +0100, Tzafrir Cohen wrote: Hi, On Thu, Nov 27, 2014 at 09:44:03PM +0100, Guido Günther wrote: Hi Tzafrir, On Thu, Nov 27, 2014 at 06:52:10PM +0200, Tzafrir Cohen wrote: Source: git-buildpackage Version: 0.6.22 Severity: wishlist Dear Maintainer, I attach a pretty trivial merge of the command gbp pq-rpm from the git-buildpackage-rpm tree. I basically included the script itself and added two patches it depended on. Those two patches are intended to make the patch queue branch name more configurable. If those patches are not acceptable, I'll try rewriting the script to avoid them. Thanks for the patch but usually I'm trying to cherry-pick form Markus tree directly. I'd be happy to add gbp pq-rpm, could you work out wich patches to cherry-pick from Markus github repo? The two first patches are cherry-picked from Markus's tree. The final one is basically a copy of the script itself and the help options it complained were missing. Yeah, I figured that out from the commit. We could actually pull in the make pq branch name configurable part iff that's consistent (also adds the necessary options to config.py / gbp pq as well so it becomes usable. We could even do without the configurable branch names. The code is bit messy anyway. There are two things we should address before that: * gbp-pq-rpm introduces several new options unsuppoted by gbp pq can we port them over. It's confusing to have different option sets for similar tools Yes, I basically agree with this. It would be nice to merge an initial version of the tool which is more or less on-par with the deb gbp-pq tool. * there are functions lq switch_pq and others which should be shared between the tools. Can these be moved over to gbp.common.pq? I'll look into that. This is a bit more complicated, at the moment, because the pq-rpm can have (upstream) version number in the pq branch name which involves parsing the rpm packaging files. One solution would be to refactor the code into a GbpPq class that would reside in gbp.common.pq and contain most of the functionality. There would be GbpPqRpm and GbpRpmDeb classes that would extend/override functionality where needed. This would not be a huge task. Another minor part missing: bash completion (and other completions). If we're down to that level of detail already (which is good) there's also the docs and the manpage. The bash completion is something I've had in my backlog for ages and which would be nice to have, indeed. But I guess we can do without it in the initial version. If you're willing to wait for few days I could look into this and provide a patchset with minimal pq-rpm implementation (i.e. all the new cmdline options, even configurable branch names, removed). What I'd like to have there are the unit tests. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682394: Acknowledgement (git-buildpackage: Provide more replacement strings)
On 4/13/13 12:09 PM, Guido Günther a...@sigxcpu.org wrote:
On Sat, Apr 13, 2013 at 03:23:43AM +0200, Daniel Dehennin wrote:
Hello,
I just began to work on this issue on a temporary branch[1].
I wonder if we could not factorize the string expansion across all tools
and how we could do it.
This would need a new section in gbp.conf
[replacements]
last_upstream = ...
foo = cmd1
bar = cmd2
Im undecided if the rhs should be evaluated by a shell or by python but
we probably want both.
Hmm, I dislike the idea of running arbitrary shell (or Python) code from
the command line. How about just allowing few git commands (through
gbp.git) and python regex or something.
I'm even planning to implement a '--no-hooks' command line option to
prevent running any hooks.
One option is to factorize the options management in reusable parsers
and let all tools use them with the parents option of
argparse.ArgumentParser, then we could add an expand method to the
options and use it when needed.
If you create a derived class from string and return that from optparse
you can use {foo} {bar}.format() whenever the actual option gets used
(not when evaluated during Option.parse()). Isn't ttmore what we want?
You'd need to override the format() method of that new string class of
course to fill in all values from replacements by default. Does this
make sense?
This probably makes more sense.
Thanks,
Markus
Any idea?
Regards.
Footnotes:
[1]
http://git.baby-gnu.net/gitweb/?p=git-buildpackage.git;a=shortlog;h=refs/
heads/feature/git-dch-define-more-replacement-strings
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694739: git-buildpackage: Use ColorizingStreamHandler to colorize log output
Hi, On 2012/11/29 at 20:34:26, Guido Günther wrote: On Thu, Nov 29, 2012 at 06:52:57PM +0100, Daniel Dehennin wrote: Package: git-buildpackage Version: 0.6.0~git20121124 Severity: wishlist Looking at the evolution of the experimental branch, I saw the addition of log colorization. I would like to point you to a library[1] I use in my python code. This looks interesting however we have the code already in place now. Any advantages to pull in another dependency (that's atm not packaged for Debian)? I'm cc'ing the orignal author of this enhancement. Yeah, looks good in principle. But, I'm now quite happy with the gbp logging :) Have to keep your library in mind, however, in case I need to write yet another gbp logger overhaul. Thanks, Markus It may interest you. Regards. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (90, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.6.0-rc3+hati.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-buildpackage depends on: ii devscripts 2.12.6 ii git 1:1.7.10.4-2 ii python 2.7.3-3 ii python-dateutil 1.5+dfsg-0.1 Versions of packages git-buildpackage recommends: pn cowbuildernone ii pristine-tar 1.26 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-8 -- no debconf information Footnotes: [1] https://code.google.com/p/logutils/ -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
