Hi,
On 5/6/25 20:31, Ahmad Khalifa wrote:
The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share
symlink but there is /usr/share/.
Perfectly reasonable method to support installing to /usr, /usr/local,
$HOME
Hi,
On 28.04.2025 15:40, Marc Haber wrote:
As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.
FWIW, switching to sysusers would break most of my CI containers --
these are orchestrated by Jenkins, and use a shell script
Hi,
On 3/15/25 22:58, Thomas Goirand wrote:
Description : next generation config management
[...]
Can you reword the description so that it reads less like an
advertisement? "next generation", compared to what?
Simon
OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public k
Hi,
On 3/10/25 17:52, Marc Haber wrote:
It is fine to disagree that these are concerns worthy spending time on
within the Debian project, which is my perception of the vote outcome.
There are not concerns about spending time. There are no people
willing to do so.
This is, however, a long t
Hi,
I'm on mobile, so only a quick reply: merging should be done with msgmerge as
well — you need to call it twice, once with the po files from both branches,
and once again with the pot file to fix all the location comments and fuzzy
flags.
Alternatively, you can define a filter in git to rem
Hi,
On 3/10/25 20:41, Andrey Rakhmatullin wrote:
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware, or apologize for the bad
experience they have when upstream changes something they don't like.
It is not our duty as volunteers to
Hi,
On 2/28/25 19:57, Colin Watson wrote:
But seeing two users who seem to have their systems configured this way
makes me wonder what's going on. Does anyone know of documentation
somewhere that recommends configuring stable systems this way?
What is weird is that both have pin priority 50
Hi,
can this be fixed to suggest Conflicts instead of Breaks/Replaces if the file
in the other package is still shipped in the current version?
Breaks/Replaces implies that ownership should be transferred from the other
package to this one. This is most often correct, but care needs to be taken
Hi,
I assume it is because the _core directory is new in NumPy 2, so dpkg
can just create the symlinks at unpack time. The latter two directories
need to be transitioned from a real directory in NumPy 1 to a symlink
during the package upgrade. Apparently this step fails, leaving an empty
dire
Hi,
On 2/18/25 00:21, Jeremy Stanley wrote:
Debian has, for legal and logistical reasons, decided that it cannot
distribute upstream Git repositories as its source packages, and
instead chooses to try to condense upstream's preferred form for
modification (back) into source tarballs.
If we "c
Hi,
On 2/12/25 13:38, Johannes Schauer Marin Rodrigues wrote:
["DSO missing from command line"]
I suspect that the problem is the order in which the -latomic is added to the
linker flags?
Yes.
Because if instead of target_link_options() with push and
pop-state I just use
target_link_
Hi,
On 2/10/25 18:48, Johannes Schauer Marin Rodrigues wrote:
I understand from the other mails that this architecture-check is not even
needed and that --as-needed will let the linker do the right thing. I still
like to special-case the only arch where this seems to be needed.
It's not neede
Hi,
On 1/22/25 00:31, Theodore Ts'o wrote:
I guess I could add an autoconf test to see if the linker barfs on
--as-needed, but I'm curious how much this actually matters in
practice.
From an upstream perspective, I think the best approach is
AC_CHECK_LIB([atomic],[main])
That creates a few
Hi,
On 1/17/25 17:45, Alexandre Rossi wrote:
Some upstreams have gone through build system tests to assess whether
to build with libatomic or not. Adding -latomic is simpler. I wonder if
the build system configure stage test is overkill.
Yes and no. A lot of the tests are just broken, like "c
Hi,
On 1/17/25 05:14, Sam Hartman wrote:
With the exception of Simon Richter, we appear to be agreed that
avoiding man pages in m-a: same packages is good.
I mean, this is specifically about the manpages included in
libpam-modules, which are at the intersection of
- likely to be useful
Hi,
atomic operations require linking against libatomic — always have. Some
architectures inline a few functions, which is how you get away with omitting
the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding libatomic
every
Hi,
On 1/16/25 13:22, Russ Allbery wrote:
There are various things one can do to try to make the output of a man
page generator like that more consistent, but they don't fix the problem,
just reduce its frequency, unless Debian sets up to do a fully
reproducible build with pinned versions of ev
Hi,
On 1/16/25 01:43, Sam Hartman wrote:
For a while we just built the man pages but if any of the docbook tools
changed between one arch build and another, we'd end up with m-a
uninstallable packages.
Can this be fixed by removing the "Generator:" comment in the generated
manpage, and possi
Hi,
I've been parsing a few package lists lately for nefarious reasons. Some
packages have Built-Using or Static-Built-Using tags, which seem to
serve the same purpose.
Is there a subtle difference I need to be aware of?
Simon
Hi,
I'm once again working on packaging ngscopeclient, which comes with a
few unit tests that submit workloads via Vulkan.
I've patched the package to skip tests if the Vulkan runtime does not
have access to any execution units -- which is basically any autobuilder
environment.
Can we do b
Hi,
On 1/13/25 03:46, M. Zhou wrote:
So what I was talking is simply a choice among the two:
1. A contributor who needs help can leverage LLM for its immediate response
and
help even if it only correct, for 30% of the time. It requires the
contributor
to have knowledge and skill t
Hi,
On 12/26/24 18:33, Julien Plissonneau Duquène wrote:
This should not make any difference in the number of write operations
necessary, and only affect ordering. The data, metadata journal and
metadata update still have to be written.
I would expect that some reordering makes it possible f
Hi,
On 12/24/24 18:54, Michael Tokarev wrote:
The no-unsafe-io workaround in dpkg was needed for 2005-era ext2fs
issues, where a power-cut in the middle of filesystem metadata
operation (which dpkg does a lot) might result in in unconsistent
filesystem state.
The thing it protects against is
Hi,
On 12/19/24 16:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
It depends on the package.
Some packages have a "registry-style" con
Hi,
On 12/18/24 19:38, Jonathan Dowland wrote:
I would also like to see this. Perhaps it's because the maintainers
don't want to close the door to alternative init systems, by making
their package depend on systemd features?
Most likely it is because BSD does not have systemd, and quite a lo
Hi,
On 12/4/24 23:37, Stefano Rivera wrote:
I don't think this can be entirely outside-in, the package needs to say
how much ram it needs per-core, to be able to calculate the appropriate
degree of parallelism. So, we have to declare a value that then gets
calculated against the proposed parall
Hi,
On 12/2/24 18:39, Jonathan Dowland wrote:
This is not correct. Whether any of /usr/bin,/usr/sbin,/bin or /sbin
share a partition or not has no relationship to whether a user can
invoke a command, or whether that path is searched for unqualified
command names (determined by $PATH).
FWIW,
Hi,
On 11/22/24 05:49, Gioele Barabucci wrote:
Unrelated to the apt proposal, how come dpkg-divert is being used here
by gpgv-from-sq instead of using the what-is-python/python-is-pythonX
approach of just shipping a symlink?
Because there is no coordination between gpgv and gpgv-sq packages,
Hi,
On 10/22/24 05:44, Aurelien Jarno wrote:
This is a native package useful for the riscv64 port, but which might also be
useful for some arm boards, therefore the goal is to provide the binary as a
arch:all package.
I remember the absolute insanity when ACPI was new and we basically
assume
Hi,
On 10/9/24 18:02, Simon Josefsson wrote:
x) Take current non-OpenBSD 'signify' source package and upload NEW
'signify-mail' package, say version 1.14-8 (?), that provides
/usr/bin/signify-mail instead of /usr/bin/signify, and has d/control:
Source: signify-mail
...
Package: signify-mail
Hi,
On 10/8/24 16:01, Simon Josefsson wrote:
1) Take current non-OpenBSD 'signify' source package and upload NEW
'signify-mail' with d/control modified as:
Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)
Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts
Hi,
On 10/7/24 21:43, Marvin Renich wrote:
trixie:
remove old src: signify
yes.
single source upload:
src: signify -> signify-mail
binary: signify -> signify-mail
new signify as transitional
unversioned Depends: signify-mail
yes.
trixie
Hi,
On 10/7/24 16:58, Marc Haber wrote:
I also see trouble in the archive when we have old signify in older
distributions and new signify in unstable and testing. Without having
any technical justification for that, I would probably go ahead to
rename signify to signify-mail, leaving signify-op
Hi,
On 9/25/24 08:55, Guillem Jover wrote:
So if there was a switch, those would end up
being recorded as well, and used when reproducing the outputs. And this
could also happen with a newer version of zlib itself.
I have a POWER9 box, which includes a NX-GZIP coprocessor, which is
currently
Hi,
On 9/22/24 19:22, Chris Hofstaedtler wrote:
The "server" group supposedly wants (and I agree) networkd, but they also want
the configuration interface of networkd.
I'm not sure about that -- I'd expect the "server" group to be split into
- "pets": their IP address doesn't change often
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
1 - 100 of 516 matches
Mail list logo
