Bug#816645: devscripts testsuite failure on raspbian and presumablly other deratives that are not special-cased.

Osamu Aoki osamu at debian.org
Fri Mar 4 11:52:43 UTC 2016


Hi,

This is uupdate related problem but ...

On Thu, Mar 03, 2016 at 04:41:11PM +0000, Peter Green wrote:
> Package: devscripts
> Version: 2.15.10
> 
> Note: this started as a mailing list post on devscripts-devel ( http://lists.alioth.debian.org/pipermail/devscripts-devel/2016-January/004781.html http://lists.alioth.debian.org/pipermail/devscripts-devel/2016-February/004793.html
> )
> 
> Starting with version 2.15.10 devscripts started failing to build in
> raspbian stretch. Sepcifically it failed with
> 
> testFileExclusion
> uupdate --no-symlink --upstream-version 1+dfsg1 ../foo_1+dfsg1.orig.tar.xz
> uupdate: New Release will be 1+dfsg1-0raspbian1.
> uupdate: Untarring the new sourcecode archive ../foo_1+dfsg1.orig.tar.xz
> uupdate: debian/source/format is "3.0 (quilt)".
> uupdate: Auto-generating foo_0+dfsg1-1.debian.tar.xz
> uupdate: Unpacking the debian/ directory from version 0+dfsg1-1 worked fine.
> uupdate: Remember: Your current directory is the OLD sourcearchive!
> uupdate: Do a "cd ../foo-1+dfsg1" to see the new package
> ASSERT:uscan: Version should be 1+dfsg1-1 but 1+dfsg1-0raspbian1 expected:<1+dfsg1-0raspbian1>  but was:<1+dfsg1-1>

Aha... I am testing only on Debian and need feedback for other platform.

> In version 2.15.10 the method used in uupdate to generate version suffixes
> was changed.
> 
>  SUFFIX="1"
> 
>  if which dpkg-vendor >/dev/null 2>&1; then
> -    case "$(dpkg-vendor --query Vendor 2>/dev/null)" in
> - "Ubuntu")
> -            SUFFIX="0ubuntu1"
> -            ;;
> -    esac
> +  VENDER="$(dpkg-vendor --query Vendor 2>/dev/null|tr 'A-Z' 'a-z')"
> +  case "$VENDER" in
> +  debian) SUFFIX="1" ;;
> +  *) SUFFIX="0${VENDER}1" ;;
> +  esac
> +else
> +  SUFFIX="1"
>  fi

This is to address not just Ubuntu but Rasbian.  My change in 2015-09-16

> It's not clear to me why this change was made, the only thing I see in the
> changelog that seems related is

This is made to cope with Ubuntu and Rasbian versioning.

>   [ Benjamin Drung ]
>   * test_uscan: Fix failure in testFileExclusion due to wrong tarfile name
>     test on Ubuntu.
> 
> but that talks about changing the test, not about changing uscan itself. It
> also doesn't seem to match up as the changelog entry talks about fixing
> Ubuntu but the change changes the behaviour for everything except Debian and
> Ubuntu.

I only addressed Ubuntu in test_uscan with following 2015-09-06 
(I forgot to update this on 16th)

if which dpkg-vendor >/dev/null 2>&1; then
    case "$(dpkg-vendor --query Vendor 2>/dev/null)" in
        "Ubuntu")
            SUFFIX="0ubuntu1"
            ;;
    esac
fi

This is not good enough for Rasbian as I guess.

> If I modify test_uscan to expect -0<vendor>1 suffixes then testFileExclusion
> passes but other tests that passed before start to fail.
> 
> testWatch4WebNonNativeBZ2
> uscan warn: Possible OpenPGP signature found at:
>    http://localhost:50014/2.0/foo/ooo/foo-2.0.tar.gz.asc.
>    Please consider adding opts=pgpsigurlmangle=s/$/.asc/
>    to debian/watch.  see uscan(1) for more details.
> uscan: Newest version of foo on remote site is 2.0, local version is 1.0
> uscan:    => Newer package available from
>       http://localhost:50014/2.0/foo/ooo/foo-2.0.tar.gz
> ASSERT:uscan: Version should be 2.0-1 but 2.0-0raspbian1
> expected:<2.0-0raspbian1> but was:<2.0-1>
> 
> So it seems that uupdate is now using -0<vendor>1 on unknown derivatives but
> other tools are still using -1 on unknown derivatives. Thoughts on the best
> way to resolve this? (it seems to me that ideally the knowlage of how to
> generate version numbers for different derivatives would be centralised
> rather than duplicated).
> 
> Reverting the change to version number generation in uupdate results in a
> successful build on Raspbian.

I think the other way.

Test needs to be updated to cope with uupdate on non-Debian platform.

Osamu



More information about the devscripts-devel mailing list