New xmltooling 1.6.3

[Ferenc Wágner]

Etienne Dysli-Metref <etienne.dysli-metref at switch.ch> writes:

> On 16/01/18 15:42, Ferenc Wágner wrote:
>
>> It's a bit more complicated (because the upstream/latest branch records
>> the contents of the officially released upstream tarballs, which
>> themselves can be reproduced with the help of the pristine-tar branch,
>> and the merge of the master tag is notation only to help tracking
>> patches) and also much simpler (because gbp helps with the bookkeeping):
>
> Oh I thought, since upstream is using Git too, that everything was
> merged from upstream branches, without tarballs... ;)

No-no, the tarballs are sacrosanct. :)

>> gbp pq import (the patches may not apply after the tarball import)
>> uscan --report (make sure you'll get the expected version in the next step)
>> gbp import-orig --upstream-vcs-tag=1.6.3 --uscan
>> gbp pq rebase (resolve conflicts now, if any)
>> gbp pq export
>
> I tried these commands on a fresh clone of the repository (cloned with
> `gbp clone --debian-branch=debian/master
> --upstream-branch=upstream/latest --pristine-tar
> ssh://git.debian.org/git/pkg-shibboleth/xmltooling.git`) and, at this
> step, the two new commits in version 1.6.3 (compared to 1.6.2) appear as
> patches in the patch queue.

I'm baffled.  Did gbp clone leave you on the debian/master branch?  If
not, the lack of gbp configuration could certainly cause problems.

> git status
>> On branch debian/master
>> Your branch is up-to-date with 'origin/debian/master'.
>> Changes not staged for commit:
>>   (use "git add <file>..." to update what will be committed)
>>   (use "git checkout -- <file>..." to discard changes in working directory)
>> 
>> 	modified:   debian/patches/Add-more-forgotten-test-result-prints.patch
>> 	modified:   debian/patches/Add-separate-pkg-config-file-for-xmltooling-lite.patch
>> 	modified:   debian/patches/Disable-forcing-of-libtool-silent.patch
>> 	modified:   debian/patches/Discover-xerces-xmlsec-openssl-and-curl-via-pkg-conf.patch
>> 	modified:   debian/patches/Enable-the-dot-feature-of-Doxygen.patch
>> 	modified:   debian/patches/Fail-configuration-if-dlopen-is-not-found.patch
>> 	modified:   debian/patches/Finish-separating-flags-use-_LIBADD.patch
>> 	modified:   debian/patches/Get-new-pthread-checks-from-the-Autoconf-Archive.patch
>> 	modified:   debian/patches/Make-pkgconfigdir-configurable.patch
>> 	modified:   debian/patches/Make-pkgxmldir-configurable.patch
>> 	modified:   debian/patches/Print-result-of-CURLINFO_TLS_SSL_PTR-test.patch
>> 	modified:   debian/patches/Propagate-requirements-into-our-pkg-config-file.patch
>> 	modified:   debian/patches/Remove-.pl-extension-of-cxxtestgen.patch
>> 	modified:   debian/patches/Use-pkg-config-for-log4shib-log4cpp.patch
>> 	modified:   debian/patches/series
>> 
>> Untracked files:
>>   (use "git add <file>..." to include in what will be committed)
>> 
>> 	debian/patches/Bump-version.patch
>> 	debian/patches/CPPXT-127-Block-entity-reference-nodes-during-unmarshalli.patch
>> 
>> no changes added to commit (use "git add" and/or "git commit -a")
>
> This doesn't feel right to me. Shouldn't there be a `gbp pq switch` to
> debian/master before running `gbp import-orig`?

That shouldn't be necessary, gbp import-orig reads the branch names from
debian/gbp.conf.  I tested the above command chain on my current
checkout, and it worked perfectly with gbp 0.8.12.2.  I've never used
gbp clone, though.
-- 
Feri