Re: please avoid writing useless/annoying stuff in debian/gbp.conf

2019-11-11 Thread Russ Allbery
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.

Re: Usage of DEP5

2019-11-09 Thread Russ Allbery
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/>

Re: Usage of DEP5

2019-11-08 Thread Russ Allbery
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/>

Re: Usage of DEP5

2019-11-06 Thread Russ Allbery
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

Accepted remctl 3.16-4 (source) into unstable

2019-11-05 Thread Russ Allbery
-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

Re: Git Branch Names / DEP-14

2019-11-05 Thread Russ Allbery
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. --

Re: Perhaps we're rehashed enough of the systemd discussions?

2019-11-04 Thread Russ Allbery
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.

Accepted remctl 3.16-3 (source) into unstable

2019-11-03 Thread Russ Allbery
-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

Re: Facilitating external repositories

2019-11-03 Thread Russ Allbery
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). --

Re: Integration with systemd

2019-11-01 Thread Russ Allbery
e same philosophical basis. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

Re: Integration with systemd

2019-10-31 Thread Russ Allbery
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/>

Re: Integration with systemd

2019-10-31 Thread Russ Allbery
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/>

Re: Integration with systemd

2019-10-31 Thread Russ Allbery
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

Re: Integration with systemd

2019-10-31 Thread Russ Allbery
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/>

Re: Integration with systemd

2019-10-30 Thread Russ Allbery
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/>

Re: Integration with systemd

2019-10-30 Thread Russ Allbery
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/>

Re: Integration with systemd

2019-10-30 Thread Russ Allbery
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/>

Re: BITS from the DPL For September/October 2019

2019-10-29 Thread Russ Allbery
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

Re: [RFC] Proposal for new source format

2019-10-29 Thread Russ Allbery
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/>

Re: [RFC] Proposal for new source format

2019-10-29 Thread Russ Allbery
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

Re: [RFC] Proposal for new source format

2019-10-29 Thread Russ Allbery
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/>

Accepted remctl 3.16-2 (amd64 source) into unstable, unstable

2019-10-28 Thread Russ Allbery
-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

Re: [RFC] Proposal for new source format

2019-10-27 Thread Russ Allbery
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)

Re: [RFC] Proposal for new source format

2019-10-27 Thread Russ Allbery
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/>

Re: [RFC] Proposal for new source format

2019-10-27 Thread Russ Allbery
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/>

Re: [RFC] Proposal for new source format

2019-10-26 Thread Russ Allbery
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

Re: Possible bug in policy?

2019-10-24 Thread Russ Allbery
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/>

Accepted gnubg 1.06.002-4 (source) into unstable

2019-10-23 Thread Russ Allbery
-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

Re: [RFC] Proposal for new source format

2019-10-23 Thread Russ Allbery
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/>

Re: [RFC] Proposal for new source format

2019-10-23 Thread Russ Allbery
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

Re: [RFC] Proposal for new source format

2019-10-22 Thread Russ Allbery
irely). All of this business with patches and whatnot is an implementation detail. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

Re: [RFC] Proposal for new source format

2019-10-22 Thread Russ Allbery
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

Re: [RFC] Proposal for new source format

2019-10-21 Thread Russ Allbery
y of the package and of decisions made in maintaining that package. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

2019-09-15 Thread Russ Allbery
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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

2019-09-14 Thread Russ Allbery
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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

2019-09-13 Thread Russ Allbery
ree software. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

2019-09-13 Thread Russ Allbery
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/>

Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread Russ Allbery
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/>

Re: Git Packaging Round 2: When to Salsa

2019-09-09 Thread Russ Allbery
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

Re: Git Packaging Round 2: When to Salsa

2019-09-08 Thread Russ Allbery
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/>

Re: Git Packaging: Native source formats

2019-08-30 Thread Russ Allbery
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

Re: Git Packaging: Native source formats

2019-08-29 Thread Russ Allbery
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/>

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Russ Allbery
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

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Russ Allbery
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/>

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-27 Thread Russ Allbery
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/>

Re: Git Packaging Round 1: Hopefully Easy Stuff

2019-08-15 Thread Russ Allbery
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/>

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

2019-08-09 Thread Russ Allbery
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/>

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

2019-08-09 Thread Russ Allbery
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/>

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

2019-08-08 Thread Russ Allbery
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/>

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

2019-08-08 Thread Russ Allbery
es, so) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: Generating new IDs for cloning

2019-08-08 Thread Russ Allbery
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/>

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread Russ Allbery
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/>

Re: duplicate popularity-contest ID

2019-08-07 Thread Russ Allbery
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/>

Re: duplicate popularity-contest ID

2019-08-06 Thread Russ Allbery
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

