-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
e discussion. It
leads to people not talking on public lists at all and taking the same
conversation private, which is a loss for everyone.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
hacks but
to instead have a native package installation mode that understands when
to sync, and perhaps that wouldn't have the same behavior.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nel
errors like:
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo
underrun on pipe B
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO
underrun
and then lots and lots of:
[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle
patterns
--
Marco d'Itri writes:
> On Jun 03, Russ Allbery wrote:
>> A possibly useful compromise is to do what Marco suggested: publish SPF
>> records for domains like lists.debian.org, where all the mail is coming
>> from Debian infrastructure. That can easily be -all. And the
SPF is slowly dying in favor of DKIM most
places.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
; notification pops up over the screensaver image.
>>
>> (This is with awesome, maybe the story is different for desktop
>> environments.)
> I cannot reproduce it with gnome (1:3.30+1) running in an Xorg session
> (rather than Wayland). Perhaps it has been fixed.
Ah, excellent.
g a
prohibitive performance price (not to mention other issues). There just
aren't any good options right now. Buy (or accept donations of) whatever
makes sense for other reasons, and expect there to be mandatory microcode
updates, kernel and virtualization workarounds, and security bugs.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Georg Faerber writes:
> On 19-06-01 11:04:28, Russ Allbery wrote:
>> I did some research on that a while back and ended up not filing a bug
>> about it because it looked relatively pointless. It appeared to be a
>> deep design choice on both sides, and not someth
or desktop
> environments.)
Yeah, I think it may be DE-related. I ran into it with Xfce and, IIRC,
GNOME (although it would have been older GNOME).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
tifications.
I did some research on that a while back and ended up not filing a bug
about it because it looked relatively pointless. It appeared to be a deep
design choice on both sides, and not something anyone was likely to solve,
so I just switched to a desktop-aware locker.
--
Russ Allbery (
esn't appear to be a Debian bug for this; it
might be a good idea to open one against light-locker (or, if you confirm
switching to slick-greeter per that bug, lightdm-gtk-greeter).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
things easy while getting
out of your way if you need to do something uncommon and complicated.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
y maintained and integrated; it's
more that they don't see any value in doing that work for the incremental
thing that they're adding. They cobble together some combination of local
config management and a deployment method until it works and then move on
to some (from their perspective) more inter
Ansgar writes:
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
>> I'm confused. I'm a happy user of dgit and don't have to think about
>> any of those things as part of using dgit. I choose to use branches,
>> but I certainly wouldn't have to, and merging, mul
user of dgit and don't have to think about any
of those things as part of using dgit. I choose to use branches, but I
certainly wouldn't have to, and merging, multiple remotes, and so forth
don't seem related to using dgit at all.
Maybe you're using dgit in a way that's suboptimal for your workflow?
--
roaches, and this one seemed to cause
the least amount of pain. It means I'm not renaming the upstream branches
when I pull them into my repository (which is possible to do in Git but
tedious and irritating if you get the .git/config runes incorrect or some
tool doesn't pay attention and merges the wro
file is absurd. This bit
is a shell script! This bit is a configuration file! This bit is
human-readable text! This bit is a patch list! This bit is a file
manifest! This bit is a structured changelog! This bit is a bunch of
preprocessor definitions! Aie.
One syntax per file, please.
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 09 Mar 2019 14:36:00 -0800
Source: libnet-duo-perl
Binary: libnet-duo-perl
Architecture: source all
Version: 1.02-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group
Changed-By: Russ Allbery
Description
n
more than twenty years. This seems like a reasonable feature to add.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the same.
You can use the same approach recursively and symlink every file. This is
an old package manager trick that I think Nix is still using to this day,
and which was used to some success by such things as GNU stow (albeit for
different reasons).
--
Russ Allbery (r...@debian.org)
ontest gathered. I
definitely do not want that dumped into my syslog.
Maybe you could start with Xorg.0.log. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
301 - 400 of 4291 matches
Mail list logo
