Hi,
it seems the only OpenMAX implementation got removed from unstable, and
ffmpeg drops OpenMAX support as well because that implementation was
providing the header files.
That is a bit suboptimal for me, because the VisionFive2 hardware video
encoder is also interfaced using OpenMAX IL.
Hi,
On 8/21/24 18:32, Christoph Berg wrote:
10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have
‘const char *(const char *, int)’
10:39:04 409 | strchrnul(const char *s, int c)
10:39:04 | ^
10:39:04 In file included from snprintf.c:43:
10:39:04 /usr/includ
Hi,
On 8/20/24 18:09, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popcon
value.
I disagree -- the users most affected by a removal are those who
automate installation, and those will not be running popcon.
Can you elaborate on that claim? I probably mi
Hi,
On 8/20/24 17:35, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popcon value.
I disagree -- the users most affected by a removal are those who
automate installation, and those will not be running popcon.
Popcon was introduced to determine which pac
Hi,
there's a bit of a discussion within Debian on collaborating using Git.
One of the long-standing issues is that there are multiple ways Debian
packaging can be represented in a git tree, and none of them are optimal.
The problem at hand is that the packaging workflow consists of
1. impor
Hi,
On 8/20/24 14:28, Helmut Grohne wrote:
enigmail
Thunderbird has native GPG support now, including (well-hidden) support
for calling into the installed gpg binary to use a smartcard.
mutextrace
Oof, I should fix that finally, because in principle a debugging layer
to find lock hiera
Hi,
On 8/16/24 23:24, Andreas Tille wrote:
I tried to express: I'm more than willing to convert all packages where
I'm Uploader (most preferably) if DEP14 is accepted.
Would it make sense to try and convert a few packages to DEP14 first, to
see if this can actually be done and where the pitf
Hi,
On 8/5/24 20:26, Kentaro HAYASHI wrote:
* Package name: gr-framework
GNURadio are already squatting the "gr-*" namespace, so discoverability
will be bad and confused GNURadio users will install it.
Ideally, they would move to "gnuradio-*", but that would be fairly involved.
Sim
Hi,
On 8/5/24 17:26, Niels Thykier wrote:
* Does this package use `gbp dch` [...]
* Does this package use some form of automatic formatting [...]
* Does the maintainer prefer MR via salsa or BTS [...]
* Does the maintainer prefer dgit and if so, which of its 5+ different
documented
Hi,
On 8/5/24 17:10, Fabio Fantoni wrote:
currently you find such information from a simple search and/or looking
a bit in the source, in the possible git in a few minutes only in part
of cases, in many other cases instead it requires more time, the
possible contact of the maintainer, attempt
Hi Ansgar,
On 7/11/24 06:15, Ansgar 🙀 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 of future developments.
Hi,
On 7/10/24 05:36, Marco d'Itri wrote:
That's my question, essentially: is this an interface with full support from
upstream, or something that may change in an incompatible way later that
will require us to deploy additional infrastructure to support?
Multiple people, one of the systemd
Hi,
On 7/9/24 23:01, Luca Boccassi wrote:
As per smcv's point, if you need to manually write a static
configuration then you can also install your favourite tool to use it.
This is not the default case - the default case is "I have ethernet
and/or wifi and I want DHCP v4+v6 on anything that can
Hi,
On 7/9/24 17:57, Matthias Urlichs wrote:
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least
for new installations?
Both are overly complex for a static-IP-onl
Hi,
On 6/11/24 07:40, Yogeswaran Umasankar wrote:
It appears that nanopb's use of the module name "proto" does not align
with the conventional identification of a Python module. Given this, it
might be plausible to make this module private within the nanopb
package. This adjustment could potent
Hi,
On 6/11/24 00:26, Simon McVittie wrote:
Reproducibility outside of sterile environments is however a problem for us
as a distribution, because it affects how well people are able to contribute
to packages they are not directly maintaining
If our package-building entry point sets up aspec
Hi,
On 6/8/24 00:42, Simon McVittie wrote:
Having an UTF-8 locale available would be a good thing, but allowing
packages to rely on the active locale to be UTF-8 based reduces our testing
scope.
I'm not sure I follow. Are you suggesting that we should build each
package *n* times (in a UTF-8
Hi,
On 6/7/24 22:40, Alexandre Detiste wrote:
Maybe a compromise would be to at least mandate some UTF-8 locale.
Having an UTF-8 locale available would be a good thing, but allowing
packages to rely on the active locale to be UTF-8 based reduces our
testing scope.
Basically, we need to de
Hi,
On 6/6/24 19:56, Johannes Schauer Marin Rodrigues wrote:
At the same time though, I also get annoyed of copy-pasting d/rules snippets
from one of my packages to the next instead of making use of a few more
defaults in our package build environment.
Same here -- I just think that such a wo
Hi,
> Would it be possible to set in stone that packages are supposed to
> always be built in an environment where LC_ALL=C.UTF-8, or, in other
> words, that builders must set LC_ALL=C.UTF-8?
This would be the opposite of the current rule.
Setting LC_ALL=C in debian/rules is an one-liner.
If yo
Hi,
On 6/3/24 21:05, Colin Watson wrote:
From the d-i side we've generally preferred to have all the UI be part
of the installer (especially for translations etc.).
Makes sense, thanks!
Simon
Hi,
On 6/3/24 15:33, Philipp Kern wrote:
* Package name : systemd-boot-installer
Can this be merged into the normal systemd source package?
I feel like from a d-i perspective that'd be highly unusual? Having the
purely d-i-specific components be owned by d-i is the common setup.
If it
Hi,
On 6/3/24 09:33, Luca Boccassi wrote:
* Package name: systemd-boot-installer
Can this be merged into the normal systemd source package?
Simon
Hi,
On 5/27/24 22:18, Simon McVittie wrote:
So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).
I a
Hi,
On 5/27/24 19:59, Luca Boccassi wrote:
This MBF is
not about removing the virtual provides where they are defined, they
can stay as-is, but downgrading/removing the hard dependencies so that
we can make Debian minimal images.
So the policy becomes "a logging service is present even if not
Hi,
On 5/27/24 17:08, Federico Ceratto wrote:
Description : Simple OBJ loader
Can this somehow include the word "Wavefront", or a hint that this is
about 3D models? OBJ is also used to refer to relocatable object files
on MS-DOS.
Simon
Hi,
On 5/27/24 11:29, Luca Boccassi wrote:
With the default system installation including persistent journald by
default, it doesn't seem useful anymore to have such dependencies. They
are leftovers from an era where not having a system logging setup that
just worked by default was a thing, and
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 exper
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 tha
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 Debi
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 wor
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.
T
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 duplicatio
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 ver
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 PO
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 latt
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,
tmpfs+swap
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
s
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 th
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 d
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
enj
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, while
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 c
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:
relationshi
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 buildi
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 desi
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 in
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 en
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 to
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 *b
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 pidofpr
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 usin
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
function
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’ inter
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 pack
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 c
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
CAP_SYSL
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 maintai
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 ha
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...
Scann
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 d
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
/var/lib/apt/extended_states.
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 ac
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 som
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" alrea
i.e. in data.tar of binary
packages). dpkg is 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
sinuate 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 still
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 spends
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 an
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*
src:
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 days,
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 a
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 r
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
direc
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 li
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 limitation
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 other
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 cons
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 do
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
ef
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 Essen
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. Of
1 - 100 of 481 matches
Mail list logo
