itional ballot option or the project leader might
extend the discussion period (unless it is already over I guess).
Ansgar
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
pinion be done before the release of
trixie?
Ansgar
2] code at all...
As Git doesn't seem any different, I think we should close this bug.
If we think the system library exception is not valid, then we probably
have to remove lots of software and switch core libraries (e.g., use
clang, libc++ instead of gcc).
Ansgar
[1]: Even ignoring fu
gnorance is strength^Wfreedom."
Ansgar
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
ree Linux in Windows'
subsystem for Linux. (Which the FSF might arguably call "free" then...)
Ansgar
can cause problems like
wasting time to investigate cruft removals, build failures, ...
Does that seem reasonable as well?
Ansgar
projectb=> select s.source, s.created from source s
where exists (
select 1 from src_associations sa
where s.id = sa.source and
sa.suite = (select id fro
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
ically impossible now.
It also avoids the problem of removed-but-not-purged packages.
Ansgar
nd does!).
(Yes, I know that users are expected to purge packages and not only
remove them to prevent that, but many users do not.)
Ansgar
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
ial
> subdistribution of Debian GNU/Linux. YMMV
Please keep such messages to appropriate mailing lists such as the
Devuan list (aka "Debian is not GNOME first discussion list" as they
are somehow concerned about GNOME).
🐟🐠🦈,
Ansgar
ersion of lintian used
> for checking uploads is older and has a different format. How would I
> configure my package to override this?
You should not override the warning, but not include non-free files in
uploads to Debian. That probably means removing non-free files here.
Ansgar
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
has to configure NetworkManager
without netplan anyway.
At that point just making NM the default without additional layers
might be better: the feature set covered by just
- The feature is supported by NetworkManager
is larger than the earlier feature set.
Ansgar
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
oes that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?
Ansgar
s. Is that something "new"? :)
(And AFAIR that includes assigning static addresses to a static
interface due to race conditions.)
> Freeze
> ifupdown functionality, mark feature requests as wontfix, and update the
> documentation.
Should non-trivial bugs also be marked as wontfix?
Ansgar
://www.debian.org/consultants/index.en.html). Note that Debian
does not endorse any people or companies listed there. You can also try
the debian-user@ mailing list for exchange with other Debian users.
I would also recommend using a non-outdated release that still receives
security updates.
Ansgar
t like they enabled a system-wide `ProtectSystem=` in initrd by
default which prevents writing to `/usr`.)
Ansgar
a fairly large set of base software like gcc,
linux, glibc, systemd, ... So it seems reasonable to try to not grow
that list much further to address your concerns.
So we probably should look at systemd-networkd more seriously. Thank
you for providing further arguments for doing so.
Ansgar
etc/network/interfaces: are we really sure this
is safe long-term? We probably should not bet on that!
Ansgar
owever, continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)
(Sadly you previously refused incoming mail as I got a bounce.)
Ansgar
should leave the
decision whether/how to log to the admin.
However there are false positives: for example xinetd already dropped
the recommendation some time ago (Oct 2023)[1]. Maybe you used
information from stable to generate the list?
Ansgar
[1]:
https://tracker.debian.org/news/1474312/accepted-xinetd-123154-1-source-into-unstable/
continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)
Ansgar
ulib is just older and targeted at the C ecosystem which still has
worse tooling that pretty much everything else.
Ansgar
``
(The PIN can still be cached.)
For OpenSSH it might also be more convenient to use Webauthn, that is,
the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.
Ansgar
>
ieve the hardware token to have a backdoor, exploiting it
might still require physical access to the token.
Ansgar
d would raise an objection of my
> own.
/sbin not in PATH by default makes many more veteran users unhappy.
Especially as even su (not `su -`) no longer does that (an incompatible
change in one of the last Debian releases).
Ansgar
elf to your preferred value. For example:
export SHELL=/home/user/.bin/the-best-shell-of-all
(The details might vary depending on the shell you are currently in.)
usrmerge does not affect this at all.
Ansgar
s fine.
Otherwise provider and consumer would disagree about ABI and likely not
work fully correct.
> But fundamentally, how do we know how third-party binaries are
> compiled ?
They have to use `dpkg-buildflags` with equivalent ABI settings.
Ansgar
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.
Ansgar
s (DBus services, DBus
itself, daemons, ...).
A quick poll on IRC in #-devel seemed to show a majority of people who
responded agreeing with this.
(This does not have to apply to libnss-* or libpam-* which are not
actually libraries, but plugins.)
Ansgar
On Fri, 2024-01-05 at 08:50 -0500, Mo Zhou wrote:
>
> On 1/5/24 03:48, Ansgar wrote:
> > On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote:
> > > Dependency of DebGPT. Will be maintained by deep learning team.
> > > It will go to the contrib section based on polic
openai-thing" package to
the general public?
Ansgar
iew is requested here, too.
Is there any reason to not just use systemd-cryptenroll?
It seems to be a more featureful implementation and also doesn't
require storing PINs in plain text in configuration files like
/etc/cryptsetup/2fa/2fa.conf as README instructs users to do here.
Nor does it st
t; /etc/alternatives/editor -> /usr/local/bin/emacs
Users should just set the VISUAL environment variable.
Alternatives are the wrong tool to set user preferences as they can
only be set globally and only by root.
(editor-is-emacs has the same problem of course...)
Ansgar
2:1, but I don't think there is a reason for it to be higher than a
simple majority.
Should we look at changing these?
Ansgar
Please consider to just use openssl everywhere or also explicitly
disable/enable build options per arch. (Personally I would in this case
probably just enable openssl everywhere and recommend people to improve
openssl in case it is slower than the built-in implementation; openssl
is probably use widely enough to warrant that.)
Ansgar
y
made up guess and one could just as well claim that those are the least
valuable 0.61%?
Ansgar
should just be extended to include
"__pycache__" as well and these would be non-issues.
Ansgar
d to write in the helpful style the mail I
replied to uses. I skipped stating {sysvinit,dpkg} proponents haven't
done their homework, using {sysvinit,dpkg} incurs technical debt, they
failed us as community projects, it's impossible to onboard people to
them[1], and possibly some other mi
On Fri, 2023-06-30 at 11:10 +0100, Sean Whitton wrote:
> On Wed 28 Jun 2023 at 06:20PM +02, Ansgar wrote:
>
> > On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote:
> > > According to Policy as currently published, systemd units are
> > > encouraged,
warnings in dpkg or for other
reasons), it's their own problem...
Ansgar
sider removing sysvinit and init scripts from
Debian. The non-technical cost of having them is too high.
Ansgar
h, for example, systemd-shim which was
promised to get maintained and timely updated...
Less prone to errors than a manual process might be to watch
automatically where legacy startup scripts disappear anyway; it's not
that complicated to do. People tend to forget things.
Ansgar
also
include a subset of desktop computers, but I think the better default
is still NM and it is up to the administrator to configure an
alternative.
Ansgar
p environments and I
personally like systemd-networkd for other environments. In both cases
these replace both ifupdown and isc-dhcp-client.
I also think that installing both ifupdown and NetworkManager on
desktop environments is worse than only NM.
Ansgar
y is available from
https://defi.43-1.org/defibrillator-test-key.asc
Ansgar
i386 on
https://release.debian.org/testing/arch_qualify.html
I would not be surprised if we consider dropping leaf software where
builds start to hit the address space limit (I expect browsers & such).
Plus the broken FPU implementation as we don't require SSE.
And it *is* our choice to make to not spend time on dead architectures.
Ansgar
[1]: It also works for other carbon emissions!
c569c0080e92d057b
| ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486]
+---
Which is an incompatible ABI change.
Ansgar
s might result in non-booting systems.
That is what we sign up to accept by having the warning in dpkg.
Ansgar
Hi Russ,
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
>
cases for old i386 hardware.
I don't think that is a good use case to keep i386 installations on
i386 hardware alive beyond 2028 (which is what we are talking about):
just grab a slightly newer amd64 netbook out of the junk by the time
LTS support for Debian bookworm ends.
Ansgar
is the bias of systems having popcon enabled at
all (it seems to be mostly desktop systems) and how it looks on the
total population.
Ansgar
keep generating i386 install
media.
> Not a major thing, but if you're going to keep most of i386 anyway...
I would hope we could eventually drop some expensive, useless packages
from i386 like src:linux.
Ansgar
i386 and no longer provide installation media for i386.
|
| We recommend hosts still running the i386 port to be upgraded
| to amd64. Legacy i386 software can be run using multi-arch,
| chroot environments or containers.
+---
Ansgar
it
could be dropped in other places (CONTROL in .deb and Packages indices)
as well.
Regards,
Ansgar
PS: Please note the following disclaimer: I might or might not be payed
for this change and refuse to disclose financial incentives or other
conflicts of interest; I might or might not suggest
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote:
> On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> >
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
>
Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton
, Helmut Grohne , Luca Boccassi
, debian-d...@lists.debian.org, debian-devel@lists.debian.org
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users
Hi Russ,
On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
> Ansgar writes:
> > As far as I understand, we do explicitly *not* care about our
> > derivatives with regard to merged-/usr as some packages in Debian
> > recommend users to move *away* from merged-
On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > Debian's dependency system requires to explicitly declare
> > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we
> > cannot do
> > that for pac
limited... Alternatively forbid *all* changes that would
require this, i.e., require stable interfaces. However we do not do
this.)
But for all these issues we just say "meh, you are out of luck".
Ansgar
le.
Not handling diversions can lead to files disappearing, data loss or
other breakage, but it's very rare a package considers this.
Ansgar
On Mon, 2023-03-27 at 00:40 +0200, Ansgar wrote:
> the stretch, stretch-debug and stretch-proposed-updates suites have now
> also been imported on archive.debian.org. People still interested in
> these should update their sources.list.
>
> I plan to remove the suites from the
On Tue, 2023-03-28 at 16:24 +, Thorsten Glaser wrote:
> Ansgar dixit:
> > I plan to remove the suites from the main archive in about a month
> > (2023-04-23 or later).
> >
> > The stretch-backports, stretch-backports-sloppy and related debug suites
> > will l
Hi,
Ansgar writes:
> With this done I plan to remove jessie from the main archive and
> jessie-security from the security archive in about a month (2023-03-18
> or later).
Bad news for old*stable lovers: this part should be happening now. So no
oldoldoldoldstable on mirrors any
relay at the end).
[1]: https://www.isc.org/blogs/isc-dhcp-eol/
> Do we do our users a service by keeping that dead horse alive for
> another 2+ years?
I still think it is too late for major changes for Debian 12/bookworm.
Ansgar
natives such as systemd-
networkd or NetworkManager, including relevant changes in the installer
and other reverse dependencies.
Ansgar
-Werror by default as it
is too fragile. Maybe one should have a "developer mode" flag instead
that allows using -Werror?
Ansgar
document).
It is different for anonymous or pseudonymous works where the author is
not known, but the author can name himself later (which is fun to find
out about: you need to follow the national register for such
publications which only exists on paper in Germany[1]).
Ansgar
[1]:
https:
less
they use a VM.
Ansgar
ing /usr/local to be empty and a sane, standard environment and
contents of $HOME and anything else that could affect build results.
Ansgar
s have those installed).
(Also we do consider not installing "required" packages unsupported as
per the description of what "required" is; so if your build environment
doesn't include it, you are on your own.)
Ansgar
t (2).
I think we are already at (1) given everything works already?
Ansgar
ity "required" and additional packages. An informational
| list of additional packages can be found in
| /usr/share/doc/build-essential/list (which is contained in the
| build-essential package).
+---
This only documents existing practice as practically all systems have
required packages installed.
Ansgar
rnels (which can come from upstream) ;-)
If you want some other "common" ground, I guess it would need to be
created and adopted instead of the current one first.
Ansgar
is a good argument for
changing the default (rather the opposite).
Ansgar
[2]: For example taken from man:pam_umask(8) for the usergroups
option.
someone has to find time to
> > implement this.
>
> ARC is meant to be an alternative to this, eventually, right?
I doubt that. You would need to trust all mail relays (like lists.d.o)
to not be abusive, otherwise it would be trivial to abuse this.
Ansgar
On Wed, 2022-09-28 at 14:02 +0200, Elimar Riesebieter wrote:
> can one tell me which mailinglist manager is used at
> lists.debian.org? (mailman/sympa)?
I think it is smartlist. https://www.debian.org/MailingLists/ also says
so.
Ansgar
know if this is a bug or what
> facility I would even file a bug report against.
If the graphical interface (which one?) doesn't manage to successfully
install the update or still offers the update even though it was
installed, then that is probably a bug.
Ansgar
On Sun, 2022-09-18 at 12:51 +0100, Luca Boccassi wrote:
> > I wrote a possible patch for debootstrap in [1], but being
> > debootstrap we might need to have it in stable as well. Maybe
> > someone has other ideas as well.
> >
> > [1]:
> > https://salsa.deb
ld reproduce the problem; "debootstrap --print-debs unstable
unstable https://deb.debian.org/debian"; or similar should be sufficient
to show the problem.
I wrote a possible patch for debootstrap in [1], but being debootstrap
we might need to have it in stable as well. Maybe someone has other
use the legacy filesystem layout for
Debian 12 (bookworm).
We will send an announcement to debian-devel-announce@ once the upload
to unstable happens.
Ansgar
[1]: https://lists.debian.org/debian-ctte/2022/09/msg5.html
[2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127
On Fri, 2022-08-19 at 12:44 +0200, Philip Hands wrote:
> Ansgar writes:
>
> > - Having to spawn an external command ("dpkg --show-changelog") just
> > to access a file is more complicated.
>
> The fact that it currently needs to dug out of the main data
-upstream-news", ...?).
- It's harder to discover a Debian-specific command than regular
files. And you already might want to look in /usr/share/doc for
other documentation anyway.
- Having to spawn an external command ("dpkg --show-changelog") just
to access a file is more complicated.
Ansgar
all their outgoing mail is DKIM-signed,
- not send mail forwarded via the BTS (breaks DKIM signatures),
- not send mail to @d.o lists that break DKIM signatures (most are
fine, but depends on the DKIM-signature).
Ansgar
quot;yes" or "no" answers independent of the use
case.
Ansgar
run on modern hardware unless you ditch that and use those unofficial
> images"
There is a relevant event at DebConf22 for talking about this:
https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/
Ansgar
On Sun, 2022-07-17 at 10:29 +0200, Dominik George wrote:
> tl;dr: DKIM-signed mail is verifiable, but only the headers; the body
> can be tampered with;
This is just wrong. There is no reason to sign mails to ensure
authenticity if one can just change the body...
Ansgar
well (but less often).
Both could be changed to rewrite the "From" to something like "Debian
Bug Tracker <...@bugs.d.o>" or "Debian Devel Mailinglist
" to prevent this.
Ansgar
[1] https://bugs.debian.org/941195
example in discussions about a DebConf taking
place in a certain location. Not much happened as a result.
(FWIW, it was said project members even went so far to try to get
support for having sponsors not sponsor that DebConf, i.e., directly
working against the project. Also seems to be fine.)
Ansgar
On Tue, 2022-04-26 at 16:04 +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar wrote:
> > Why?
>
> If only I knew. I myself don't feel to comfortable to rely on
> Microsoft being able to pull the plug on us any time. I don't know
> whether they
of
> firmware already, with a couple of harmless "ERROR:" messages.
I would assume such NICs actually come with preinstalled non-free
firmware which just has less functionality...
I get the impression you pretend that preinstalled non-free firmware
just doesn't exist.
Ansgar
n even.
Maybe then the "DFSG-free" installer should also exclude drivers for
devices that require non-free firmware, including preinstalled non-free
firmware? It could also show a message indicating that such devices are
not supported (if possible).
People could still assemble their "non-free firmware enabled" install
media including such drivers.
Ansgar
the binary
generated by Debian is then signed by Microsoft's key.
Ansgar
o make.
Do you think the choice for the default should be part of a GR too, a
separate GR or decided some other way?
Ansgar
1 - 100 of 562 matches
Mail list logo
