Bug#334164: Release goal proposal: remove yada
severity 334164 serious thanks On 4 August 2011 13:14, Adam D. Barratt a...@adam-barratt.org.uk wrote: To get a fuller picture, what are the changes being made to each of the files in question and when/where are they being made? You mentioned earlier that cleaning the package would lead to changes being made - it sounds like the above build may well fail part of the autobuilding section of the RC policy; specifically: debian/rules must include the targets: clean, binary, binary-arch, binary-indep and build; and these targets cannot require any interaction with the user. The build target must not do anything that requires root privileges. These targets must not change the package's build-dependencies or the changelog. Thanks for pointing this out. Indeed, the build-dependencies are potentially modified in all of those targets (including just clean), and this has been against the RC policy since etch (most likely introduced at a later time than the previous discussion on this bug). So I'm upgrading the severity to serious on those grounds, if there are no objections. -- Tim Retout dioc...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334164: Release goal proposal: remove yada
[Forwarding to bug too.] On 4 August 2011 10:07, Ricardo Mones mo...@debian.org wrote: I don't think this situation is even possible: you have to freeze things before release, and that includes helpers. And if you have to do that because a grave problem on the helper affecting packages build process you should issue binNMUs on the packages using it to ensure the problem is solved with the new helper version before releasing. Right; but the helper being frozen does not mean that we binNMU every package depending on it? See for example: yada version 0.55 is in stable. aylet - Build-Depends: yada (= 0.53) in stable. cvsconnect - Build-Depends: yada (= 0.48) in stable. etc. If you try rebuilding these in a stable chroot, you'll get a different debian/rules and debian/control in the new source package. If yada were actively maintained, the changes could be a lot more drastic. The best, of course, are found in experimental: libhttp-davserver-perl: Build-Depends: yada (= 0.21) securecgi: Build-Depends: yada (= 0.23) and FTBFS because automake1.8 no longer exists - I'll go and file a bug. I strongly suspect the ftp-masters will not allow packages through NEW that contain yada, but that it's not in the FAQ because not that many people bother to try. Kind regards, -- Tim Retout dioc...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334164: Release goal proposal: remove yada
On Thu, Aug 04, 2011 at 12:03:10PM +0100, Tim Retout wrote: On 4 August 2011 10:07, Ricardo Mones mo...@debian.org wrote: I don't think this situation is even possible: you have to freeze things before release, and that includes helpers. And if you have to do that because a grave problem on the helper affecting packages build process you should issue binNMUs on the packages using it to ensure the problem is solved with the new helper version before releasing. Right; but the helper being frozen does not mean that we binNMU every package depending on it? Err, I think I lost something here... I meant you binNMU if you have to upload a new helper version to fix something affecting build process, i.e., something you have to really verify. I think this applies to every helper in the situation you described, not only yada. See for example: yada version 0.55 is in stable. aylet - Build-Depends: yada (= 0.53) in stable. cvsconnect - Build-Depends: yada (= 0.48) in stable. etc. If you try rebuilding these in a stable chroot, you'll get a different debian/rules and debian/control in the new source package. If yada were actively maintained, the changes could be a lot more drastic. According the bug response, the only change to build depends should be the yada version number (which would become 0.55), and rules should be the same. If that's not true then I would agree the problem is more serious. The best, of course, are found in experimental: libhttp-davserver-perl: Build-Depends: yada (= 0.21) securecgi: Build-Depends: yada (= 0.23) and FTBFS because automake1.8 no longer exists - I'll go and file a bug. Yeah, same as before, but what I see here is packages with a lazy or inexistent maintainer, which should have uploaded some update so the yada version numbers were current. As said not a yada problem itself. Imagine some maintainer using debhelper which refuses to bump compat level, do we remove debhelper or the package? Like is already done with other changes, make usign yada $testing_ver - 1 (for example) a serious bug and things would improve (either packages are fixed or removed). Futhermore, this can be automated :) I strongly suspect the ftp-masters will not allow packages through NEW that contain yada, but that it's not in the FAQ because not that many people bother to try. Umm, that could be too :) any ftp-master around to confirm? -- Ricardo Mones ~ Physics is like sex: sure, it may give some practical results, but that's not why we do it.Richard Feynman signature.asc Description: Digital signature
Bug#334164: Release goal proposal: remove yada
On 4 August 2011 12:52, Ricardo Mones rica...@mones.org wrote: According the bug response, the only change to build depends should be the yada version number (which would become 0.55), and rules should be the same. If that's not true then I would agree the problem is more serious. Yep, that is not true, and I would like the release team to override the maintainer's opinion of the severity. Here's what happens if aylet is rebuilt after just 'dch -i', for example: $ diffstat aylet-debdiff changelog |6 ++ control |2 +- rules |6 +++--- 3 files changed, 10 insertions(+), 4 deletions(-) The fact that the rules change is so small is because we're only talking a few minor versions. In principle the rules and control files could be entirely different. Yes, perhaps we could make dependencies on old versions of yada RC, but the real problem here is yada. This is completely different to debhelper compat versions. Kind regards, -- Tim Retout dioc...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334164: Release goal proposal: remove yada
On Thu, 4 Aug 2011 13:07:05 +0100, Tim Retout wrote: On 4 August 2011 12:52, Ricardo Mones rica...@mones.org wrote: According the bug response, the only change to build depends should be the yada version number (which would become 0.55), and rules should be the same. If that's not true then I would agree the problem is more serious. Yep, that is not true, and I would like the release team to override the maintainer's opinion of the severity. Here's what happens if aylet is rebuilt after just 'dch -i', for example: $ diffstat aylet-debdiff changelog |6 ++ control |2 +- rules |6 +++--- 3 files changed, 10 insertions(+), 4 deletions(-) [...] Yes, perhaps we could make dependencies on old versions of yada RC, but the real problem here is yada. This is completely different to debhelper compat versions. To get a fuller picture, what are the changes being made to each of the files in question and when/where are they being made? You mentioned earlier that cleaning the package would lead to changes being made - it sounds like the above build may well fail part of the autobuilding section of the RC policy; specifically: debian/rules must include the targets: clean, binary, binary-arch, binary-indep and build; and these targets cannot require any interaction with the user. The build target must not do anything that requires root privileges. These targets must not change the package's build-dependencies or the changelog. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334164: Release goal proposal: remove yada
On 2 August 2011 13:24, Ricardo Mones mo...@debian.org wrote: From the dialog on the bug seems only Build-Depends are adjusted by the packages existing in the build environment, i.e., not arbitrary rewritting but a precise one. What has changed in this regard to make it serious? Allow me to focus on this issue, because it sets yada apart from debhelper, cdbs or packages without any helpers. I will CC the bug in question. Firstly, the scope of the rewriting is greater than merely the Build-Depends field. The entire control file in the source package (not just in the binary packages) is regenerated from debian/packages during each build - indeed, so is debian/rules. Any manual modifications to debian/control or debian/rules are likely to be overwritten when 'debclean' is run. Secondly, consider the case where yada is updated during the course of a release cycle, and a package using yada is not rebuilt before the release: 1. yada-0.55-1 is uploaded. 2. foo-0.1-1 is uploaded - Build-Depends: yada (= 0.55) 3. yada-0.56-1 is uploaded. 4. Release happens. 5. Security bug is found in the 'foo' package. Then the security update for 'foo' will be given a different Build-Depends line from foo-0.1-1. If any other details of how control or rules files are generated have changed in yada 0.56, then these will also be applied to the security update. This makes it difficult to produce a minimal diff for a security update (or even an NMU in unstable) for a package using yada, and increases the risk of unintentional changes. The same problems do not occur with other methods of building packages, because the source packages are not automatically modified. Kind regards, -- Tim Retout dioc...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334164: Release goal proposal: remove yada
On 3 August 2011 14:24, Tim Retout dioc...@debian.org wrote: Firstly, the scope of the rewriting is greater than merely the Build-Depends field. By the way, in case there is any doubt that this bug should be RC, turning on automagic use of the equivalent feature in cdbs qualifies for a reject from the ftp-masters: http://ftp-master.debian.org/REJECT-FAQ.html http://bugs.debian.org/311724 Even if removal of yada does not qualify for a release goal, the release team could choose to upgrade the severity of bug #334164. Kind regards, -- Tim Retout dioc...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
