Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

2024-04-06 Thread James Addison
Thanks for the response! On Fri, 5 Apr 2024 11:12:33 +0200, Guillem wrote: > On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote: > > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > > > On 2

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

2024-04-03 Thread James Addison
Hi Guillem, On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > On 2024-03-29 22:41, Guillem Jover wrote: > > I think with my upstream hat on I'd rather ship a clear manifest (checked > > into Git) that tells distributions which files

Re: RFC: advise against using Proton Mail for Debian work?

2023-11-15 Thread James Addison
Hi, My few smallcoins, responding to each of the proposed outcomes (even if they were intended to be mutually-exclusive...) are: A) Educating contributors that retaining control of their signing keys is important seems valuable -- it seems OK to provide a few illustrative examples of situations

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-06-27 Thread James Addison
On Mon, 26 Jun 2023 at 20:33, Aurelien Jarno wrote: > > On 2023-06-09 16:39, Thorsten Glaser wrote: > > In particular I would, at the same time, like the baseline lowered > > to i586 again. It was raised mostly for multimedia stuff, and it’s > > now justifyable to ask people to use amd64 or armhf

Re: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

2023-06-04 Thread James Addison
Hi Abou, Please find some slightly re-ordered responses below, and with the gtk-gnome list and bug on cc because others are likely to know more than me about this. On Sat, 3 Jun 2023 at 22:40, Abou Al Montacir wrote: ... > However, when starting the conversion, g-ir-generate crashes with an

Re: [2016] client-side signature checking of Debian archives (Re: When should we https our mirrors?)

2023-06-01 Thread James Addison
On Thu, Jun 1, 2023, 02:08 Simon Richter wrote: > > The reason for the change is that it reduces user confusion. Users are > learning that unencrypted HTTP has neither integrity nor > confidentiality, and that they should actively check that web sites use > HTTPS, so we have gotten several

Re: [2016] client-side signature checking of Debian archives (Re: When should we https our mirrors?)

2023-05-31 Thread James Addison
Hi Simon - thanks for the response. Please find my reply inline below: On Wed, 31 May 2023 at 11:07, Simon Richter wrote: > > On 5/31/23 05:42, James Addison wrote: > > >* It allows other devices on the local network segment to inspect the > > content that ot

Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-31 Thread James Addison
If there's a well-supported social or technical reason to remove the i386 Debian installer, I think that it would still be disappointing, but acceptable. I don't know what those reasons are yet (I've imagined that they could be maintainer burden -- but as mentioned, I don't think there's much

Re: [2016] client-side signature checking of Debian archives (Re: When should we https our mirrors?)

2023-05-30 Thread James Addison
In follow-up to: https://lists.debian.org/debian-devel/2016/10/msg00592.html As an update here: the default recommendation in the Debian release notes now recommends[1] HTTPS instead of HTTPS by default. Despite the validity of many of the theoretical concerns about APT over HTTP, I reckon that

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-25 Thread James Addison
On Fri, 26 May 2023 at 00:27, Roger Lynn wrote: > > On 21/05/2023 07:00, James Addison wrote: > > On Fri, 19 May 2023 at 22:58, Ansgar wrote: > >> One of the problems with popcon is that it draws too much attention to > >> old releases which isn't really interes

Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

2023-05-22 Thread James Addison
On Sat, 20 May 2023 at 17:47, Adam Borowski wrote: > > On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote: > > How easily could we add 64-bit system detection to the i386 installer, > > and a message saying something like: > > > > "You're installing the i386 architecture on a 64-bit

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-20 Thread James Addison
On Fri, 19 May 2023 at 22:58, Ansgar wrote: > > On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote: > > Do we know how often the i386 installer is downloaded compared to > > amd64, and could/should we start with updated messaging where those > > are provided before

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-20 Thread James Addison
On Sat, 20 May 2023 at 09:39, Cyril Brulebois wrote:> > James Addison (2023-05-20): > > Replying individually, but may bring this back on-list depending on > > what I learn: > > > > On Sat, 20 May 2023 at 06:00, Cyril Brulebois wrote: > > > >

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-19 Thread James Addison
On Fri, 19 May 2023 at 12:42, Steve McIntyre wrote: > > I'm planning on stopping publishing installer images for i386 > soon. Why? We should be strongly encouraging users to move away from > it as a main architecture. If they're still installing i386 on 64-bit > hardware, then that's a horrible

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

2023-05-16 Thread James Addison
On Tue, 16 May 2023 at 04:22, Russ Allbery wrote: > > > It did look like a veto to me. More importantly, isn't relying on > > passersby to spot alleged harmful changes dangerous, especially for > > undocumented, uncodified and untested use cases, like unspecified and > > vague cross-compatibility

Re: DEP 17: Improve support for directory aliasing in dpkg

2023-04-28 Thread James Addison
On Fri, 28 Apr 2023 at 17:52, Jochen Sprickerhof wrote: > > Hi James, > > * James Addison [2023-04-28 14:54]: > >To make sure we don't miss any packages out accidentally: could you > >confirm that those hundred-or-so errors occurred from 27 or so > >distinct packag

Re: DEP 17: Improve support for directory aliasing in dpkg

2023-04-28 Thread James Addison
On Thu, 27 Apr 2023 at 14:37, Helmut Grohne wrote: > > Hi Simon, > > On Sat, Apr 22, 2023 at 11:41:29AM +0100, Simon McVittie wrote: > > You might reasonably say that "the maintainer of bar didn't add the > > correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but > > judging by the

Bug#1021292: dpkg-buildflags: Please add support for pointer authentication on arm64

2023-03-27 Thread James Addison
Package: dpkg-dev Followup-For: Bug #1021292 X-Debbugs-Cc: woo...@wookware.org, debian-devel@lists.debian.org > We decided that the best thing to do was create a new hardening flags > feature called 'branch' to add to the existing set. This enables > -mbranch-protection=standard on arm64, and >

Bug#1030835: ITP: ruff -- linter for Python, written in Rust

2023-02-07 Thread James Addison
Package: wnpp Severity: wishlist Owner: James Addison X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ruff Version : 0.0.243 Upstream Contact: Charlie Marsh * URL : https://github.com/charliermarsh/ruff/ * License : MIT Programming Lang: Rust

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

2022-12-17 Thread James Addison
Package: wnpp Severity: wishlist Owner: James Addison X-Debbugs-Cc: debian-devel@lists.debian.org, j...@jp-hosting.net * Package name: quadrilateralcowboy Version : 1.0.0 Upstream Contact: Brendon Chung * URL : https://www.blendogames.com/qc/ * License