l to see
> what we are trying to achieve here.
The Linux Foundation has issued a statement on the FSF board changes?
Ansgar
Hi,
please see the debian-user[1] mailing list for user support.
Ansgar
[1]: https://lists.debian.org/debian-user/
age (install, remove, update)
packages, then I believe PackageKit[1] tries to offer this.
Ansgar
[1]: https://www.freedesktop.org/software/PackageKit/
ransitions should be coordinated).
Upload processing on the security archive will also be ⏸d tomorrow
morning.
Ansgar
ld suggest [1]. But be
careful as [1] itself is non-free (licensed as CC-ND).
Ansgar
[1]: https://www.gnu.org/distros/free-distros.html
APT is not the only way to download packages: often enough users (and
developers) will ignore apt, download packages manually for various
reasons, *not* do the integrity checks apt does and install them.
Using https:// URLs for mirrors wherever possible makes this a bit less
bad.
Ansgar
should not support.
Ansgar
rs is insignificant and can be totally ignored feels rather far
fetched just to support an outcome you want to see true. We would have
much, much larger problems for the future of Debian and Debian-based
distributions than merged-/usr if this was true. So if you have any
support for this claim, I'm interested in seeing it.
Ansgar
Hi,
On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote:
> * Ansgar [210822 05:08]:
> > To get a filesystem layout equivalent to merged-/usr via symlinks
> > farming *every* package shipping files in at least /usr/bin,
> > /usr/sbin
> > and possibly some of /us
maken your point. It clutters the discussion with needless
> debunking.
I think you misunderstand how the partially-symlink-farmed-root
proposal is different from the merged-/usr proposal. Exactly to avoid
such misunderstandings the partially-symlink-farmed-root proposal
should not be named merged-/usr.
Ansgar
nstable:
lib/systemd/system/ifup@.service: root=admin/ifupdown2 usr=admin/ifupdown
lib/systemd/system/networking.service: root=admin/ifupdown2 usr=admin/ifupdown
Ansgar
> Caching packages and transport level encryption are fundamentally
> incompatible.
No. You can explicitly configure apt to use a local caching mirror or
use a trusted TLS certificate for the mirror the proxy impersonates.
Ansgar
acing deb.d.o by a non-CDN feasible? If no, what does use of
https change?
As far as I know there is also at least https://cdn-aws.deb.debian.org/
if you don't like Fastly.
Ansgar
, but not other packages, that
> mechanism doesn't exist yet.
If a CA is untrustworthy, I don't think we would only want to detrust
it for apt's https method. So I see no problem.
>
> It's not about what I like, but on what external services we want to
> depend.
So your concern is about Debian providing the deb.debian.org service at
all? That seems unrelated to the https or not question.
Ansgar
that one size
> does not fit everyone. Either way makes some people unhappy.
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
debootstrap or the mirror team seem reasonable choices?
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
ey 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 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
ckages. (And I'm not sure debootstrap even checks
Valid-Until.)
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
em to keep
adding 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
behavior
of contributors. Please see https://www.debian.org/code_of_conduct
Ansgar
place 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
ettings in /etc/dpkg/origins/debian, the version in
/etc/debian_version and so on.)
Ansgar
| source, amd64,
arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
+---
So this would just be "Depends: valgrind" on all architetures?
Ansgar
thout
fallback (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
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
on providers' whitelists
instead (as it "impersonates" other domains in mail sender addresses).
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
ault is already quite
bad. It seems like a unsafe choice on both single-user and multi-user
systems...)
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
nually
enables pam_umask?
Ansgar
ended. So this would need to be
changed to use root:root as well.
(Not that I would recommend having a user with this name.)
Ansgar
place all 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
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
ll usrmerge and stop caring.
Ansgar
butable and 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
our own, but I do not think this is a good
default.
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
ignore the firmware 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 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
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
the binary
generated by Debian is then signed by Microsoft's key.
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
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
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
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
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
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
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
quot;yes" or "no" answers independent of the use
case.
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
-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
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
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
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
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
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 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
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
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.
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
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
t (2).
I think we are already at (1) given everything works already?
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
ing /usr/local to be empty and a sane, standard environment and
contents of $HOME and anything else that could affect build results.
Ansgar
less
they use a VM.
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:
-Werror by default as it
is too fragile. Maybe one should have a "developer mode" flag instead
that allows using -Werror?
Ansgar
natives such as systemd-
networkd or NetworkManager, including relevant changes in the installer
and other reverse dependencies.
Ansgar
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
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
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
(language, domain) and consider
following whatever they do" to make it easier to interact with these
people when asking for advice or so.
Ansgar
nged to use
`Source: ...` instead of `Package: ...`; more places could follow later.
Ansgar
by their archive management
system.
As far as I understand git-archive is fairly good as reproducing
identical uncompressed tarballs at a later time from the git repository.
Ansgar
Guillem Jover writes:
> On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
>> the thread about naming (source) packages reminded me of an other thing:
>> Debian's bug tracking system currently (mostly) tracks bugs against
>> binary packages and (less often) against sou
Sune Vuorela writes:
> On 2019-10-23, Ansgar wrote:
>> So I'm wondering if we should start just filing all bug reports against
>> source packages? Reportbug could probably be easily changed to use
>> `Source: ...` instead of `Package: ...`; more places could follo
ss possible as
everything shipping any systemd service will start to pull in systemd,
even though one might not use it to start the service.
I think this is not a good idea.
> - apt being able to blacklist packages and hide packages that depend on
>those
Implicitly hiding some packages seems very confusing.
Ansgar
t; then this question
>doesn't arise. But it's entirely possible that the answer to question
>1 is "yes" but the answer to this question is still "no."
I don't really believe writing init systems is Debian's goal, just like
implementing our own X server or other stuff.
That other implementations that use systemd's unit files might be
useful, but so far no other implementation has come into existence for
years.
Ansgar
Package: ftp.debian.org
Hideki Yamane writes:
> firefox-esr package doesn't migrate to testing but I cannot
> find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
I believe we should remove firefox-esr/armel to allow the current
version to migrate to testing.
Ansgar
even marginally preparing.
I'm not sure what that has to do with Debian supporting multiple init
systems? Nobody is suggesting to not package software that doesn't need
tight integration with systemd; most software probably won't.
Ansgar
esides that, from earlier communication from the 2000 active developers
of the Devuan distribution, they were planning to stop importing updates
from Debian anyway.
Ansgar
difficult because it's
> more featureful.
There is already an alternative implementation for tmpfiles.d:
https://github.com/OpenRC/opentmpfiles
I don't know more than that it exists though.
Ansgar
could
> migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ +
> signed-by. Right now it ships keyrings in both places.
I would recommend against doing this as long as sources.list is a
configuration file: it would need regular updates to change to the new
signing key. That doesn't work out of the box.
Ansgar
an we provide security updates for
> them, or will we shunt these users onto a "rolling release" track, and if
> yes, who manages that track?
Currently the systemd maintainers also maintain a backport for systemd.
Ansgar
It shouldn't matter
if you can sign the kernel or any module run in the same context as the
kernel.
Ansgar
new branch to be a descendant by "fake"
merges, but that is not a good idea for various reasons: it creates an
incorrect history and confuses tools that now think commits were
applies when they really were not.)
Ansgar
perimental and/or only available via
experimental.
But for packages like firefox, users should really get updates by
default.
Unstable is arguably also easier to use than experimental (no extra
source entries, no pinning, ...). I believe binNMUs are also mostly
only scheduled for packages in unstable.
Ansgar
t; pretty consistent in the archive.
As far as I know Python also byte-compiles modules in postinst, so such
a dependency might be required for that alone. Though that tests if the
`py3compile` program (or similar) is actually installed.
Ansgar
Thomas Goirand writes:
> Do you already have a list of affected package?
A list of affected packages was attached to the mail.
Ansgar
e reason there is /bin/bash and /usr/bin/bash probably?
Ansgar
.)
Alternatively the upstream repository without the Debian packaging bits
can be found at [1] (might be a mirror, not sure).
Ansgar
[1]: https://github.com/OpenRC/opentmpfiles
hould Debian choose to use tmpfiles for more generic purposes.
> this does not entirely
> obviate my concerns related to needing to have systemd-the-package's
> daemons present in order to gain access to these facilities.
I'm happy to have helped overcome these concerns.
Ansgar
nd effort on this.
Ansgar
ckage may cause your system to become totally
broken and you may not even be able to use dpkg to put things back, so
only do so if you know what you are doing."
"Essential" packages just have additional requirements (in particular
essential packages must work even in the "unpacked" state).
Ansgar
ontexts for a long time and there it might be easier to just
change the ABI, but for a general-purpose distribution we start seeing
more and more problems and I don't really see us supporting them as a
full architecture in 10+ years.
Ansgar
Russ Allbery writes:
> Ansgar writes:
>
>> So maybe just recommend people to move to 64-bit architectures and put
>> 32-bit applications in a time namespace so they believe they are still
>> in 2001 ;-) 32-bit architectures will probably still be useful in
>> embedde
it yet.
I think a `--facility` option should be fairly easy to implement. Just
adapt some code from the existing `--identifier` and `--priority`
options, there is already a method to translate facility names to
numbers (see calls to `log_facility_unshifted_from_string`).
Ansgar
[1]: https://gith
-linux-i386, i386 are distict architectures
after all. So an incompatible newglibc-linux-i386 would be different
from i386 as well?
Ansgar
101 - 200 of 562 matches
Mail list logo
