Hi,
On Fri, 2025-06-06 at 10:51 +, Holger Levsen wrote:
> On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:
> > > Also they contribute massivly to burning down our only planet
> > > faster.
> > So do in-person conferences, rebuilding software just to obse
Hi,
On Fri, 2025-06-06 at 10:33 +, Holger Levsen wrote:
> On Fri, Jun 06, 2025 at 12:03:32PM +0200, Lucas Nussbaum wrote:
> > > or maybe Debian should not.
> > Maybe. Honestly, I don't know.
>
> I'd rather not take their offer based on moral grounds: they stole
> and
> steal from everyone an
Hi,
On Mon, 2025-05-05 at 16:13 +, Stefano Rivera wrote:
> Read section A.2 of the constitution: you can withdraw your ballot
> option, and the GR won't happen. Others may pick it up and carry it
> through to a GR, though.
There is that part though:
+---
| No new ballot options may be prop
Hi,
On Mon, 2025-05-05 at 11:15 -0400, Mo Zhou wrote:
> It is too rush to start to vote for this within 3 weeks as I'm
> completely not available for involving into discussions.
It is two weeks unless something specific happens, so discussion period
might already have ended by now...
Ansgar
Hi,
On Wed, 2025-04-16 at 17:12 +, Bill Allombert wrote:
> Le Wed, Apr 16, 2025 at 08:39:18AM +0200, Ansgar 🙀 a écrit :
>
> > Debian has always allowed GPL-2-only code linked against GPL-3+-only
> > libraries such as the libstdc++ or GCC runtime libraries. (You ignore
Hi,
On Wed, 2025-04-16 at 07:27 +0200, Simon Josefsson wrote:
> Yes that seems likely. I think that the decision in other distributions
> may have had more to do with aligning interests with organization who
> fund them, though.
This is moving into conspiracy theory territory... We can as well
Hi,
On Mon, 2025-04-14 at 16:18 -0500, Richard Laager wrote:
> On 2025-04-14 11:10, Russ Allbery wrote:
> > I do find it fairly hard to understand the logic behind a position that
> > somehow our git-remote-https binary as distributed is a derived work of
> > OpenSSL and thus violates the GPLv2 li
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
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 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 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 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 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 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 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 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 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,
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 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 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 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 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,
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,
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 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 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-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-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 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 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
>
34 matches
Mail list logo
