6 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
der and targeted at the C ecosystem which still has
worse tooling that pretty much everything else.
Ansgar
IN 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
>
the hardware token to have a backdoor, exploiting it
might still require physical access to the token.
Ansgar
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
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
us 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
ng" 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 store p
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
don't think there is a reason for it to be higher than a
simple majority.
Should we look at changing these?
Ansgar
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
up guess and one could just as well claim that those are the least
valuable 0.61%?
Ansgar
egex should just be extended to include
"__pycache__" as well and these would be non-issues.
Ansgar
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 minor points.
Ansgar
[1]: Of course stating this
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,
for other
reasons), it's their own problem...
Ansgar
it scripts from
Debian. The non-technical cost of having them is too high.
Ansgar
h 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
et of desktop computers, but I think the better default
is still NM and it is up to the administrator to configure an
alternative.
Ansgar
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
available from
https://defi.43-1.org/defibrillator-test-key.asc
Ansgar
ebian.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
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 possib
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
systems having popcon enabled at
all (it seems to be mostly desktop systems) and how it looks on the
total population.
Ansgar
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 merg
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 packages
ld
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
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 t
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
es 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://www
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
we are already at (1) given everything works already?
Ansgar
d" 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
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
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
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
ce 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
ideas as well.
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
am-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
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
o "yes" or "no" answers independent of the use
case.
Ansgar
n 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
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
xample 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 can, bu
; 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
bborn 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
enerated 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
On Wed, 2022-04-20 at 19:47 +0530, Pirate Praveen wrote:
> 2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
> > On Wed, 2022-04-20 at 12:55 +0530, Pirate Praveen wrote:
> > > liberated.computer it is refurbished and some components like
> > > wifi
> > > cards
exists. However, that
does not "free" you from the restrictions of proprietary software that
comes from using non-free firmware in any way compared to having the OS
supply the firmware data.
Ansgar
On Tue, 2022-04-19 at 23:00 +0200, Jonas Smedegaard wrote:
> Quoting Ansgar (2022-04-19 19:04:36)
> > Firmware shipped as packages part of stable releases will probably
> > change the same way as software (i.e., security updates, other
> > important updates). So there shou
our own, but I do not think this is a good
default.
Ansgar
licenses not specific to Debian, but I think that
is the case. Maybe we should make that an explicit requirement for
firmware in non-free-firmware.)
Ansgar
nstall usrmerge and stop caring.
Ansgar
eds manual attention when the package
ends in BYHAND due to introducing additional binary packages.
At least I missed the earlier ping; please feel free to inquire about
packages stuck in by-hand a bit more/earlier.
Ansgar
[1]: https://lists.debian.org/debian-devel/2022/04/msg00029.html
cron jobs with .timer units, then we might also choose to
no longer install cron by default and users would have to install it
manually.
Ansgar
this would need to be
changed to use root:root as well.
(Not that I would recommend having a user with this name.)
Ansgar
pam_umask?
Ansgar
be anywhere, and are likely *not* in a single user's
> home.
Setting a default ACL on project directories seems a technical better
solution for this problem. It would only affect permissions of files
that should intentionally be group-readable, not all files created
anywhere.
Ansgar
ready quite
bad. It seems like a unsafe choice on both single-user and multi-user
systems...)
Ansgar
ices like mailing lists, our bug
tracker and so on, seems impractical. I also doubt many mail providers
allow user to do so.
And SRS also relies on whitelists again (otherwise it just allows
bypassing any SPF policy).
Ansgar
providers' whitelists
instead (as it "impersonates" other domains in mail sender addresses).
Ansgar
t; > to db.debian.org [1][2].
>
> Can you point to some quick guide on how to do this for gmail? The
> support page seems kinda confusing to me.
This usually requires you running your own mail server (for outgoing
mail).
I don't think mail providers like GMail allow you to set up DKIM for
individual IP addresses.
Ansgar
lt-in command
+---
I suggest to implement a new utility named
`/usr/bin/posix-which2` utility if you do not want that ;-)
(Only after proper standardization of course.)
Ansgar
(which as far as I understand some software already does on
i386 or would like to do) or dropping support for AMD Geode processors.
Ansgar
[1]:
https://salsa.debian.org/release-team/release.debian.org/-/blob/bb0660c80401eeacbe7063044a9a1b711dcc2303/www/bookworm/arch_spec.yaml#L108
| source, amd64,
arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
+---
So this would just be "Depends: valgrind" on all architetures?
Ansgar
/origins/debian, the version in
/etc/debian_version and so on.)
Ansgar
e to one where it has.
Why do you claim that?
Given packages already did such moves in the last years and you claim
this happens in a non-negligible number of cases, could you please
point to some examples where this already happens in practice?
Ansgar
havior
of contributors. Please see https://www.debian.org/code_of_conduct
Ansgar
TLS support to more and more libraries, so such a dependency can
just silently appear later.
Python programs using OpenSSL also usually don't have such an exception.
,
Ansgar
uld *not* edit .changes files manually as it is too
easy to refer to the wrong files, e.g., a different .orig tarball than
was used to build the package. I suspect someone did manually edit the
file here.
Ansgar
ble packages. (And I'm not sure debootstrap even checks
Valid-Until.)
Ansgar
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> > So what do you suggest then? Tech-ctte as with merged-/usr? Or a
> > GR? Or
> > something else?
>
> I propose that the proponents pay the cost. In this
ublic Key in the Certificate suffered a Key
| Compromise
+---[ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf ]
So that would not be helpful.
Ansgar
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote:
> > Maybe we should just find out who is responsible for this decision
> > and
> > reassign the bug to them. The installer team maintaining d-i and
> > deb
1 - 100 of 1858 matches
Mail list logo
