.
Also, I'm not sure what would start the user service manager if you're not
running systemd as PID 1.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g other
than saving a small amount of disk space on non-systemd systems.
(Splitting doesn't avoid the library dependency problem that currently
causes problems with elogind, since I believe the programs in question
also depend on that shared library.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s,sysusers} to see if it has
> any value.
Yes. I agree with this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
The Wanderer writes:
> On 2020-01-03 at 13:35, Russ Allbery wrote:
>> The Wanderer writes:
>>> If the maintainers of systemd-the-package would be willing to not only
>>> split out these binaries into standalone package(s), but accept such
>>> init scr
ipts for inclusion in those packages,
Why would that be necessary?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ead ask that
people arrange to run the systemd implementation so that we have the same
features everywhere.
Support for kFreeBSD and Hurd is obviously a valid argument in favor of
some level of support for non-systemd implementations.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ill be to maintain, analyze, and reason about. When I was
doing lots of work on Lintian, there were so many times when we could have
done so much better if we didn't have to parse free-form shell scripts and
try to extract meaning from them.
--
Russ Allbery (r...@debian.org) <
pen.
This also allows Guillem to support these facilities properly inside dpkg
with tracking of which users and tmp files belong to which package, using
the same interface, which I think would be ideal in the long run.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
who are absolutely convinced gnubg
wins against human players because it cheats on dice). I've not changed
that, but one could make an argument that's a privacy leak as well (and
feel free to convince me that I should change it).
--
Russ Allbery (r...@debian.org) <https://www.eyr
batim copies
of this license document, but changing it is not allowed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
PID 1, but I wasn't sure I was anticipating possible future
changes.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Mike Hommey writes:
> On Mon, Dec 02, 2019 at 11:21:12PM -0800, Russ Allbery wrote:
>> This is the typical practice, including all the intermediate
>> experiments or false starts in experimental.
>> I sympathize with wanting to clean up some of that, but as a project
notes should be in NEWS instead, which are
shown to more people via apt-listchanges), and removing versions from the
history has bad effects on the bug-tracking system, historical archives,
etc.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
from the archive and use it directly, and all that
pristine-tar failing costs me is some time.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r
> was to edit debian/gbp.conf was to have:
> debian-branch=debian/buster
> I only do this when I need to do the first stable backport of a
> serious/security bug, such that I have to create the debian/buster
> branch in the first place. So it hasn't been all that annoying for me.
a couple of days and turn it into
something vaguely maintainable and usable by someone else.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
text for what needs to be included in
debian/copyright. Attempts to clarify in the past usually turn into a
game of telephone. It's really a policy set by and enforced by
ftp-master, so it would be awesome if that team would write it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
inion
about the wiki comment, but we've talked about making machine-readable
copyright more strongly encouraged from time to time and there are always
objections from folks who are still not convinced it solves any problems
for them and who find it harder to work with for whatever reason.
--
R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 05 Nov 2019 20:45:18 -0800
Source: remctl
Architecture: source
Version: 3.16-4
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 944151 944152
Changes:
remctl (3.16-4) unstable
that case, both debian/sid and debian/unstable are, well, wrong if the
latest version was uploaded to experimental. debian/master correctly
captures the semantics of what I'm doing: it's the master development
branch, which is going into either unstable or experimental as
appropriate.
--
roblem was that Sam was extremely transparent about what he was preparing
to do next, which prematurely started the conversation (for which I'm as
responsible as anyone else). We were going to have the conversation
anyway; I'm sure Sam wasn't planning on posting a GR and immediately
calling for a vote.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 03 Nov 2019 10:52:30 -0800
Source: remctl
Architecture: source
Version: 3.16-3
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Changes:
remctl (3.16-3) unstable; urgency=medium
est practice document
somewhere for how I should set this up? I'm currently installing keyrings
in /etc/apt/trusted.gpg.d because I thought that was how *-archive-keyring
packages were supposed to work, but this area seems a bit underdocumented
(or at least I've not found the right documentation).
--
e same philosophical basis.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
o be,
but that's not at all the same thing.
One advantage of a GR is that you can express an opinion without being
required to dig through and interact with large and somewhat contentious
debian-devel threads.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ways done." I think
that's a recipe for endless sniping, hard feelings, and eventual
obsolescence. Debian is too large now to be able to do literally
*everything* by consensus; there are some things where we'll always find
someone who objects to every course of action.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
not painless (see, for
instance, translations, where we do *reasonably* well but where
translations can still sit in the BTS for extended periods of time). If
it's possible to allow the people who are maintaining those files to
upload them directly, it would remove that friction and proce
oject made at the time for other reasons, but this is the downside that
we have not yet come to grips with, and I think it's worth noting that Ian
was correct about the negative consequences.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
apable* of producing a non-systemd alternative
that's viable? If the answer to question 1 is "no," then this question
doesn't arise. But it's entirely possible that the answer to question
1 is "yes" but the answer to this question is still "no."
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
people
are interested in init system diversity sufficiently to do the reasonably
substantial implementation work required to maintain a competing
implementation of the systemd unit features we care about.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
quite a lot to say in this area
(and that needs to be said), once we have that direction from the project
as a whole.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
an can make
informed decisions about how to proceed. The simmering uncertainty and
low-level tension of not having a decision eventually becomes its own
problem.
A GR may not be the best mechanism to make that decision, but I'm not sure
what method would be better.
--
Russ Allbery (r...@debi
looks a lot like 3.0
(native) with overlays, which at least reduces the necessary tools to the
compressor and tar, although tar is still richer than one would ideally
want and therefore kind of a mess from a reproducibility standpoint.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Blank writes:
> On Tue, Oct 29, 2019 at 12:19:03PM -0700, Russ Allbery wrote:
>> Could you help me understand what this would look like? Is it something
>> like this workflow?
>>
>> 1. tag2upload determines the local Git tree that should be uploaded as
al is to define a source package
format that allows this to be done more easily than our current source
package format allows?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
-dbgsym remctl-server
remctl-server-dbgsym ruby-remctl ruby-remctl-dbgsym
Source: remctl
Architecture: amd64 source
Version: 3.16-2
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 938350
Description:
libnet-remctl-perl - Perl client for Kerberos
ing a new
change to the package. In my ideal world, someone would be able to make a
normal Git commit to the packaging repository and then push a tag and all
the right things would happen, although that's hard to achieve with a
rebase workflow.
--
Russ Allbery (r...@debian.org)
that's a separate
problem), but it's orthogonal to this thread, and it's confusing to raise
this point here as if anyone in this thread is arguing against this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
rmat unblocks the issues
raised with tag2upload (although it would be great to spell out exactly
how that would happen), I'm all in favor.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Hm, that's an interesting thought. I do generally include that sort of
information in the docuemntation of all packages for which I'm upstream,
but for Debian I've assumed the preferred way to propose changes is the
BTS. Now that's potentially changing with Salsa. I don't really mind
monitoring multi
deed, that's a bug. Thank you! The automated conversion to
reStructuredText wasn't perfect, and we missed a few issues like this.
Now fixed for the next release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 23 Oct 2019 20:19:00 -0700
Source: gnubg
Architecture: source
Version: 1.06.002-4
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 936627
Changes:
gnubg (1.06.002-4) unstable
ns, and it should be
> easy for someone to implement a shim from that API to a specific VCS.
This sounds like a fine (if more complicated) way to support tag2upload.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russell Stuart writes:
> On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
>> This history has at least one commit per upload, although ideally has
>> the package maintainer's full revision history and upstream's full
>> revision history.
> I understand you
irely). All of this business with
patches and whatnot is an implementation detail.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bastian Blank writes:
> On Mon, Oct 21, 2019 at 09:29:05PM -0700, Russ Allbery wrote:
>> If we're going to go to the trouble of defining a new source format,
>> I'd prefer we embrace a VCS-based one rather than once again rolling
>> our own idiosyncratic representation of a
y of the package and of decisions made in maintaining that package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
o the extent of
telling people they're not allowed to use non-free editors to make changes
to their Debian packages. I think people need to consider whether they
want to create bugs that are resolvable by just deleting the Vcs-* fields
without making any other changes, and if that really achie
Thomas Goirand writes:
> On 9/14/19 1:03 AM, Russ Allbery wrote:
>> Thomas Goirand writes:
>>> Sorry, WHAAAT ? That's shocking to read this from the DPL. Are you
>>> sure you didn't do a mistake in this sentence?
>>> There's absolutely no problem within th
ree software.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
it doesn't make
sense to me to have strong opinions about where the Git repository is if
they use one.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
cache files, .lesshst, .history,
.viminfo, and so forth.
All of the logic is implemented for you in Perl in File::BaseDir, in Rust
in the xdg crate, in Python in python3-xdg, and so forth.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
eaction; I may decide later that this is wrong. But it was my
first reaction.) But I don't think we should look at this through whether
it matches what I, or Jonas, or David, or someone else already deeply
enmeshed in Debian would do. We should be choosing a default
recommendation anticipating the mindset of
so even in that case not
everything would be lost, but Salsa would preserve unreleased work,
branches that weren't uploaded with dgit, and so forth.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes ("Re: Git Packaging: Native source formats"):
>> [ discussion of benefits of maintaining the Debian delta as
>> a linear series of broken-down changes ]
>>
>> There are obviously ways to represent this with a p
and may require delicate handling
(part of which, in my experience, is effortless transparency so that they
don't feel like anything is being hidden from them).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bastian Blank writes:
> On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
>> I think this requirement is a bit incomplete, in that I don't
>> understand the use case that would lead you to want to do this. It's
>> more of a description of an implementation str
upload records maintained by DAK, and I'm not sure of a use
case for that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
is. It's more of a
description of an implementation strategy than a use case, which makes it
hard to find other ways of accomplishing the same use case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ot of people
prefer to contribute and it's kind of a shame. But having to poll some
external system is not really viable for me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
d update Debian Policy.
With my Policy Editor hat on, I'm in complete support of this. It just
needs cycles for someone to write the language.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
use of an onion router.)
Yes, it's built into the IPv6 protocol. See RFC 4941.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
t came along after sysvinit. This is
a very widely-known flaw in the sysvinit design and basically every
implementation that everyone else fixed.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
es, so)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
had already done
this and knew the results, to save the effort of a research project if the
information is already documented somewhere or known to someone.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nit have some support for customizing things that need to change
when cloning an image? Does it already handle machine-id? Maybe we just
need to popularize it and explain better how to add additional hooks for
the needs of other packages?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
think we
shouldn't underestimate the pure psychological value of that, even if it's
hard to attribute specific meaning to the statistics.
(Thank you, Bill, for maintaining popcon!)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ularity-contest files, they will
> report at the same time, causing network spikes.
You could add a bit of per-run randomization to the cron job. I assume an
individual report doesn't take a lot of effort to process, so even skewing
that load across 10-20 seconds might be enough.
--
Russ
making this a bit less common, but building out a system and then
cloning it repeatedly used to be the most common way of scaling a web
service in environments such as AWS.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e ongoing maintenance burden (and random failure
rate) would be higher than the current proposal.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
formal.
The problem is what version of Lua to link with, and how to handle
upgrades (which are inevitable since option 2 from the original message
isn't viable in the long run; eventually, we're going to remove the old
version of Lua from the archive).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-tar despite its shortcomings.
>> $ dgit --gbp build
>> $ dgit --gbp push-source
> or dgit --gbp sbuild
Ack, yes, sorry, I meant sbuild and typed it incorrectly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
t sbuild set up (and you've already crossed that hurdle),
and the payoff in reduced mental load was totally worth it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s://release.debian.org/britney/hints/jmw>
> # 20190721
> # temporary removal to unblock readline transition
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 21 Jul 2019 12:15:00 -0700
Source: gnubg
Architecture: source
Version: 1.06.002-2
Distribution: unstable
Urgency: medium
Maintainer: Russ Allbery
Changed-By: Russ Allbery
Closes: 932351
Changes:
gnubg (1.06.002-2) unstable
Ian Jackson writes:
> Ie I think you would consider this a blocker for you to use it as a
> sponsor. Do you consider this a blocker for deployment at all ?
No, it's just a regular bug (in something), at least to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes ("Re: git & Debian packaging sprint report"):
>> Ian Jackson writes:
>>> I think in general those places are probably mistakes. But I'm not
>>> aware of all of them. One way to look at this is that from t
Ian Jackson writes:
> Russ Allbery writes ("Re: git & Debian packaging sprint report"):
>> If so, I think that security model is roughly equivalent to the
>> automatic signing of binary packages by buildds, so probably doesn't
>> introduce a new
s has way more security impact per unit time than
tuning compiler options or plowing through fuzzing bugs, since it can
remove whole classes of attacks permanently regardless of future code
errors.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
files.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
stem is vulnerable to
collisions, that's another matter; there are viable SHA-1 collisions. But
given the design described, I don't think it is. (That said, designing
the system for hash agility if possible is certainly recommended.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
> The client tool could possibly also just create the .dsc and .changes,
> except for hashes of the compressed files, and the web service just
> recreate the tarball and compress them.
I think experience with pristine-tar indicates that recreating tarballs is
unfortunately not trivial.
Ansgar Burchardt writes:
> Russ Allbery writes:
>> If so, I think that security model is roughly equivalent to the
>> automatic signing of binary packages by buildds, so probably doesn't
>> introduce a new vulnerability,
> It doesn't rely on strong cryptographic hashe
There are also some interesting nuances here around handling DM packages,
where not everyone with a key in the keyring can upload every package,
although the obvious way to address that is probably for this service to
do the same DM checks that ftpmaster would normally do.
--
Russ All
Peter Pentchev writes:
> On Sun, Jul 14, 2019 at 12:30:16PM -0700, Russ Allbery wrote:
>> There seems to be a clear infrastructure gap for the non-systemd world
>> here that's crying out for some inetd-style program that implements the
>> equivalent of systemd socket
d in stable
releases because it doesn't get security support for the lifetime of
stable, so doesn't meet our stable guarantees.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Bernat writes:
> ❦ 14 juillet 2019 12:30 -07, Russ Allbery :
>> There seems to be a clear infrastructure gap for the non-systemd world
>> here that's crying out for some inetd-style program that implements the
>> equivalent of systemd socket activation and
that behaves like inetd for a single service. Even here,
though, I'm not sure if any of those implementations use the same socket
passing protocol as systemd, and I'm not sure if they're yet trivial to
configure as part of Debian packaging.
--
Russ Allbery (r...@debian.org) <http:
personal repository and
didn't want to deal with configuring reprepro (which I thought was
best-in-class here the last time I surveyed the field), I'd use aptly,
which will do the signing for you and has a pretty simple interface for
adding a new package to the repository.
--
Russ Allbery (r...@d
e should keep in mind that Policy
> Ansgar> might not reflect consensus when referring to it.
> When the policy decision was made, I think we did have consensus.
> So, no, that's our current policy at least until something changes it.
For the record, this is exactly the way
Russ Allbery writes:
> The Policy process is not equipped to deal with this because that
> process requires fairly consensus, and I don't believe that's possible
> to reach on this topic.
Argh. That should have been "fairly strong consensus" and fell victim to
last-minute
el free to disagree if he thinks I'm wrong.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
on is
stale, but at least previously ftp-master rejects were not based on
severity, but rather on a hard-coded list of tags maintained by
ftp-master.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise writes:
> On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
>> Ben Finney writes:
>>> I don't recognise the repository structure that was raised by myself
>>> and some others: A VCS repository that contains only the Debian
>>> packaging files,
It may be “bare debian” is meant to cover this; but I don't recognise
> the comment “requires use of quilt and similar tools” because I've never
> needed to use Quilt for this.
How do you handle needed changes to the upstream source? Or do you just
never make any changes to the upstream sour
group felt strongly enough
about CRS to do the work, I don't see any obvious reason why debtags
couldn't handle a set of CRS tags, which has the huge advantage of not
requiring any work by the package maintainer and instead shifting the
burden to the people who care about CRS.
--
Russ Allb
Sam Hartman writes:
>>>>>> "Russ" == Russ Allbery writes:
> Russ> debian.org already publishes a CAA record, which conveys that
> Russ> information (although has its own verification concerns, but I
> Russ> think debian.org is using
rtificates from either LE or Amazon:
gwaihir:~$ host -t caa debian.org
debian.org has CAA record 0 iodef "mailto:d...@debian.org;
debian.org has CAA record 128 issuewild ";"
debian.org has CAA record 128 issue "letsencrypt.org"
debian.org has CAA record 128 issue "a
mass bug filing.
> Updating dh to a new compat level might include extra assumption that
> will then need to be overrided.
The same is true of using any packaging helper that uses debhelper, and is
still true for new versions of Policy even if you hand-code everything.
--
Russ All
Paul Wise writes:
> On Sat, Jun 8, 2019 at 10:09 AM Russ Allbery wrote:
>> Please let us have internal conversations without using them to
>> prematurely pick fights with external maintainers.
> It definitely wasn't my intention to pick a fight.
Yeah, I didn't think that pa
301 - 400 of 4312 matches
Mail list logo
