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/>
umenting our preferences, which seems like
a good thing all around.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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/>
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/>
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
n cut and paste
just the command.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r packages until someone writes such a tool. We
are part of a larger ecosystem, and some critical components of that
ecosystem are moving in this direction regardless of what we do.
> On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote:
>> Configuration file has a very specific meaning
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/>
's not something that Policy
requires one way or the other and there are vigorous advocates of both
methods.
--
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/>
ey said. If specific Policy
language that seems to be based on erroneous information is proposed for
seconds, then by all means bring the refutation up again at that point.
--
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
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/>
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/>
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
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
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
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.
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/>
Dominik George writes:
> On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:
>> This implies that Salsa is happy to create accounts for people under
>> the age of 13, since the implicit statement here is that Debian's own
>> Git hosting infrastructure is less
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/>
purpose? If not,
then why are you taking this incredibly aggressive position that general
guidance is pointless unless it says "must"?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nfigure the same files in both
tmpfiles.d and in the unit file, because it would make it much easier for
those who want to support other init systems to do so.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Thorsten Glaser writes:
> On Tue, 13 Jun 2023, Russ Allbery wrote:
>> namely if you're running anything in a chroot that needs directories
>> created in /tmp and /run, the chroot either needs to have a persistent
>> /tmp and /run or you have to arrange for it to run at least
chroot, and when it is, often
they just use persistent /tmp and /run.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
less I'm very mistaken about how dh_installtmpfiles and systemd-tmpfiles
works (possible, I guess), I don't think we need to have this argument in
this bug. If I am right in assuming that nothing about this proposal will
change how chroots work, arguing with people about why they use chroots is
run when
appropriate (at boot, mostly), then there is no need to provide fallbacks
via, for instance, init scripts with different functionality than the
systemd units. This is the whole reason why we did the work to package a
standalone systemd-tmpfiles package that can be used regardless of the
init syste
requiring
integration with maintainer scripts (via triggers or direct invocation).
My understanding is that this is exactly what dh_installtmpfiles already
does, via generating an explicit call to systemd-tmpfiles --create.
Or am I missing something?
--
Russ Allbery (r...@debian.org)
ages should be considered a last resort.
This sounds good to me. The argument for building up from should instead
of down from must seems compelling.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bill Allombert writes:
> On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
>> I prefer that too, but in this case, it feels like must is appropriate
>> for at least systemd configuration files. And also, just intuitively,
>> I feel like must is correct
, and it tends to prompt people to file weird
bugs or create weird Lintian checks that are unactionable for maintainers
of packages whose upstreams have no intention of providing these files for
whatever reason.
Policy is only about Debian packages. We're not writing policy for
upstream; there's a wiki page that tries to collect that sort of advice.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e if this works
for them or if they still feel like it's too strong before I second it.
But if I were the only one deciding, I'd second this wording. (Probably
not that surprising since you took all of my wording suggestions.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
rsions, and I do think that matches how we use diversions
between two Debian packages (work around some weird situation where we
have no better option).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
chanism accomplishes the same goal, but I think that's a
feature here rather than a bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the people who routinely provide detailed and incredibly useful
analyses of Policy problems say that they would rather use Salsa to do so,
that's important feedback and I would like to hear that feedback. But the
goal here is not to maximize development speed. It's to think hard about
a problem and ge
whereas having it in the bug means I can, at any
time, load the entire bug into Gnus and re-read the discussion of how we
arrived at the decision in the same tool that I use for reading all other
Debian discussions.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s
when updating alternatives, so the resulting behavior would be
confusing and unpredictable.
I keep wanting to suggest an alternative, but I'm not sure there's an
obvious alternative to suggest (the options are going to be very
situation-specific), so I'm inclined to just leave it at that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:
>> […] I suspect Policy should say something stronger and more general,
>> namely that no package in Debian should divert a file from another
>> package unless this is arranged cooperatively
Sean Whitton writes:
> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:
>> In other words, dpkg-divert is primarily for local administrators,
>> non-Policy-compliant local packages that are doing unusual things, and
>> the occasional rare problem that requires special
together is important, but dpkg-divert
has no equivalent and every diversion already has to be maintained
separately. Given that, I think the burden of asking people to use
masking instead of diversion for systemd configuration files is a fairly
minor request, so I weigh the problems on the systemd side hig
p-ins and masking. And then explicitly call out
systemd and udev configuration as cases where dpkg-divert should not be
used, alongside conffiles and critical system files.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Robert Ernst writes:
> Also I kindly remark my still open questions regarding:
> - Is there enough manpower in the debian policy team?
No, not really.
> - Who is part of the debian policy team besides of the two delegates
> - Russ Allbery (rra)
> - Sean Whi
hat
purpose should be ignored. Builds that set this profile must also add
nocheck to DEB_BUILD_OPTIONS
It still doesn't say this explicitly, but it says build dependencies
should be ignored, so presumably the build would fail if it required any
build dependcies, implying that it sh
everal possible behavior choices. But obviously
one cannot have package installation fail because the service cannot be
started when the package has to be installed so that you can configure it
so that the service can start.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
a while, so
some of the machinery has probably rusted and will need repairs.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ransparent, admittedly).
(Also, if you're editing files written in Chinese, presumably you're using
an editor with good Chinese input support, and thus one that's more likely
to also have good Chinese encoding support.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
like to be able to test this configuration (at least for my own
packages), but since recent changes to locales it doesn't appear to be an
option in debconf and I was confused trying to figure out how I should
make it work.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
, not rhetorical. It's quite likely
that there is some benefit that I'm not seeing (such as with bootstrapping
new architectures).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
1 - 100 of 2062 matches
Mail list logo
