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
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 i
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 w
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
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 erro
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 inquir
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 other
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
comp
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 t
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 in
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 sys
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
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:
> > >
> >
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 mi
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
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 p
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
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
> -f
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
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
20 matches
Mail list logo
