Bug#761273: Use changelog release for control generation
Hi, just do the debian/rules control call in a session under the target release, e.g. under “cowbuilder --login”. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761273: Use changelog release for control generation
Package: openjdk-8 Version: 8u40~b04-2 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu utopic ubuntu-patch Hi guys, We got a backport request in Ubuntu for openjdk-8, with a note that gcc-4.9 → gcc-4.8 in d/control is required. I took a look and noticed some automagic generation, but this assumes that the release on the machine being built for is the same as the one the package is being prepared for. I don't think this assumption will always hold. How about the attached approach, which uses the changelog distribution instead? A modification might be to fall back to the old way in the UNRELEASED case? Don't have a solution for the distribution variable apart from maintaining a table mapping from release to distro, but I think that it's less likely to be a problem in practice. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -u openjdk-8-8u40~b04/debian/rules openjdk-8-8u40~b04/debian/rules --- openjdk-8-8u40~b04/debian/rules +++ openjdk-8-8u40~b04/debian/rules @@ -27,8 +27,8 @@ PKGVERSION := $(call vafilt,$(CHANGELOG_VARS),Version) distribution := $(shell lsb_release --id --short) -distrel := $(shell lsb_release --codename --short) -ifeq ($(distrel),n/a) +distrel := $(strip $(patsubst %-backports, %, $(patsubst %-updates, %, $(call vafilt,$(CHANGELOG_VARS),Distribution +ifeq ($(distrel),UNRELEASED) distrel := sid endif
Bug#761273: [Openjdk] Bug#761273: Use changelog release for control generation
Control: tags -1 - patch Am 12.09.2014 um 12:07 schrieb Iain Lane: We got a backport request in Ubuntu for openjdk-8, with a note that gcc-4.9 → gcc-4.8 in d/control is required. I took a look and noticed some automagic generation, but this assumes that the release on the machine being built for is the same as the one the package is being prepared for. I don't think this assumption will always hold. How about the attached approach, which uses the changelog distribution instead? A modification might be to fall back to the old way in the UNRELEASED case? Don't have a solution for the distribution variable apart from maintaining a table mapping from release to distro, but I think that it's less likely to be a problem in practice. I'd like to keep it this way. You usually do a test build on the target release anyway, don't you? Maybe check for a envvar TARGET_DISTRELEASE instead? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761273: [Openjdk] Bug#761273: Use changelog release for control generation
On Fri, Sep 12, 2014 at 12:24:42PM +0200, Matthias Klose wrote: […] I'd like to keep it this way. You usually do a test build on the target release anyway, don't you? Maybe check for a envvar TARGET_DISTRELEASE instead? The problem is the build-depends generation in d/control. If I debuild -S and then do a build in sbuild then it doesn't get updated for the release I'm building for (which is in debian/changelog), but the one I built the source package on. Then my test build has the wrong build-depends. (There's no solution I know of for syncs, but the current approach doesn't help there either) -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org