Hi,
On 5/23/24 04:32, Andrey Rakhmatullin wrote:
It could be argued that testing migration is a CI process. >> Its a CI process
at a way too late stage.
Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to
Hi,
On 5/22/24 20:34, Bill Allombert wrote:
You can run autopkgtests locally, you do not need Salsa for that.
Also, Debian runs autopkgtests on all packages that provide them, and
makes passing them on all supported architectures a requirement for
testing migration.
It could be argued
Hi,
On 5/21/24 15:54, Andrey Rakhmatullin wrote:
The Debian archive itself is a VCS, so git-maintained packaging is also a
duplication, and keeping the official VCS and git synchronized is causing
additional work for developers, which is why people are opposed to having it
mandated.
The
Hi,
On 5/21/24 10:43, Luca Boccassi wrote:
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is
not to double down on them.
Our
Hi,
On 5/21/24 07:43, Bernd Zeimetz wrote:
Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.
Hi,
On 5/20/24 04:32, Otto Kekäläinen wrote:
I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.
Outside of DM uploads, I'm not sure that
Hi,
On 5/19/24 16:11, Jonas Smedegaard wrote:
My concern about Gitlab is not its *additions* to existing services, but
its *duplications* of core services already in Debian.
I agree, that's the key problem.
The Debian archive itself is a VCS, so git-maintained packaging is also
a
Hi,
On 5/15/24 10:31, Sirius wrote:
Where is the systemd-dev package for regular Bookworm? The only package
that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if
I try and install that, it seems like it wants to uninstall most of my
system in the process.
The
Hi,
On 5/8/24 07:05, Russ Allbery wrote:
It sounds like that is what kicked off this discussion, but moving /tmp to
tmpfs also usually makes programs that use /tmp run faster. I believe
that was the original motivation for tmpfs back in the day.
IIRC it started out as an implementation of
Hi,
On 5/6/24 19:57, Michael Biebl wrote:
Afaik, /var/tmp has never been cleaned up on /boot.
So I'm not sure what you mean with "no longer"?
Oof, you're right, it was /tmp, /var/run, /var/lock:
[ "$VERBOSE" != no ] && echo -n "Cleaning"
[ -d /tmp ] && cleantmp
[ -d
Hi,
On 5/6/24 20:19, Luca Boccassi wrote:
Is that the default layout, or a selectable option?
When you create a partition manually, it asks for the mount point, and
makes a number of suggestions in a dropdown, and /tmp is one of these.
There is also a "enter manually" option.
If the
Hi,
On 5/6/24 17:40, Michael Biebl wrote:
If we go with a/, then I think d-i should be updated to no longer create
/tmp as a separate partition.
I think if the admin explicitly configures tmpfs as a separate file
system, then that should be honored -- if there is memory pressure,
Hi,
On 13.04.24 00:19, Marc Haber wrote:
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.
That does not only apply to young contributors. I am an old fart and I
Hi,
On 4/9/24 01:48, Marc Haber wrote:
Otoh, I am fully aware of the "you can't force a volunteer to do
things", knowing that I myself would be the first one to violently
oppose a decision that I don't like while - at the same time - being
mad at some core package maintainers who have forced
Hi Julien,
On 4/8/24 22:45, Julien Puydt wrote:
I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
> - What does that web interface have that people don't like?
It's a normal GitLab install. For anything that is a normal software
project (like
Hi,
On 4/8/24 05:42, Wookey wrote:
I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
Hi,
because life isn't hard enough as it is: When /bin is a symlink to
usr/bin, and I install two packages, where one installs /bin/foo and the
other installs /usr/bin/foo, then, if both are installed in the same
dpkg invocation, the contents of the first package end up being
installed,
Hi,
On 3/5/24 17:56, John Paul Adrian Glaubitz wrote:
For m68k, there is mitchy.debian.net and for powerpc, there is
perotto.debian.net.
As soon as the container with my stuff arrives, I have another A1200
with 68060 and 603e+. Alas, Linux does not support asymmetric
multiprocessing so I
Hi
On 2/29/24 14:57, Steve Langasek wrote:
Furthermore, this is a downgrade from a replacing package to a replaced
package. Unless you also --reinstall the package at the end, missing files
are quite to be expected.
I wonder if this could be improved -- e.g. by ignoring Replaces:
Hi,
On 1/23/24 05:25, matt wrote:
* Package name: chatterino
I might be interested in that.
- I plan on maintaining it by compiling the latest package or use the
deb they provide, inside a packaging team
樂
I would need a need a sponsor
I currently have a 60 hour workweek,
Hi,
On 1/21/24 21:35, Matthias Urlichs wrote:
Now … does that apply to crossing release boundaries? Specifically, if
foo/testing requires bar >=1.1 to work but just states "Depends: bar
>=1", and bar/stable is 1.0.42 … is that a bug? If so which severity?
I'd say yes, with normal severity.
Hi,
On 1/16/24 03:55, Simon McVittie wrote:
I would personally like to see *more* privilege separation across IPC
boundaries rather than less, if that can reduce the total attack surface
of the setuid/setcap executables in the trusted computing base.
Yes, however there is a downside to
Hi,
On 06.01.24 22:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
We have a mandated tooling and workflow.
The tooling follows an interface that is defined in Policy. The
interface is deliberately
Hi,
More metapackages will make transitions harder though, I believe we want
to avoid that.
In what way would transitions become harder?
The alternatives system has "manual" and "automatic" modes for each
group, these would probably correspond to "manually installed" and
"automatically
Hi,
On 12/28/23 04:28, Luca Boccassi wrote:
if you want to activate a new alternative, you have to download a new
package that provides it anyway, so there's no difference. Subsequent
switches will use the cached package, and if you have issues
downloading a 3 kilobytes metapackage then just
Hi,
On 21.12.23 23:19, Antonio Terceiro wrote:
I think so, yes. I don't think it's likely that there are people doing
upgrades on running systems not using apt.
What about aptitude and the various other frontends, like the DBus based
package management tools? I'd expect quite a few people
Hi,
On 21.12.23 23:31, Marc Haber wrote:
Do those GUI frontends that work via packagekit or other frameworks
count as "using apt"? I now that WE recommend using apt in a text
console outside of X, but even many of our own users do what their
Desktop Environment does, and our downstreams like
Hi,
On 11/15/23 08:40, Nicholas D Steeves wrote:
1. I've received a report that this provider is not appropriate for DM
and DD use, because the key pair is stored on their servers. Ie: The
applicant doesn't control the means to validating identity and
authorship.
Correct. I'd even go as far
Hi,
On 11/14/23 18:42, Andreas Henriksson wrote:
Instead I think pidof can just be part of procps package. The
sysvinit-utils package will then pull in procps via a dependency (once
sysvinit-utils stops being Essential), which would smooth the transition
for all sysvinit users until LSB
Hi,
On 11/11/23 03:34, Julian Andres Klode wrote:
1) we use libgcrypt in libapt-pkg, which needs global initialization.
Libraries should not be doing the initialization, we're basically
misusing it.
I remember that KiCad had problems with OpenSSL for this exact reason --
we were
Hi,
On 11/10/23 21:07, Stephan Verbücheln wrote:
In my opinion, this is yet another reason to use a proper cryptography
library (openssl, gnutls or gcrypt) instead of a custom implementation
for this kind of algorithm.
Yes and no. The reason several of our core tools bring their own
Hi,
What would you think about having coreutils Depend on libssl3? This
would make the libssl3 package essential, which is potentially
undesirable, but it also has the potential for serious user time savings
(on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than
coreutils’
Hi,
On 10/17/23 01:24, Michael Prokop wrote:
# Restrict access to the various process namespace types the Linux kernel
provides
RestrictNamespaces=true
There is one plugin that uses namespaces. I wonder if it would make
sense to split it out into a separate package, and have that
Hi,
On 10/11/23 19:14, Michael Biebl wrote:
- CAP_NET_ADMIN: use of setsockopt()
- CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on
the number of open files, in system calls that open files (e.g. accept
execve), use of setns(),...
I see, thanks!
I looked over the code
Hi,
On 10/11/23 16:00, Andrius Merkys wrote:
Yes, but what does it do? Why would I pick this out of a package list
if I didn't know the name of the package already?
The following line in the RFP says:
Vite is a frontend build tool, including development server and build
command bundling
Hi,
On 10/11/23 15:30, Andrius Merkys wrote:
Description : Next Generation Frontend Tooling
Yes, but what does it do? Why would I pick this out of a package list if
I didn't know the name of the package already?
Simon
Hi,
On 10/11/23 03:22, Michael Biebl wrote:
I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives
CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
Hi,
On 10/10/23 06:24, Jonathan Kamens wrote:
* binary package name different from source name
* deb contains no changelog or NEWS files in /usr/share/doc
* creates a symlink in /usr/share/doc with the binary package name as
its name, pointing at another directory in /usr/share/doc
Hi,
On 10/10/23 03:16, Helmut Grohne wrote:
For one thing, dh_installsystemd generates maintainer scripts for
restarting services. Before version 13.11.6, it did not recognize the
/usr location. If you were to backport such a package, bookworm's
debhelper would not generate the relevant
Hi,
On 09.10.23 11:49, Jonathan Kamens wrote:
I need to be able to tell from one of my package scripts whether the
host has networking connectivity.
無. There is no such thing as "networking connectivity."
There is "has access to a particular service, at this precise moment in
time" and "is
Hi,
On 9/25/23 14:08, Paul Wise wrote:
The problem with that approach is that the help needed information
changes independently to packages, so the information will get very out
of date in between point releases, which is why how-can-i-help does
online checks. If desired, it would be easy to
Hi,
On 9/23/23 12:10, Paul Wise wrote:
You may be thinking of how-can-i-help, which is recommended to every
new person who asks about how to contribute to Debian.
There is also the older wnpp-alert in devscripts.
What I'd like to see is something like
Scanning processes...
Hi,
On 9/22/23 16:41, Christoph Biedl wrote:
That's not surprising: lpr is an old technology, it may be simple but it
has quirks. People moved on, and if they cared a little, they let go.
Erm. We're talking about printers here. lpr is the protocol with the
fewest quirks.
I agree that the
Hi,
On 18.09.23 05:16, Julian Andres Klode wrote:
If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and
Hi,
On 18.09.23 04:29, Russ Allbery wrote:
It at least used to be that you could print directly to a remote printer
with lpr and a pretty simple /etc/printcap entry that you could write
manually. I used to use that mechanism to print to an office printer
until I discovered rlpr, which is even
Hi,
On 9/11/23 23:08, Simon McVittie wrote:
Some packages rely on their own configuration existing in /etc. For these
packages, ideally they'd try loading from /etc as highest priority, but
fall back to /usr as a lower-priority location. This is a
package-by-package change, and probably best
Hi,
On 7/11/23 00:55, Sam Hartman wrote:
* The more I look at this, I think the real complexity is not in
bootstrapping, but is in the rest of the proposal for canonicalizing
paths. I am very uncomfortable overall; it seems complicated enough
that we probably will break something
Hi,
On 7/7/23 16:55, Helmut Grohne wrote:
If we have a consensus we're unwilling to wait for a patch, it doesn't
matter whether that's because:
While you try to remove the reasoning for this point of view
from the consensus, the "willing to wait" language implies a reason of
"too slow"
s not augmented with a general mechanism
supporting aliasing nor do we encode specific aliases into dpkg.
I recognize that this is not unanimous, but I think we still have
sufficient consensus on this. I suspect that maybe Simon Richter and a
few more would disagree here. If consensus fails, we
insinuate that it would be impossible to get changes merged for "social
reasons", but there is no opposition from either camp to changing dpkg.
I think this is a misrepresentation. There is no readily mergable patch
for aliasing support. The most complete one is the tree from Simon
Rich
Hi,
On 6/29/23 04:49, Helmut Grohne wrote:
* Package A 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which replaces the file in package A.
* User uninstalls package B.
F is now gone, even though it's supposed to be
Hi,
On 6/29/23 01:56, Sam Hartman wrote:
Russ> This feels like exactly the kind of problem that normally
Russ> Debian goes to some lengths to avoid creating, but it sounds
Russ> like several commenters here don't think the effort is worth
Russ> it?
Normally, Debian
Hi Russ,
On 6/29/23 01:58, Russ Allbery wrote:
According to Policy as currently published, systemd units are
encouraged, and init scripts are mandatory.
I thought I found and fixed all of the places init scripts were said to be
mandatory, but apparently I missed one. Could you file a bug
Hi,
On 6/28/23 22:42, Holger Levsen wrote:
I'm not sure Debian Policy is the best place to document this, because Debian
Policy
documents what packages *must* comply with, while legacy initscripts are a thing
of the past which still are permitted (and liked & prefered by some), so *maybe*
Hi,
On 6/28/23 15:19, Russ Allbery wrote:
Yeah, I knew that part, but for some reason I thought we normally always
combine Replaces with Breaks or Conflicts even for other cases. Maybe I
just made that up and confused myself.
No, we just have very few use cases for Replaces alone these
Hi,
On 6/28/23 13:05, Russ Allbery wrote:
In that case, I don't actually know why we usually use Conflicts with
Replaces. Maybe we don't really need to?
Replaces+Conflicts together has a special meaning, that is used for
replacing a package completely in an atomic operations, such as when
Hi,
On 6/28/23 02:31, Russ Allbery wrote:
Normally Conflicts is always added with Replaces because otherwise you can
have the following situation:
* Package A version 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which
Hi Ansgar,
On 6/27/23 01:45, Ansgar wrote:
[systemd service wrapper provided by init]
I think sysvinit maintainers looked at such ideas in the past, but
weren't capable to get it to work. That might be a blocker for such
approaches. There was also a GSoC project in 2012 and some other work.
Hi,
On 6/25/23 23:15, Mark Hindley wrote:
The most recent proposal[6] for updating the Policy with a requirement to use
tmpfiles.d(5) states
"Init systems other than ``systemd`` should allow providing the same
functionality as appropriate for each system, for example managing the
Hi,
On 6/19/23 01:37, Vincent Danjean wrote:
All we can do with the dependency system (not yet done) would be to
force a dependency on a new virtual package to ensure that at least one
ICD with the correct minimal version is available.
I'm not sure if this is really possible (is it possible
Hi,
On 10.06.23 00:41, Steve McIntyre wrote:
What exactly do you mean here? You know that even a statically linked
executable needs an interpreter defined in the ELF header?
/sbin/ldconfig has no PT_INTERP segment.
If you use libdl, you need to be loaded through ld.so, and since PAM
uses
Hi,
- when you use switches, the local network segment has no other nodes
- if there were other nodes, they would likely miss some packets in
the conversation, which means they cannot generate checksums
- there is no software that can perform this inspection
Yep, there are
Hi,
On 5/31/23 05:42, James Addison wrote:
* It allows other devices on the local network segment to inspect the
content that other nodes are sending and receiving.
That is very theoretical:
- when you use switches, the local network segment has no other nodes
- if there were
Hi,
On 20.05.23 16:15, Josh Triplett wrote:
That might help reduce the number of actual installations of i386 by
people who don't realize they could be and should be using amd64.
Crossgrades are probably broken with systemd, but it might be possible
to hack something that diverts /sbin/init
Hi,
On 5/18/23 18:08, Luca Boccassi wrote:
Without it, leaving them in place makes no difference for usrmerged
systems, and allows derived distributions that don't need usrmerge to
continue using our packages.
Not quite. Having packages only ship files under /usr (and possibly
/etc) is very
Hi,
On 5/18/23 02:15, Sam Hartman wrote:
Helmut> I think at this point, we have quite universal consensus
Helmut> about the goal of moving files to their canonical location
Helmut> (i.e. from / to /usr) as a solution to the aliasing problems
Helmut> while we do not have
Hi,
On 5/8/23 20:38, Luca Boccassi wrote:
[local diversions]
Sure, they are supported in the sense that they can be enabled, and
then you get to keep the pieces.
They are supported in the sense that someone actually added an explicit
flag for dpkg-divert for specifically this feature and
Hi,
On 5/7/23 18:14, Ansgar wrote:
Is there any specific reason why specifically diversions are a problem
where "it might work" is not sufficient? That is, why should we divert
from the usual standard for dealing with packages outside the Debian
ecosystem here?
Locally created diversions are
Hi,
On 06.05.23 21:28, Luca Boccassi wrote:
[shipping usrmerge symlinks in packages]
In the far future I'd like for these details to be owned by image
builders/launchers/setup processes rather than a package, but this can
be discussed separately and independently, no need to be tied to this
Hi,
On 06.05.23 07:11, Luca Boccassi wrote:
- every package is forcefully canonicalized as soon as trixie is open
for business
You will also need to ship at least
- /lib -> usr/lib (on 32 bit)
- /lib64 -> usr/lib64 (on 64 bit)
as a symlink either in the libc-bin package or any other
Hi,
On 05.05.23 18:36, Timo Röhling wrote:
- it is not an error to register a diversion for an alias of an
existing diversion, provided the package and target matches, this is a
no-op
- it is not an error to unregister a diversion for an alias of a path
that has been unregistered previously,
Hi,
On 04.05.23 20:26, Helmut Grohne wrote:
From my point of view, the ultimate goal here should be moving all files
to their canonical location and thereby make aliasing effects
irrelevant. Do you confirm?
Yes, that would solve the problem for the current transition without any
changes in
Hi,
On 03.05.23 19:19, Helmut Grohne wrote:
What still applies here is that we can have usr-is-merged divert
/usr/bin/dpkg-divert and have it automatically duplicate any possibly
aliased diversion and then the diverter may Pre-Depends: usr-is-merged
(>=...) to have its diversions duplicated.
Hi,
On 30.04.23 03:08, Marvin Renich wrote:
My understanding from following this thread (and others) is that dpkg
has a bug that can easily be triggered by a sysadmin replacing a
directory with a symlink (and some other necessary conditions that don't
happen very often), which is explicitly
Hi,
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> Ok, let's move on. I've proposed diversions as a cure, but in reality
> diversions are a problem themselves. Consider that
> cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is
> usually owned by cryptsetup. If
Hi,
On Thu, Apr 27, 2023 at 11:57:58AM +, Holger Levsen wrote:
> Constitution 2.1.1 is great, however we don't really have a mechanism how to
> deal with people flat out ignoring Constitution 6 aka the tech-ctte and
> doubting
> and activly working against it's decisions.
We have: we can
Hi,
On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote:
> I am not sure whether it is doing non-systemd users a favor to keep a
> probably outdated, bitrotting and untested init script in the
> canonical place. My gut feeling is that it might be better to ship the
> old init script in
Hi,
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> At some point the question becomes: Do we want that complexity inside
> dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what
> we're talking about here). It seems clear at this time, that complexity
> is
> to its canonical location without having any trouble even with an
> unmodified dpkg. So from my pov, the question about important files can
> be disregarded. I hope Simon Richter agrees.
Yes, the relevant code at
https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749
alre
Hi,
On 22.04.23 11:36, Helmut Grohne wrote:
For clarity let me propose the following requirements for the definition
of done:
* All files shipped in Debian packages are shipped in their canonical
location rather than an aliased path.
With proper support in dpkg, that is even somewhat
Hi,
On 21.04.23 15:03, Raphael Hertzog wrote:
Here you are considering all files, but for the purpose of our issue,
we can restrict ourselves to the directories known by dpkg. We really
only care about directories that have been turned into symlinks (or
packaged symlinks that are pointing to
Hi,
On Fri, Apr 21, 2023 at 02:15:54PM +0200, Raphael Hertzog wrote:
I'd like to express some disappointment that nobody replied publicly
sofar.
There were a few replies on the dpkg mailing list.
Last year's developer survey concluded that "Debian should complete
the merged-/usr
Hi Mike,
On 2/2/23 00:14, Mike Gabriel wrote:
* Package name: hud
Unity HUD is a heads-up-display interface for controlling the behavior of
applications as well as Unity via typed-in commands. It provides access to
all applications menu via a single central interface, in order to
Hi,
On 12/11/22 16:47, Andreas Tille wrote:
May be I interpreted
posts in this thread wrongly but I read it like serious is a to high
severity. Moreover what does this mean for other packages where
configure.ac is missing?
It depends on the licence, to some extent.
The GPL's definition of
Hi,
On 9/29/22 11:07, Mathias Behrle wrote:
* Package name: stripe
* URL : https://github.com/stripe/stripe-python
Ideally the package would be named "python-stripe" or "stripe-python", I
think.
Simon
OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key
Hi Ian,
On 7/19/22 19:24, Ian Jackson wrote:
How does LTO work with ABI compatibility, which we rely on very
heavily ?
Symbols that are visible to the dynamic linker or that have their
address taken are hard borders for optimization, even in non-LTO builds.
For example,
int a() {
Hi,
On 4/23/22 11:07 PM, Iustin Pop wrote:
Making Debian hard to use is a very short-sighted view of how to promote
free software - it works in the very short term only.
The same applies in the other direction -- making no real distinction
between free and non-free software is a short term
Hi,
On 4/20/22 12:14 PM, Jonathan Dowland wrote:
However I think we should continue to produce install media without
non-free components, at least for a period of time after making the
switch (as another reply said, perhaps 1-2 releases and review). It
feels like me too big a step to take to
Hi,
On 3/10/22 8:59 PM, Michael Biebl wrote:
have you considered a more declarative approach as provided by
systemd-sysusers (8)?
We currently don't have a good mechanism for leaving configuration
behind on purge, which we've historically done with user accounts to
avoid reuse of UIDs that
Hi,
On 2/10/22 6:55 PM, Sam Hartman wrote:
Over time, if people see the value in migrating toward something more
people understand, the probability of people seeing the value and
migrating increases.
What we are absolutely missing is a workflow for software that does not
have well-defined
Hi,
> > (I've used /bin -> /usr/bin as an example, but the canonicalization must
> > deal with the other merged paths too.)
/lib and /lib64 are a bit special, because they are part of the ELF ABI,
and any manipulation of these paths needs to be atomic.
Bootstrapping a new Debian system works by
Hi,
On Fri, Nov 19, 2021 at 12:28:56PM -0700, Sam Hartman wrote:
> But we could you know fix dpkg:-)
> I'm sure that will be painful at the political level, but personally I
> think it needs doing.
I think the main blocker at the moment is that the dpkg change *also*
has the potential to break
Hi,
On 11/18/21 4:08 PM, Stephan Lachnit wrote:
I guess this raises the (maybe already answered) question if the
additional license QA from NEW is for the end-product (i.e. Debian
stable) or for the servers that run the Debian infrastructure, which
of course includes experimental.
The
Hi,
On 11/8/21 12:56 PM, Marco d'Itri wrote:
Right now, it is sufficient to preseed debconf to disallow the usrmerge
package messing with the filesystem tree outside dpkg. Managed installations
usually have a ready-made method to do so.
This is not really relevant, since the conversion is
Hi,
On 11/8/21 12:03 AM, Marco d'Itri wrote:
I have been asked to remove from the usrmerge package the debconf
question which asks to confirm the conversion.
Does anybody REALLY believe that it should not be removed?
While it may be more convenient for home users to not be bothered with
Hi,
+ One example of a migration path that might be used is for an
Essential package to add a dependency on the usrmerge package, so
that it will be installed automatically during upgrades. We do not
require this to be the migration path that is chosen; it is
Hi,
On 10.09.21 01:46, Paul Wise wrote:
Another important argument is that it creates a dependency on
third-party commercial CDNs, and their *continued* sponsorship.
This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed
Hi,
On 04.09.21 22:12, Hideki Yamane wrote:
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
The
Hi,
On 02.09.21 23:02, Ansgar wrote:
As it is now, I can install a Debian system where no X.509
certificate authorities are trusted.
That doesn't change with the proposal?
- If I deselect all CAs in the configuration dialog of the
ca-certificates package, what mechanism will allow apt
Hi,
On 02.09.21 03:22, Hideki Yamane wrote:
Providing "default secure setting" is good message to users.
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
We
1 - 100 of 682 matches
Mail list logo
