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/>
> important to play it.
I'm still hoping that upstream will port to GTK+ 3 (or later) before I
have to start removing functionality. I realize that it's on borrowed
time, though, and I totally understand if the GNOME maintainers want to
remove some of these old libraries before the next rel
Luca Boccassi writes:
> On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh,
>> major player in Linux distributions, and I'm not sure how much they
>> care about compatibility with anyone else.)
> T
why people who are familiar with the ABI process
are jumping in to say "please don't touch that, this is a big deal to us."
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
es of our own creation with known
workarounds.
--
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/>
t because I was looking at the
clang package instead of the clang-16 package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ild-essential, but build-essential forces installation of gcc,
specifically, as opposed to, say, clang.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ructures stored on disk (possibly including caches, depending on the
situation). In other situations, this is something that's going to
require some distribution-wide coordination that I don't think we've
started yet.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
5.38 isn't out yet.
In the interim, you would need to install Pod::Man directly from CPAN,
vian cpanm for example, to get the new behavior.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ous
to me. Sorry about the noise.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t distribution before using it to
build the file system the actual installation is going into.
I suspect this won't be Ted's favorite option because this isn't a natural
way to think about the option space from a file system developer
perspective, but maybe we could find some compromise along those
up for occasional breakage. So the proximity-to-release argument to me
feels most relevant if this change is specifically a problem for the
release process and would hold up things Debian itself needs to do, due to
(for example) it being difficult to change tooling so that file systems
are gene
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/>
C when running Lintian.
Lintian should probably force all output it controls to UTC for
reproducibility, including tar's, but I'm still mystified as to why it
works on the other system. This part of tar doesn't seem to have changed,
and as you mentioned replacing tar didn't change anything.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
that could also be the case for the original reporter.
Although echo -n is undefined in POSIX, Debian requires it to work in all
shells that are eligible to be /bin/sh. See:
https://www.debian.org/doc/debian-policy/ch-files.html#scripts
--
Russ Allbery (r...@debian.org) <htt
ts are being passed to the sourced
file, which is a bashism. The missing logic is understanding that a $()
block is effectively a quoted string and thus should be ignored for the
purposes of this test.
--
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/>
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: r...@debian.org
A section 8 manual page for a binary in /usr/libexec triggers:
I: kafs-client: spare-manual-page [usr/share/man/man8/kafs-dns.8.gz]
N:
N: Each manual page in /usr/share/man should have a reason to be there. This
Package: libppix-regexp-perl
Version: 0.086-1
Severity: minor
X-Debbugs-Cc: r...@debian.org
Starting I believe with 0.086, the following test program:
use 5.010;
use strict;
use warnings;
use Test::MinimumVersion;
all_minimum_version_ok('5.010');
produces warning messages for modules using
on/review, and I might again have
> perhaps missed instances or similar.
Will take a look soon!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mes
failing, which makes it look correlated with other system events by
accident.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ts use the approach of only updating the years when the files are
changed; others update all years on all files every year (the FSF does
this, for instance, based on legal advice from their lawyers).
This doesn't feel like something Lintian should have an opinion about.
--
Russ Allbery (r...@debi
the time, but I haven't seen it in years.
I think something may have changed about how locales works or about how
upgrades are sequenced that resolved it? However that happened, I'm
wondering if this 19-year-old bug should be closed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
since I'm not sure
if it will be pulled into a point release or only the next major release
of Perl.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nce Perl in Debian has
been updated to a version with that release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
te
> character.
This bug has been fixed in podlators 5.00, which was released yesterday.
Hopefully it should make its way into at least the next major upstream
version of Perl, if not the next patch release. (5.00 has fairly
significant changes, so I'm not sure if it will be pulled i
nger sure of the right way to test this on a system
that wasn't already using an ISO 8859-1 locale.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Jean-Michel Vourgère writes:
>> I'm using pod to generate man files in package rrdtool.
>> I had an issue with long man lines such as:
>> BIvnameE>=IrrdfileE>:Ids-nameE>:ICFE>[:step=IstepE>][:start=ItimeE>][:end=ItimeE>][:reduce
Package: tripwire
Version: 2.4.3.7-4+b3
Severity: grave
X-Debbugs-Cc: r...@debian.org
Looks like tripwire needs another rebuild against the latest libc6.
tripwire --check and tripwire --init both segfault once they start
analyzing the file system. Rebuilding the package with no changes
causes it
itdiff;h=a5cbfbaee05ebfc5eb30268521159a9df7fe2307
but the fix is not very trivial. I have a few other major changes that I
need to finish and then can release podlators 5.00 and start the process
of getting this into Perl core.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
folks feel strongly that
we're doing this wrong. But more discussion, unless it's about truly new
approaches, often makes that kind of situation worse rather than better.
We may have to just uncomfortably sit with the disagreement for a while
and incrementally work our way out of it.
--
about within a single package.
Thanks, good catch. We've been dealing with this elsewhere as the other
replies pointed out, but we should update the wording in Policy to make
this explicit.
I'll open a separate bug for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f a
Debian package, and a compatibility symlink at the old path is needed,
the symlink must be managed in a way that will not break when /path
and /usr/path are the same underlying directory due to symlinks or
other mechanisms.
We've had that rule in Policy since May of 2017
ay be a bit longer
than normal for it to propagate into a Perl release and then into Debian.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Vincent Lefevre writes:
> On 2022-09-23 10:13:50 -0700, Russ Allbery wrote:
>> naïvely (and naïve) are correct alternate spellings in English.
>> English historically uses a diaeresis to indicate that two adjacent
>> vowels form separate syllables rather than a di
Russ Allbery writes:
> naïvely (and naïve) are correct alternate spellings in English. English
> historically uses a diaeresis to indicate that two adjacent vowels form
> separate syllables rather than a diphthong. This is one of the only
> "native" accept marks in the E
y insists on
diaereses in its house style, even going so far as to use coöperate when
every other publication has switched to cooperate:
https://www.merriam-webster.com/words-at-play/mary-norris-diaeresis
The other place you'll sometimes see diaereses in English is with proper
na
Russ Allbery writes:
> The fact that this has gone unnoticed in a source package in an existing
> release makes a pretty strong argument that nothing in Debian cares and
> we should just remove the constraint.
Here is a patch dropping the restriction on hard links in source packag
Wouter Verhelst writes:
> On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
>> Wouter Verhelst writes:
>>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
>>> (probably after debconf though)
>> Here, a couple of
nfusing. It was also using two terms for the same concept in the same
section, since earlier the same construction was referred to as a
"portion." I've fixed this to use "portion" consistently in this section.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote:
>> Helmut Grohne writes:
>>> […] It can be made explicit in section 3.8 quite easily:
>>> Since dpkg will not prevent upgrading of other packages while an
>>> ``essential``
Russ Allbery writes:
> Here is a patch that I believe implements that, and which I think is
> ready for seconds.
Thanks for the review, both. This has now been applied for the next
release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I considered whether instead of starting with a priority of 40, we
> should instead bump the priority if the window manager supports the
> desktop specification, but I think this is a place where the structure
> of X environments has changed over the yea
the definition was internally
> inconsistent. I think the only thing missing is policy clarifying that
> this field is only mandatory on non-source-only uploads.
Here is a patch to fix this wording in Policy. I think it's ready for
seconds.
--
Russ Allbery (r...@deb
s, but are they
likely and important enough to have it be worth retaining a section
talking about this, as opposed to using the "not every bug is a Policy
violation" rule? We do pay a (small) complexity cost for each additional
requirement we put in Policy, so I'm tempted to just drop this
on of the Files field
implies that the section may just be - in some cases.
The current documentation certainly seems inadequate, although I'd like to
understand what the behavior of Debian software is before proposing
alternative wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
>> Wouter Verhelst writes:
>>> -policy: this is a question that has come up before
>>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is
>>> another example
failed-upgrade
> Please, update the relevant section to mention those new arguments.
Here is a patch that I believe implements that, and which I think is ready
for seconds.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>From 2260f7a3aafe93282860aad07b7d8c
Cyril Brulebois writes:
> Russ Allbery (2022-09-19):
>> but I suspect that, to the extent that this is a Policy issue, the problem
>> was that a source package is not itself a udeb and therefore it wasn't clear
>> whether Policy applies to source packages that only p
by them.
> If I were to redo such a specification from scratch, I would ask
> non-European language speakers their opinion too.
I'm definitely interested in that opinion from anyone who is listening in!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
readers. But that's a fix for another day.
> I've gone one by one, but please review carefully as I might have
> perhaps switched in excess!
Reviewed, and also checked for remaining uses of "paragraph." Everything
looked good.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Holger Levsen writes:
> On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:
>> I'm fine with this change, but as Sam points out, the deeper point here
>> is that Policy doesn't apply to udebs. This is the whole point of
>> udebs.
> When you say it like this, i
his paragraph in 1.1 (Scopes):
udebs (stripped-down binary packages used by the Debian Installer) do
not comply with all of the requirements discussed here. See the Debian
Installer internals manual for more information about them.
That could be as simple as saying "udebs (...) and source packages that
produce only udebs do not comply"
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I feel like we should stress that
you may put your system into a surprising state by removing required
packages, and may have difficulties recovering because standard tools are
missing, even though dpkg should continue to wrok.
Do you have any suggestions for what an accurate statement would be?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nk it's up to you whether you think that is important or
not. I would be inclined to say that it's *safe* to add DPKG_ROOT to
paths even on upgrade actions, but you only *must* do so for maintainer
script actions that run during initial installation.
Thank you very much for starting th
tely open to patches here, and I agree that the
current Policy specification for Maintainer is both underspecified and
somewhat obsolete, but I think the patches should be conservative and not
introduce the stuff that RFC 5322 allows in headers but that we currently
don't support.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> The killer features of YAML for the purposes of the copyright format are
> the > and | symbols after a key, which let you write paragraphs of text
> afterwards with normal structural indentation and full editor support
> for wrapping and the like, and
ing to look entirely invalid.
I knew the backward compatibility issues were going to be a whole can of
worms.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
>> Yes, we should distinguish between formatted text with synopsis and
>> formatted text without synopsis more clearly. Or, you know, just
>> propose a new YAML format which would make i
are you thinking of some sort of
container or other type of restricted system?
Also, in this case, how does this work? Is the path somehow remapped at
the kernel level? (If so, I'm wondering if that would qualify as "made
available" for the purposes of Policy anyway.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
In the case of a sponsored upload, the uploader signs the files, but
> the changelog maintainer name and address are those of the person who
> ]]]
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
her way, we should
address this in the Policy wording, and then encode that in
dh_installtmpfiles if needed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e more second. Ideally, I'd like this to be someone else who
has a lot of understanding of the semantics of essential packages
(Guillem, for instance). Alas, due to the ordering of the BTS actions,
you may have to hunt down the cloned bug against debian-policy to second
it.
--
Russ Allbery (r..
gement. Old-school window managers that don't use a desktop
environment (fvwm2, for instance) may implement support for desktop files,
or for the Debian menu system for that matter; newer ones are likely to
not handle menus at all and expect some other component to deal with that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mething else entirely will
happen. This is really outside of our control.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
oticed that this formatting is technically incorrect.
I think it would be fine to leave them and have this be fixed by a future
format change, even if it takes a while.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote:
>> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
>>> Russ Allbery writes:
>>>> I would happily apply a version of 0002 that only changes Files and
>>>> leave
ne wrapping
semantics for line-based lists, which adds yet more irritating ugliness to
the deb822 format. Probably just "if the line is indented by more than
one space, it's a continuation for the previous line" I guess.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ackage paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?
As mentioned in the other thread, I think source package stanza and binary
package stanza (of the template control file) sound great.
Obviously a patch to Policy would be delightful, but it's not
or Policy to do.
I vote for switching to stanza. Paragraph is going to be confusing when
talking about package descriptions, which often have multiple paragraphs
in the normal English meaning of the term.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover writes:
> Another minor patch I had laying around, switching references to the
> OpenPGP specification instead of to the specific PGP implementation.
Thanks, applied.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I would happily apply a version of 0002 that only changes Files and
> leaves Copyright alone.
Or, perhaps even better, one that changes Copyright the way that you did,
but just adds an extra space. I think that's the simplest compromise
between what you're
gaps.)
I would happily apply a version of 0002 that only changes Files and leaves
Copyright alone.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ut I'm happy to convert these to some
> of the UTF-8 ones if you prefer.
Thank you! Applied for the next release.
I have a minor bias against the UTF-8 quotes only because they're more
annoying to type with a typical US keyboard, while agreeing that they're
typographically more correct.
--
Package: graphicsmagick
Version: 1.4+really1.3.38+hg16739-1
Severity: normal
X-Debbugs-Cc: r...@debian.org
Attempting to display an SVG file breaks due to a missing font file:
% gm display _static/spawning.svg
gm display: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb)
[No
much difference in practice, and I'm curious what
problem Daniel ran into that motivated filing a bug report, but I think
that logic might make sense? But I'm also not sure we should make changes
here just for the sake of making changes, so I'm curious about the
motivation and what problem this change would fix.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
o aligning with them, but SPDX
still has a ton of work to do to absorb all of the licenses in Fedora,
which will help us when we're ready to do a switch. (But I would
definitely use SPDX identifiers where there isn't a Debian standard to
follow, since it will make that switch easier.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
101 - 200 of 6053 matches
Mail list logo