Re: duplicate popularity-contest ID

2019-08-05 Thread Russ Allbery
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/>

Re: tag2upload (git-debpush) service architecture - draft

2019-08-03 Thread Russ Allbery
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/>

Re: Question about embedded Lua

2019-07-25 Thread Russ Allbery
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/>

Re: Sorce only uploads with sbuild

2019-07-23 Thread Russ Allbery
-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/>

Re: Sorce only uploads with sbuild

2019-07-23 Thread Russ Allbery
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/>

Re: autoremovals a month early?

2019-07-22 Thread Russ Allbery
s://release.debian.org/britney/hints/jmw> > # 20190721 > # temporary removal to unblock readline transition -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Accepted gnubg 1.06.002-2 (source) into unstable

2019-07-21 Thread Russ Allbery
-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

Re: git & Debian packaging sprint report

2019-07-21 Thread Russ Allbery
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/>

Re: git & Debian packaging sprint report

2019-07-21 Thread Russ Allbery
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

Re: git & Debian packaging sprint report

2019-07-21 Thread Russ Allbery
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

Re: seccomp woes

2019-07-19 Thread Russ Allbery
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/>

Re: file(1) now with seccomp support enabled

2019-07-19 Thread Russ Allbery
files. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: git & Debian packaging sprint report

2019-07-16 Thread Russ Allbery
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/>

Re: git & Debian packaging sprint report

2019-07-15 Thread Russ Allbery
> 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.

Re: git & Debian packaging sprint report

2019-07-15 Thread Russ Allbery
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

Re: git & Debian packaging sprint report

2019-07-15 Thread Russ Allbery
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

Re: systemd services that are not equivalent to LSB init scripts

2019-07-15 Thread Russ Allbery
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

Re: Proposition: Insert Mozilla Firefox Release in Debian

2019-07-14 Thread Russ Allbery
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/>

Re: systemd services that are not equivalent to LSB init scripts

2019-07-14 Thread Russ Allbery
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

Re: systemd services that are not equivalent to LSB init scripts

2019-07-14 Thread Russ Allbery
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:

Re: unsigned repositories

2019-07-14 Thread Russ Allbery
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

Re: Is it the job of Lintian to push an agenda?

2019-07-14 Thread Russ Allbery
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

Re: Is it the job of Lintian to push an agenda?

2019-07-13 Thread Russ Allbery
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

Re: Is it the job of Lintian to push an agenda?

2019-07-13 Thread Russ Allbery
el free to disagree if he thinks I'm wrong.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: Is it the job of Lintian to push an agenda?

2019-07-13 Thread Russ Allbery
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/>

Re: Survey results: git packaging practices / repository format

2019-07-03 Thread Russ Allbery
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,

Re: Survey results: git packaging practices / repository format

2019-07-03 Thread Russ Allbery
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

Re: Content Rating System in Debian

2019-06-24 Thread Russ Allbery
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

Re: The Difference between debcheckout and dgit and what they try to accomplish

2019-06-19 Thread Russ Allbery
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

Re: The Difference between debcheckout and dgit and what they try to accomplish

2019-06-19 Thread Russ Allbery
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

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

2019-06-16 Thread Russ Allbery
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

Re: Removing bzip2 support from apt due to rustification

2019-06-07 Thread Russ Allbery
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

Re: Removing bzip2 support from apt due to rustification

2019-06-07 Thread Russ Allbery
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/>

Re: speeding up installs

2019-06-07 Thread Russ Allbery
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/>

Re: Bug#929834: Buster/XFCE unlock screen is blank

2019-06-03 Thread Russ Allbery
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 --

Re: @debian.org mail

2019-06-03 Thread Russ Allbery
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

Re: @debian.org mail

2019-06-03 Thread Russ Allbery
SPF is slowly dying in favor of DKIM most places.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: Buster/XFCE unlock screen is blank

2019-06-03 Thread Russ Allbery
; 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.

Re: Realizing Good Ideas with Debian Money

2019-06-01 Thread Russ Allbery
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/>

Re: Buster/XFCE unlock screen is blank

2019-06-01 Thread Russ Allbery
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

Re: Buster/XFCE unlock screen is blank

2019-06-01 Thread Russ Allbery
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/>

Re: Buster/XFCE unlock screen is blank

2019-06-01 Thread Russ Allbery
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 (

Re: Buster/XFCE unlock screen is blank

2019-05-31 Thread 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/>

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

2019-05-27 Thread Russ Allbery
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/>

Re: Difficult Packaging Practices

2019-05-26 Thread Russ Allbery
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

Re: Preferred git branch structure when upstream moves from tarballs to git

2019-05-02 Thread Russ Allbery
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

  1   2   3   4   5   6   7   8   9   10   >