Re: Looking for feedback on a recent upload
Dear Lumin,
I hope is still do not disturb.
I'm coming back to you for one more advice. Here is point by point list
of what I did with one question:
> I indeed spotted something that doesn't match the debian-science
> conventions:
>
> 1. Git repository layout in question
>
> File debian/source/format writes "3.0 (quilt)", so the master
> branch should hold the "packaging commits" instead of the
> "upstream commits". By the way, please always keep the
> "upstream" and "pristine-tar" branches up to date. In order
> to achieve that, you can use this command when importing
> a new upstream verison:
>
> │
> │ $ gbp import-orig --pristine-tar XXX_YYY.orig.tar.gz
> │
>
> More details can be found in Debian Science Team Policy[1].
I created a new tarball on GitHub and used it to create a pristine-tar
which I imported.
> 2. "watch" file not working.
>
> We often use "uscan"[2] to conveniently obtain an tarball from upstream.
> However the present watch file doesn't work anymore. Try to fix it
> like this:
>
> │
> │ version=4
> │ opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%toulbar2-$1.tar.gz%" \
> │ https://github.com/toulbar2/toulbar2/tags \
> │ (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
> │
>
> I can obtain a tarball via this watch file.
I used the watch file you provided. Thanks a lot. uscan does not complain.
> 3. Reproducibility problem.
>
> With the upstream tarball downloaded by uscan. The package doesn't
> build because the contents of git HEAD doesn't match with the
> tarball.
>
> Actually this makes it harder for the others to review your work :-)
This should be fine now since I follow the pristine-tar approach
> 4. Policy version and debhelper compatibility level.
>
> debian/control: "Standards-Version: 3.9.8"
> This version is quite old. Please check the policy check list [3]
> and upgrade it.
I upgraded to 4.1.4. Browse the policy page but didn't find any issue (I
just swapped to lines in the control file to use the same order as in
the policy, probably useless).
> Apart from that, the compat level is 9. This is just a
> recommend-to-fix. Have a look at manpage debhelper(7) and check
> the "COMPATIBILITY LEVELS" part if you are interested in this.
Upgraded to 10
> 5. Failed to build from source.
>
> I changed the source format to native[4] and tried to build it
> in docker. However it failed to build.
>
> │
> │ Start 200: Phase2_10_1.bep_2
> │ 200/200 Test #200: Phase2_10_1.bep_2 .................................. Passed 0.01 sec
> │
> │ 99% tests passed, 1 tests failed out of 200
> │
> │ Total Test time (real) = 43.65 sec
> │
> │ The following tests FAILED:
> │ 39 - Phase1_Toulbar_enum/latin0 (Failed)
> │ Errors while running CTest
> │ make[1]: *** [Makefile:155: test] Error 8
> │ make[1]: Leaving directory '/home/whalebuilder/toulbar2/obj-x86_64-linux-gnu'
> │ dh_auto_test: cd obj-x86_64-linux-gnu && make -j1 test ARGS\+=-j1 returned exit code 2
> │ make: *** [debian/rules:3: build] Error 2
> │ dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> │ debuild: fatal error at line 1152:
> │ dpkg-buildpackage -rfakeroot -us -uc -ui -j4 failed
> │
>
> Currently I have no idea about it at all. The problem is produced
> from git HEAD[5] of the salsa repo.
This was caused by a bug in the test system that depends on "bc" (binary
calculator). Build dependency added in control.
> 6. You have an RC bug.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831148
>
> It is FTBFS with GCC6. Since the default compiler is GCC7 now,
> Does it reporduce with GCC-7?
> If the bug doesn't exist anymore, you can close it with a changelog
> entry like this:
>
> │
> │ * import upstream release 1.0.0 . (Closes: #XXXXXX)
> │
Got it. It has been killed in upstream. The changelog now includes a
"Close" for it.
> 7. Please try to build it on Debian sid/unstable.
>
> Lintian didn't report anything about the standards version, which
> indicates that your building system is Debian stable. It ships
> an ancient lintian.
>
> A package can be built for Debian unstable with one of the following:
>
> Docker, sbuild, pbuilder, schroot
>
> I can see several lintian warnings and errors from the source package
> check. Please run lintian like this:
>
> │
> │ $ lintian -EviI --pedantic XXX_YYY.changes
> │
Tried with docker, Fixed various stuff.
When I try to build the package, there is a series of messages:
dpkg-source: warning: ignoring deletion of directory lib
dpkg-source: warning: ignoring deletion of directory lib/win32
dpkg-source: warning: ignoring deletion of directory lib/win32/gmp
dpkg-source: warning: ignoring deletion of directory lib/win32/gmp/info
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-4, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-6, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-5, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-2, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-3, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-8, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-1, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/info/gmp.info-7, use --include-removal to override
dpkg-source: warning: ignoring deletion of directory lib/win32/gmp/include
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/include/gmp.h, use --include-removal to override
dpkg-source: warning: ignoring deletion of directory lib/win32/gmp/lib
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/lib/libgmp.la, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
lib/win32/gmp/lib/libgmp.a, use --include-removal to override
which I would like to repair but do not know how. Google did not help.
My problem is that the upstream tar ball contains a directory with
binary libraries for Windows with bad licencing info. I need to remove
them in the debian packaging (which is Ok for toulbar2 that does not use
this except on Windows).
I did this with a "git rm -r lib"+commit in a branch deb/removeWin32lib
and merged in deb/integration.
This needs to be done otherwise it raises:
license-problem-gfdl-invariants in lintian (critical).
Is there a way to remove a directory for the debian branch ?
Kind regards
Thomas
Reply to: