Hi,
On Sun, 2024-06-09 at 08:58 -0500, r...@neoquasar.org wrote:
> What it is is functional, and paid for. And likely, already installed
> and in use somewhere (like all of my 32-bit systems).
>
> It's not just a matter of "buy something better." That's easy.
Indeed, that is easier and cheaper
Hi Simon,
On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
> I believe NM does not have a fixed configuration format, but only a dbus
> API.
It's perfectly fine to edit configuration files for NM manually, see
man:nm-settings-keyfile(5).
> Our best bet there would be a firstboot unit,
Hi Simon,
On Thu, 2024-07-11 at 05:14 +0900, Simon Richter wrote:
> It is supported *now*, but the roadmap is unclear -- that support could
> be discontinued at any moment, and it would not be the first time a
> feature Debian relied on was removed.
I understand your fears about the uncertainty
Hi,
On Tue, 2024-07-16 at 15:23 +0200, Lukas Märdian wrote:
> On 16.07.24 15:05, gregor herrmann wrote:
> > On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
> >
> > > I suspect having something that's agnostic about the underlying
> > > implementation as our default would be rather better
Hi Texas,
thank you for your interest in Debian. However the debian-devel@
mailing list is for development of Debian itself which your mail is not
about.
If you want personal support to implement solutions based on Debian,
you can try contacting someone providing services for Debian
(https://www.
Hi,
On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote:
> On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote:
> > If ifupdown's paradigm were working for people we wouldn't be having this
> > conversation.
> > How else would you move /etc/network/interfaces forward without breaking
Hi Vincent,
On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> POSIX says:
>
> SHELL This variable shall represent a pathname of the user's
> preferred command language interpreter. If this interpreter
> does not conform to the Shell Command Language in XCU
>
Hi Helmut,
On Wed, 2024-02-28 at 07:41 +0100, Helmut Grohne wrote:
> I see that you are working on merging /bin and /sbin, for instance
> via
> brltty bug #1064785. Again Fedora is pioneering this matter and their
> documentation is at
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.
Hi,
On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
>
> > I think that the real question is whether we should really still
> > use
> > code-signing keys which are not stored in (some kind of) HSM.
> What are the option
Hi,
On Sun, 2024-03-31 at 14:34 +0200, Pierre-Elliott Bécue wrote:
> The PGP submodule of a Yubikey can host 3 keys, one signing, one
> authent, and one encrypt. ISTR accessing the signing key is always
> prompting for the PIN. Same for the encryption key. (I think both can
> be configured other
Hi,
On Sun, 2024-05-12 at 08:41 -0700, Russ Allbery wrote:
> "Theodore Ts'o" writes:
> > And yet, we seem to have given a pass for gnulib, probably because it
> > would be too awkward to enforce that rule *everywhere*, so apparently
> > we've turned a blind eye.
>
> No, there's an explicit exc
Hi,
On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote:
> I have an N270 system I can use to contribute, if someone is willing
> to explain what I need to do to make it useful.
>
> From: Victor Gamper
> Sent: Sunday, May 19, 2024 08:03
> To: debian-devel@lists.debian.org
> Subject: Re:
Hi,
On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote:
> TL;DR: drop or downgrade dependency on system-log-daemon from any
> package that declares it
+1. Log service freedom is important. Packages should in general not
pull in a log service as a dependency.
> The list of affected packages a
Hi,
On Mon, 2024-10-21 at 15:05 +1100, Russell Coker wrote:
> $ cat debian/source/lintian-overrides
> # We aren't building with Discord support and therefore everything under
> # 3rdparty/discord-rpc is not relevant. If in future we add Discord support
> we
> # should Build-Depend on rapidjson-
Hi,
On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
> On 22.09.24 15:58, Ansgar 🙀 wrote:
> > On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> > > I've repeated the reasons why I think a hybrid stack using Netplan is a
> > > feasible solutio
Hi,
On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> I've repeated the reasons why I think a hybrid stack using Netplan is a
> feasible solution many times in previous threads, therefore I'd like to refer
> to a list of frequently asked questions, instead of spreading more reasons
> acros
Hi Steve,
On Fri, 2024-09-27 at 11:01 -0700, Steve Langasek wrote:
> On Mon, Sep 23, 2024 at 12:27:13PM +0200, Ansgar 🙀 wrote:
> > So on desktop installations including NetworkManager, netplan will be
> > configured to do nothing? Why install netplan at all on desktop s
Hi,
On Tue, 2024-09-24 at 15:34 +0200, Lukas Märdian wrote:
> My ideas was not so much about switching from one networking daemon to
> another.
> In most cases users will probably stick to the network stack of their chosen
> environment. With systemd-networkd and NetworkManager being good candida
Hi,
On Thu, 2024-12-19 at 12:34 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 11:00:03 +0100
> Ansgar 🙀 wrote:
> > On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> > >
> > > Debian GNU/Systemd is only an unofficial
> > > su
Hi,
On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
> Also, /etc would thus be full of empty /etc/$proj directories? I don't
> see the point of not just putting the example files there? Why making it
> more difficult for the admin to configure their server?
Examples belong to /usr/share
Hi,
On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 09:01:09 +0100
> Marco d'Itri wrote:
> >
> > No: the expected default for systemd-managed services is to use
> > /etc/$SERVICE/ .
>
> Debian GNU/Systemd is only an unofficial
> subdistribution of Debian GNU/Lin
Hi,
On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > What I completely fail to understand is why people would want to not
> > > see
Hi,
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> What I completely fail to understand is why people would want to not
> see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random
configuration bits, possibly from
Hi,
On Sun, 2025-03-09 at 15:58 +0100, Simon Josefsson wrote:
> Ansgar 🙀 writes:
>
> > Hi,
> >
> > On Sun, 2025-03-09 at 14:19 +0100, Simon Josefsson wrote:
> > > Our experience seems to differ, I now run Trisquel and Guix on many of
> > > my home a
Hi,
On Sun, 2025-03-09 at 14:19 +0100, Simon Josefsson wrote:
> Our experience seems to differ, I now run Trisquel and Guix on many of
> my home and machines and servers. For my uses they all work without
> non-free firmware. You have to be careful about what hardware you buy,
> and chose your u
Hi,
On Mon, 2025-03-10 at 13:27 +0530, Pirate Praveen wrote:
> On 3/9/25 9:20 PM, Ansgar 🙀 wrote:
> > What is the point of this then?
>
> If I understood the argument of FSF correctly, the point is, having the
> same freedom as the hardware manufacturer to modify or not m
Hi,
On Mon, 2025-03-10 at 10:57 +0100, Simon Josefsson wrote:
> I don't think the above fully resolve my concerns though. The mere
> presence of official documented hooks to load non-free software is
> problematic from a freedom perspective.
Maybe a "free" version of Debian could be provided wit
27 matches
Mail list logo
