On Wed, 8 Jan 2025 at 23:08, Daniel Kahn Gillmor wrote:
>
> Thanks for this discussion, all--
>
> On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
> > I believe this would be good, I frequently run into GnuPG bugs in the
> > 2.2.x branch that was fixed years ago in 2.4
>
> Can you identify
On Wed, 8 Jan 2025 at 14:35, Peter Pentchev wrote:
>
> On Wed, Jan 08, 2025 at 10:19:34AM +0100, Julien Plissonneau Duquène wrote:
> > Le 2025-01-07 21:52, Peter Pentchev a écrit :
> > >
> > > Hm. That sounds interesting, but I think the Debian project cannot
> > > protect such a mirror from autom
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: sphinxcontrib-globalsubs
Version : 0.1.2
Upstream Author : Stefan Wiehler
* URL :
https://github.com/missinglinkelectronics/sphinxcontrib-globalsubs
On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
>
> On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> [...]
> > To pick a random example, a less well known, less used, less
> > popular distribution like Nixos has 7000+ contributors listed on
> > Github.
On Thu, 1 Aug 2024 at 21:57, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
> wrote:
> >On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
> >>
> >> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> >> wrote:
> >> >T
On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> wrote:
> >The vast majority of people who
> >are forced to use emails do so for work via a
> >work-mediated/administered interface that tries to make it somewhat
&g
On Thu, 1 Aug 2024 at 13:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
> >
> > run a CI before uploading, even a very basic one is just fine, better
> > than nothing.
>
> Thanks for the remider ! I will have a closer
On Thu, 1 Aug 2024 at 09:49, Jonas Smedegaard wrote:
> Quoting Otto Kekäläinen (2024-08-01 07:30:18)
> > You have for sure developed an optimal workflow for yourself.
>
> Then I have failed: I have strived towards a collaborative workflow.
>
> Just not a web-centered collaborative workflow, but an
On Thu, 1 Aug 2024 at 10:36, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Otto,
>
> Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian package
On Tue, 16 Jul 2024 at 14:46, Daniel Gröber wrote:
>
> Hi Luca,
>
> On Mon, Jul 15, 2024 at 02:50:17PM +0100, Luca Boccassi wrote:
> > Let's put some hard numbers on the table given this is an important
> > detail. The following is all starting from a defaul
On Tue, 16 Jul 2024 at 14:05, gregor herrmann wrote:
>
> On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
>
> > I suspect having something that's agnostic about the underlying
> > implementation as our default would be rather better for the non-systemd
> > options that people care about, …
On Tue, 16 Jul 2024 at 00:26, Steve Langasek wrote:
>
> On Mon, Jul 15, 2024 at 03:47:16PM +0100, Luca Boccassi wrote:
> > Assuming that's really needed, and it's far from clear that different
> > use cases should really use the exact same things, using
> >
On Mon, 15 Jul 2024 at 14:36, Lukas Märdian wrote:
> = "How to do networking on Debian?" =
>
> If we have to tell our users and sysadmins to do "X" on Debian server systems
> (using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop
> systems (using NetworkManager), while doin
On Sun, 14 Jul 2024 at 19:21, Simon McVittie wrote:
> Dependency size and maintenance
> ---
>
> I also notice that the netplan.io package would bring GLib, Python,
> python3-dbus and python3-yaml into the dependencies of the base system,
> among others. As an upstream a
On Sun, 14 Jul 2024 at 19:21, Simon McVittie wrote:
>
> On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
> > Luca Boccassi wrote:
> > >Networking is not static, it constantly changes in the kernel,
> > >sometimes in dramatic and incompatible ways.
>
On Sun, 14 Jul 2024 at 21:26, Philip Hands wrote:
>
> Luca Boccassi writes:
>
> > Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
> > In the last ~2.5 years, in netplan.io's github repo, there are only 2
> > contrib
ntributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:
569 Lukas Märdian
310 Danilo Egea Gondolfo
39 Simon Chopin
38 Danilo Egêa Gondolfo
11 Robert Krátký
Same stat, for the same period, for systemd:
6650 Yu Watanabe
5415
On Thu, 11 Jul 2024 at 12:12, Lukas Märdian wrote:
>
> On 11.07.24 11:13, Marco d'Itri wrote:
> > On Jul 11, Philip Hands wrote:
> >
> >> I've only seen netplan mentioned in passing in this thread so far.
> > Because I believe that Netplan is the answer to a question that nobody
> > asked here.
>
On Tue, 9 Jul 2024 at 18:02, Simon McVittie wrote:
>
> On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote:
> > On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
> > > I believe NM does not have a fixed configuration format, but only a dbus
> > > API.
> >
> > It's perfectly fine to edit co
On Tue, 9 Jul 2024 at 14:44, Simon Richter wrote:
>
> 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 leas
On Fri, 14 Jun 2024 at 13:21, Mourad De Clerck wrote:
>
> > PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
> > bumped early at boot from 1048576 to the max value that the kernel
> > allows, which on amd64 is currently 1073741816.
>
> Hi,
>
> It seems some proprietary software
On Fri, 14 Jun 2024 at 11:54, wrote:
>
> Then it's not a problem in the first place. If you can't reproduce a bug with
> a reasonable effort, then it is unconfirmed and you can stop worrying about
> it. A bug that can't be reproduced, effectively doesn't exist.
>
> That's not a reason to stop su
ot;I have an old machine
under the desk and can build some trivial packages", I am afraid.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
ed to switch to close_range, which is
very simple to use and documented at:
https://man7.org/linux/man-pages/man2/close_range.2.html
Please enjoy your extra file descriptors responsibly.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
On Thu, 6 Jun 2024 at 09:07, Gioele Barabucci wrote:
>
> Hi,
>
> setting LC_ALL=C.UTF-8 in d/rules is a common way to fix many
> reproducibility problems. It is also, in general, a more sane way to
> build packages, in comparison to using whatever locale settings happen
> to be set during a build.
On Thu, 6 Jun 2024 at 10:02, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Helmut,
>
> Quoting Helmut Grohne (2024-06-06 09:28:52)
> > I have just uploaded
> > * base-files
> > * bash
> > * dash
> > * glibc
> > * util-linux
> > to unstable. These were the last remaining packages shipping ali
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: systemd-boot-installer
Version : 0.1
Upstream Author : Luca Boccassi
* URL :
https://salsa.debian.org/installer-team/systemd-boot-installer
* License
On Fri, 31 May 2024 at 06:07, Jakub Wilk wrote:
>
> * Jun MO , 2024-05-31 01:05:
> >And something "off topic". I find there is a char __glibc_reserved[20]
> >variable in the struct utmp, which is commented as "Reserved for future
> >use". Just a brainstorm, if this variable is not currently used,
On Wed, 29 May 2024 at 11:48, Lorenzo wrote:
>
> Hi,
>
> socklog-run is a syslog daemon, it has no dependency on
> system-log-daemon
Yes the initial list had some false positives, it has been pruned when
filing and socklog-run is not part of it:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users
On Wed, 29 May 2024 at 08:18, Marc Haber wrote:
>
> On Wed, 29 May 2024 00:44:29 +0200, Marco d'Itri wrote:
> >On May 28, Andreas Metzler wrote:
> >> I think it is bad choice to deliberately have different behavior for
> >> freshly installed and upgraded systems. Offering upgrades has always
> >
On Tue, 28 May 2024 at 08:43, Guillem Jover wrote:
>
> Hi!
>
> On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote:
> > 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
On Tue, 28 May 2024 at 02:57, Simon Richter wrote:
>
> 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
On Sun, 5 May 2024 at 21:04, Luca Boccassi wrote:
>
> On Tue, 5 Jul 2022 19:42:37 +0200 Michael Biebl
> wrote:
> >
> > Hi Eric
> >
> > On Fri, 31 Jul 2020 15:12:48 + Eric Desrochers
> > wrote:
> > > Package: systemd
> > > Version: 2
On Mon, 27 May 2024 at 17:04, Russ Allbery wrote:
>
> Simon McVittie writes:
>
> > I know fail2ban and logcheck do read plain-text logs (although as
> > mentioned, fail2ban already has native Journal-reading support too), and
> > I would guess that fwlogwatch, snort and xwatch probably also read
On Mon, 27 May 2024 at 15:09, Simon McVittie wrote:
>
> On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote:
> > Yes this sounds reasonable - do you already have an idea about which
> > is which, from the list above?
>
> Nothing reliable, so please check before
On Mon, 27 May 2024 at 13:59, Simon McVittie wrote:
>
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> > The list of affected packages according to apt-cache showpkg is not
> > that long either:
> >
> > anacron
> > approx
> >
On Mon, 27 May 2024 at 13:41, Simon McVittie wrote:
>
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> > In Bookworm we enabled persistent journald by default, which was the
> > right choice. The problem is that some packages declare a dependency on
> > th
On Mon, 27 May 2024 at 13:38, Simon Richter wrote:
>
> 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 dependenci
On Mon, 27 May 2024 at 12:53, Ansgar 🙀 wrote:
>
> Hi,
>
> On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote:
> > TL;DR: drop or downgrade dependency on system-log-daemon from any
> > package that declares it
>
> +1. Log service freedom is important. Packages s
On Mon, 27 May 2024 at 06:00, Simon Richter wrote:
>
> 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
> &g
tils-inetd
inetutils-talkd
inetutils-telnetd
ldirectord
logcheck
lyskom-server
prelude-lml
psad
request-tracker4
request-tracker5
rlinetd
snort
socklog-run
socklog-run:i386
spamd
sympa
xinetd
xwatch
zoneminder
--
Kind regards,
Luca Boccassi
signature.asc
Description:
On Thu, 23 May 2024 at 03:01, Simon Richter wrote:
>
> 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
On Wed, 22 May 2024 at 12:35, Bill Allombert wrote:
>
> On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > >
> > > When a change leads to a RC bug a month or three after having be
> > > part of a package, fixing the probl
On Wed, 22 May 2024 at 00:40, Russ Allbery wrote:
>
> Salvo Tomaselli writes:
>
> > If the debian/ directory is on salsa, but the rest of the project is
> > somewhere else, then this no longer works, I have to tag in 2 different
> > places, I have 2 different repositories to push to and so on.
>
On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > The Debian archive itself is a VCS, so git-maintained packaging is also
> > > > a
> > > > duplicatio
On Tue, 21 May 2024 at 03:16, Simon Richter wrote:
>
> 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. [...]
>
&
On Tue, 21 May 2024 at 02:08, Simon Richter wrote:
>
> 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 ecosy
On Sun, 19 May 2024 at 23:30, Thomas Goirand wrote:
>
> On 5/19/24 17:30, r...@neoquasar.org wrote:
> > I have an N270 system I can use to contribute, if someone is willing to
> > explain what I need to do to make it useful.
>
> Hi,
>
> If you allow me ... I was expecting someone else to write it
something to do
> with
> X/gdm/gnome?
>
> /tmp/.X0-lock
> /tmp/.X1024-lock
> /tmp/.X1025-lock
>
> /tmp/.X11-unix
> /tmp/.X1-lock
>
> /tmp/.XIM-unix
>
> /tmp/.font-unix
>
> /tmp/.ICE-unix
These are all already covered by /usr/lib/tmpfiles.d/x11.conf
On Tue, 7 May 2024 at 17:33, Sam Hartman wrote:
>
> >>>>> "Luca" == Luca Boccassi writes:
>
> Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
> Luca> wrote:
> >>
> >> Luca Boccassi writes:
> >>
&
On Tue, 7 May 2024 at 22:57, Russ Allbery wrote:
>
> Richard Lewis writes:
> > Luca Boccassi writes:
>
> >> what would break where, and how to fix it?
>
> > Another one for you to investigate: I believe apt source and 'apt-get
> > source'
On Tue, 7 May 2024 at 15:53, Sam Hartman wrote:
>
> > "Johannes" == Johannes Schauer Marin Rodrigues
> > writes:
> >> > > If [files can be deleted automatically while mmdebstrap is using
> them],
> >> > > how should applications guard against that from
> >> > > happening?
>
On Mon, 6 May 2024 at 23:03, Richard Lewis
wrote:
>
> Luca Boccassi writes:
>
> > Hence, I am not really looking for philosophical discussions or lists
> > of personal preferences or hypotheticals, but for facts: what would
> > break where, and how to fix it?
>
&
On Mon, 6 May 2024 at 23:00, Johannes Schauer Marin Rodrigues
wrote:
>
> Quoting Luca Boccassi (2024-05-06 23:28:59)
> > On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
> > >
> > > On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues
> &g
On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
>
> On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> > If [files can be deleted automatically while mmdebstrap is using them],
> > how should applications guard against that from
> > happening?
>
> As documented in
On Mon, 6 May 2024 at 21:08, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-05-06 15:20:08)
> > While personal anecdotes and stories can be interesting and amusing in many
> > circumstances, I am not really looking for those at this ve
On Mon, 6 May 2024 at 21:30, Salvo Tomaselli wrote:
>
> On a fresh installed fedora system I downloaded a .iso in /tmp, then the
> OOMkiller killed wayland, so everything died.
>
> If you know you won't ever fill it up, I guess it's fine. But I'd go for the
> safer (and sadly slower) option.
You
On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter wrote:
>
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
>
> It's a question of what the *default* behaviour should be.
No, it is not, at least not for the strawman you conjured. So I gather
that git doesn't warn when clon
On Mon, 6 May 2024 at 16:42, Simon Richter wrote:
>
> 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
On Mon, 6 May 2024 at 16:30, Simon Richter wrote:
>
> 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
On Mon, 6 May 2024 at 15:42, Richard Lewis
wrote:
>
> Luca Boccassi writes:
>
> > Hence, I am not really looking for philosophical discussions or lists
> > of personal preferences or hypotheticals, but for facts: what would
> > break where, and how to fix it?
>
>
On Mon, 6 May 2024 at 16:03, Barak A. Pearlmutter wrote:
>
> If it clones into /tmp the *entire* tree will either be reaped (upon
> reboot) or not.
>
> But having just some files deleted from a git dir or git working dir
> is much more dangerous, because various git commands can treat files
> dele
On Mon, 6 May 2024 at 15:31, Barak A. Pearlmutter wrote:
>
> > What I am looking for right now is packages or internal
> > infrastructure that need
> > an update to cope with these two changes before I upload them, so if
> > you know of any please do let me know and I'll happily look into it
> > a
On Mon, 6 May 2024 at 13:42, Barak A. Pearlmutter wrote:
>
> > Then upon reading the release notes, on such a machine, one can simply do:
> >
> > touch /etc/tmpfiles.d/tmp.conf
> >
> > And they get no automated cleanups.
>
> This also disables on-boot cleaning of /tmp/.
Yes, as it's going to be a
On Mon, 6 May 2024 at 12:15, Michael Biebl wrote:
>
> Am 06.05.24 um 12:35 schrieb Simon Richter:
> > 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
On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter wrote:
>
> > We have two separate issues here:
>
> > a/ /tmp-on-tmpfs
> > b/ time based clean-up of /tmp and /var/tmp
>
> > I think it makes sense to discuss/handle those separately.
>
> Agreed.
>
> I also don't see any issue with a/, at worst peop
On Mon, 6 May 2024 at 11:48, Michael Biebl wrote:
>
> Am 06.05.24 um 12:18 schrieb Luca Boccassi:
> > Defaults are defaults, they are trivially and fully overridable where
> > needed if needed. Especially container and VM managers these days can
> > super trivially overrid
On Mon, 6 May 2024 at 09:40, Michael Biebl wrote:
>
> We have two separate issues here:
>
> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp
>
> I think it makes sense to discuss/handle those separately.
>
> Regarding a/:
> tmp.mount as shipped by systemd uses the following mount opt
On Mon, 6 May 2024 at 06:36, Paul Gevers wrote:
>
> Hi Luca,
>
> On 05-05-2024 10:04 p.m., Luca Boccassi wrote:
>
> > Hence, I intend to apply these changes in the next src:systemd upload
> > to unstable, probably next week.
>
> > In case anybody is aware of
On Sun, 5 May 2024 at 22:22, Salvo Tomaselli wrote:
>
> > In case anybody is aware of packages/programs needing an update to cope
> > with these changes, or any other issue, please let me know and I will
> > file bugs.
>
> in localslackirc@.service
>
> ReadWritePaths=/var/tmp
>
> It uses /var/tmp
ns to override for anybody
wanting to keep the old behaviour, which is as trivial as:
systemctl mask tmp.mount (or touch /etc/systemd/system/tmp.mount)
touch /etc/tmpfiles.d/tmp.conf
for the former and the latter respectively.
In case anybody is aware of packages/programs needing an update to cope
On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler wrote:
>
> Fellow Developers,
>
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten Kuk
On Sat, 13 Apr 2024 at 10:11, Salvo Tomaselli wrote:
>
> > New contributors won't start in a vacuum, most will start contributing
> > first to existing projects on Salsa
>
> Or maybe they start with an ITP+RFS… was that an informed statement or a
> supposition?
It is my experience in receiving pa
On Fri, 12 Apr 2024 at 17:17, Simon Richter wrote:
>
> 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.
>
On Mon, 8 Apr 2024 at 23:23, Joerg Jaspert wrote:
>
> On 17194 March 1977, Luca Boccassi wrote:
> >> Simple packages need someone who is responsible and responsive for
> >> them
> >> in the long run and know there history much more than needing
> >> sp
On Mon, 8 Apr 2024 at 22:49, Bill Allombert wrote:
>
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining simp
On Fri, 5 Apr 2024 at 16:18, Colin Watson wrote:
>
> On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote:
> > I find that having the upstream source code in git (in the same form that
> > we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> > but excluding any fi
On Sat, 30 Mar 2024 at 15:44, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > In the end, massaged tarballs were needed to avoid rerunning autoconfery
> > on twelve thousands different proprietary and non-proprietary Unix
> > variants, back in the day. In 2024, we
On Sun, 31 Mar 2024 at 08:39, Bastian Blank wrote:
>
> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > > As others have said, the best solution is to relay on HSW for handling
> > > the cryptographi
On Sat, 30 Mar 2024 at 06:29, Russ Allbery wrote:
>
> Antonio Russo writes:
>
> > The way I see it, there are two options in handling a buildable package:
>
> > 1. That file would have been considered a build artifact, consequently
> > removed and then regenerated. No backdoor.
>
> > 2. The file
On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote:
>
> On 2024-03-30 08:02:04, Gioele Barabucci wrote:
> > Now it is time to take a step forward:
> >
> > 1. new upstream release;
> > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > 3. the buildd is notified of the new release;
>
On Thu, 25 Jan 2024 at 18:22, Gard Spreemann wrote:
>
> Hello.
>
> Paul Wise writes:
>
> > On Thu, 2024-01-25 at 00:24 +, Wookey wrote:
> >
> >> People keep telling us (@ARM) how marvellous Rust is, and we keep
> >> telling them that it's useless in the real world until it sorts out
> >> the
On Thu, 25 Jan 2024 at 16:11, Russ Allbery wrote:
>
> Simon Josefsson writes:
>
> > I want to explore if there is a possibility to change status quo, and
> > what would be required to do so.
>
> > Given how often gnulib is vendored for C code in Debian, and other
> > similar examples, I don't thi
On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>
> Luca Boccassi writes:
>
> >> Having reflected a bit, and learned through my own experience and
> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
> >> to update my p
On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-01-24 12:59:38)
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distribution
On Wed, 24 Jan 2024 at 11:42, Simon Josefsson wrote:
>
> Simon Josefsson writes:
>
> >> > My naive approach on how to fix a security problem in package X
> >> > which is
> >> > statically embedded into other packages A, B, C, ... would be to
> >> > rebuild
> >> > the transitive closure of all pac
On Fri, 19 Jan 2024 at 18:41, Sam Hartman wrote:
>
>
> There are a number of changes, and I'd just like a bit more confidence
> that it works as expected before uploading to unstable in about a week.
>
> Changes include:
>
> * Running pam_umask with usergroups support by default.
>
> * libpam-modu
On Thu, 28 Dec 2023 at 03:01, Simon Richter wrote:
>
> 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
> >
On Sun, 24 Dec 2023 at 22:48, Stephan Seitz wrote:
>
> Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci:
> >After the installation there would be no /usr/bin/gpg. Once the user
> >installs, say, ggp-is-gnupg then /usr/bin/gpg will point to
> >/usr/bin/gpg-gnupg. Users (and scripts) a
On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci wrote:
>
> On 22/12/23 00:40, Daniel Kahn Gillmor wrote:
> > If you're asking about using /etc/alternatives or something like that to
> > provide some sort of generic swapping capability, or a dpkg Provides:,
> > such that /usr/bin/gpg on some systems
On Tue, 14 Nov 2023 at 10:13, Helmut Grohne wrote:
> So in essence, you asked for changing the pidof implementation and
> Andreas and me try to turn this into a much bigger quest of making it
> non-essential. While these matters are related, they can be done
> independently in principle and if you
On Fri, 10 Nov 2023 at 14:22, Pierre-Elliott Bécue wrote:
>
> Luca Boccassi wrote on 10/11/2023 at 15:00:24+0100:
>
> > On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
> >>
> >> Luca Boccassi writes:
> >>
> >> > If we want to
On Fri, 10 Nov 2023 at 13:48, Michael Stone wrote:
>
> On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
> >Per-architecture dependencies are possible though, so maybe starting
> >to add the libssl dependency only on amd64 is a good starting point,
> >
On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
>
> Luca Boccassi writes:
>
> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> > Whether that qualifies as "plenty" we'll leave as an exercise for the
> > readers.
>
>
On Fri, 10 Nov 2023 at 11:54, Matthew Vernon wrote:
>
> Luca Boccassi writes:
>
> > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> >> What would you think about having coreutils Depend on libssl3? This
> >> would make the libssl3 pac
On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote:
>
> 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
On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> Dear Debian folks,
>
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires GPL-3+ and
> Ope
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-sdbus
Version : 0.11.1
Upstream Author : various
* URL : https://github.com/python-sdbus/python-sdbus
* License : LGPL-2.1-or-later
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pkcs11-provider
Version : 0.2
Upstream Contact: Red Hat
* URL : https://github.com/latchset/pkcs11-provider
* License : Apache-2.0
Programming
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : python-varlink
Version : 31.0.0
Upstream Author : various
* URL : https://github.com/varlink/python
* License
1 - 100 of 294 matches
Mail list logo
