Bug#690750: Broken links in developers-reference as published on the Debian's website
Hi, Holger Wansing wrote: > > Proposal: maybe the easiest way to make all variants (view via debian.org > and opened locally) work correctly, would be to change it this way: > > "This page is also available in > https://www.debian.org/doc/devel-manuals#devref";>French, German, > Italian, Russian, and Japanese." > > since the links on that page are fine and can be linked from everywhere > with one single static link. > Of course, there are still some corner cases which do not work (for example, > when you have the packages installed locally, you cannot switch from the > local english to the local german version via that links, and when you > have no internet connection, you also get an irritating situation), but most > usecases should be fine, and it would be an improvement compared to the > current situation, where all links do not work! > > Would fix #690750 and #912724. > > > Comments? If noone objects shortly, I will commit this next weekend then. Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#845715: Required targets must not write outside of the source package tree
On Sat, Nov 10, 2018 at 08:42:27PM -0700, Sean Whitton wrote: > Hello, > > On Sat 03 Nov 2018 at 11:42PM +0100, Bill Allombert wrote: > > >> How about: > >> > >> As an exception, required targets may write to the directory specified > >> by the ``TMPDIR`` environment variable (or ``/tmp`` if that is not > >> set), provided that files created in that directory are deleted before > >> the target completes and are not reused by subsequent executions of > >> the target. > >> > >> This explicitly states that this is an environment variable and makes it > >> clear that it refers to a directory. > > > > I may be wrong but I expect that a lot of packages targets leaves stray > > files and directory in /tmp (that are created by mktemp but not removed) > > but not reused, and also that some of them fail to honor TMPDIR. > > > > Do we have some data about this ? > > There isn't any data about this that I know of. > > The patch says > > provided that files created in that directory are deleted before the > target completes and are not reused by subsequent executions of the > target. > > rather than > > but files created in that directory must be deleted before the > targets completes and must not be reused by subsequent executions of > the target. I am not sure I see the difference. Do you imply something like but files created in that directory SHOULD be deleted before the targets completes and MUST not be reused by subsequent executions of the target. > so I don't think applying this patch would make a package RC-buggy > simply because it left some things behind in /tmp. This is my concern, yes. > On the other hand, if a package built differently the second time > because of some things left behind in /tmp, that would surely already be > considered to be a bug, possibly RC, depending on what the differences > were. Oh, of course I agree with that. What about the severity of using /tmp even if TMPDIR is set ? I do not think it is RC outside of the build process so it would be inconvenient. (note that if everything honor TMPDIR, the issue of stray tmpfiles is easily fixed by export TMPDIR=`mktemp -d` ... rm -r $TMPDIR unset TMPDIR ) Cheers, -- Bill. Imagine a large red swirl here.
Bug#824495: debian-policy: Source packages "can" declare relationships
On Sat, 10 Nov 2018 at 19:29:03 -0700, Sean Whitton wrote: > On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote: > >(ii) output packages with additional features or functionality. > >Such additional features MAY imply additional functional runtime > >dependencies, which then SHOULD be represented in the output > >packages' metadata. In this case the additional packages > >SHOULD NOT be declared in Build-Conflicts. > > Do we really want (ii)? It seems like a recipe for all sorts of > confusion. Do any packages currently work like that? I don't have any concrete examples, and I'd argue that they are not best-practice, but they almost certainly exist in the archive. This will happen whenever an Autoconf package has a feature enabled by an "automagic" dependency, the maintainer has not enabled the feature for all Debian users by adding its required package to B-D or explicitly enabling it with --with-foo or --enable-foo (either deliberately, or because they didn't notice the feature being added), and the maintainer has also not explicitly disabled it with --without-foo or --disable-foo. For instance, dbus has optional support for using AppArmor policy to decide which messages to deliver. If its maintainer hadn't noticed that feature being added, then it wouldn't have B-D: libapparmor-dev or ./configure --enable-apparmor, but it also wouldn't have ./configure --disable-apparmor, resulting in the upstream default behaviour (AppArmor-related features enabled if and only if libapparmor-dev is installed). I think the best practice is for maintainers to notice new features being added, make a deliberate decision on what to enable (in an architecture- or kernel-specific way if appropriate), and use the equivalent of --disable-apparmor for any feature we don't (yet?) want to enable. smcv
Bug#845715: Required targets must not write outside of the source package tree
On Sat, Nov 10, 2018 at 08:38:07PM -0700, Sean Whitton wrote: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index dc80243..3c6c9d5 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -291,6 +291,20 @@ For packages in the main archive, no required targets > may attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. > > +Required targets must not attempt to write outside of the unpacked > +source package tree. There are two exceptions. Firstly, the binary > +targets may write the binary packages to the parent directory of the > +unpacked source package tree. Secondly, required targets may write to > +the directory specified by the ``TMPDIR`` environment variable (or > +``/tmp`` if that is not set), provided that files created in that > +directory are deleted before the target completes and are not reused > +by subsequent executions of the target. > + > +This restriction is intended to prevent source package builds creating > +and depending on state outside of themselves, thus affecting multiple > +independent rebuilds. In particular, the required targets must not > +attempt to write into ``HOME``. > + seconded, thanks. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#824495: debian-policy: Source packages "can" declare relationships
Hello, On Sun 11 Nov 2018 at 11:31AM GMT, Simon McVittie wrote: > I think the best practice is for maintainers to notice new features being > added, make a deliberate decision on what to enable (in an architecture- > or kernel-specific way if appropriate), and use the equivalent of > --disable-apparmor for any feature we don't (yet?) want to enable. Right. ISTM that it would be a bug if this was not done, which is why it seems unwise to include Ian's (ii) in Policy. -- Sean Whitton signature.asc Description: PGP signature
Bug#845715: Required targets must not write outside of the source package tree
Hello Bill, On Sun 11 Nov 2018 at 11:41AM +0100, Bill Allombert wrote: > I am not sure I see the difference. Do you imply something like > > but files created in that directory SHOULD be deleted before the > targets completes and MUST not be reused by subsequent executions of > the target. That's basically how I was reading it, yes. > What about the severity of using /tmp even if TMPDIR is set ? > I do not think it is RC outside of the build process so it would > be inconvenient. The current wording makes that RC-buggy, indeed. What exactly do you mean by "not RC outside of the build process"? -- Sean Whitton signature.asc Description: PGP signature
Bug#845715: Required targets must not write outside of the source package tree
On Sun, Nov 11, 2018 at 07:42:15AM -0700, Sean Whitton wrote: > Hello Bill, > > On Sun 11 Nov 2018 at 11:41AM +0100, Bill Allombert wrote: > > > I am not sure I see the difference. Do you imply something like > > > > but files created in that directory SHOULD be deleted before the > > targets completes and MUST not be reused by subsequent executions of > > the target. > > That's basically how I was reading it, yes. Then this should be written to be less ambiguous. > > What about the severity of using /tmp even if TMPDIR is set ? > > I do not think it is RC outside of the build process so it would > > be inconvenient. > > The current wording makes that RC-buggy, indeed. > > What exactly do you mean by "not RC outside of the build process"? Debian policy does not mandate that packages support TMPDIR, so it is valid to package a program that does not support TMPDIR and always use /tmp instead. However if some other package use this program in its own build process, then this other package is RC buggy under this new rule. This can be inconvenient. Do we have some data about how many packages fails to honor TMPDIR ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#845715: Required targets must not write outside of the source package tree
Hello, === Addressing the participants in this thread more generally, especially those who seconded my most recent patch: === Bill has raised several scenarios in which this new requirement could be interpreted as making a package RC-buggy, where that might be considered unreasonable. Building in wording to avoid each of the cases would make the whole patch a lot more complex, but it could be done. An alternative would be for us to weaken the main requirement of the patch from 'must' to 'should'. That way, this patch would not be in the business of making any packages RC-buggy. I don't think Bill thinks his cases are not bugs, just that they are not of RC severity. A third alternative is that we just keep the patch as it is now, and rely on maintainers to exercise their judgement about the corner cases that Bill describes. So in summary, we can 1) make the patch a lot more complex, in order to reduce to bugs of normal severity situations where a package build: (i) harmlessly ignores TMPDIR, or (ii) leaves files in TMPDIR which do not affect further builds; or 2) weaken the main requirement from 'must' to 'should'; or 3) not explicitly account for Bill's cases. Concerns about (1): Policy becomes a lot less useful if we complicate the wording to build in all sorts of exceptions, where good judgement on the part of package maintainers could handle those cases just fine. I am apprehensive about the idea of distinguishing between 'should' and 'must' within the explicatation of the details of two exceptions to a 'must' requirement. The gain seems so minimal for the loss of readability. Concerns about (2): it seems to me that this would not reflect the project's consensus that source package builds really should not be writing to places outside of TMPDIR and their own trees, aside from the final generated binary packages. So I am inclined towards (3) myself, but would very much like to hear other's opinions. === Addressing Bill's most recent message in particular: === On Sun 11 Nov 2018 at 04:04PM +0100, Bill Allombert wrote: >> > What about the severity of using /tmp even if TMPDIR is set ? >> > I do not think it is RC outside of the build process so it would >> > be inconvenient. >> >> The current wording makes that RC-buggy, indeed. >> >> What exactly do you mean by "not RC outside of the build process"? > > Debian policy does not mandate that packages support TMPDIR, > so it is valid to package a program that does not support TMPDIR and > always use /tmp instead. > > However if some other package use this program in its own build process, > then this other package is RC buggy under this new rule. This can be > inconvenient. Okay, thanks, I see what you mean now. > Do we have some data about how many packages fails to honor TMPDIR ? Not to my own knowledge. -- Sean Whitton signature.asc Description: PGP signature
Bug#845715: Required targets must not write outside of the source package tree
On Sun, Nov 11, 2018 at 11:25:58AM -0700, Sean Whitton wrote: > Hello, > > === Addressing the participants in this thread more generally, > especially those who seconded my most recent patch: === > > Bill has raised several scenarios in which this new requirement could be > interpreted as making a package RC-buggy, where that might be considered > unreasonable. Building in wording to avoid each of the cases would make > the whole patch a lot more complex, but it could be done. > > An alternative would be for us to weaken the main requirement of the > patch from 'must' to 'should'. That way, this patch would not be in the > business of making any packages RC-buggy. I don't think Bill thinks his > cases are not bugs, just that they are not of RC severity. More accurately: I am not sure the Debian archive is ready for these bugs to be RC, especially since they are usually upstream bugs. I can be convinced otherwise with data, though. Other corner cases are /var/tmp and builds leading to files in /run or /var to be created or modified. Package support for TMPDIR can be introduced as a general requirement, outside of the build process. > Concerns about (2): it seems to me that this would not reflect the > project's consensus that source package builds really should not be > writing to places outside of TMPDIR and their own trees, aside from the > final generated binary packages. Note that you used "should" :) Maybe the proposal could be rewritten in a way that does not need to cover the detail of temporaries files. How about: +Required targets must not attempt to write outside of the unpacked +source package tree. There are two exceptions. Firstly, the binary +targets may write the binary packages to the parent directory of the +unpacked source package tree. Secondly, required targets may write to +/tmp, /var/tmp and to the directory specified by the ``TMPDIR`` environment + variable, but must not depend on the content of either. + +This restriction is intended to prevent source package builds creating +and depending on state outside of themselves, thus affecting multiple +independent rebuilds. In particular, the required targets must not +attempt to write into ``HOME``. As far as RC bug are concerned, Policy need to reflect current practice before the Project's consensus. If a change causes a lot of packages to be RC buggy, then there is a need for a transition period during which the bug is not RC and the maintainers are notified of the bugs and given the opportunity to fix them. The alternative is that the policy requirement is ignored. Cheers, -- Bill. Imagine a large red swirl here.
Bug#913295: debian-policy: Update location of example init.d script
[2018-11-10 17:02] Sean Whitton > Hello Dmitry, > > On Fri 09 Nov 2018 at 08:17AM GMT, Dmitry Bogatov wrote: > > > Examples on which you can base your systemd integration on is available in > > the man page systemd.unit(8). An example on which you can base your > > -``/etc/init.d`` scripts is found in ``/etc/init.d/skeleton``. > > +``/etc/init.d`` scripts is available in the man page init-d-script(5). > > Reading #913154, I note that the example in init-d-script(5) is shorter > than the old file /etc/init.d/skeleton. So shouldn't Policy refer to > the new file in /usr/share/doc/initscripts/examples, instead? Sorry, I do not understand. Why? Currently, there is no such thing as `/usr/share/doc/initscripts/examples'.
