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/>
-policy.
Ack, yes, this is my fault. Will fix.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ding 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/>
mething 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/>
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
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 proje
omething 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/>
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) <h
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 r
tructure 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/>
d 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/>
ther elaborations or rephrasings of your
current arguments are going to change my mind.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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/>
aring 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 a
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/>
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/>
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
>> @@ -
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 (
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/>
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/>
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/>
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.
--
Ru
g
> 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/>
.conf"
will also be parsed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ish 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/>
mplementation 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 Allb
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/>
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
+
+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/>
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/>
ebian 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/>
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-maintain
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
tries, but only marginally.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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.
>&
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/>
t; 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 favor of giving the MIA team more actual power.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ill make MIA tracking substantially
harder, or will make orphaned package tracking substantially harder.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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/>
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/>
at 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/>
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, wh
phviz).
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/>
'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/>
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
ame 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.
>
>
> Package
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
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/>
ove 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/>
atch.
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/>
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/>
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 update
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/>
to just do the setup
work to have a non-native package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e 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).
--
R
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 a
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
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 n
-priorities of one or more packages may need to be adjusted.
-
-
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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 pa
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 v
age during a
+later system upgrade to a newer Debian release.
+
+
+
+
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
you can set character sets with
whatever granularity you want.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
evel-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/>
n place when you were testing.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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 m
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 gener
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
-
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 i
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 docu
ll 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/>
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 U
rmat. 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/>
cial 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 bette
riorities
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
ma
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
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/>
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
only created once during package installation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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
) 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
ked around a bunch through the interface and
couldn't reproduce that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
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 c
rent 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 tr
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
ld 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/>
hould 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/>
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
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)
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,
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 M
lable 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/>
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
ProtectKernelMo
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/>
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'
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/>
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
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 (
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/>
hy I've historically
waited for the base-files release first.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
701 - 800 of 6052 matches
Mail list logo
