package fails to build because of upstream modifications
anarcat opened this issue · comments
hi
i have tried building the package here:
[1029]anarcat@curie:tuptime$ DIST=sid ARCH=amd64 gbp buildpackage
dh clean --with=systemd
dh_testdir
dh_auto_clean
dh_clean
gbp:info: Creating tuptime_3.3.0.orig.tar.gz from '3.3.0'
gbp:info: Exporting 'HEAD' to '/home/anarcat/src/build-area/tuptime-tmp'
gbp:info: Moving '/home/anarcat/src/build-area/tuptime-tmp' to '/home/anarcat/src/build-area/tuptime-3.3.0'
Building with cowbuilder for distribution sid, architecture amd64
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: dh-systemd (>= 1.5)
W: Unmet build-dependency in source
dpkg-buildpackage: info: source package tuptime
dpkg-buildpackage: info: source version 3.3.0-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Ricardo Fraile <rfraile@rfraile.eu>
dpkg-source --before-build tuptime-3.3.0
fakeroot debian/rules clean
dh clean --with=systemd
dh_testdir
dh_auto_clean
dh_clean
dpkg-source -b tuptime-3.3.0
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building tuptime using existing ./tuptime_3.3.0.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
tuptime-3.3.0/README.md
tuptime-3.3.0/tuptime-manual.txt
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/tuptime_3.3.0-3.diff.MSwWeC
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b tuptime-3.3.0 gave error exit status 2
gbp:error: '/usr/bin/git-pbuilder' failed: it exited with 2
[1030]anarcat@curie:tuptime1$
The important bit is:
[...]
dpkg-source: info: local changes detected, the modified files are:
tuptime-3.3.0/README.md
tuptime-3.3.0/tuptime-manual.txt
dpkg-source: error: aborting due to unexpected upstream changes [...]
This is because of the changes to the readme and manual made in #30 and #29. Since those are changes that affect files outside of the debian/ directory, dpkg-source finds (correctly) that there are non-debian changes to the package that are not reflected the tarball.
i think the simplest fix may be for you toswitch back to making this a "native" package. i think this would be simply changing the version number to (say) 3.3.1 and changing the debian/source/format to 3.0 (native).
this does mean that you will need to tag a new release here any time you want to upload a new package into Debian, but that's you are doing anyways.
as things stand, i can't upload the package like this because of those changes.
Hello,
Reading the following doc, I think that it will look better If I release a new version (3.3.1) and over it, release the Debian version (3.3.1-1). For me it's not a problem, what do you recomend? :)
"When to use a native vs a non-native package
Default to making packages non-native. You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native..."
I disagree with this:
You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives.
I maintain a few native Debian packages that are useful outside of Debian. It makes it simpler for me to not have to make two releases every time I publish a new version (one for debian, one for the rest). I think the above should include an exception when upstream manages the package as well.
To quote another part, which I agree with:
The disadvantage of a native package is that there is no clear separation between "upstream code" and "Debian changes". This means that it is harder to separate out patches that should be sent upstream, and unnecessarily muddies the waters of who is responsible for what
That's not a problem for us: you are actually responsible for both the upstream code and the Debian changes.
Additionally, a native package requires a whole new upstream source tarball to be created whenever there are packaging changes (which wastes bandwidth and mirror space), while a non-native package only requires the upload of a new Debian packaging file, which is typically much smaller.
That shouldn't be a problem either - we can ship debian-specific changes along with normal changes when necessary.
It's your call, really: if you want to manage the Debian releases, make a native package. If you just want to manage your regular upstream releases, make a non-native package, and I will manage the debian/ subdir. That could involve changing the Vcs-Git fields, maintainers and so on, however...
Ok, you have more experience and know better the right way, no problem at all.
I did the changes and lintian only report a warning with "latest-debian-changelog-entry-changed-to-native" which is right.
Please, let me know if it's needed anything else.
Thanks,
that looks good, i'll upload shortly.
done!
just in time! :)
by the way, we are too late to get new things in stretch now. i suggest you now treat the 3.3.x branch as a LTS branch that will only receive critical and security fixes from now on. to get an idea of what can still get through the freeze, see this:
https://release.debian.org/stretch/freeze_policy.html
https://www.debian.org/Bugs/Developer#severities