making those buggy if
> we just ban network access for all non-free packages. How about you?
Yup, let's go with Bill's change since it's a bit more conservative. I
think it accomplishes the same goal.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
icient. Builds that use the network
seem like a bad idea even in non-free packages because it means we may not
be able to rebuild them since all of the relevant data is not in the
Debian source package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
te outside of the unpacked
>> source package tree. There are two exceptions. Firstly, the binary
> LGTM, Seconded.
Also looks good to me. Seconded.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hould really be doing from Perl and the rest of it remains
somewhat useful, but given that upstream has archived the project, I would
go ahead and remove it.
Maybe someday I'll dust off and finish a proper Kerberos Perl module that
uses the modern C API. In my copius free time. :)
--
Rus
Package: libarchive13t64
Version: 3.7.2-1.1
Severity: important
X-Debbugs-Cc: r...@debian.org
So far it looks like no one has been able to figure out an obvious way
for this to be exploitable, but I wanted to make sure that you were
aware of this upstream issue:
he disagreement that at
some point we need to confront.
(I know, I know, I'm one to talk given that I dropped all my Policy work
on the floor and disappeared for six months. But still, I would give
myself the same advice.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
full ecosystem of packaging tools fits together. I
think the only way out for the /usr-merge transition specifically is
through, and until we finish that we're probably not in a good position to
absorb those lessons in a more comprehensive way, but I hope we don't skip
that step.
--
Russ Allbery (
ly unsupported since July of 2017. I think one can make a good
argument that both the Lintian tag description and xymon should just drop
all support for Apache versions prior to 2.4. Hopefully no one is still
running it, since it almost certainly has significant unfixed security
vulnerabilitie
orrect
hash is no longer available.
I believe what hash algorithm GnuPG uses by default is controlled by local
GnuPG configuration, and it may well default to SHA-256 these days.
Also, all of these modules should switch to a sane interface to OpenPGP
signing and verification, like sup,
to put this metadata and thus it is always
lost.
perl-nocem itself doesn't seem to care and just copies the whole input
into a temporary file for GnuPG. What's the nature of the failure? Is
GnuPG failing to validate the resulting file if the hash algorithm is
omitted?
--
Russ Allbery (r...@debi
or Debian packages. As soon as DAK doesn't
require it, I'm happy to make it optional (and indeed it would arguably be
a bug in Policy if it's optional in the archive but Policy claims it's
mandatory).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gregor herrmann writes:
> On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:
>> gregor herrmann writes:
>>> According to https://github.com/rra/docknot/issues/6 fixed upstream
>>> (in git, not released yet).
>> Yeah, I'm sorry about the delay here. I'm t
says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ography (the hyphen-minus is one of 25 dashes in Unicode), you may want
to say that explicitly in addition to saying that it's the character used
in UNIX command-line options (and, arguably as importantly, in UNIX
command names).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
en turned
into \-. People will have to rewrite them using proper Unicode hyphens to
get proper formatting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Germann writes:
> Am 14.10.23 um 21:41 schrieb Russ Allbery:
>> Upstream specifically says that the Gtk-3 support is buggy, does not
>> work, and should not be used. How thoroughly did you test it?
> I have played a round against the computer and have not seen a prob
horoughly did you test it?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
This bug would have caused the type of corruption that I saw in
> Russ's database, so I'm pretty sure it will go away in 4.2.
I installed 4.2 locally and then did an apt upgrade and everything worked
correctly, so I am also hopeful. 4.2 is on its way to experimental now.
--
Russ Allber
Package: apt-listchanges
Version: 4.1
Severity: normal
X-Debbugs-Cc: r...@debian.org
As of apt-listchanges 4.1, if I suspend the less command showing the
report with Ctrl-Z and then resume with fg or %, the terminal state
is incorrect. The report screen is not refreshed, Ctrl-L doesn't work,
and
see yours.
I'm sending you this via direct mail. I'm now seeing the problem with
each apt upgrade (in other words, I feel like 4.1 might be worse than 4.0,
which seemed to exhibit the problem only with some packages).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: apt-listchanges
Version: 4.1
Severity: normal
X-Debbugs-Cc: r...@debian.org
Looks like some variation of this bug still exists in 4.1, although I'm
not sure if it's the same bug. But the following upgrades:
Unpacking golang-1.21-doc (1.21.3-1) over (1.21.2-1) ...
Unpacking
Jonathan Kamens writes:
> Not the same bug. #1053696 only applies to changelog entries, not NEWS
> entries, since the latter can't be downloaded via apt.
> I am thus far unable to reproduce this. Still investigating.
Ah, whoops, sorry, I wasn't reading carefully enough.
--
Russ A
e problem.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hanges exhausted the changelog shipped with the package and still
couldn't find the beginning of the entries it wanted to display.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: apt-listchanges
Version: 4.0
Followup-For: Bug #1053696
X-Debbugs-Cc: r...@debian.org
Same thing happened with the following upgrades:
Unpacking gcc-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking libgcc-12-dev:amd64 (12.3.0-10) over (12.3.0-9) ...
Unpacking cpp-12 (12.3.0-10) over
Package: apt-listchanges
Version: 4.0
Severity: normal
X-Debbugs-Cc: r...@debian.org
An apt run that included the following upgrades:
Unpacking python3.11-dev (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11-dev:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11:amd64 (3.11.6-3)
even less information
and are even less suited to making this decision. Of those two options,
having apt-listchanges do it would be less obscure (it's not immediately
obvious that apt could run less), although possibly surprising.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s, not the full changelog. Any new
NEWS.Debian file entry for a package that you have installed is generally
worth reading, and this is the supported way (other than the Release Notes
for the full stable release) that Debian communicates major breaking
changes like this to users.
--
Russ
m created by the maintainer and overriding the
maintainer will not help. Someone will have to do this work, and it is
very far from trivial.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Niels Thykier writes:
> Russ Allbery:
>> Ooo, this is a great framing of the problem. I have a lot of thoughts
>> about this. Unfortunately, I'm not sure if they're actionable thoughts
>> since my grand vision requires someone to sit down and do some serious
>> Polic
ncluding packagers
who need to coordinate cross-package integrations, secondarily have an
audience of tool makers who need a reference manual for Debian's file
formats and integrations, and then have a deprioritized tertiary audience
of toolchain maintainers.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ory, and then cruft could
just consume that database of registered paths to get attribution
information until such time as that can move into dpkg.
This design is just off the top of my head, and I'm probably missing some
problems and some details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ause it's breaking
the FHS file system layout rules), and there have been a few attempts to
handle it some other way, but none of them so far have been successful.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e helpful, or detailed descriptions, or
*something*. You're giving me nothing to work with here, which means that
I'm likely to go forward with requiring some of these empty directories be
registered with dpkg because that's the less invasive change and avoids a
regression.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t for the TC bug to be resolved,
since there is a standing TC decision to make /bin a symlink to /usr/bin
and we can always change our wording later if that decision changes, but
we need to wait for the buildd /usr-merge anyway, so either way I don't
think we're ready to merge patches for this bug right n
Bill Allombert writes:
> On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
>> On Sep 17, Russ Allbery wrote:
>>> (I am a little confused by this wording, but I think what you're
>>> saying is that /usr is encrypted and read-only, and /var is
be a temporary stop-gap.
I'm not going to assume that this is going to happen on any particular
time scale. dpkg has to gain a mechanism for registering transient files
first, which in my understanding depends on other significant dpkg
architectural work.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
that
integration has already been done to invoke systemd-tmpfiles during boot
on systems using sysvinit?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ft sidebar at the top is very difficult to read because it's
almost the same color as the background.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ATH stays
consistent from one build to the next.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ink Policy says anything about /usr-merge at all right now, and
once the buildds are merged and all Debian systems relevant to unstable
development are /usr-merged, we probably should.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
on about how to talk about those paths in Policy. I
therefore don't think resolution of this bug blocks on the TC bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Wed, 13 Sept 2023 at 04:48, Russ Allbery wrote:
>> Simon pointed out that this bug is not yet ready to act on, which was
>> very helpful. Thank you. However, presumably the buildds will be
>> /usr-merged at some point in the not-too-distant f
about where we're
headed based on previous discussions).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Russ Allbery writes:
>> Maybe the right way to do this is just have two examples, one as the
>> default and another if you're using tmpfiles.d functionality added in a
>> specific version of systemd that's newer than the version shipped with
Russ Allbery writes:
> Maybe the right way to do this is just have two examples, one as the
> default and another if you're using tmpfiles.d functionality added in a
> specific version of systemd that's newer than the version shipped with
> the stable version of Debian prior to th
or recommendation is going
to achieve.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
y 1024 and rounded up.
> +The disk space is given as the accumulated size of each regular file and
> +symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other
> +filesystem object type.
>
> .. _s-f-Files:
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
p explain to the reader how Debian is designed beyond just a
mechanical set of instructions.
If you have a chance, feel free to send a proposed diff to add this to the
DEB_BUILD_OPTIONS section.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
derstand
what our goals would be.
(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ight file, though. If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical. Otherwise, you'll need to cut
and paste it into the file as always.
--
Russ A
one of the force options).
(And while we're there, we don't document the Build-Essential field
either.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman writes:
>>>>>> "Luca" == Luca Boccassi writes:
> Luca> Thank you, looks good to me, seconded.
> LGTM too, seconded.
Thanks! This has now been merged for the next Policy release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> Seconded.
Thanks! I think the wording changes subsequent to Sam's second are
informative and within the changes the Policy Editor can make without
seconds, so I'm proceeding with this and Sam's second and have merged this
change for the next Policy release.
--
R
ough that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ions instead of using debhelper
your package will be buggy." This is not ideal!
I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing. It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word). But I also want to be realistic about whether
we're really capable of maintaining that specification.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Antoine Beaupré writes:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
>> Antoine Beaupré writes:
>>> I get the argument against bad binaries not being in PATH but we have
>>> some tooling for that, don't we? /usr/libexec, no?
>> /usr/libexec isn't a replaceme
root's, which is a distinct use case.
Thanks, Simon and Bill. I had forgotten about that point even though it
has come up before (just not in this bug). I agree that's a more
compelling argument for keeping /usr/games.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e size of disks (which is
only sort of keeping up with full commercial games, but is certainly
keeping up with the games packaged in Debian).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ely explicit in a bunch of places in Policy currently due to a
conversion artifact from DebianDoc-XML.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
As usual, the things I notice only after I post text, even though I'd
already read it several times.
Russ Allbery writes:
> +Volatile and temporary files (``tmpfiles.d``)
> +-
> +
> +Some packages require empty directories, files with tri
orts GNU Backgammon to anything newer than Gtk+ 2,
and the chances of that port currently aren't looking great.
> But again, happy to shelve this for now, as it's a more complex topic.
Agreed, we don't have to cross this bridge today.
--
Russ Allbery (r...@debian.org) <
like a good idea.
> But given that hard links in source packages do not seem prevalent at
> all, and that the tooling or linters can be improved in that direction I
> suppose it might make sense to lift this specific restriction.
Thank you for the review! Now applied for the next
t. (Unfortunate, but oh well, too late now.)
Here is an updated patch that restructures this paragraph to try to make
this clearer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 Mon Sep 17 00:00:00 2001
, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
be we
still need to do something with common-licenses?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
need serious improvements.
That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright. Has someone already done this (J
> perhaps missed instances or similar.
All of these changes seem straightforward and uncontroversial to me, and
there are huge advantages to using consistent terminology between Policy
and dpkg. I have applied all of them for the next Policy release. Thank
you!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> It's now been about a year and it looks like this message didn't get a
> reply, so I'm going to go ahead and close this bug because I don't think
> we have enough information to act on it. If there are more details
> about my questions above, feel
t it produces must also be in the
*non-free-firmware* archive area.
Please let me know, and I will propose some follow-up wording for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/debian/changelog b/debian/changelog
index 66d6fa0..a5e
Russ Allbery writes:
> This patch from a while back is still waiting for one more second before
> it can be merged for the next Policy release. It previously got one
> second from Wouter. I revised the patch to mention the experimental
> suite as well as the backports suites.
This patch is still waiting for one more second. It was previously
seconded by Helmut.
Russ Allbery writes:
> Here is a patch dropping the restriction on hard links in source
> packages that I think is ready for seconds. I'm copying Guillem for his
> review, in case there's some dpk
This patch from a while back is still waiting for one more second before
it can be merged for the next Policy release. It previously got one
second from Wouter. I revised the patch to mention the experimental suite
as well as the backports suites.
--
Russ Allbery (r...@debian.org
Here is an updated proposed change for this bug, incorporating Guillem's
suggestions. It is ready for seconds.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 66175d3775f238a5ce3a2254388ad974e81d462f Mon Sep 17 00:00:00 2001
From: Russ Allbery
Russ Allbery writes:
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal. This is
> what I would do if the decision was entirely up to me:
> Licenses will be included in common-licenses if t
articular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
do send a list. (Feel free to
send that privately if you think it might be controversial.) I'm happy to
take a look.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Hideki Yamane writes:
> Russ Allbery wrote:
>> Licenses will be included in common-licenses if they meet all of the
>> following criteria:
> How about just pointing SPDX licenses URL for whole license text and
> lists DFSG-free licenses from that? (but yes, w
32
MPL 1.1 165
MPL 2.0 361
SIL OFL 1.0 11
SIL OFL 1.1 258
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
*empty* files
(and even then, I'm not clear on precisely when this would be needed).
For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
maintainer script, and I can see no possible way that action could (or
should) be handled by the tmpfiles.d mechanism.
What am I missing?
--
Russ Al
Russ Allbery writes:
> -If a service unit is not present, ``systemd`` uses dependency information
> -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
> -which scripts to run and in which order. The ``sysv-rc`` runlevel system
> -for ``sysvinit`` uses the s
Package: debian-policy
Version: 4.6.2.0
Severity: important
X-Debbugs-Cc: r...@debian.org
As part of reviewing #1039102, I took a detailed look at Policy 9.3
on system services and realized that it is largely obsolete and is
not followed by most Debian packages that provide system services.
longer accomplish the
goal of getting that system service to work with systemd and therefore
no longer seems to serve a purpose.
Here is what I came up with. I think it is ready for seconds or
objections.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
&g
er
upgrading or removing foo. (dpkg does not do this because dpkg in general
operates on only the packages it's told to operate on and doesn't expand
the scope of one invocation to change other packages.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
is attached.
Thanks, applied for the next Policy release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ich is more aggressive than you propose.
I think this is informative rather than normative and therefore
technically doesn't require seconds, but I'll give this some time for
other people to take a look and talk me out of deleting this section if
they wish.
--
Russ Allbery (r...@debian.org) &l
inst Policy as unactionable since I
don't know of any efforts towards implementing this support, and Policy
would only be able to change once the support is available.
If I misunderstood the current state, please do let me know.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ection 2.2.4 that
previously was for non-US back when we had cryptography restrictions. I
don't think this will cause any actual problems (and one of my long-term
wishlist items is for Policy to rely less on section numbering, which is
inherently unstable, and switch to some sort of persisten
ve to be the last
arguer standing in order to get your change into Policy. The more
messages there are, and the more emotional heat there is, the more energy
the whole process requires and the longer it takes.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
patch this in the Debian package.
Please feel free to move forward with Perl and don't block on this
package; this is totally my own (known) problem.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e not run into
the problem before. (In other words, I doubt this is a problem with your
local configuration.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
utgoing mail that is from your debian.org address through the
debian.org mail servers. See:
https://dsa.debian.org/user/mail-submit/
I don't think this is the direct answer to your original question, but I
suspect it would work around the problem.
--
Russ Allbery (r...@debian.org)
nces.
That's the standard for our projects at my current employer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Bjarni Ingi Gislason writes:
>> wrong type size is created with, for example in gcc(1),
>> .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
>> combined with
>> \s-1ISO \*(C+\s0
>> #
>> Do not use "\s0&qu
lding an index of the current document.
perlpod:
"X" -- an index entry
This is ignored by most formatters, but some may use it for building
indexes. It always renders as empty-string. Example: "X"
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
believe includes the latest podlators. All of this size manipulation
code, and the C++ macro, have been removed in podlators 5.00, which drops
all of the troff-specific guesswork formatting. It has proven much to
difficult to maintain and has created lots problems for fairly minor
format
pod2man doesn't try to second-guess one space vs. two spaces.
(Determining whether a given double space is at the end of a sentence in a
way compatible with multiple languages is incredibly hard to do and is not
something I'm very enthused about trying to tackle in a Perl core module.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e also a fair number of people who would be happy to
help write systemd unit files for packages, since (at least in my opinion)
it's kind of fun. This isn't the right place to coordinate that, but
there must be some good spot in Debian. debian-mentors, maybe?
--
Russ Allbery (r...@debian.org)
us and is underway, *then* change Policy to reflect
this project decision.
If the mass bug filing already happened and I just didn't notice, my
apologies.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> I.e.: if the attached version works, then that's good enough for me.
Seconded. Thank you for your work on multiple revisions of this patch!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
1 - 100 of 6052 matches
Mail list logo
