Bug#872950: debian-policy: Too much indirection in info file menus
Guillem Jover <guil...@debian.org> writes: > The info file, on its initial page contains a Menu with the following > entries: > ,--- > * Menu: > * Version:: > * Contents:: > * Legal Notice:: > `--- > For which Version contains a one-liner. It would be nicer if Contents > would get expanded into the main Menu. Just FYI, some of these bugs are likely to be assigned to Sphinx (with affects on debian-policy), since I think this is just generic upstream Sphinx behavior, but I'll take a look and see if there's a way to make this better before reassigning. (We didn't have info pages before, so I just turned this on because we could, as sort of a bonus.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#872896: debian-policy: An html.tar.gz has leaked into the .deb?
Sean Whitton <spwhit...@spwhitton.name> writes: > On Tue, Aug 22 2017, Guillem Jover wrote: >> It seems that an html.tar.gz has leaked (?) into the .deb, which >> contains the single single html file plus ancillary files. It is not >> clear whether this is an intentional change as it's not listed on the >> changelog. It looks at least a bit redundant. > Hmm, I thought that it was needed as it is offered for download on > www.debian.org. Russ, can you remember how that download link worked > previously? I don't know how the download link works, but I can confirm that we weren't shipping tar.gz files in the package before. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#872900: debian-policy: Very generic info file name
Guillem Jover <guil...@debian.org> writes: > Package: debian-policy > Version: 4.1.0.0 > While I'm not a very big fan of info files (even when using pinfo), > it seems for now it's the only way to get section numbers w/o having > to use a browser. :/ w3m works very well, FWIW. (And yeah, the lack of section numbers in the text output is definitely a regression that we'll need to fix.) > So while using it I noticed that it has been installed with an extremely > generic name, for something that is a global resource. I think it should > be renamed to debian-policy. Ack, yes, this is my fault. Will fix. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7
Sean Whitton <spwhit...@spwhitton.name> writes: > Thus I am seeking seconds for the following patch: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index f706a13..89b355a 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -99,10 +99,11 @@ later reconfigure the package without losing the changes > you made. > Debian changelog: ``debian/changelog`` > -- > > -Changes in the Debian version of the package should be briefly explained > -in the Debian changelog file ``debian/changelog``. [#]_ This includes > -modifications made in the Debian package compared to the upstream one as > -well as other changes and updates to the package. [#]_ > +Every source package must include the Debian changelog file, > +``debian/changelog``. Changes in the Debian version of the package > +should be briefly explained in this file. [#]_ This includes > +modifications made in the Debian package compared to the upstream one > +as well as other changes and updates to the package. [#]_ > > The format of the ``debian/changelog`` allows the package building tools > to discover which version of the package is being built and find out Looks good to me. Seconded. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#872868: debian-policy: section numbers missing
Sean Whitton <spwhit...@spwhitton.name> writes: > The PDF, HTML, info and ePub output formats have section numbering. > The plain text format doesn't yet, mainly because it's put together with > a local hack -- Sphinx generates one plain text file for each chapter, > but we want a single policy.txt. We are waiting on better upstream > support. Well, it's not just that, but also that Sphinx in general doesn't add section numbers to the text output. But yes, it's unfortunately a casualty of the reStructuredText conversion. If we have to, we'll hack together something that will add section numbers at some point, but I'm still hoping that Sphinx upstream will add support for this. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#872768: Please remove me from Uploaders
Source: khronos-opencl-headers Version: 2.1-1 Severity: minor Per my message to pkg-nvidia-devel, I'm unlikely to have a chance to work on this any time soon, and I'm also not a member of pkg-opencl and couldn't make changes if I wanted to. :) Could you drop me from Uploaders in the next release? Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#844431: Revised patch: Oppose
Bill Allombert <ballo...@debian.org> writes: > On Wed, Aug 16, 2017 at 12:14:53PM -0700, Russ Allbery wrote: >> If you have specific wording suggestions that you believe would bring >> this Policy requirement closer in line with what we're already doing in >> the project (and which has gotten us to 94% reproducible already), >> please make them. > This percentage was reached mostly by fixing software tools (compiler, > doc generators, packaging tools) to be deterministic, rather than by > fixing individual packages. This is a topic that is wholy absent from > policy. Indeed. There are many things that go into making Debian work that are wholly absent from Policy. Hopefully, over time, we can slowly reduce that, but there will always be new initiatives that aren't documented. > For example policy could mandate that programs that set timestamps > honour SOURCE_DATE_EPOCH. Please propose language. (Ideally in a separate bug, since this one is already quite large and it's easier to address specific issues in specific bugs.) I'm not opposed to adding more advice and requirements that make sense, but there are lots of things in Policy that aren't as fully described as they possibly could be if people did more work. I'm not willing to block this on having the perfect language, but if you want to contribute, you're absolutely welcome to do so. Most packages do not have to care about SOURCE_DATE_EPOCH because it's set by dpkg-buildpackage and consumed by the tools that are most frequently relevant, but I'd be very happy to see that documented in Policy for the packages that do care. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: Oppose
Bill Allombert <ballo...@debian.org> writes: > This is one of the reasons I do not attend DebConf anymore. We are an > online organization. Consultation should happen online. Metting are nice > but they should not be used to vet consensus and ignore absentees. > So I object to Adrian being overriden on that ground. That's only a part of what went into this, but I will strongly defend using the opportunity of in-person meetings to judge consensus. It's very difficult to judge consensus over email because only the strong opinions are visible. There are frequently situations where there's a large sentiment in one direction or another that isn't expressed in long threads full of lots of back and forth between a small handful of people who may or may not have representative opinions. We can't always do it, and we obviously have to be sensitive to the fact that not everyone is in the room, but we're also going for consensus, not unanimity. When we have the opportunity to get direction from a large gathering of developers, we should make use of it. But I'm taking this position for a large number of reasons, of which consensus at DebConf is only one. > But as a technical document, it is lacking practical recommendation for > maintainers how to make sure their package build reproducibly and create > confusion on the goal by using the term 'reproducible build' when > 'robust build' is meant (which is a worthwile goal by itself, but a > different project nevertheless). If you have specific wording suggestions that you believe would bring this Policy requirement closer in line with what we're already doing in the project (and which has gotten us to 94% reproducible already), please make them. I am not at all trying to rule out constructive suggestions to make the language better, either now or in subsequent revisions of Policy. I think what we've got is pretty good, and I am comfortable with putting it into Policy now, but concrete wording proposals with justification would be welcome. Like everything else in Policy, we can always improve how we describe our project-wide baseline. It's not normally Policy's role to offer detailed advice on how to meet a particular requirement. For example, Policy mentions debhelper in a few footnotes but doesn't document how to use it to create compliant packages in general. That's not its purpose; usually that sort of documentation can be better-maintained by other teams, such as the reproducible builds team. The definition in the current proposal is intentionally weaker (in the sense that fewer packages would fail it) than what current reproducible build testing is doing in a few places (such as with environment variables) because it takes a conservative stance to set a baseline and it errs on the side of a clear and simple problem statement. It's possible that we'll want to make it more complex in the future, but I think with environment variables we should first have a discussion (Ximin and I started that; I probably should move it off this thread) because I'm not sure that's the best approach. In the meantime, this achieves the goal of declaring a baseline that Debian packages should be reproducible under controlled and simple-to-state circumstances, which is something for which I'm quite sure we have general project consensus. If you believe it is premature to specify this in Policy entirely, I strongly disagree, and am not persuadable on that point. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: Oppose
Just to be completely, 100% clear: I will not be responding further to this line of argument in this bug. If you disagree with my decision as a project delegate, I've spelled out your possible next steps under Debian's governance process. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Bill Allombert <ballo...@debian.org> writes: > On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote: >> Note that, for most developers, this is pretty much equivalent to the >> current situation with FTBFS on, say, s390 architectures. Or even >> issues with running under whichever init system is not the one the >> maintainer personally uses. > Debian provides porter box for that purpose. This means if your package > FTBFS on s390 you can login to a s390 porter box, use sbuild to set up a > build environment, fix the problem and then check the package now build > correctly. > Now compare with reproducible build. You get some error report you > cannot reproduce, do some change following the help provided and hope > for the best. Then some day later you get the same error report. This hasn't been my experience with reproducible build bug reports. Once there's a bug report of unreproducibility under some specific situation, I've always been able to reproduce it by doing multiple builds with that specific variation and seeing how the output changes. I agree that this may not always be the case, but it's also not always the case that one can reproduce an s390 buildd failure on a porter box. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Ximin Luo <infini...@debian.org> writes: > Fair enough. I actually spotted that but thought it was better to get > "something" into Policy rather than nitpick. I guess other people were > thinking similar things. Well, lesson learnt, I will be more forceful > next time. > The sentence I amended said "most environment variables" so our intent > is clear. If we want to fix this now, I would suggest amending: > - a set of environment variable values; and > + a set of reserved environment variable values; and > then later: > + A "reserved" environment variable is defined as DEB_*, DPKG_, > SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags > and other variables explicitly used by buildsystems to affect build output, > excluding any variables used by non-build programs to affect their behaviour. > Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any > variables ending with *PATH. We intentionally didn't spell this out in this much detail because it felt better to defer this (stricter) bar until we have documentation of the *.buildinfo file, and also because we were worried about the list changing (once it goes into Policy, it's more irritating to change). The current standard in Policy is intentionally weaker than this in order to be simpler. I still lean towards taking this approach, because I'm pretty worried about the scope of: other variables explicitly used by buildsystems to affect build output That's not really an enumerable list. My recommendation, if you want to allow some environment variables to vary without affecting reproducibility, is to explicitly list the set of environment variables that can vary, rather than trying to list the ones that have to remain fixed. But, more fundamentally, I'm dubious that weakening the environment variable set is a good use of anyone's time. Why not define reproducible builds as setting a specific set of environment variables and no others? We're long past the point where building packages in an isolated environment with a fixed set of environment variables is a great hardship or even particularly unusual. I think the effort would be better spent on fixing (with enumerated exceptions) the set of environment variables set by buildds, sbuild, pbuilder, and other infrastructure that builds packages than in making packages tolerate random environment variables being set during the build. It's really hard to track down all the environment variable settings that might affect Autoconf, the build tools, document formatters, and so forth. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Bill Allombert <ballo...@debian.org> writes: > I am still concerned that there will be no reliable way for maintainers > to check whether a package is reproducible according to policy before > uploading it to the archive. Ximin answered this, but I also wanted to note that while having such a tool would be ideal, we don't have such tools for every aspect of Policy, and I'm generally comfortable with that. There are a lot of elements in building a distribution where we can't proactively test exhaustively and maintainers have to be reactive. Obviously, full testing in advance is best, but we can live with some reactive bug fixing. There is an infrastructure that will test your package for reproducibility after upload and let you know if that fails, which is better than some other aspects of Policy. Note that, for most developers, this is pretty much equivalent to the current situation with FTBFS on, say, s390 architectures. Or even issues with running under whichever init system is not the one the maintainer personally uses. Maintainers generally do not proactively test such things; they follow best practices, use standard tools, and then reactively respond to bugs filed or by failures detected by other parts of the infrastructure when those tools fail for some reason. And generally that's fine; lots of proactive testing for the maintainer would often be a waste of their time. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: Oppose
ee; I feel like I have a pretty complete understanding of the issues here, and it's highly unlikely that further elaborations or rephrasings of your current arguments are going to change my mind. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Adrian Bunk <b...@debian.org> writes: > This is not about experimenting for raising the bar in the future. > This is about the reproducible builds team not using policy as a stick > for claiming a bar higher than what policy actually defines. > Is it really allowed to claim that a package is not reproducible, > when it actually is reproducible according to policy? Yes. Ideally one would distinguish between those various definitions of reproducible, though, and present all of them. > Unless policy is supposed to be completely detached from reality, the > criteria for claiming in various places that a package is unreproducible > have to match the policy definition of reproducibility. No, I don't agree. This is not how we do things in Debian. There is quite a bit of information that we give developers about possible flaws in their package, from Lintian and build log analysis and many other things, that is not required by Policy. This is no different. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Adrian Bunk <b...@debian.org> writes: > Future policy versions might change this definition, but whatever latest > policy states has to be the definition used by both packages and the > reproducible builds team. > Another example is that a package that is reproducible according to the > policy definition must not show up as non-reproducible in tracker/DDPO > based on results from the reproducible infrastructure. This seems really inflexible and unnecessarily absolutist. I don't agree with taking this approach. The point of adding this definition to Policy is that we're setting a new minimum bar for packages in Debian to meet. We're giving official blessing to this requirement for Debian packages (at the normal bug level, not RC bug, for now), meaning this is a goal that the project is working towards and something every packager should think about at this level. This in absolutely no way constrains the reproducible build team from working on raising the bar in the future, just as the absence of this language from Policy did not prevent them from starting to work on this problem four years ago. They should continue to work on making package builds more reproducible and raising the bar for reproducibility as makes sense for their goals and judging the impact of that. Once any new requirements reach maturity and look feasible and have some project committment, we'll change Policy to set a new baseline for the whole project. But the reproducible builds work should not *wait* for that, and should definitely push forward and experiment just as they have up until now. I do think it might be worth considering distinguishing between packages that are minimally reproducible and packages that meet higher reproducibility bars (such as not caring about the location of the build tree) in reporting infrastructure like tracker. But I'm totally fine with surfacing failures on new, higher bars in places like tracker before we change Policy, just like we've been surfacing reproducibility failures before Policy said anything about it at all. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Adrian Bunk <b...@debian.org> writes: > I would expect the reproducible builds team to not submit any bugs > regarding varied environment variables as long as as the official > definition of reproducibility in policy states that this is not required > for a package to be reproducible. I believe the planned next step here is to publish the *.buildinfo files, which contain a specification of the environment variables the build cares about, and then Policy can be modified to include a description of *.buildinfo files and how to use them. As part of those changes, we'd certainly update the definition of reproducible to reference matching the environment specified in the corresponding *.buildinfo file. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#299007: Transitioning perms of /usr/local
Thomas Hochstein <t...@inter.net> writes: > Santiago Vila wrote: >> I wonder if we really want to do all that in 2017. The staff-writable >> /usr/local for a "sysadmin assistant" was an interesting idea twenty >> years ago. Today, we would give a sysadmin assistant an entire virtual >> machine to play with, and would probably not bother with this. > There seems to be at least another usecase for a staff-writable > /usr/local, see ian's message at > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484841#62>. Personally, I'm okay with breaking this and requiring people who want to use a system like this to set it up again. I suspect the number of people who are intentionally using such a system is pretty small. (Obviously, we would need clear release notes and documentation.) That said, if folks want to do the work to have a clean transition, I'm okay with that too. I'm just kind of dubious it's worth it; I feel like we've changed things like this in Debian before with less of a transition. But doing a proper transition is the fully-correct thing to do, and would be nice. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#587279: Clarify restrictions on main to non-free dependencies
Control: tags -1 pending Sean Whitton <spwhit...@spwhitton.name> writes: > On Sun, Jun 25, 2017 at 02:43:36PM -0700, Russ Allbery wrote: >> diff --git a/policy.xml b/policy.xml >> index 7ba5fc0..daf4c3c 100644 >> --- a/policy.xml >> +++ b/policy.xml >> @@ -595,7 +595,9 @@ >>Build-Depends, >>Build-Depends-Indep, or >>Build-Depends-Arch relationship on a >> - non-main package), >> + non-main package) unless that package >> + is only listed as a non-default alternative for a package in >> + main, >> >> >> > Seconded. Thanks, applied for the next release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Reproducibility in Policy
Bill Allombert <ballo...@debian.org> writes: > This require policy to define the build environment and build > instruction much more precisely than it does now, which does not seems > to be practical. Unless maybe if a reference implementation is provided. I don't see anything in this proposal that would require a more precise definition than we have in Sean's current proposal. This is the standard that we're already using for filing reproducible build bugs in the archive, and it's been basically fine. The tools aren't in place yet to make it super-easy for people to test for themselves, but that's in the works, and that's also why it's a should (not must) and there's infrastructure in place for Debian to check it for you. We can always aspire to get more formal and specific in the future, but that's true of many other parts of Policy as well. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Johannes Schauer <jo...@debian.org> writes: > Policy §4.9 defines "build architecture" in the context of > dpkg-architecture already and I think what you mean here is either "host > architecture" or at least "build and host architecture" or you need to > mention that you are only talking about native builds where build and > host architecture are equal. I suspect we want to say build and host architecture for right now. (Maybe we can later aspire to making the build architecture not matter.) Thanks, good catch! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Ximin Luo <infini...@debian.org> writes: > To echo dkg and others' comments, it would be nice if we could add here: > +Packages are encouraged to produce bit-for-bit identical binary packages even > +if most environment variables and build paths are varied. This is technically > +more difficult at the time of writing, but it is intended that this stricter > +definition would replace the above one, when appropriate in the future. > If this type of "intent" wording is not appropriate for Policy then > disregard what I'm saying, I don't wish to block this patch for this > reason. Oh, that's a good way to capture that. This seems fine to me, and I have no objections to adding this advice. Seconded the original with or without this addition. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Revised patch: seeking seconds
Sean Whitton <spwhit...@spwhitton.name> writes: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 127b125..cc4b020 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or > build system (for > example, a package that builds the same source multiple times to > generate different binary packages). > > +Reproducibility > +--- > + > +Packages should build reproducibly, which for the purposes of this > +document [#]_ means that given > + > +- a version of a source package unpacked at a given path; > +- a set of versions of installed build dependencies; > +- a set of environment variable values; and > +- a build architecture, > + > +repeatedly building the source package on any machine of the same > +architecture with those versions of the build dependencies installed > +and exactly those environment variable values set will produce > +bit-for-bit identical binary packages. > + > .. [#] > See the file ``upgrading-checklist`` for information about policy > which has changed between different versions of this document. > @@ -790,3 +806,7 @@ generate different binary packages). > often creates either static linking or shared library conflicts, and, > most importantly, increases the difficulty of handling security > vulnerabilities in the duplicated code. > + > +.. [#] > + This is Debian's precisification of the `reproducible-builds.org > + definition <https://reproducible-builds.org/docs/definition/>`_. Seconded. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Reproducibility in Policy
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote: >> - a version of a source package unpacked at a given path; > I don't like the idea of hard-coding a fixed build path requirement into > debian policy. We're over 80% with variable build paths in unstable > already, and i want to keep the pressure up on this. The build location > should not influence the binary output. It shouldn't, but my understanding is that it currently does. If you can fix that, that's great, but until that's been fixed, I don't see the harm in documenting this as a prerequisite for a reproducible build. If we can relax that prerequisite later, great, but nothing about listing it here should reduce the pressure on making variable build paths work. It just documents the current state of the world. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844431: Reproducibility in Policy
Sean Whitton <spwhit...@spwhitton.name> writes: > Proposal: > This is what Holger and I think we should add to Policy, after > readability tweaks: > Packages should build reproducibly, which for purposes of this > document means that given > - a version of a source package unpacked at a given path; > - a set of versions of installed build-dependencies; and > - a build architecture, > repeatedly building the source package on the architecture with those > versions of the build dependencies installed will produce bit-for-bit > identical binary packages. I think we need to add all environment variables starting with DEB_* to the prerequisites. If you set DEB_BUILD_OPTIONS=nostrip or DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different package, for instance. I feel like there are a bunch of other environment variables that have to be consistent, although I'm not sure how to specify that since other environment variables shouldn't matter. But, say, setting GNUTARGET is very likely to cause weirdness by changing how ld works. There are probably more interesting examples. How does the current reproducible build testing work with the environment? Maybe we should just document that for right now and relax it later if needed? > Explanation: > The definition from the reproducible builds group[1] says: > A build is reproducible if given the same source code, build > environment and build instructions, any party can recreate > bit-by-bit identical copies of all specified artifacts. > The relevant attributes of the build environment, the build > instructions and the source code as well as the expected > reproducible artifacts are defined by ... distributors. > i.e. Debian has to define the build environment, source code and build > instructions. I think that my wording defines these as Debian currently > understands them. > Later, we could narrow the definition of build environment by adding > more constraints, but we're not there yet. > [1] https://reproducible-builds.org/docs/definition/ We should add a link to that page (maybe in a footnote). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#858970: please add /etc/krb5.conf.d
Hi Sam, Per our discussion today, unfortunately, it looks like include and includedir support was merged into Heimdal, but hasn't yet made it into a release. It's on the master branch, but is not in 7.4.0. But maybe soon? Once that code is released, it looks like the way to include a directory of fragments in Heimdal is: includedir /etc/krb5.conf.d include also works, for single files. There are some name restrictions, namely: Only files whose names consist only of alphanumeric characters, hyphen, and underscore, will be parsed, though files ending in ".conf" will also be parsed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#871699: libpam-krb5: Add no_subsequent_prompt option
kpp <krayn...@km.ru> writes: > Please add no_subsequent_prompt option to pam_krb5. This option is > implemented in redhat and very useful. > Example: > authrequired pam_env.so > auth[success=ok ignore=2 authinfo_unavail=2 default=die] > pam_pkcs11.so card_only > auth[default=ignore] pam_krb5.so no_initial_prompt > no_subsequent_prompt > authsufficientpam_permit.so > authsufficientpam_krb5.so > authrequired pam_deny.so > This pam configuration allows authorization by username/password with > obtaining kerberos ticket ONLY if smartcard is not inserted. > If smartcard is inserted, authorization is possible ONLY by pkcs11 and > kerberos ticket is obtained by pam_krb5 using certificate without asking > PIN again. > I am unable to create the same configuration using pam_krb5 with > try_pkinit option because of pam_krb5 will ask password if pkinit failed > due invalid PIN. Thanks for the report! It looks like what needs to happen to make this work is to switch to the krb5_responder API for MIT Kerberos, which allows the module to distinguish between the different types of things the library is asking for and reject ones other than the PKINIT PIN. Note that this pam_krb5 will spell this option use_pkinit, which already exists and works with Heimdal, but is not currently supported with MIT Kerberos. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#871534: debian-policy: Clarify whether mailing lists in Maintainers/Uploaders may be moderated
Chris Lamb <la...@debian.org> writes: > Hi Bill, >> How do you define "moderated" ? > I can't really, sorry. I guess getting a "Your message awaits moderator > approval" quasi-bounce… but that's not exactly right. My personal feeling is that the current vagueness is a feature rather than a bug. I think a moderated mailing list is fine *if* the moderation queue is very promptly processed, but not okay if the moderation queue is just a place for messages to go to die. I feel like Policy already strikes a fairly good balance here: The maintainer must be specified in the Maintainer control field with their correct name and a working email address. The email address given in the Maintainer control field must accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes non-spam mail from the bug-tracking system, all mail from the Debian archive maintenance software, and other role accounts or automated processes that are commonly agreed on by the project. and also note the footnote, which directly addresses moderated mailing lists: A sample implementation of such a whitelist written for the Mailman mailing list management software is used for mailing lists hosted by alioth.debian.org. This language dates from an earlier bug about moderated mailing lists from ftp-master, and was the result of that bug discussion. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
Didier 'OdyX' Raboud <o...@debian.org> writes: >> diff --git a/policy.xml b/policy.xml >> index 6086901..c14d9b4 100644 >> --- a/policy.xml >> +++ b/policy.xml >> @@ -2556,11 +2556,28 @@ endif >> >> >> This is an optional, recommended configuration file for the >> -uscan utility which defines how to >> +uscan utility which defines how to >> automatically scan ftp or http sites for newly available updates >> of the package. This is used Debian QA tools to help with quality > While were at patching this, this sentence should read: >> This is used _by_ Debian QA tools … > or >> This is used _by some_ Debian QA tools… > Other than that, seconded! Thanks! I made that fix and also the OpenPGP fix, and am now merging this for the next release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
Holger Levsen <hol...@layer-acht.org> writes:
> On Mon, Aug 07, 2017 at 09:40:22AM -0700, Russ Allbery wrote:
>> In an ideal world, we would have a documented set of metadata for
>> finding upstream releases, of which uscan is just one implementation,
>> and document that in Policy. This patch doesn't attempt to do that; it
>> tries to find a compromise between the current Policy language
>> ("include a watch file for uscan") and specifying the location of the
>> upstream signing keys, while deferring all of the details to the uscan
>> documentation.
>> I decided to keep this all in the uscan section rather than adding a
>> new section for the upstream signing key location, since right now this
>> is all closely linked to uscan functionality (and to avoid renumbering
>> sections or having a section weirdly separated from the uscan
>> description).
>> How does this look to everyone?
> looks good to me and the reasoning as well. happy to second if you think
> it's ready.
Yup, I think it's ready, as long as dkg is happy with this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
Control: tag -1 patch
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
> debian-policy should encourage verification of upstream cryptographic
> signatures.
> Since devscripts 2.13.3 (see #610712), uscan has supported the ability
> to automatically verify upstream's cryptographic signatures if the
> signing key and URL to the signature is well-known.
>
> debian-policy should recommend that package maintainers regularly
> verify these signatures for new versions, and mention the files used.
Hi everyone,
Here's a proposed new patch for this.
In an ideal world, we would have a documented set of metadata for finding
upstream releases, of which uscan is just one implementation, and document
that in Policy. This patch doesn't attempt to do that; it tries to find a
compromise between the current Policy language ("include a watch file for
uscan") and specifying the location of the upstream signing keys, while
deferring all of the details to the uscan documentation.
I decided to keep this all in the uscan section rather than adding a new
section for the upstream signing key location, since right now this is all
closely linked to uscan functionality (and to avoid renumbering sections
or having a section weirdly separated from the uscan description).
How does this look to everyone?
diff --git a/policy.xml b/policy.xml
index 6086901..c14d9b4 100644
--- a/policy.xml
+++ b/policy.xml
@@ -2556,11 +2556,28 @@ endif
This is an optional, recommended configuration file for the
-uscan utility which defines how to
+uscan utility which defines how to
automatically scan ftp or http sites for newly available updates
of the package. This is used Debian QA tools to help with quality
control and maintenance of the distribution as a whole.
+
+If the upstream maintainer of the software provides PGP signatures
+for new releases, including the information required for
+uscan to verify signatures for new upstream
+releases is also recommended. To do this, use the
+pgpsigurlmangle option in
+debian/watch to specify the location of the
+upstream signature, and include the key or keys used to sign
+upstream releases in the Debian source package as
+debian/upstream/signing-key.asc.
+
+
+For more information about uscan and these
+options, including how to generate the file containing upstream
+signing keys, see
+
uscan1.
+
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#299007: Transitioning perms of /usr/local
Santiago Vila <sanv...@unex.es> writes: > However: > I wonder if we really want to do all that in 2017. The staff-writable > /usr/local for a "sysadmin assistant" was an interesting idea twenty > years ago. Today, we would give a sysadmin assistant an entire virtual > machine to play with, and would probably not bother with this. > So my question would be: Do we really need to support both ways to > handle /usr/local at this point? Yeah, that was the same conversation that Sean and I had. I think it may be fine to just do a straight cutover to typical permissions with no support of the staff group. > And for practical purposes: Will packages really stop fiddling with > /usr/local once I remove /etc/staff-group-for-usr-local in buster > initial install? I have been hesitant of doing this move because I never > took the time to recollect data that would tell me whether or not it > would work. Yeah, that's a great question. We should at least be sure that debhelper will do the right thing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#845255: debian-policy: Include best practices for packaging database applications
Paul Gevers <elb...@debian.org> writes: > It has been a while since the first version of the "Best practices for > packaging database applications" was drafted by Sean Finney as the > creator of dbconfig-common. The discussion on the document has died down > a long time ago, but as the new (since last year) maintainer of > dbconfig-common, I think would be appropriate to include or attach the > database policy in the Debain policy. I asked the audience during my > dbconfig-common BoF at Debconf 16 if they agreed with me, and the > consensus was yes (for whatever it is worth). > The current text of the "Best practices for packaging database > applications" is contained in the dbconfig-common package and can be > found on www.debian.org/doc¹. I attach current source to this bug report > as a base-line of the content for discussion. > What would be the best way forward? Is this appropriate for the policy? > ¹ https://www.debian.org/doc/manuals/dbapp-policy/ch-dbapps.html Hi Paul, Sean and I talked this over at DebConf and we both feel this is indeed appropriate for Policy and that it makes sense to maintain it as part of Policy. I can think of two approaches for incorporating it, which could be termmed "low-scrutiny" and "high-scrutiny": 1. The low-scrutiny approach is to incorporate this as a sub-policy and mark it as optional, similar to how we did with copyright-format. This avoids making any package buggy but provides the policy in a central place for reference and to make it more findable. 2. The high-scrutiny approach is to incorporate this as an additional section in Policy directly (probably in section 11). Here, we'd want to go over the exact requirements it sets very carefully and be sure we understand the implications in terms of making existing packages buggy, etc. I think the low-scrutiny approach could happen pretty quickly (mostly we just need the policy in DocBook), but I think the high-scrutiny approach would be better for Debian in the long run. And, of course, we could do approach 1 first and then approach 2. Either way, I think the immediate next step would be to get a DocBook translation of the source, since we've just finished converting away from DebianDoc-SGML. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Adrian Bunk <b...@debian.org> writes: > On Fri, Aug 04, 2017 at 02:57:49PM -0700, Russ Allbery wrote: >> but regardless of that discussion, machine-readable team information is >> not something we have now. > Policy says that Uploaders should list all co-maintainers. Your understanding of Policy is incorrect. (This is one of the few topics in this thread where I can put on my Policy Editor hat and say that this isn't just a matter of opinion.) Policy says that all co-maintainers *who are not included in the Maintainer* field should be listed in Uploaders, which obviously means that team members do not have to be listed there since they're included in the Maintainer field. The only reason why anyone gets added to Uploaders from a Policy perspective for a team-maintained package is the statement under discussion here: This is normally an optional field, but if the Maintainer control field names a group of people and a shared email address, the Uploaders field must be present and must contain at least one human with their personal email address. *At least one human.* Not everyone on the team. And note how this specifically talks about how the Maintainer field can represent a *group* of people. Team membership information does not exist in a machine-readable form right now. You have misunderstood the meaning of Uploaders and it is leading you to draw a bunch of other erroneous conclusions. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Tobias Frost <t...@sviech.de> writes: > Am Donnerstag, den 03.08.2017, 11:58 -0700 schrieb Russ Allbery: >> Or track MIA teams, which in a lot of ways is a much easier problem, >> and seems like a worthwhile problem to solve anyway. > No, because with a $TEAM you have to expand it to $TEAM_MEMBERS and > check them individually. Well, as I've already said, I don't agree with this approach for finding MIA teams. I'm not sure if you disagree for reasons you're not saying, or if you just didn't see that message, or if I missed another message from you explaining why you disagree. Anyway, I truly don't understand why you can't determine MIA teams based on whether their packages are maintained. Team-maintained packages not being uploaded translates into the team being MIA (regardless of the MIA status of individual members). I think it's in a lot of respects much more straightforward than MIA maintainers, since you don't have to worry about voting and other maintainer privileges and access. And with most teams there will be fewer edge cases where there are legitimate reasons for all of their packages to have just not needed an upload, since teams are less likely to only have a single leaf package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Adrian Bunk <b...@debian.org> writes: > In a more general note, I am a bit puzzled that it is so controversial > that machine-readable team membership information is important and > should continue to be available. One of the major points of disagreement in this thread is that you think this information is currently available and useful, and other people (such as myself) think that your understanding of Uploaders has little relationship to how the field is currently used in the archive. I'm dubious that it's worth the effort to maintain this, but regardless of that discussion, machine-readable team information is not something we have now. We instead have a partial record of some people who have previously worked on the package, without much information about whether they're currently working on the package. It's marginally more useful than the debian/changelog entries, but only marginally. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Adrian Bunk <b...@debian.org> writes: > On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote: >> Adrian Bunk <b...@debian.org> writes: >>> Regressing on being able to orphan all packages of a known-MIA/retired >>> maintainer would be very bad. >> I agree, but that's not directly relevant here, since we're talking >> about team-maintained packages. The whole *point* of team maintenance >> is that there's no reason to orphan a package just because one team >> member went away. If that weren't the case, the package is, *by >> definition*, not team-maintained (or the team itself is MIA, which is a >> different issue as discussed below). > Your definition is completely detached from the reality in Debian. > Many (likely the majority) of teams in Debian have not more than 1 > active member. Then when that one member disappears, that team becomes MIA, which is something that would need to be detected by an MIA process for teams, which I agree should exist, but which I think is detectable via other mechanisms than Uploaders. One approach as Holger points out: look for packages where all the recent uploads have been by the MIA member, which doesn't require the Uploaders field at all. I stand by my statement that as long as the team *does* have more than one member, not having to change anything abot package maintenance when one team member disappears is kind of the whole point of having team maintenance. If the team is not providing that, it feels like there's not much point in having a team, although I guess it could be aspirational. > When all members of a team are confirmed to be MIA/retired, this should > result in an orphaning of all packages maintained by the team. One of the whole points of this discussion is that this "members of a team" concept is not well-defined in Debian and is probably not something that we *can* make well-defined in Debian. Or, more to the point, *want* to make well-defined. >> No, I'm not -- as I pointed out in a separate message, this is a >> problem worth solving, but this is an MIA team problem that I think is >> best tackled from that angle. If all of a team's packages are >> bitrotting, then the team's packages should be orphaned just like we do >> with an MIA single maintainer. > This would create both longer bitrot for packages and more work for > an already overworked team. Why? I don't see how this follows; in fact, I believe the exact opposite. The current work that the MIA team does to track down Uploaders that mention MIA people on team-maintained packages and file a bunch of bugs to have them removed is work that they *don't* have to do in this model. Instead, just treat the team like another maintainer and look at whether that maintainer's packages are being maintained and whether that team is active and orphan packages if they aren't. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Adrian Bunk <b...@debian.org> writes: > Regressing on being able to orphan all packages of a known-MIA/retired > maintainer would be very bad. I agree, but that's not directly relevant here, since we're talking about team-maintained packages. The whole *point* of team maintenance is that there's no reason to orphan a package just because one team member went away. If that weren't the case, the package is, *by definition*, not team-maintained (or the team itself is MIA, which is a different issue as discussed below). >> Currently, when the MIA team finds someone who is no longer active, >> teams have to go do a bunch of work to strip their name out of uploader >> fields. That work doesn't really make Debian any better; it's just >> bookkeeping. When the team has other ways of knowing the health of >> their packages, I'd like to let them not do this bookkeeping. > You are assuming that the team notices without the current notifications > from the MIA team that a team member is no longer active in Debian. I'm really not. I'm pointing out that for a lot of teams, that literally *does not matter at all*. Absolutely nothing changes about the maintenance status of many team-maintained packages if the person who last worked on that package disappears. Teams often don't notice that someone is MIA because *it doesn't matter* for their workflow; they're happy to have people come and go. > You are assuming that the team has a non-zero number of active members > left after a member becomes MIA. No, I'm not -- as I pointed out in a separate message, this is a problem worth solving, but this is an MIA team problem that I think is best tackled from that angle. If all of a team's packages are bitrotting, then the team's packages should be orphaned just like we do with an MIA single maintainer. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Tobias Frost <t...@debian.org> writes: > Some time ago I did some spring cleaning going over DDs that have > retired but still in the Maintainer/Uploader fields: There were quite a > lot "team maintained" packages where the team did not recognize that the > (sole) Uploader wasn't there anymore and the packages were > bitrotting. Without the Uploader field there would have been excactly > zero change to find those packages and get them back into maintainance > again. I'm dubious about this assertion and would like to dig into it a bit more. The way we hopefully would find bitrotting packages is that they are, well, bitrotting. This is based on lack of uploads, open bugs, old Policy versions, incomplete transitions, and in serious cases, missing from stable releases. While we can *also* find bitrotting packages via the MIA process, it shouldn't be our primary or even a major way of finding them since it's entirely possible for someone to be quite active in Debian while still neglecting some of their packages. Keeping around uploader information that we know gets constantly out of date and is kind of irritating to maintain, plus results in noise for team members that they don't want, just so that we can detect packages that aren't being worked on feels like putting the cart before the horse. It's pretty obvious *from the package* if a package isn't being worked on. And detection based on uploaders isn't even accurate: there are teams that use semi-automated tools and sprints and mass uploads to maintain tons of packages, and listing themselves as Uploaders on everything they touch is just extra work and doesn't carry any useful meaning. Currently, when the MIA team finds someone who is no longer active, teams have to go do a bunch of work to strip their name out of uploader fields. That work doesn't really make Debian any better; it's just bookkeeping. When the team has other ways of knowing the health of their packages, I'd like to let them not do this bookkeeping. > I think the "how can I contact somone on the team" could be fixed, like > (brainstomring) e.g by a Team-Contact field in d/control with an human > contact and formalizing requirements on a Team so that they are allowed > to drop the Uploaders -- if they fulfill this requirements. We already have a way of contacting the team: the address in the Maintainer field. I feel like we're inventing extra complexity without a good motivating reason for it. If no one replies to mail to that address, I'm dubious you're going to get much more of an (actually useful) reply to mailing individuals either. > One requirement could be e.g that the team has a site on the Wiki and we > need some central place to record the team members and a mandatory > enrollment process (like the yearly team member ping that the perl team > does, AFAIK) This feels like way more bureaucratic structure than Debian needs. What specific problem in Debian are you trying to solve with this sort of formal org chart maintenance? I think this is quickly going to get out of date, and it's not particularly compatible with structures like the Perl team, which has tons of members doing varying amounts of work based on their available time and energy and knowledge. > This is not the point I wanted to make: In my experience if there is NOT > a name tacked to an task, the likelyhood of noone will feel responsible > and the task not done is very high. And yet I can name counter-examples, such as the Perl team who maintain hundreds of packages as a team effort and do not look out for *only* the packages they personally care about. Packaging teams that aren't doing a great job of maintaining their packages will continue to not do a great job of maintaining their packages whether or not they're listed as uploaders. We already have other tools for finding packages that aren't well-maintained. I can see the argument for keeping uploaders if it gave people some motivation to work on those packages, but in practice (and I say this as someone who has been a member of a ton of packaging teams), the uploaders changes quickly become just a minor bit of bureaucratic housekeeping that I do once and then never look at again, and I stopped looking at my package list on qa.debian.org because it became useless due to all the team noise. So I don't think this is achieving what you intend to achieve. > Also mind that we really do not have processes at hand to handle those > situations. The MIA team has already now no actual power on "partially > MIA" situations, but in the past it often helped to write a nice mail. > If I write to the anonymity of a team mailing list, I guess those mails > will be more easily ignored. I agree that this is a problem, but this is a problem regardless, and we will need to address this regardless. I don't think it's closely related. (I am entirely in
Bug#798476: Returning to the requirement that Uploaders: contain humans
Jonas Smedegaard <jo...@jones.dk> writes: > Do the MIA team also track MIA teams? > My concern is that packages without maintainers may go unnoticed when > none of its previously active maintainers were tracked individually. > For such detection of abandonment we need not track _all_ active > maintainers, but at least one - as individual. Or track MIA teams, which in a lot of ways is a much easier problem, and seems like a worthwhile problem to solve anyway. I don't feel like dropping the Uploaders field for team-maintained packages if the team so chooses will make MIA tracking substantially harder, or will make orphaned package tracking substantially harder. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#835520: Seconding nine patches & seeking seconds for two more
gregor herrmann <gre...@debian.org> writes: > On Thu, 03 Aug 2017 10:55:30 -0400, Sean Whitton wrote: >> I've spoken to h01ger and gregoa IRL and they say that they missed the >> magic word "should" which is what makes debhelper required by these >> patches. So I'm seeking seconds for the following replacement for >> Andreas' 5th and 8th patches: > Indeed, I missed the magic "should" which unfortunately didn't come > in friendly bold red blinking letters :) > Thanks for catching this glitch, and I'm happy to second the improved > version: I also second the improved version. Thank you! >> diff --git a/policy.xml b/policy.xml >> index 3daa532..c6c7412 100644 >> --- a/policy.xml >> +++ b/policy.xml >> @@ -8525,6 +8525,14 @@ fi >> update-rc.d, please consult its man page >> >> update-rc.d8. >> >> + >> +It is easiest for packages not to call >> +update-rc.d directly, but instead use >> +debhelper programs that add the required >> +update-rc.d calls automatically. See >> +dh_installinit, >> +dh_systemd_enable, etc. >> + >> >> >> >> @@ -8573,6 +8581,14 @@ invoke-rc.d package >> action >> invoke-rc.d, please consult its man page >> >> invoke-rc.d8. >> >> + >> +It is easiest for packages not to call >> +invoke-rc.d directly, but instead use >> +debhelper programs that add the required >> +invoke-rc.d calls automatically. See >> +dh_installinit, >> +dh_systemd_start, etc. >> + >> >> >> -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Bill Allombert <ballo...@debian.org> writes: > The patch also remove the requirement to list individual email of the > maintainers. That is what I am objecting to. Oh, okay, I see that, but I'm not sure why. What is the purpose of listing those email addresses that you want to preserve? > When a team is reduced to a single individual, it is no more a team, yet > the package is still maintained and need not be orphaned. It still is a team even when it's one individual. I don't know why you would say that it's not. A team can certainly contain just one person. I'm confused about how this is at all related to listing individual email addresses, and I don't understand why you think this would result in a package being orphaned. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#798476: Returning to the requirement that Uploaders: contain humans
Bill Allombert <ballo...@debian.org> writes: > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote: >> I've also included a purely informative change which emphasises that >> packages that are team maintained in name only should be orphaned >> properly, with their maintainer field set to the QA team. This is >> already current best practice, but it's worth emphasising, because one >> might fail to orphan a package on the grounds that "someone else on the >> team might fix it", which is not true of a lot of teams. > You are omitting the case of a team which get reduced to a single > member, in which case the package need not be orphaned. Yet it is > important the fact is mentionned in the package. I don't think I understand the objection. Sean's proposed wording seems fine for that case -- it just says that the package should be orphaned if the team is not maintaining it, which shouldn't depend on the size of the team. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#809637: debian/copyright checks fail on upstream filenames containing blanks
Sean Whitton <spwhit...@spwhitton.name> writes: > On Sat, Jan 02, 2016 at 10:49:04AM +, Mike Gabriel wrote: >> At the moment, we are not able to exactly specify file paths of >> files/folders containing blanks in debian/copyright when complying with >> the DEP-5 specs. (I agree that it is indeed uncommon as a developer to >> use blanks in filenames and that it should be avoided by upstream >> devs). >> Suggestions to solve this: >> (a) allow escaping of blanks somehow (e.g., "\ ") >> (b) allow quotes for filenames or such > This should be fixed. Our machine-readable copyright format should not > be causing us to file bugs to upstream saying "could you rename this > file that our Debian build process doesn't even use, please?" (e.g.) > Would it be possible to permit Files: to be a line-based list? Then > there could be one glob per line, and I think they could contain spaces. > This avoids introducing new syntax. I like solution (a), honestly. I think we could just add backslash as an escape character that escapes anything other than a newline and have the problem basically go away. It would require a new version of the spec, though, since it's not backward compatible (although I doubt many files contained literal backslashes). Line-based lists is much less backward-compatible, since we break every debian/copyright file that uses space-separated lists, which is much more common than having whitespace in filenames. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#485776: debian-policy: Adding graphical flowcharts for maintainer scripts invocation would help understand the process
Sean Whitton <spwhit...@spwhitton.name> writes: > On Tue, Aug 01, 2017 at 04:55:33PM +0100, Ian Jackson wrote: >> We should surely import the diagrams as-is. > Russ -- you were the one that suggested generating them. What do you > think about importing them as-is now? My only concern about importing them as-is is that dia is kind of tedious to use and we'd need to be sure to update them for further changes. (Documenting triggers will require changing those diagrams, for instance.) They felt like they might be more maintainable in something like dot files (for Graphviz). That said, I don't think that concern should stop us from importing them. Having them is clearly better than not having them. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#824839: librrd-simple-perl: FTBFS on armhf and arm64: t/23graph.t failures
intrigeri <intrig...@debian.org> writes: > You did the initial upload of librrd-simple-perl to Debian back in 2013, > so I'm seeking your opinion wrt. removing it from sid as part of the > pkg-perl ongoing effort towards removing the most hopeless of our > RC-buggy packages. > Summary: > * This package was not shipped in Stretch due to this bug. > * On https://rt.cpan.org/Public/Bug/Display.html?id=78785 you've >attached a patch that fixed the problem on x86_64, but sadly it >doesn't fix it on armhf and arm64. > * This is a leaf package and popcon is fairly low: >Inst = 43, Vote = 5. > Are you interested in working further on this problem? > Would you mind if we removed this package from sid? Yeah, go for it. I was using it for a specific project, and I think I ended up abandoning that project anyway (and I'm no longer working for the employer who had that problem). If someone runs into a need for it, they can always circle back and look at the package again. It seemed pretty seriously unmaintained. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#868497: debian-policy: Signed .dsc Files
Paul Hardy <unifoun...@gmail.com> writes: > Package: debian-policy > Version: 4.0.0.4 > Severity: wishlist > Debian Policy Manual, Section 5.4, "Debian source control files - .dsc", > states in the first sentence: > "This file consists of a single paragraph, possibly surrounded by a PGP > signature." > This does not state whether someone who is creating a package to be > uploaded by a sponsor can clearsign their own .dsc file, or if only the > sponsor is able to do that without causing upload problems. > What is permissible? Can you clarify that in a future update to this > section? (I'm pretty sure the actual answer to this question is that nothing cares.) I assume you're talking about sponsorship via mentors.debian.org? If so, that's out of scope for Policy and one should refer to the local documentation for how that system works (it's not the same as the regular Debian archive). All of the concepts you refer to in this bug report (sponsorship, sponsors, someone else uploading a package for someone) are outside the scope of Policy currently, so we'd have to define a whole bunch of terms to even talk about this. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#678607: debian-policy: "original authors" in 12.5 is unclear
Sean Whitton <spwhit...@spwhitton.name> writes: > I'm not sure why Jonathan thinks his patch is a strawman. It addresses > the main issue of this bug. I don't think the explanation of what an > upstream contact is needs to be relegated to a footnote. So I am > seeking seconds for the following patch, which uses Jonathan's wording: > diff --git a/policy.xml b/policy.xml > index ce5960b..725a951 100644 > --- a/policy.xml > +++ b/policy.xml > @@ -11777,8 +11777,12 @@ END-INFO-DIR-ENTRY > > > In addition, the copyright file must say where the upstream > -sources (if any) were obtained, and should name the original > -authors. > +sources (if any) were obtained, and should include a name or > +contact address for the upstream authors. This can be the > +name of an individual or an organization, an email address, a > +web forum or bugtracker, or any other means to unambiguously > +identify who to contact to participate in the development of > +the upstream source code. > > > Packages in the contrib or Seconded. This looks good to me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#867144: apt-listchanges overrides a lot of less configuration
Package: apt-listchanges Version: 3.13 Severity: normal I appreciate the problem solved by this change: * Override the LESS environment variable to make sure it does not contain certain flags like -F that might cause less program to quit before even user is able to see the files generated by the program. but I'm finding it fairly irritating. My existing LESS configuration already didn't have this problem, but I would like to be able to press space on the last screen of the changelog to exit, which used to work (since I use -e). I'm on board with overriding it by default for new users, but is there some way that apt-listchanges could honor some other environment variable instead and pass that to less as LESS? That way I could set its variant as well. Or maybe only filter out the specific options that you're concerned with? I think -E and -F are the only ones that would cause this specific problem. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-listchanges depends on: ii apt 1.5~beta1 ii debconf 1.5.62 ii debianutils 4.8.1.1 ii python3 3.5.3-3 ii python3-apt 1.4.0~beta3+b1 ii ucf 3.0036 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 59.0.3071.104-1 ii firefox [www-browser] 54.0-1 ii google-chrome-stable [www-browser] 59.0.3071.115-1 ii links [www-browser] 2.14-2+b1 ii postfix [mail-transport-agent] 3.2.2-1 ii python3-gi 3.22.0-2+b1 ii w3m [www-browser] 0.5.3-34 ii xterm [x-terminal-emulator] 330-1 -- debconf information: apt-listchanges/save-seen: true apt-listchanges/confirm: false apt-listchanges/which: both apt-listchanges/email-address: apt-listchanges/frontend: pager
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Charles Plessy <ple...@debian.org> writes: > First, minor point, but I think that #196367 (Clarify Policy on priority > inversion in dependencies) can also be closed by the changes. Thank you! > Second, I would like to propose one more clarification to the > description of the "Important" priority. I believe this is #776557 (and kind of unrelated to this discussion). Maybe move this discussion there? There's already been a fair bit of (rather inconclusive) discussion on that bug. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems
Sean Whitton <spwhit...@spwhitton.name> writes: > I don't think that it should be a point of Policy that the rules clean > target is not to be used for this purpose, because it is entailed by the > ftp-master's interpretation of DFSG plus this sentence that we already > have in Policy: > Every [source or binary] package in main must comply with the DFSG > (Debian Free Software Guidelines). Well, if it's a common-enough error, I think there's no problem with also mentioning this in the section on the clean rule. It's not likely that this interpretation is going to change. > However, as you say, we should document this to prevent others from > tripping over it. As you suggest, such a note would need to refer to > repacking the tarball. The Developer's Reference already contains a > discussion of repacking upstream tarballs, so perhaps this should go > there? +1 on putting any detailed instructions in the Developer's Reference rather than in Policy, unless someone wants to tackle documenting upstream source repackaging and the upstream version number convention in Policy directly (which isn't the worst idea, but probably isn't hugely urgent). > Or we could use a footnote to Policy. I attach a patch doing that. I'm on a war against footnotes in Policy because I think they make it much harder to read (particularly in text form, particularly with DocBook which now moves all the footnotes to the end of the chapter). I'd love to move them all to either inline text or sidebars of some kind, although that's going to be a long effort. > diff --git a/policy.xml b/policy.xml > index 782bd88..303688b 100644 > --- a/policy.xml > +++ b/policy.xml > @@ -2170,6 +2170,16 @@ >build has been invoked as root (since >build may create directories, for >example). > + > + > + The clean target should not be used to remove files > + in the source tree that are not compatible with the > + DFSG. This is because the files would remain in the > + upstream tarball, and thus in the source package, so > + the source package would continue to violate DFSG. > + Instead, the upstream source should be repacked. > + > + > > > s/should not/cannot/ (to get away from using standards language here and because this isn't a Policy statement so much as a statement of capability), and I would say "repacked to remove those files" in the last sentence, but otherwise this looks good to me and could just be included directly in that section on clean, I think. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#849853: [debian-policy] Document source-is-missing lintian kind of problems
Sean Whitton <spwhit...@spwhitton.name> writes: > Policy currently defers to the DFSG for a definition of what counts as > free software for Debian's purposes. Thanks to the DPL's delegation of > the ftp-masters, Policy defers to the DFSG plus the ftp-masters jointly. > If we included text in Policy about common ways in which a package could > fail to satisfy DFSG, Policy would effectively cease to defer to the > ftp-masters. I don't think that Policy has the authority to do that, > and I don't think it would be desirable. Agreed. This area is also fairly controversial and fluid, whereas Policy (at least right now) is very static and slow-moving, so I think we would run a very high risk of incorporating rules that the project then changes and thereby adding to the confusion. > A footnote with a link to the REJECT-FAQ sounds useful. Here's a patch. As much as I don't like footnotes, this does seem like a good use of one. I second your patch (not that I really need to since it's informative). Seems like a good thing to merge. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#866192: Broken Link in Policy HTML Page
Sean Whitton <spwhit...@spwhitton.name> writes: > I've taken a stab at this, in branch bug866192-spwhitton of > debian-policy.git repo. Reviews very welcome. This looks good to me. Thanks! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables
Control: tags -1 = pending Niels Thykier <ni...@thykier.net> writes: > On Sun, 25 Jun 2017 14:58:06 -0700 Russ Allbery <r...@debian.org> wrote: >> Everyone seemed generally happy with this text, but it never clearly got >> enough seconds to apply. Here's an updated patch so that we can take >> another run at getting enough seconds and getting it merged. > Seconded, thanks for writing it. :) Thanks, both. This has now been applied for the next release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Control: tags -1 = pending Control: tags 759260 = pending Control: tags 660249 = pending I've merged this patch for the next release. The only change from my proposed wording was that I added this sentence to the description of extra, just to be clear how to treat any packages found in the wild with that priority: This priority should be treated as equivalent to optional. I don't think this will change anything, but it seemed best to be clear. The upgrading-checklist entry for this change: 2.5 Priorities are now used only for controlling which packages are part of a minimal or standard Debian installation and should be selected based on functionality provided directly to users (so nearly all shared libraries should have a priority of optional). Packages may now depend on packages with a lower priority. The extra priority has been deprecated and should be treated as equivalent to optional. All extra priorities should be changed to optional. Packages with a priority of optional may conflict with each other (but packages that both have a priority of standard or higher still may not conflict). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Sean Whitton <spwhit...@spwhitton.name> writes: > Native packages are also used for software that is intended for use > beyond Debian, but where the upstream maintainer also maintains the > Debian package. In such cases, the Debian revision and orig tarballs > represent needless overhead (tweaks to the packaging can use an > increment to the minor version number, or similar). > Some people frown upon this practice, but there are more than one of us > that do it, so probably worth mentioning in policy as a secondary use of > native packages (possibly a footnote, due to lack of consensus? There > is certainly not a consensus that it's terrible). I thought there actually was a consensus that it's terrible. I certainly think it's not good practice. I would recommend against anyone doing this, speaking as someone who maintains lots of upstream software that I also package for Debian, and therefore would rather not document it in Policy, unless we're going to say not to do it. Bumping the minor version for things that no one cares about (because they only affect people consuming it from Debian) is probably between you and your users, although I think it's poor practice and would be vaguely irritated by it. But the stronger argument against this approach is NMUs and change of maintainership. As soon as such a package is NMU'd for whatever reason, or if you no longer have time to maintain the package for Debian but are still developing it upstream, the native package status gets really awkward. At that point, the package is diverging from upstream, but all the normal mechanisms to handle that divergence with patch sets and whatnot are no longer available. I've also repeatedly had the experience as upstream maintainer that I actually do need to carry a Debian-specific patch for a while, since Debian needs some quick fix that I don't want to take upstream in the same form. Which means that I want to use the patch handling mechanisms of Debian even for myself. And the overhead is basically nonexistent once you get your tools configured and a workflow set up. Whenever this came up on debian-mentors, it seemed to me like there was fairly strong consensus that native status should only be used for software with no independent existence, and as soon as there's a separate upstream release and Debian packaging, it's better to just do the setup work to have a non-native package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Andreas Henriksson <andr...@fatal.se> writes: > Can't help but wonder why not just remove the "extra" (and mentioning it > as deprecated in upgrade notes) rather than explicitly documenting it as > deprecated. I guess keeping it around is useful to avoid people > mass-bug-filing RC-bugs for all current extra packages. I'd like to keep the documentation of extra because, for some time to come, there will be a lot of packages in the wild that will have that priority in their control files (even if they've been overridden by ftp-master in the archive metadata). We therefore need to document that the priority still exists. Hm, it occurs to me that this wording should probably explicitly say that the extra priority should be treated the same as optional if it appears anywhere (although the archive-wide override change will mostly take care of that). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#587279: Clarify restrictions on main to non-free dependencies
Simon McVittie <s...@debian.org> writes: > On Sun, 25 Jun 2017 at 14:43:36 -0700, Russ Allbery wrote: >> Here is an updated version of the patch from earlier in this (now very >> long) thread for discussion. I still think this is consistent with >> previous practice and reasonable documentation of what we're currently >> doing. >> diff --git a/policy.xml b/policy.xml >> index 7ba5fc0..daf4c3c 100644 >> --- a/policy.xml >> +++ b/policy.xml >> @@ -595,7 +595,9 @@ >>Build-Depends, >>Build-Depends-Indep, or >>Build-Depends-Arch relationship on a >> - non-main package), >> + non-main package) unless that package >> + is only listed as a non-default alternative for a package in >> + main, >> >> >> >> If we still can't reach consensus on this, we should probably bump it >> to the Technical Committee for resolution so that this doesn't just sit >> around unresolved forever. (I feel like that happened at some point in >> the past, but it's been so long that my memory is very hazy.) > A TC resolution in 2014 said that > "Depends: package-in-main | package-in-non-free" is acceptable for main, > and not a Policy §2.2.1 violation. What you're doing here is editing > Policy §2.2.1 to make the 2014 TC's interpretation more obviously the > correct one. Ah, thank you! I did remember correctly that the Technical Committee took this up. > This is certainly not unanimous (the TC vote in 2014 wasn't unanimous > either); but I think there's rough consensus, it matches current > practice, and it's better for Policy to be clear and specific as a > self-contained document, rather than leaving ambiguity in place and > requiring past TC decisions to be consulted for disambiguation. So I > second this patch. Thanks! Yeah, given that it was a TC decision, we definitely should document it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865769: Second data package including some machine-readable data
Guillem Jover <guil...@debian.org> writes: > On Sat, 2017-06-24 at 09:57:33 -0700, Russ Allbery wrote: >> - The list of archive sections and their descriptions > I think this belongs on each archive providing those, alongside the > other archive metadata. And I'd rather see the involved parties > defining an appropriate file to provide so that any downloader which > has to fetch the matadata anyway would use instead of hardcoding it. > Using a file from policy does not seem useful to me, because it would > mean software would need to depend on such policy provided package, > and if you are going to mix and match repos, you really need the > metadata from the archive you are pulling from. > In addition the text in policy states that the canonical list is > maintained by the archive anyway. :) I don't see how this would work. The program would dynamically retrieve the list of sections every time it ran? This seems like a bad idea, and even impossible in a lot of situations (off-line development work, for instance). We maintain a list of archive sections in Policy anyway, so it's easy for us to provide this list in a machine-readable format as well. (Well, we don't have the descriptions, but that's not hard to add and doesn't really add much additional maintenance work.) I think it's fine that a debian-policy-data package only provide information for the Debian archive. The same is also true of the virtual package names, of course; some other archive may have different virtual packages too. Programs that want to work with various different package archives will need to know how to obtain this data from multiple sources. The intent is to provide a tiny package that others can easily depend on without much overhead. >> - The list of valid Debian control field names (by type of control file) > This one, I'm uncertain, but I'd tend to think it is partly in a similar > situation to the previous one. > For example dpkg contains already such a list (provably more > exhaustive) in Dpkg::Control::Fields, and I don't see making dpkg > depend on an external list, because dpkg is being used beyond Debian. This was just an idle thought of mine, and maybe it doesn't solve any real problems. > For the equivalent in policy I think I see where you are coming from, > and I think it would be nice to have most of policy in a declarative > format that could be used by linters, or some parsers, but if that means > it's going to make those somewhat Debian-specific it might not take > off. I'm in general fine with the things provided by Debian Policy being Debian-specific. That, in my opinion, is the point of the package. If some other distribution wants something equivalent, they can certainly fork Debian Policy or write their own separate document that supplements Debian Policy, and maintain corresponding data files. > The list of common licenses perhaps. Other things that come to mind > could be perhaps a file with common regexes to validate things that > policy specifies, say package names, version strings etc. Precisely > because those can and do diverge from what dpkg accepts for example. Yes, those would also be interesting. > Valid pathnames, etc, and as I've mentioned above ideally all of policy > would be available in a declarative format, but that'd be a pretty huge > undertaking. But then it might make sense to do a quick poll and ask > whether people would use any of this, because otherwise it seems perhaps > a bit like a waste. Indeed. The virtual package name list has a specific use case already, and people suggesting using sed scripts to parse files from the debian-policy package to generate it right now, so maybe we should just start there and see if uses of the other data actually materialize. Lintian is a large possible use case, but Lintian already has mechanisms for gathering and maintaining this data internally, and Lintian may not want to depend on a debian-policy-data package for various reasons (it makes lintian.debian.org a bit harder). > I don't think I have a direct use for any of the above anyway, but I > also think I'd prefer YAML, because it is more human readable. But not a > strong objection in any case. I have a professional aversion to YAML because the security properties of YAML are so awful. I wish everyone would just use TOML, but unfortunately it's not at a 1.0 version yet and is not as widely supported by default as JSON is. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Simon McVittie <s...@debian.org> writes: > On Sun, 25 Jun 2017 at 14:08:05 -0700, Russ Allbery wrote: >> +upstream_version components in >> +native packages ending in +nmu followed >> +by a number indicate an NMU of a native package. > I thought 1.2.3-4+nmu1 was also allowed as an alternative to 1.2.3-4.1? > But perhaps that's non-standard (it's certainly redundant). There's some previous discussion in the bug. The summary is that this was proposed and is sometimes used, but pretty much everyone uses the 4.1 syntax still, so it doesn't seem to really have consensus. Note that this list is not exclusive; there may be version numbering conventions that aren't documented. I just wanted to get down the most likely ones that people will encounter. >> +N is the major version number >> +of the Debian stable release to which the package was >> +package uploaded directly to a stable release, and the > You have some duplicated lines here I think. Argh. For some reason, less constantly messes with me when I cut and paste diffs instead of saving them to a file and including them directly. I could have sworn I configured it to never use partial pages. Included is the correct version of the patch. > One rarer case is missing here: > 1.2.3-4~deb9u1 > Everything in 1.2.3-4 from unstable was in fact needed in Debian > 9, so it was simply rebuilt for Debian 9 and uploaded there > (prominent examples: firefox-esr, intel-microcode) Is this widespread enough to be worth describing? It's kind of hard to describe. diff --git a/policy.xml b/policy.xml index 7ba5fc0..fbc53c9 100644 --- a/policy.xml +++ b/policy.xml @@ -357,6 +357,21 @@ + native package + + + A native package is software written specifically for Debian + whose canonical distribution format is as a Debian package. + Native packages have no separate upstream source in their + source package representation and no separate Debian + revision in their version numbers. Native packages are an + exception: most Debian packages are "non-native" and have + source packages composed of an upstream software release and + separate Debian-specific modifications. + + + + UTF-8 @@ -589,13 +604,10 @@ must not require or recommend a package outside of main for compilation or execution - (thus, the package must not declare a - Pre-Depends, Depends, - Recommends, - Build-Depends, - Build-Depends-Indep, or - Build-Depends-Arch relationship on a - non-main package), + (thus, the package must not declare a "Pre-Depends", + "Depends", "Recommends", "Build-Depends", + "Build-Depends-Indep", or "Build-Depends-Arch" relationship + on a non-main package), @@ -3725,11 +3737,11 @@ Package: libc6 It is optional; if it isn't present then the upstream_version may not -contain a hyphen. This format represents the case where a -piece of software was written specifically to be a Debian -package, where the Debian package source must always be -identical to the pristine source and therefore no revision -indication is required. +contain a hyphen. This format represents a native +package: a piece of software written specifically to be a +Debian package, where the Debian package source must +always be identical to the pristine source and therefore +no revision indication is required. It is conventional to restart the @@ -3814,6 +3826,110 @@ Package: libc6 + + + Special version conventions + + +The following special version numbering conventions are used in +the Debian archive: + + + + +The absence of debian_revision, +and therefore of a hyphen in the version number, indicates +that the package is native. + + + + +debian_revision components +ending in . followed by a number +indicate this version of the non-native package was +
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
eprecated. Use the + optional priority instead. + + + The extra priority was previously used + for packages that conflicted with other packages and + packages that were only likely to be useful to people with + specialized requirements. However, this distinction was + somewhat arbitrary, not consistently followed, and not + useful enough to warrant the maintenance effort. - -Packages must not depend on packages with lower priority values -(excluding build-time dependencies). In order to ensure this, the -priorities of one or more packages may need to be adjusted. - - -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables
Russ Allbery <r...@debian.org> writes:
> Looking at this section, there are several issues. One is the issue
> addressed above, and I like Jonathan's wording for that. Another is the
> one Colin mentioned earlier: this only applies to programs installed in
> the system path. (I considered saying programs intended to be directly
> invoked by users, but I can imagine pointless arguments about /usr/sbin
> programs, so let's just go with that.) A third issue is that parts of
> that section are now out of date, since /etc/profile.d exists (but still
> shouldn't be used for this purpose).
> I propose the attached patch to address all of those issues. Seconds or
> further discussion?
Hi folks,
Everyone seemed generally happy with this text, but it never clearly got
enough seconds to apply. Here's an updated patch so that we can take
another run at getting enough seconds and getting it merged.
diff --git a/policy.xml b/policy.xml
index 7ba5fc0..ace6a3b 100644
--- a/policy.xml
+++ b/policy.xml
@@ -9352,11 +9352,14 @@ Reloading description
configuration...done.
Environment variables
-A program must not depend on environment variables to get
-reasonable defaults. (That's because these environment variables
-would have to be set in a system-wide configuration file like
-/etc/profile, which is not supported by all
-shells.)
+Programs installed on the system PATH (/bin,
+/usr/bin, /sbin,
+/usr/sbin, or similar directories) must not
+depend on custom environment variable settings to get reasonable
+defaults. This is because such environment variables would have
+to be set in a system-wide configuration file such as a file in
+/etc/profile.d, which is not supported by all
+shells.
If a program usually depends on environment variables for its
@@ -9364,7 +9367,7 @@ Reloading description
configuration...done.
reasonable default configuration if these environment variables
are not present. If this cannot be done easily (e.g., if the
source code of a non-free program is not available), the program
-must be replaced by a small "wrapper" shell script which sets the
+must be replaced by a small "wrapper" shell script that sets the
environment variables if they are not already defined, and calls
the original program.
@@ -9377,12 +9380,6 @@ BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
-
-Furthermore, as /etc/profile is a
-configuration file of the base-files package,
-other packages must not put any environment variables or other
- commands into that file.
-
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#587279: Clarify restrictions on main to non-free dependencies
Raphael Geissert <geiss...@debian.org> writes: > After five years of letting the discussion settle down, perhaps there's > a way to move things forward now? > Other than the discussion about foo2zjs I think that only Bill believes > that the new wording proposed in message #56 differs from the current > practice. > Moreover, as demonstrated by follow ups, the issue raised by Bill > regarding the possibility of an accidental installation of non-free > software appears to be a system configuration problem. That is, the > granularity of what should or should not be taken into consideration > when resolving a package's dependencies can and should be handled on the > package manager's side. > As such, I believe that the proposed wording is appropriate and open for > seconding. Here is an updated version of the patch from earlier in this (now very long) thread for discussion. I still think this is consistent with previous practice and reasonable documentation of what we're currently doing. diff --git a/policy.xml b/policy.xml index 7ba5fc0..daf4c3c 100644 --- a/policy.xml +++ b/policy.xml @@ -595,7 +595,9 @@ Build-Depends, Build-Depends-Indep, or Build-Depends-Arch relationship on a - non-main package), + non-main package) unless that package + is only listed as a non-default alternative for a package in + main, If we still can't reach consensus on this, we should probably bump it to the Technical Committee for resolution so that this doesn't just sit around unresolved forever. (I feel like that happened at some point in the past, but it's been so long that my memory is very hazy.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
stribution. The +N is the major version number +of the Debian stable release to which the package was +uploaded, and the X is a +number, starting at 1, that is increased for each stable +upload of this package. + + + + Suppose Debian 9 released with a package with version + 1.4-5. If that package later + receives a stable update in Debian 9, the first update + would have the version 1.4-5+deb9u1. + A subsequent update would have version + 1.4-5+deb9u2. These numbers are + designed to sort earlier than 1.4-6, + the version number that would be used for the next + unstable upload. + + + + + +upstream_version components in +native packages or +debian_revision components in +non-native packages ending in ~bpoNuX +indicate a backport of a version of the package to an +older stable release. The part of the version before +~bpo is the version of the package +being backported, the N is the +major version number of the Debian stable release to which +the package was backported, and the +X is a number, starting at 1, +that is increased for each revision of the backport of +that package version. + + +This version convention was chosen to sort before the +original package release that is being backported so that +the backport will upgrade to the original package during a +later system upgrade to a newer Debian release. + + + + -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Declaring a charset of UTF-8 for policy files
Paul Wise <p...@debian.org> writes: > On Sat, 2017-06-24 at 20:07 -0700, Paul Hardy wrote: >> 2) Set the HTTP headers for charset="UTF-8" > FYI, there are 1018 non-UTF-8 out of 2605 total *.txt files on the > Debian website and 9 non-UTF-8 out of 1102 total *.txt files in the > Debian archive mirrors. It seems feasible to convert the files in the > Debian archive to UTF-8 but it doesn't seem to be feasible to do that > for www.debian.org. Can't we just set the character set for the text files that come from Debian Policy? At least with Apache you can set character sets with whatever granularity you want. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Declaring a charset of UTF-8 for policy files
Paul Hardy <unifoun...@gmail.com> writes: > If using the UTF-8 signature in a document is too aesthetically > distateful (and I don't disagree), and if setting the HTTP header to > denote a UTF-8 charset is not a universal solution because it will only > have effect on Debian's servers, would a tool that converted such text > files to an HTML document be desirable? Such a hypothetical tool would > insert a meta tag in the header saying . That's one of the things that confuses me a bit -- why not just use the existing HTML files? All the text files in Debian Policy (except for virtual-package-names-list.txt, which doesn't have any UTF-8) are generated by rendering the HTML to text. The HTML is there alongside, and if you're looking at things in a web browser, I'd think they'd be preferrable. I assume you're looking at: https://www.debian.org/doc/devel-manuals#policy All of the primary links are to HTML. I'm certainly happy to try to get the text versions correct, but I would expect most people would prefer to use the HTML versions. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Declaring a charset of UTF-8 for policy files
Stéphane Blondon <stephane.blon...@gmail.com> writes: > pabs added such configuration few days ago for Apache configuration: > https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/commit/?id=5bcf8431d6b375d211a29f9d2c338e4400332e1a > The reason is a bad display in some browser for UTF-8 encoded txt file. > The start of this thread: > https://lists.debian.org/debian-www/2017/06/msg00068.html Perfect, thank you! Paul, does this resolve your original issue? I'm a bit worried that it might not because this was a little bit ago, and I think it should have already been in place when you were testing. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Russ Allbery <r...@debian.org> writes: > I did a bit more research, and apparently this approach has become more > blessed again. I'm glad I looked it up! As of Unicode 5.0, the > standard explicitly recommended against doing this, but the latest > version of the standard is moderately positive about it (although > doesn't require it): > In UTF-8, the BOM corresponds to the byte sequence BF16>. Although there are never any questions of byte order with UTF-8 > text, this sequence can serve as signature for UTF-8 encoded text > where the character set is unmarked. > (although it does strongly discourage it if there's any other signaling > method available). Okay, I experimented with this, but unfortunately less displays the BOM at the start of the file as a very ugly reverse-video <U+FEFF> at the top of the screen. I think this is arguably a bug in less; this is a control character in a sense, but the whole point is for it to be invisible, particularly when it's the first character of the file. Nonetheless, that's how less currently behaves. My feeling is that good display in less is a more important use case for us than enabling this autorecognition in web browsers (which will normally be viewing the HTML versions). Given that, I think the right fix here is to fix the declared charset on www.debian.org for these files. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Declaring a charset of UTF-8 for policy files
debian-www, not debian-web. Colin Watson <cjwat...@debian.org> writes: > On Fri, Jun 23, 2017 at 11:49:20PM -0700, Russ Allbery wrote: >> I'm still a bit dubious about this, since I don't believe editors and >> generators normally add it, but given how we generate the text versions >> of the documents, it's relatively easy to add a leading BOM and seems >> harmless. I'll take a look. > I share the discomfort in your previous message with using the UTF-8 > BOM. I'd have thought that a better approach here would be to fix this > at the HTTP layer: > https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt > (and other text files here) should return "Content-Type: text/plain; > charset=UTF-8", not just "Content-Type: text/plain". debian-www folks, is there a way to declare UTF-8 as the charset for all the *.txt files that originate from the debian-policy package and are served by www.debian.org? I can guarantee that all the text files shipped as part of the Policy package will be valid UTF-8. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865769: Second data package including some machine-readable data
Package: debian-policy Version: 4.0.0.2 Severity: wishlist A discussion in #865720 got me thinking that there is some data maintained in Policy that would be useful to have in a machine-readable format. The things that have occurred to me so far are: - The list of registered virtual packages - The list of archive sections and their descriptions - The list of valid Debian control field names (by type of control file) These are things that either we already maintain or that have no other obvious place to live. This data could then be consumed by packages like lintian (although that's a bit tricky for lintian.debian.org), libconfig-model-dpkg-perl, etc. The idea would be to provide these in some machine-readable form (probably JSON unless someone has objections) in files under /usr/share/debian-policy or some similar path (so that software can consume them) in a separate binary package built from the debian-policy package (debian-policy-data, perhaps) so that other packages can depend on that package without pulling in the larger human-focused Policy documentation. If anyone has ideas for other things that should be included, or any concerns, please speak up! -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#865720: libconfig-model-dpkg-perl: hard-codes the list of virtual packages, mistake in recent update
Paul Wise <p...@debian.org> writes: > On Fri, 2017-06-23 at 23:39 -0700, Russ Allbery wrote: >> That said, if there's some desire for automated consumption of the list >> from the Policy package, I'd be happy to provide it in a >> machine-readable format. I wonder if there would be some merit in >> building a separate binary package from the debian-policy source >> package that includes a few lists like that (archive sections also come >> to mind) in machine-readable formats in /usr/share somewhere. > That sounds like a good idea to me, especially for archive section > descriptions, which are hard-coded in a number of packages: > https://wiki.debian.org/NewArchiveSections I'll create a bug. These days, I normally use JSON for that sort of thing. Does that seem reasonable, or is there a reason to use some other format instead? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Declaring a charset of UTF-8 for policy files (was: Re: Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature)
Colin Watson <cjwat...@debian.org> writes: > On Fri, Jun 23, 2017 at 11:49:20PM -0700, Russ Allbery wrote: >> I'm still a bit dubious about this, since I don't believe editors and >> generators normally add it, but given how we generate the text versions >> of the documents, it's relatively easy to add a leading BOM and seems >> harmless. I'll take a look. > I share the discomfort in your previous message with using the UTF-8 > BOM. I'd have thought that a better approach here would be to fix this > at the HTTP layer: > https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt > (and other text files here) should return "Content-Type: text/plain; > charset=UTF-8", not just "Content-Type: text/plain". debian-web folks, is there a way to declare UTF-8 as the charset for all the *.txt files that originate from the debian-policy package and are served by www.debian.org? I can guarantee that all the text files shipped as part of the Policy package will be valid UTF-8. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Paul Hardy <unifoun...@gmail.com> writes: > Alternatively, if convenient, you could convert the non-breaking space > characters to a plain space in that text file in a script. That will > avoid the problem until you need some other non-ASCII character in the > file other than non-breaking space. You could convert all of those > non-breaking space characters to ordinary spaces in one fell swoop with: > sed -i 's/\o302\o240/ /g' upgrading-checklist.txt If this file doesn't already contain UTF-8 characters that can't be trivially replaced, it almost certainly will in the future, so I'm fine with it containing the non-breaking spaces to force the matter (even if in general they're a little irritating). The file will definitely be UTF-8, so I think we should try to get this right. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Russ Allbery <r...@debian.org> writes: > I don't believe it's correct to expect UTF-8 files to include this. > I've heard of BOM marks used this from the very early days of Unicode, > but so far as I understand it, the world has largely given up on this > approach and UTF-8 generators do not produce them. I did a bit more research, and apparently this approach has become more blessed again. I'm glad I looked it up! As of Unicode 5.0, the standard explicitly recommended against doing this, but the latest version of the standard is moderately positive about it (although doesn't require it): In UTF-8, the BOM corresponds to the byte sequence . Although there are never any questions of byte order with UTF-8 text, this sequence can serve as signature for UTF-8 encoded text where the character set is unmarked. (although it does strongly discourage it if there's any other signaling method available). I'm still a bit dubious about this, since I don't believe editors and generators normally add it, but given how we generate the text versions of the documents, it's relatively easy to add a leading BOM and seems harmless. I'll take a look. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865720: libconfig-model-dpkg-perl: hard-codes the list of virtual packages, mistake in recent update
Paul Wise <p...@debian.org> writes: > libconfig-model-dpkg-perl hard-codes the list of virtual package names > in the @virtual_list array in the lib/Config/Model/Dpkg/Dependency.pm > file. The authoritative list is available in the debian-policy package. > Config::Model::Dpkg should depend on debian-policy and use the Perl > equivalent of the below command to extract the list of virtual > packages. This would prevent the kind of mistake that was recently done > in the below commit (wish -> virtual-mysql-testsuitewish). It's worth noting that registering a virtual package with Policy is optional if it is used among a cooperating set of packages, and there are numerous virtual packages in Debian that are not listed there. Policy is not particularly clear about this, but note the parenthetical in 3.6 here: They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. That said, if there's some desire for automated consumption of the list from the Policy package, I'd be happy to provide it in a machine-readable format. I wonder if there would be some merit in building a separate binary package from the debian-policy source package that includes a few lists like that (archive sections also come to mind) in machine-readable formats in /usr/share somewhere. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Paul Hardy <unifoun...@gmail.com> writes: > That might not be the only UTF-8 that appears in such files someday > though, so a more general solution would be to start the file with the > UTF-8 signature, aka the Byte Order Mark (BOM). This is the UTF-8 > encoding of U+FEFF, which is 0xEF 0xBB 0xBF or octal \357 \273 \277. > Then a web browser should display UTF-8 characters within the text file > properly. Hi Paul, I don't believe it's correct to expect UTF-8 files to include this. I've heard of BOM marks used this from the very early days of Unicode, but so far as I understand it, the world has largely given up on this approach and UTF-8 generators do not produce them. Debian is full of UTF-8 files (copyright files, changelog files, etc.), and I don't believe we include those BOM marks anywhere. I don't think it makes sense for Policy to go to special effort to be unique in this regard. You should just assume that all text files in Debian are UTF-8 unless they are declared otherwise and configure browsers and other file readers accordingly. (Also, if you're viewing things in a web browser, just view the HTML files. It will be a much better experience.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Andreas Henriksson <andr...@fatal.se> writes: > Even if ftp-masters where really keen on actively managing the overrides > file I wonder what purpose this would serve? > As already mentioned previously in this bug backlog it would just be a > waste of ftp-master time. > Either way, I'm adding ftpmaster to CC now. Thanks! Let's just ask directly. ftp-master folks, we're discussing eliminating the requirement that packages only depend on other packages with the same or higher priority (so important packages would be able to depend on optional packages), and deprecating the extra priority entirely (so everything at extra priority would end up being optional over time). This also means eliminating the requirement that no two packages at optional priority conflict with each other. Some parts of this have more consensus than others, so I'm not sure we'll do all of these things. But one question that keeps coming up is whether y'all care or have strong opinions about any of this. Do you care about any of these topics as ftp-master and the current effective owners of archive priorities? Or would you be fine with just going with whatever decision the Policy discussion produces? (The underlying mental model behind these changes is the belief that priorities have become basically meaningless to the typical user who is installing packages -- they use other mechanisms to find the package they want to install -- and really only serve a purpose at the priorities higher than optional for initial installs, deciding what to put on CD images, and for hinting purposes for tools like debootstrap. None of the requirements we're considering removing are particularly relevant to those purposes, so feel like largely wasted effort by ftp-master and package maintainers.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865140: Broken with network-manager 1.8.0-5 (at least for split tunnel)
Package: network-manager-openconnect Version: 1.2.4-1 Severity: important After upgrading network-manager to 1.8.0-5 from 1.6.2-3, connecting to a VPN with network-manager-openconnect still works but doesn't set up the routing table entries properly. (This is a split-tunnel VPN.) I'm guessing something changed in the NetworkManager internals that broke part of this plugin. The problem went away again after downgrading network-manager back to 1.6.2-3. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager-openconnect depends on: ii adduser 3.115 ii libc62.24-11 ii libglib2.0-0 2.50.3-2 ii libnm0 1.8.0-5 ii network-manager 1.6.2-3 ii openconnect 7.08-1 network-manager-openconnect recommends no packages. network-manager-openconnect suggests no packages. -- no debconf information
Bug#863582: Allow configurable build directory
Sean Whitton <spwhit...@spwhitton.name> writes: > I believe that Ian's intention is that the build tool should be > configured to put build products somewhere else, and then dgit should be > told where they are using --build-products-dir. I.e. you have > ~/.gbp.conf telling gbp where to put build products, and then > % dgit --build-products-dir ~/foo gbp-build This appears to not work. In fact, there appears to be no way to get dgit to work with gbp-buildpackage if you set an export-dir in your ~/.gbp.conf (at least in some brief experiments). Even with that flag, dgit writes some (but not all) of its output files in the parent directory (pieces of the source package and the downloaded dsc file of the previous release), and then aborts because it can't find the right files. It appears to be doing pieces of the build outside of gbp-buildpackage, since I know gbp-buildpackage will always write all of its files in my configured export-dir. I could be missing something, but I tried a few different iterations before just giving up and using dgit build, and I couldn't figure out any way to get all of the build product in the right location and get dgit push to find it. I unfortunately didn't save a full transcript of my session, but I tried: $ dgit -wgf --build-product-dir ../build-area gbp-build $ dgit -wgf --build-product-dir ../build-area push and then again with expicitly setting --export-dir on the gbp-build command line in case dgit was overriding it somehow. My ~/.gbp.conf has: [buildpackage] export-dir = ../build-area/ tarball-dir = ../tarballs/ -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#864310: Recommends cleanup
Package: xscreensaver Version: 5.36-1 Severity: minor Per discussion on debian-devel, there are a couple of packages in Recommends of xscreensaver that can be safely removed: - libgnomeui-0 is now obsolete; it was for integration with GNOME 2, and per the debian-devel thread now doesn't do anything particularly useful. - perl5 doesn't exist as a package any more. If there are plugins that want Perl, the right Recommends is perl, not perl5. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xscreensaver depends on: ii libatk1.0-0 2.22.0-1 ii libc62.24-11 ii libcairo21.14.8-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglade2-0 1:2.6.4-2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libice6 2:1.0.9-2 ii libpam0g 1.1.8-3.6 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxml2 2.9.4+dfsg1-2.2 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.36-1 Versions of packages xscreensaver recommends: pn libgnomeui-0 pn libjpeg-turbo-progs pn perl5 ii wamerican [wordlist] 2017.01.22-1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 58.0.3029.96-1 ii firefox [www-browser] 53.0.is.52.0.2-1 pn fortune pn gdm3 | kdm-gdmcompat ii google-chrome-stable [www-browser] 59.0.3071.86-1 ii links [www-browser] 2.14-2+b1 pn qcam | streamer ii w3m [www-browser] 0.5.3-34 pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information
Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd
Dmitry Smirnov <only...@debian.org> writes: > Interesting... Why not use Debhelper to install the file? Historical > reasons? ;) It's in /run, which is ephemeral and destroyed on each reboot, and maintainer scripts created by debhelper (and directories shipped in the package) are only created once during package installation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863841: Enable systemd hardening options for named
Package: bind9 Version: 1:9.10.3.dfsg.P4-12.3 Severity: wishlist BIND named is a great candidate for enabling systemd hardening features, since it has very limited required access to the local file system and a long history of security issues due to its complexity. I'm currently using the following settings on jessie without any impact, although I'm not using dynamic DNS or a few other things that may make a difference. jessie had much more limited options; there are other options now available in newer systemd, and I didn't start looking at system call filtering. CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID NoNewPrivileges=true PrivateDevices=true PrivateTmp=true ProtectHome=true ProtectSystem=full CAP_DAC_OVERRIDE is required for rndc to read /etc/bind/rndc.key; a possible alternative would be to find a way to run it as the bind user instead. It's possible that you could drop CAP_SETGID and CAP_SETUID and instead let systemd switch to the bind user, and put CAP_NET_BIND_SERVICE into the ambient capability set instead so that it can still bind to a low-numbered port. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bind9 depends on: ii adduser3.115 ii bind9utils 1:9.10.3.dfsg.P4-12.3 ii debconf [debconf-2.0] 1.5.61 ii init-system-helpers1.48 ii libbind9-140 1:9.10.3.dfsg.P4-12.3 ii libc6 2.24-11 ii libcap21:2.25-1 ii libcomerr2 1.43.4-2 ii libdns162 1:9.10.3.dfsg.P4-12.3 ii libgeoip1 1.6.9-4 ii libgssapi-krb5-2 1.15-1 ii libirs141 1:9.10.3.dfsg.P4-12.3 ii libisc160 1:9.10.3.dfsg.P4-12.3 ii libisccc1401:9.10.3.dfsg.P4-12.3 ii libisccfg140 1:9.10.3.dfsg.P4-12.3 ii libk5crypto3 1.15-1 ii libkrb5-3 1.15-1 ii liblwres1411:9.10.3.dfsg.P4-12.3 ii libssl1.0.21.0.2l-1 ii libxml22.9.4+dfsg1-2.2 ii lsb-base 9.20161125 ii net-tools 1.60+git20161116.90da8a0-1 ii netbase5.4 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind9-doc ii dnsutils1:9.10.3.dfsg.P4-12.3 pn resolvconf pn ufw -- debconf information: bind9/start-as-user: bind bind9/different-configuration-file: bind9/run-resolvconf: false
Bug#863729: marked as done (debian-policy: please use the cgit link in Vcs-Browser)
ow...@bugs.debian.org (Debian Bug Tracking System) writes: > The (Browse) link on https://tracker.debian.org/pkg/debian-policy. Now > I notice it isn't the one in the control file. I assumed that was the > result of some redirection, but that's not the case. You indeed fixed > this in the experimental version (commit 670b8419), it's just the > package tracker still carrying the old link from the unstable control > file. Oh! Yes. It will probably be fixed once the package is uploaded to unstable after the stretch release. I suspect tracker.debian.org (rightfully) prefers unstable to experimental. > Sorry for the noise, No problem at all! Thank you for the report -- definitely want to know about things like this, since I personally tend to never test or notice them since my workflow always involves a local checkout. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863729: debian-policy: please use the cgit link in Vcs-Browser
Ferenc Wágner <wf...@debian.org> writes: > Package: debian-policy > Severity: minor > Your control file specifies > https://anonscm.debian.org/git/dbnpolicy/policy.git > as Vcs-Browser, but the gitweb interface gives "Bad object id:" messages > when clicking into the shortlog section. Please switch to > https://anonscm.debian.org/cgit/dbnpolicy/policy.git > if possible. We were specifically asked by the anonscm maintainers to use the URL that we're currently using. It's supposed to work And it does seem to work fine for me? I clicked around a bunch through the interface and couldn't reproduce that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#759492: File conflicts between /bin and /usr/bin
wf...@niif.hu (Ferenc Wágner) writes: > On Sat, 31 Dec 2016 23:33:13 -0800 Russ Allbery <r...@debian.org> wrote: >> + To support merged-/usr systems, packages must not >> + install files in both path > Is there a reason to omit the leading slash in this construct? I think > I'd find /path more symmetric and thus easier to > follow. Yup, I completely agree and have fixed that for 4.0.0.1. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863578: Initial upload to experimental should probably still merge history
Sean Whitton <spwhit...@spwhitton.name> writes: > For the first upload of policy 4.0.0.x to unstable, I'm suggesting > --deliberately-not-fast-forward so that the history is a linear > descendent of the upload you made to experimental today. With > --overwrite, instead, the parent of HEAD would be a pseudomerge with > dgit's representation of policy 3.9.8.0. Maybe you prefer this, of > course. Oh, hm. I actually think the second is better, isn't it? Since it allows anyone who had cloned dgit's representation of 3.9.8.0 to update cleanly to the current dgit tree. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863578: Initial upload to experimental should probably still merge history
Sean Whitton <spwhit...@spwhitton.name> writes: > On Sun, May 28, 2017 at 02:59:16PM -0700, Russ Allbery wrote: >> Does that merge the dgit history of the package from the unstable >> branch into the history in the way that dgit-maint-native implies is >> supposed to happen? Or by "be a descendent of unstable" do you mean a >> descendent of the dgit unstable repository? > No, it basically prevents that automatic merge from happening (and as > such it only works when the package is new in the suite). Oh, okay, I think I understand. And then, when uploading to unstable, it would then work? Or would I need --overwrite on the upload to unstable? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863578: Initial upload to experimental should probably still merge history
Sean Whitton <spwhit...@spwhitton.name> writes: > This is already possible: have your git history be a descendent of > unstable, and use --deliberately-not-fast-forward instead of > --overwrite. Documentation of this is waiting in #856402. Ah, yes, I presume that would work. Does that merge the dgit history of the package from the unstable branch into the history in the way that dgit-maint-native implies is supposed to happen? Or by "be a descendent of unstable" do you mean a descendent of the dgit unstable repository? > In light of what I wrote above, the suggestion would be to have > --deliberately-not-fast-forward be implicit for --new uploads to > experimental where HEAD is a descendent of dgit/dgit/sid? I think the missing piece may be how the naive new user like myself, who is currently told to just do dgit push --overwrite, should create the appropriate merge so that this condition is true of my existing repository. (I know enough Git that I could probably fumble my way through, but dgit should probably do it for me somehow.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863582: Allow configurable build directory
Control: forcemerge 857316 -1 Sean Whitton <spwhit...@spwhitton.name> writes: > I believe that Ian's intention is that the build tool should be > configured to put build products somewhere else, and then dgit should be > told where they are using --build-products-dir. I.e. you have > ~/.gbp.conf telling gbp where to put build products, and then > % dgit --build-products-dir ~/foo gbp-build Oh! That was the flag I was missing. Thank you. Could you mention --build-products-dir in dgit-maint-gbp, since this is a very common setting? > Of course, it really should be possible to set a permanent > --build-products-dir in ~/.gitconfig. That's #857316. > Does this fulfill your feature request? If so, this bug should be > merged with #857316. Yup! That seems fine. Thank you! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863582: Allow configurable build directory
Package: dgit Version: 3.10 Severity: wishlist I use git-buildpackage for all of my package building, and one reason why is that I deeply dislike the default Debian behavior of cluttering the parent directory with random package build files. git-buildpackage has always supported configuring a build directory (../build-area appears to be common) to use for build output, where it doesn't clutter directory listings and can easily be purged after successful uploads. It looks like dgit doesn't support this. At least, I don't see any configuration option that lets me set it, and dgit was unable to find builds in my configured build directory for upload. And there's no mention of this (quite common) configuration in the dgit-maint-gbp man page. Could this please be added? Or if I'm missing the documentation for it, maybe a few pointers to the correct documentation could be added to that man page? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii apt 1.4.4 ii ca-certificates 20161130+nmu1 ii coreutils 8.26-3 ii curl 7.52.1-5 ii devscripts2.17.5 ii dpkg-dev 1.18.24 ii dput-ng [dput]1.12 ii git [git-core]1:2.11.0-4 ii git-buildpackage 0.8.12.2 ii libdpkg-perl 1.18.24 ii libjson-perl 2.90-1 ii liblist-moreutils-perl0.416-1+b1 ii libperl5.24 [libdigest-sha-perl] 5.24.1-2 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl1.7-5+b4 ii libwww-perl 6.15-1 ii perl 5.24.1-2 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:7.4p1-10 Versions of packages dgit suggests: pn sbuild -- no debconf information
Bug#863578: Initial upload to experimental should probably still merge history
Package: dgit Version: 3.10 Severity: wishlist If a package that hasn't been using dgit is uploaded using dgit to experimental, when it hasn't been uploaded to experimental before, one cannot use the --overwrite option and merge previous dgit history. Presumably (I haven't gotten that far yet) this will happen on the first upload to unstable. I may be naive about dgit's branch model, but it seems like it would be good to merge dgit's history with the maintainer's history as early as possible in this process, and experimental uploads (when there's no previous experimental upload) should be considered a descendent of the unstable history. The separation makes a lot of sense to me for stable branches or backports branches, but experimental is not a "true" suite in the way in which it's used in Debian; it's more of a temporary branch from unstable, and I guess I was expecting dgit to treat it that way. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii apt 1.4.4 ii ca-certificates 20161130+nmu1 ii coreutils 8.26-3 ii curl 7.52.1-5 ii devscripts2.17.5 ii dpkg-dev 1.18.24 ii dput-ng [dput]1.12 ii git [git-core]1:2.11.0-4 ii git-buildpackage 0.8.12.2 ii libdpkg-perl 1.18.24 ii libjson-perl 2.90-1 ii liblist-moreutils-perl0.416-1+b1 ii libperl5.24 [libdigest-sha-perl] 5.24.1-2 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl1.7-5+b4 ii libwww-perl 6.15-1 ii perl 5.24.1-2 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:7.4p1-10 Versions of packages dgit suggests: pn sbuild -- no debconf information
Bug#863576: Perl error on --overwrite --new
Package: dgit Version: 3.10 Severity: minor I'm uploading a native package (debian-policy) using dgit that has never used dgit before, and I'm uploading the package to experimental. This isn't really anticipated by dgit-maint-native, so I went down a path of trying to use the command there, being told that the package doesn't exist in that suite (I'm going to file another wishlist bug about that), and being told to add --new. But if I do that, I get the following output: mithrandir:~/dvl/debian/policy$ dgit -wgf --overwrite --new push canonical suite name is experimental no version available from the archive Use of uninitialized value $objid in hash element at /usr/bin/dgit line 991. ! Push failed, while preparing your push. ! You can retry the push, after fixing the problem, if you like. I was able to guess that the problem was that --overwrite and --new aren't meaningful together, but the error message is quite opaque and flags a line in the middle of deep dgit plumbing that doesn't make the cause obvious. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii apt 1.4.4 ii ca-certificates 20161130+nmu1 ii coreutils 8.26-3 ii curl 7.52.1-5 ii devscripts2.17.5 ii dpkg-dev 1.18.24 ii dput-ng [dput]1.12 ii git [git-core]1:2.11.0-4 ii git-buildpackage 0.8.12.2 ii libdpkg-perl 1.18.24 ii libjson-perl 2.90-1 ii liblist-moreutils-perl0.416-1+b1 ii libperl5.24 [libdigest-sha-perl] 5.24.1-2 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl1.7-5+b4 ii libwww-perl 6.15-1 ii perl 5.24.1-2 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:7.4p1-10 Versions of packages dgit suggests: pn sbuild -- no debconf information
Bug#823180: SSO certificates for tracker.debian.org broken
Enrico Zini <enr...@debian.org> writes: > On Mon, Jan 16, 2017 at 09:26:10PM -0800, Russ Allbery wrote: >> Is there any way that I or someone can help with the current issue with >> enrolling on sso.debian.org? It looks like this was originally >> reported in May of last year on this bug. > Sure. Although I'm bad at project managing myself[1], I'm very happy to > help. Well, this was also rather embarassing on my part. I sent that message in January in a burst of optimism and energy, coming off vacation, and then promptly ran out of any time and never followed this up. > Ack. I refactored sso.debian.org when we got rid of DACS, and now there > are two login pages, one for debian.org and one for alioth.debian.org, > because sso.debian.org has now been setup with two views of the same > functionalities each with a different apache authentication. > That link should probably just be changed to https://sso.debian.org/ I confirm this is now fixed. >> If one goes directly to sso.debian.org, clicks on Debian account >> certificates, and logs in, clicks on Get new certificate, and then >> submits, it just produces "/usr/bin/openssl failed" as an error message >> at the top of the page. > That would be with chrome/chromium, I suppose? They disabled the > certificate generation functionality by default: > https://wiki.debian.org/DebianSingleSignOn#chromium_.2F_chrome > I know of no way of doing certificate generation on recent chromes > without explicitly enabling it as described on the wiki link above, and > I read somewhere months ago[citation needed] that the chrome devs > decided it's a feature that they intend to remove altogether. It'd be > nice if they changed their mind or started suggesting alternatives. Oh! Yes, that's indeed the problem, and that makes sense. I thought the old error message (about openssl failure) indicated some server-side issue rather than a client issue. I see that the error message is now much nicer (thank you!). > I started playing with the idea of a command line tool that would take > care of browsers: https://github.com/spanezz/debsso-client and it looks > like a promising avenue, in that it's possible to feed client > certificates to chromium and firefox from the command line: > https://lists.debian.org/debian-devel/2016/10/msg00131.html > debsso-client could do SPKAC with sso.debian.org and inject the > resulting certificate into the browsers key store: > 1. openssl genrsa -out user.key 2048 > openssl spkac -key user.key -challenge FvIu8NDJZxGmpKmA5pp3asMDZChXD4rc | > cut -d= -f2- > 2. Post it to https://sso.debian.org/debian/certs/enroll_manually or > https://sso.debian.org/alioth/certs/enroll_manually authenticating > with HTTP basic auth, together with the validity and comment fields > that you see on the page > 3. get the client certificate as the result of the POST > 4. feed it into the browser key store I went through the equivalent of that process manually using the manual certificate generation instructions, and it works great. This seems like the right approach to me as well. I should probably take the five month delay in even responding to this message as a sign that I have no business trying to dive into new responsibilities and help out more with this at the moment. :( Apologies for offering help and then going totally silent; my reach exceeded my grasp. But thank you *very* much for taking the time to describe the problem and the proposed approach, and if I manage to pry free any time to work on SSO stuff again, I will take a look at the code and also look at the problem area and see if there's something better we can do. (That said, I suspect that an external script to inject the certificate into the browser is probably the best approach. There are various security worries about letting the browser generate certs directly, and I'm not sure if the browser authors will be particularly excited about supporting this functionality. I think people in the industry have largely given up on client-side browser certs in favor of U2F, although that doesn't solve exactly the same problem.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#863260: kstart: k5start does not recognize network changes
Control: reassign -1 libkrb5-3 Control: affects -1 kstart Kai Wohlfahrt <kai.scor...@gmail.com> writes: > Package: kstart > Version: 4.2-1 > Severity: important > Tags: upstream > Dear Maintainer, > The k5start program repeats attempts to contact the KDC server if it is > unavailable. However, it continues to fail if a new network is > available. > Steps to reproduce: > - Disable network interface > - Run k5start (e.g. k5start -f /etc/krb5.keytab -K 10 -u host/jason -k > test.tkt) > - Enable network interface > I expect to see the error below repeated until the network comes back > up, and then it should stop: > k5start: error getting credentials: Cannot contact any KDC for realm > 'MY.REALM.NAME' > Instead, I continue to get errors until I stop the k5start > process. Starting it again after the network is available shows no > errors and gets the ticket correctly. k5start just calls krb5_get_init_creds_*, so if something is being inappropriately cached, this would be a bug in the underlying Kerberos library (rather than in kstart). Reassigning accordingly. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#862698: ITP: minecraft -- blocks to build anything you can imagine
Simon McVittie <s...@debian.org> writes: > If this package downloads proprietary files automatically, here are some > issues that should be considered: > * minimizing amount of code run as root (downloading the Minecraft > launcher per-user is probably better - the launcher will download > Minecraft itself once per user anyway, so sharing files between users > to reduce disk space usage is not straightforward) > * not executing code that was not obtained in a way that can be trusted: > downloading via https with correct certificate validation, or checking > the launcher against known-good cryptographic hashes like > game-data-packager does, or similar > * not preventing offline apt updates in which packages are downloaded > while online, then installed at a later time without Internet access > game-data-packager/doc/why.mdwn might be interesting reading. Another thing that would be a really neat addition to a wrapper around Minecraft would be to run it inside a restrictive namespace by default. Minecraft has a pretty well-understood file access pattern, and there's really no reason to allow it to read, say, your Firefox cookie database, or something else that's in your home directory. You could probably also cut off quite a lot of syscalls with seccomp without changing the functionality. I played around with configurations for a server and can confirm that the following systemd jailing configuration works for the server, but I'm quite sure that one could get more restrictive than this with some work (for example, I didn't even start on syscall filtering). PrivateUsers=true ProtectSystem=full ProtectHome=true ProtectKernelTunables=true ProtectControlGroups=true NoNewPrivileges=true ProtectKernelModules=true -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#175064: DocBook XML conversion is read with this script
Guillem Jover <guil...@debian.org> writes: > Ok, here's the updated patch series for the conversion omitting the > actual conversion commit. Attached and in the pu/markup-singularity > branch at <https://git.hadrons.org/cgit/debian/policy.git/>. This has now been applied including the conversion generated by the script. Thank you both for all your work on this! This is a huge milestone. I have also gone through and reformatted and rewrapped the resulting DocBook source to make it a bit more human-maintainable. Not saying that it's the best possible format (unfortunately, DocBook has fairly long tag names), but it's a bit better than no indentation whatsoever, and is at least relatively consistent. And it's the formatting that I like and I'm doing most of the patch merging right now, so :P There's almost certainly going to be a bunch of remaining minor issues and formatting bugs introduced by this conversion. One thing I noticed already is that the heavy use of footnotes gets more awkward for most of the output formats, and I think I may go looking for a better way of representing some of that data and moving it out of footnotes. But we can start tweaking things more easily now, and investigate better markup language usage using the broader power of DocBook. The next step is an upload. More on that in another message. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#849835: Include MPL-1.1 and MPL-2.0 in common-licenses
Santiago Vila <sanv...@unex.es> writes: > Of course. The fact that it's in git means that the change has been > approved by the policy group, that's the idea, and that's enough. Thanks! > I've already made the upload, but I still have a minor comment: > We have symlinks like GPL -> GPL-3 for some licenses, but not for all > of them. > Because the MPL license itself does not seem to encourage the "or any > later version" wording (as the GPL does), I decided that we can live > without a symlink for the MPL. But if there is a good reason why we > should have it, please let me know. I agree with this decision -- I think we shouldn't have a symlink. I feel like the symlink was mostly there for the "or any later version" semantics (and only arguably useful there), and don't see a need to add it for licenses that don't use that provision. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#835490: debian-policy: remove references to upstart
Ansgar Burchardt <ans...@debian.org> writes: > Upstart is no longer part of Debian[1] nor actively maintained > upstream. Policy should drop references to it as an alternative init > system. > I've attached a patch to remove section 9.11.1 (actually to replace it > with an empty stub to ensure there is no section 9.11.1 with different > contents in the future). Thanks, applied for the next release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#698012: debian-policy: Please update 10.6 "Device files" for udev and the like
Russ Allbery <r...@debian.org> writes: > Andreas Henriksson <andr...@fatal.se> writes: >> I don't think it's policys place to describe the actual implementation >> details (which might change and we really don't care that much). >> Instead only focus on if package maintainers needs to take special care >> (like currently described in policy) or not (which is the actual truth). >> Some parts of 10.6 might still be considered useful (but I wonder if >> anyone would actually violate it even if it wasn't there these days, >> after all policy can't describe every way to get things wrong so maybe >> the entire chapter should still be considered for removal). > I propose the following section to completely replace this section. This > preserves what I think are the still-useful requirements while making it > clear that nearly all packages should keep their hands off of /dev > entirely. It also takes notice of device files outside of /dev, which are > more like named pipes than regular device files and which packages may > need to create for various jailing reasons (like creating a /dev/null > inside your file system namespace). > Comments, seconds? This has now been applied for the next release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#856263: git-buildpackage: Incorrect handling of --basepath in --git-pbuilder-options
Guido Günther <a...@sigxcpu.org> writes: > Just for completeness: Russ, I've applied this patch to gbp. Would be > nice if the version in gbp and the one shipped by you wouldn't diverge > too much. Applied, thank you! Sorry about the long delay on this. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#860244: libpam-krb5: Support mappings configuration option
James Dingwall <james-deb...@dingwall.me.uk> writes: >* What led up to the situation? > We have one way domain trusts with Samba that winbind cannot > handle. To enable users to log in using a DOMAIN\user format name > instead of a kerberos principal we wanted a mappings option similar > to that available in the pam_krb5 version used in RHEL. >* What exactly did you do (or not do) that was effective (or > ineffective)? > We have modified the pam_krb5 module provided in Ubuntu 14.04 to > support this option. Source code changes are published in the > username-mappings branch of https://github.com/JKDingwall/pam-krb5 Could you put this up as a pull request against: https://github.com/rra/pam-krb5 instead? Unfortunately, no guarantees on how fast I can get to it, since I'm way behind on free software stuff at the moment, but I'll definitely take a look. (Good tests, if present, will definitely bump it up the priority list since that will mean I won't have to write tests myself -- I haven't looked at all yet.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
