From owner at bugs.debian.org Fri Oct 31 01:09:13 2014 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 31 Oct 2014 01:09:13 +0000 Subject: [debhelper-devel] Processed: 766711 is also present in testing References: <20141031010111.GA17807@ugent.be> Message-ID: Processing commands for control at bugs.debian.org: > found 766711 9.20141003 Bug #766711 [debhelper] debhelper: Dependency added by dh_installdocs --link-doc breaks binary-only NMUs Bug #766795 [debhelper] afterstep not binnmu safe and not installable in sid Marked as found in versions debhelper/9.20141003. Marked as found in versions debhelper/9.20141003. > thanks Stopping processing here. Please contact me if you need assistance. -- 766711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766711 766795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766795 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Fri Oct 31 01:09:13 2014 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 31 Oct 2014 01:09:13 +0000 Subject: [debhelper-devel] Processed: 766711 is also present in testing References: <20141031010111.GA17807@ugent.be> Message-ID: Processing commands for control at bugs.debian.org: > found 766711 9.20141003 Bug #766711 [debhelper] debhelper: Dependency added by dh_installdocs --link-doc breaks binary-only NMUs Bug #766795 [debhelper] afterstep not binnmu safe and not installable in sid Marked as found in versions debhelper/9.20141003. Marked as found in versions debhelper/9.20141003. > thanks Stopping processing here. Please contact me if you need assistance. -- 766711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766711 766795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766795 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From adelia.mendes at tce.am.gov.br Sat Nov 1 00:33:43 2014 From: adelia.mendes at tce.am.gov.br (Ruth Horwitz) Date: Fri, 31 Oct 2014 20:33:43 -0400 (AMT) Subject: [debhelper-devel] Congratulations In-Reply-To: <1417932794.1548062.1414801975312.JavaMail.root@tce.am.gov.br> Message-ID: <1387541232.1548129.1414802023870.JavaMail.root@tce.am.gov.br> Dear E-mail Account User, After a random automated selection of email addresses over the Internet, your email emerged as one of our special winners to receive ?3,252,590.00 and is attached to the following details: FILE CATEGORY - LOTTTO-ENGLAND/01/2014 Ticket No: 13/299 Reference Number: 89,DW,83/LOTTO-LUCKY5 To confirm the authenticity and validity of your winnings as well as to commence receipts of your entitlement, you MUST FORWARD a copy of this announcement as well as your FULL NAMES - VALID MOBILE/CELL NO. - COUNTRY OF RESIDENCE - to our Winnings Director via contact information below: Mr.Michael Thompson, Winnings Director, Automated Winnings Department, Email: michael_wd at foxmail.com Yours faithfully, Ruth Horwitz, Automated Winnings Coordinator, Automated Winnings Department Email: rhorwitz984 at gmail.com From smcv at debian.org Sun Nov 2 13:46:02 2014 From: smcv at debian.org (Simon McVittie) Date: Sun, 2 Nov 2014 13:46:02 +0000 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <544C25ED.8070502@debian.org> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> Message-ID: <20141102134602.GA21493@reptile.pseudorandom.co.uk> On Sun, 26 Oct 2014 at 00:36:29 +0200, Robert Luberda wrote: > > It seems after the binnmu for the libjpeg-turbo transition afterstep is > > no longer installable in sid (and hence the binnmu won't migrate and the > > transition won't complete in testing). > > This is debhelper bug. I've just uploaded afterstep 2.2.12-3, which > removes usage of {misc:Depends} as a work-around. I'm not so sure that this isn't a bug in afterstep, actually. Summary of the bad situation: suppose we have an arch-independent package, foo-common, and an arch-dependent package, foo-bin. If foo-bin uses dh_installdocs --link-doc=foo-common then bad things occur. The current bad thing is that foo-bin Depends: foo-common (= ${binary:Version}) which is not binNMU-safe: when foo-bin is binNMU'd, foo-common will not satisfy the dependency. The solution proposed by Robert Luberda seems to be to change debhelper so that foo-bin Depends: foo-common (= ${source:Version}) instead, in the case where foo-common is arch-independent. However, that would mean that the changelog.Debian.amd64.gz (or whatever) for foo-bin is not provided by anything, so the binNMU is not documented anywhere. Is that itself considered to be a bad thing, and possibly a policy violation? The solution I used in telepathy-glib was to link the documentation of all arch-dependent packages to the shared library (which in practice they all depend on anyway), and leave the one arch-independent package alone: override_dh_installdocs: dh_installdocs -a --link-doc=libtelepathy-glib0 dh_installdocs -i Is that considered to be best-practice? S From smcv at debian.org Sun Nov 2 13:46:02 2014 From: smcv at debian.org (Simon McVittie) Date: Sun, 2 Nov 2014 13:46:02 +0000 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <544C25ED.8070502@debian.org> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> Message-ID: <20141102134602.GA21493@reptile.pseudorandom.co.uk> On Sun, 26 Oct 2014 at 00:36:29 +0200, Robert Luberda wrote: > > It seems after the binnmu for the libjpeg-turbo transition afterstep is > > no longer installable in sid (and hence the binnmu won't migrate and the > > transition won't complete in testing). > > This is debhelper bug. I've just uploaded afterstep 2.2.12-3, which > removes usage of {misc:Depends} as a work-around. I'm not so sure that this isn't a bug in afterstep, actually. Summary of the bad situation: suppose we have an arch-independent package, foo-common, and an arch-dependent package, foo-bin. If foo-bin uses dh_installdocs --link-doc=foo-common then bad things occur. The current bad thing is that foo-bin Depends: foo-common (= ${binary:Version}) which is not binNMU-safe: when foo-bin is binNMU'd, foo-common will not satisfy the dependency. The solution proposed by Robert Luberda seems to be to change debhelper so that foo-bin Depends: foo-common (= ${source:Version}) instead, in the case where foo-common is arch-independent. However, that would mean that the changelog.Debian.amd64.gz (or whatever) for foo-bin is not provided by anything, so the binNMU is not documented anywhere. Is that itself considered to be a bad thing, and possibly a policy violation? The solution I used in telepathy-glib was to link the documentation of all arch-dependent packages to the shared library (which in practice they all depend on anyway), and leave the one arch-independent package alone: override_dh_installdocs: dh_installdocs -a --link-doc=libtelepathy-glib0 dh_installdocs -i Is that considered to be best-practice? S From robert at debian.org Sun Nov 2 21:16:32 2014 From: robert at debian.org (Robert Luberda) Date: Sun, 02 Nov 2014 22:16:32 +0100 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <20141102134602.GA21493@reptile.pseudorandom.co.uk> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> <20141102134602.GA21493@reptile.pseudorandom.co.uk> Message-ID: <54569F30.2040003@debian.org> Simon McVittie writes: > The solution proposed by Robert Luberda seems to be to change debhelper > so that foo-bin Depends: foo-common (= ${source:Version}) instead, > in the case where foo-common is arch-independent. However, that would > mean that the changelog.Debian.amd64.gz (or whatever) for foo-bin > is not provided by anything, so the binNMU is not documented anywhere. Yes, but is it important to have it documented? To be honest I can't really understand why autobuilders adds those changelog entries, I can only guess that it is easier to force new version of package this way. Please also note that normal autobuilds do not document theirs normal operation into changelog, even though they could use (for various reasons) versions of build-dependent packages different than maintainer used for they source+binary upload. > Is that itself considered to be a bad thing, and possibly a policy violation? Which point of the policy? See this footnote 116: [116] Please note that this does not override the section on changelog files below, so the file /usr/share/doc/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version). AFAIK binNMU does not change "source package and [source] version". > > The solution I used in telepathy-glib was to link the documentation of > all arch-dependent packages to the shared library (which in practice > they all depend on anyway), and leave the one arch-independent > package alone: Which means that you assume that nobody will never do binNMU of the arch-independent package :) (Yes, I know that most probably such assumption is correct, but anyway...) Regards, robert From robert at debian.org Sun Nov 2 21:16:32 2014 From: robert at debian.org (Robert Luberda) Date: Sun, 02 Nov 2014 22:16:32 +0100 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <20141102134602.GA21493@reptile.pseudorandom.co.uk> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> <20141102134602.GA21493@reptile.pseudorandom.co.uk> Message-ID: <54569F30.2040003@debian.org> Simon McVittie writes: > The solution proposed by Robert Luberda seems to be to change debhelper > so that foo-bin Depends: foo-common (= ${source:Version}) instead, > in the case where foo-common is arch-independent. However, that would > mean that the changelog.Debian.amd64.gz (or whatever) for foo-bin > is not provided by anything, so the binNMU is not documented anywhere. Yes, but is it important to have it documented? To be honest I can't really understand why autobuilders adds those changelog entries, I can only guess that it is easier to force new version of package this way. Please also note that normal autobuilds do not document theirs normal operation into changelog, even though they could use (for various reasons) versions of build-dependent packages different than maintainer used for they source+binary upload. > Is that itself considered to be a bad thing, and possibly a policy violation? Which point of the policy? See this footnote 116: [116] Please note that this does not override the section on changelog files below, so the file /usr/share/doc/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version). AFAIK binNMU does not change "source package and [source] version". > > The solution I used in telepathy-glib was to link the documentation of > all arch-dependent packages to the shared library (which in practice > they all depend on anyway), and leave the one arch-independent > package alone: Which means that you assume that nobody will never do binNMU of the arch-independent package :) (Yes, I know that most probably such assumption is correct, but anyway...) Regards, robert From smcv at debian.org Sun Nov 2 21:38:05 2014 From: smcv at debian.org (Simon McVittie) Date: Sun, 02 Nov 2014 21:38:05 +0000 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <54569F30.2040003@debian.org> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> <20141102134602.GA21493@reptile.pseudorandom.co.uk> <54569F30.2040003@debian.org> Message-ID: <5456A43D.4000408@debian.org> On 02/11/14 21:16, Robert Luberda wrote: >> The solution I used in telepathy-glib was to link the documentation of >> all arch-dependent packages to the shared library (which in practice >> they all depend on anyway), and leave the one arch-independent >> package alone: > > Which means that you assume that nobody will never do binNMU of the > arch-independent package :) No, our arch-independent package ships its own independent /usr/share/doc subdirectory which will always contain its appropriate changelog, so it doesn't need any dependency on the library (let alone a lockstep dependency). If your arch-dep and arch-indep packages *do* have a versioned dependency relationship for other reasons (e.g. the arch-dep package is not just documentation), then because arch-dep and arch-indep can already have version skew, you *already* have to either assume that arch-indep will never be binNMU'd (which is a safe assumption until Debian's buildd infrastructure knows how to build Architecture:all packages, at which point there will be much rejoicing): Package: foo-bin Depends: foo-common (= ${source:Version}) or use a slightly less strict relationship, perhaps something like this: Package: foo-bin Depends: foo-common (>= ${source:Version}), foo-common (<= ${binary:Version}) Regards, S From smcv at debian.org Sun Nov 2 21:38:05 2014 From: smcv at debian.org (Simon McVittie) Date: Sun, 02 Nov 2014 21:38:05 +0000 Subject: [debhelper-devel] Bug#766795: afterstep not binnmu safe and not installable in sid In-Reply-To: <54569F30.2040003@debian.org> References: <544C1A31.40009@p10link.net> <544C25ED.8070502@debian.org> <20141102134602.GA21493@reptile.pseudorandom.co.uk> <54569F30.2040003@debian.org> Message-ID: <5456A43D.4000408@debian.org> On 02/11/14 21:16, Robert Luberda wrote: >> The solution I used in telepathy-glib was to link the documentation of >> all arch-dependent packages to the shared library (which in practice >> they all depend on anyway), and leave the one arch-independent >> package alone: > > Which means that you assume that nobody will never do binNMU of the > arch-independent package :) No, our arch-independent package ships its own independent /usr/share/doc subdirectory which will always contain its appropriate changelog, so it doesn't need any dependency on the library (let alone a lockstep dependency). If your arch-dep and arch-indep packages *do* have a versioned dependency relationship for other reasons (e.g. the arch-dep package is not just documentation), then because arch-dep and arch-indep can already have version skew, you *already* have to either assume that arch-indep will never be binNMU'd (which is a safe assumption until Debian's buildd infrastructure knows how to build Architecture:all packages, at which point there will be much rejoicing): Package: foo-bin Depends: foo-common (= ${source:Version}) or use a slightly less strict relationship, perhaps something like this: Package: foo-bin Depends: foo-common (>= ${source:Version}), foo-common (<= ${binary:Version}) Regards, S