tic: I put a whole "should not" under emphasis, not only the "not"
> Here is how the section 9.7 would read with this patch applied.
Looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, ema
7 if #562920 is better to stay closed ?
I think we should close all of them. I don't think anything has changed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "
ces keep not engaging for Policy. I need to
pay more attention to that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
Julien Cristau writes:
> On Sun, Aug 12, 2012 at 14:25:12 -0700, Russ Allbery wrote:
>> Okay, once more for the win. Here is the current version of the patch,
>> incorporating substantial improvements from Jonathan Nieder and
>> hopefully incorporating all the feedback in
any label information, so presumably there's
some database somewhere that has that information. Is any action
necessary to set up that database in the first place?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-p
t; +
> +
>
> multiselect
>
Minor nit: I think there's formal DocBook markup for a cross-reference to
a manual page. If I'm remembering correctly, we should use that markup
here.
--
Russ Allbery (r...@debian.org) <ht
Russ Allbery writes:
> The following patch implements the decision of the Debian Technical
> Committee in #629385 to make build-arch and build-indep mandatory.
> Please review. Note that I'm not looking for conventional seconds since
> the Technical Committee has already
263 Clarify 9.9 - Environment variables
#648271 11.8.3 says xterm passes -e option straight to exec
#671355 [debconf] document escape capability
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.
tart jobs in packages, which I
> think meets your criteria.
Sure, sounds good to me. I was dithering about putting that on my list
already.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.
cy, and we
can deal with any further refinements as additional work. I don't think
there's anything about this that would force unreasonable behavior.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-re
n you intended, and I don't think it's still doing anyone any good.
We didn't arrive at any conclusion about dropping the separation and no
one is pursuing this right now, so I don't think there's much point in
keeping the wishlist bug against Policy open anyway. We can a
Zachary Harris writes:
> Under #652011, presumably with reference to my proposed addition to
> policy here, Russ Allbery wrote:
>> Policy already says what you want it to say currently,
> Where? If policy is already clear on this, then this bug should be
> closed rath
erity are reserved for places where what Policy says is contradictory,
deceptive, or simply wrong. That's not the case here; the clarification
that you're proposing is effectively a weakening of something that Policy
(sort of implicitly) tells one to do right now.
Anyway, order of processing of bug
Bill Allombert writes:
> On Mon, Aug 27, 2012 at 08:31:50AM -0700, Russ Allbery wrote:
>> Russ Allbery writes:
>>> The following patch implements the decision of the Debian Technical
>>> Committee in #629385 to make build-arch and build-indep mandatory.
>>&g
pull out the footnote saying that it doesn't work properly), but I'd
rather not. I think it's already working.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
s is
something I want to tackle for the general DocBook rewrite, at which point
we'll also regroup all the init system stuff.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a
1;bug=661816
With Guillem's review, this now has enough seconds. I've applied it for
the next release with the wording tweaks Guillem suggested. Thanks!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-req
ation itself.
That works for me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http:/
n agent
> already exists for the given subject
I think you meant PolicyKit rather than debian-policy. I'm a bit dubious
the problem is there, but reassigning there to start with.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCR
9.11
New section documenting general requirements for alternate init
systems and specific requirements for integrating with upstart.
12.5
All copyright files must be encoded in UTF-8.
Note that the change to make build-arch and build-indep mandatory is not
RC for
Package: debian-policy
Severity: normal
There are various bugs already filed about some edge cases and
specific issues with multiarch, but none to track the general
documentation of multiarch handling in Policy. This bug will be
used to discuss the overall wording. It's possible some of the
exis
d file
conflicts or lack thereof for the various types of multiarch packages, and
everything else from the multiarch wiki documentation that needs to be
folded into Policy. I'd rather not do this piecemeal, since we need to
review the whole multiarch specification across Policy to be sure tha
fo/*.symbols,
> but packages should not rely on this and instead should use dpkg-query
> --control-path package shlibs if for some reason these files need to
> be examined.
> Should that be /var/lib/dpkg/info/*.shlibs?
Indeed, thanks. I will fix that for the next release.
--
Russ
Package: debian-policy
Severity: normal
Based on discussion in debian-devel, the current Built-Using description
would imply that it had to be present for, say, the code from libgcc
incorporated into every binary build. The description should be modified
to be clear that it is only mandatory if t
er about to do an
upgrade (and hence will call postinst again and would just recreate the
alternative) or we're about to call abort-upgrade in postinst.
As near as I can tell, postinst should just unconditionally call
update-alternatives; it's at worse a no-op.
--
Russ Allbery (r...@debian.o
er than through
maintainer scripts, in which case there are further options open, such as
dpkg remembering the manual alternative configuration and restoring it
once the deconfigured package has been reconfigured. (I suspect this is
oversimplified.)
--
Russ Allbery (r...@debian.org)
new GR, but I think it's a good idea
and I think that limitation is solely due to a bug in the original GR, so
I don't see much point in arguing about it.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-
d
paid attention.
> Or is (my|our) reading here that wrong?
I was definitely reading it wrong. That certainly resolves all of my
(unimportant) concern. Sorry about the noise!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, em
t;secure
transport," since if Debian ever needed to guarantee integrity of the
file, that's probably the mechanism that we'd use.
Thank you for doing this work!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to deb
"license statements," which is what is actually being displayed). I'd
prefer to work on that language if necessary rather than adding a new
statement, possibly by strengthening the degree to which Policy says to
not prompt unnecessarily.
--
Russ Allbery (r...@debian.org)
Russ Allbery writes:
> To me, this feels like a specific instance of the general problem of
> excessive maintainer script prompting.
Oh, I see why you didn't class it that way: this isn't something done by
the maintainer scripts, but rather something done by the package itse
The dbnpolicy group, which is used to control access to the Git repository
used to maintain debian-policy, was missing both aba and plessy. I've
just submitted an RT ticket to DSA requesting that it be updated.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.or
Raúl Benencia writes:
> Package: debian-policy
> Version: 3.9.4.0
> Severity: minor
> At the beginning, when the policy says "The shlibs system is an simpler
> alternative". s/an/a
Thanks, fixed for the next release.
--
Russ Allbery (r...@debian.org)
ng upgrades, except
> for virtual packages?
That makes sense to me on first glance. I can't think of a case where I'd
want to use Provides/Conflicts/Replaces with non-virtual packages rather
than using a transitional package.
--
Russ Allbery (r...@debian.org) <h
re
immediate concern, which would argue for changing gnome-pkg-tools to not
do this in the short run, but moving towards (1).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of
n debian-policy, the specific problem is what to
put in the Copyright field. (The rest is covered by the existing "Public
Domain" section.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.
have any objections, but the changes have been infrequent enough
that it didn't seem worthwhile to try to figure out how to make that
change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.deb
pecification that the
> package's copyright file references, e.g. 1.0 for the present), then the
> packager is free to pick any short name desired. IMHO if there is
> indeed an SPDX identifier, it might be preferable to use that, but it is
> not mandatory in any way.
Right, this
e it clear to
automated parsers that they're following the base license template. That
gains some of the benefit of your proposal in terms of making the file
clearer and allowing use of the standard license short names, without
losing the verbatim text of the license.
--
Russ Allbery (r...@de
ith the base license.
Separating out the language so that it's presented in separate paragraphs,
which I think is the key point of having this feature, runs the risk of
not correctly reproducing the *actual* license text in the copyright file.
--
Russ Allbery (r...@debian.org)
Ximin Luo writes:
> On 25/12/12 18:28, Russ Allbery wrote:
>> You should consider the possibility that no one is trying to delay
>> anything, but rather that we simply aren't convinced by the changes
>> that you're proposing.
> Well, more criticism would be ap
Jonathan Nieder writes:
> Russ Allbery wrote:
>> It might be worthwhile to recognize some sort of syntax similar to
>> license exceptions so that one can tag the license as "BSD-3-Clause by
>> " or the like. That would let one use standalone
>> license para
Jonathan Nieder writes:
> Russ Allbery wrote:
>> Jonathan Nieder writes:
>>> Russ Allbery wrote:
>>>> It might be worthwhile to recognize some sort of syntax similar to
>>>> license exceptions so that one can tag the license as "BSD-3-Clause by
&g
nses that I regularly see out there in the open
source world. It may be hard to extend a system to other license
families, but just solving that one problem would have a huge impact on
the percentage of Debian packages, say, that could be accurately
classified automatically for the purposes of li
Charles Plessy writes:
> I wonder if it would be useful to mandate in the next revision that the
> files must start with the Format field.
Yes, definitely. Good idea.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to d
ould be to
describe the intent of Breaks, Conflicts, Provides, and Replaces in
isolation in their current sections, but then move all of the text about
how they work in concert to a new section that lays out the specific use
cases discussed and provides guidance for how to implement each one.
--
)
The advantage of putting format first is that in some obscure situations,
it could help with backward compatibility with changes that otherwise
wouldn't be backward-compatible (like allowing a field to be duplicated
that couldn't be duplicated before, that sort of thing
nary package (udeb).
> +
> +
>
>
>
> Does anybody know if this field mandatory or optional ?
Seconded, once that question has been resolved.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE
e to mark it
> recommended.
Sounds right to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
A
Charles Plessy writes:
> here is a new version trying to addres Simon's and Guillem's comments.
Seconded.
In response to the other follow-up, I don't think this is the right place
(or bug) to discuss udeb package behavior or what portions of Policy they
comply with.
-
Jonathan Nieder writes:
> Russ Allbery wrote:
>> In response to the other follow-up, I don't think this is the right
>> place (or bug) to discuss udeb package behavior or what portions of
>> Policy they comply with.
> Surely it is relevant to people reading policy t
on with an additional mention of udebs
without having that statement.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
by the Debian Installer) are
not fully covered in this manual and do not comply with all of the
requirements discussed here. See the
http://d-i.alioth.debian.org/doc/internals/ch03.html";> for more
information about them.
?
--
Russ Allbery (r...@debian.org)
ty policies.
I'm not at all sure what package this sort of bug belongs to, so I'm
reassigning it to network-manager-gnome, which should at least get it into
the general ballpark. The network-manager maintainers should have a
better idea of where specifically it should go.
--
Russ Allbery
ons to applying patches there.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
e backslashes and newlines in its replies.
>> See debconf-escape
>> 1.
> Nice wording; I second it.
> Are there other comments, opinions, or seconds ?
Looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~ea
59-1
or KOI8-R or SJIS documents out there and people who work with those
documents may prefer to continue to operate in that locale.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.o
le).
There may be reasons why files should be encoded in legacy encodings for
specific uses, and I don't feel like it's the proper role of Policy to
dictate to all package maintainers that they can't work with those use
cases.
--
Russ Allbery (r...@debian.org) <ht
ml";> for more
> + information about them.
> +
>
>
>
Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
I wonder if we should explicitly recommend against
diverting conffiles, or if some of those problems have been cleaned up.
Some Debian sites, such as (IIRC) MIT, have extensive local infrastructure
based on diverted conffiles and have run into all sorts of weird edge
cases with them.
--
Russ A
pure ASCII stance feels like a very English-centric stance.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
Bill Allombert writes:
> On Sat, Mar 16, 2013 at 03:13:04PM -0700, Russ Allbery wrote:
>> Many were posted to this thread. I guess I just disagree with you on
>> whether those uses are "good." For me, allowing the correct spellings
>> of words and the correct na
already contains a similar warning about files vitally important
> for the systemm, and I think that it would be confusing to separate the
> two warnings.
This sounds okay for the time being, although it sounds like we may be
able to drop some of those warnings before too long.
--
Russ
d others) think ?
Looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: htt
t; install-info should not invoke
> install-info directly and should not
> depend on, recommend, or suggest install-info
> for this purpose.
>
>
> Info readers requiring the /usr/share/info/dir file should
> depend on instal
to that effect in Policy.
We have files in the archive already using non-ASCII encodings, and asking
them to convert to ASCII feels like a real step back.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@list
Don Armstrong writes:
> On Fri, 29 Mar 2013, Russ Allbery wrote:
>> I think we should require UTF-8 as the character encoding for file
>> names and fix the non-UTF-8 file names in the archive currently.
>> None of the other courses of action really make any sense to me.
>
are still calling 'build' not 'build-arch', don't
> they ?
No, I believe dpkg has been changed to probe whether the build-arch target
exists and call it by preference if it does, and I think that change is
already live on the buildds.
--
Russ Allbery (r...@debian.
hen they can be represented in that character
> set.
>
>
This looks good to me. I think that strikes the right balance without
going into too many details about what justification should or shouldn't
be required for using UTF-8.
--
Russ Allbery (r...@debian
states)
I thought Guillem requested we use the capitalized versions. I think the
capitalized versions stand out more and make it clearer that the expected
meaning isn't necessarily the plain English meaning of the phrase.
--
Russ Allbery (r...@debian.org) <http://www.eyri
Installed" state
> - "Failed Config" state -> "Half-Configured" state
> - config-failed -> "Half-Configured"
Please go ahead -- I'm all in favor.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rom
> dpkg 1.17.x, for the reason above.
I also agree and am happy to second a patch.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
th adding a recommendation to include a desktop file, since
that's what most of the desktop environments actually use. That way, we
don't lose functionality.
Would you be willing to take a first stab at writing something like that?
--
Russ Allbery (r...@debian.org)
), tcsh, telnet, texlive-base (TeXconfig), units, w3m, and zsh. I
suspect that most, if not all, of those programs do not have desktop
files currently.
Do you want them to? A straightforward reading of this modification to
Policy, were I the bc and dc maintainer, would indicate that
keep
the current background information (the definition of MIME and the
discussion of what it's used for), though, and at least for right now we
should probably also keep the mailcap instructions, since I'm fairly sure
they're still used by very widely used programs like
Josselin Mouette writes:
> Le dimanche 12 mai 2013 à 08:03 -0700, Russ Allbery a écrit :
>> I'm not sure that "mostly called from the terminal" is quite the right
>> way of phrasing the point, but I'm not sure what the right way of
>> handling it is.
nfo”, the package can ship a
> MIME file in XML format as described in the Shared MIME-info
> specification:
> http://standards.freedesktop.org/shared-mime-info-spec/latest/
I'll leave it to Charles to make the call on whether to keep the old
language about m
e are desireable, though, and would strongly
encourage the various parties involved in menu implementations to get
together and find consensus on these sorts of issues. The result of that
consensus would be appropriate for inclusion in Policy (probably as a
desktop file sub-policy).
--
Rus
one the work. I think enough
years have gone by that it doesn't make sense to keep waiting for someone
to volunteer to do this work for the less common window managers like
fvwm.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to
uot;. If we later on decide to add
> additional categories that the upstream fdo spec doesn't list, we can
> always add our own categories to (a sub-)policy.
Here's what's currently available -- what do you think?
http://standards.freedesktop.org/menu-spec/latest/
See i
7.2: The mailcap entries, for when something can not be expressed in a
> Desktop entry.
This all sounds good to me.
> For media types, there is at least one more provider: the 'file'
> package. I wonder if there is something to mention there, or if it is
> more relevant
Package: debian-policy
Severity: normal
Policy 8.4 currently says:
If there are development files associated with a shared library,
the source package needs to generate a binary development package
named librarynamesoversion-dev, or if you prefer only to support one
development ve
best way to get this to
the right place would be "reportbug python".
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listma
ian
things lately. I'd love to see someone take this on.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
ndard
Filename: pool/main/p/python-defaults/python_2.7.3-13_i386.deb
Size: 178948
MD5sum: 97a9169dd6121123ce0be535562b59d6
SHA1: 23afe0d6105ff58b1f52272ed1f5410d81857ccd
SHA256: 5a1190cdccb0c4aad3657deb2653fcea92938a4f40c8384dc201818bd85540f2
--
Russ Allbery (r...@debian.org) <http://www.e
ing on there, but you could try reporting the bug
against python-defaults directly instead.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehd0ylt9@windlord.stanford.edu
The general consensus on
debian-devel (at least as I understood it) was to only use Built-Using
when there's some licensing reason why we need to keep the referenced
package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSC
Thorsten Glaser writes:
> Russ Allbery dixit:
>> In the meantime, please don't add Built-Using for libgcc. The libgcc
>> license does not require it, due to the runtime exception, and
>> essentially
> The dietlibc licence does require for libgcc to be added t
Thorsten Glaser writes:
> Russ Allbery dixit:
>> If not, I'm confused. I don't see any reason why dietlibc's license
>> would change something about libgcc's license.
> dietlibc is GPL, so a derivate is also GPL.
> The mksh-static and lksh binaries, w
your choice,
consistent with the licensing of the Independent Modules.
The runtime-lib-exception lets you relicense the portion of included
libgcc code under any terms you want provided that you use an Eligible
Compilation Process (which basically means building with GCC).
--
Russ
the binary requiring that the libgcc source be
available.
We probably need to have a broader discussion about this, but I think I'm
going to start with leader and see if Lucas has an opinion about where to
start with making decisions here. One option available to leader is to
ask for an opinion fr
bian
Policy so that people know when to use Built-Using and when not to.
Do you have an opinion on how we should make these decisions as a project?
Is this a place where possibly we should seek the opinion of legal
counsel?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/
il the binaries built from that
source were replaced.
At the time, though, the assumption was that Built-Using would be a fairly
rare thing that would only be used for those few score packages that were
Build-Depending on *-source packages.
--
Russ Allbery (r...@debian.org)
Jonathan Nieder writes:
> Russ Allbery wrote:
>> mksh-static of course links statically and therefore pulls in
>> substantial portions of library source, but there are parts of libgcc
>> and possibly libc that are always incorporated into binaries, even ones
>>
f
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
which means that libgcc is a System Library, and therefore is not part of
the Corresponding Source.
--
Russ Allbery (r...@debian.org) <htt
e deleted when an architecture moves off the main archive (to
> d-ports, or because it’s no longer even in oldstable) normally.
Hm, that's an interesting point, indeed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email t
;;
> stop)
> exit 0
> ;;
> esac
> fi
> fi
Libraries, even shell libraries, should generally not call exit. It's
very surprising behavior. The overall program flow should remain under
the control of the main program.
--
ot of
web servers in Debian that still do so and that need to be notified of
this?
If this is a transition that's already complete, I'm not sure it's worth
saying anything here. It doesn't strike me as the sort of idea that's so
obvious that people are lik
t the change, shall
> I list you as seconding this patch ?
Looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe&
;m still dealing with a ton of
ongoing effort with my day job, which has sharply limited the amount of
time that I have to spend on Debian and my Policy work has suffered (let
alone work on Lintian). Unfortunately, it's probably not that likely that
it will let up appreciably in the next few mo
801 - 900 of 2198 matches
Mail list logo
