Re: Tool to build Debian packages not requiring root in containers ?

Le Tue, May 07, 2024 at 08:17:31PM -0700, Otto Kekäläinen a écrit : > > Can you give me an example of a package you want to build and what is > the starting point, and I can tell you what command to issue to > https://salsa.debian.org/otto/debcraft to achieve it? > > It supports running Podman in

Re: Tool to build Debian packages not requiring root in containers ?

Hi! On Tue, 7 May 2024 at 15:27, Charles Plessy wrote: .. > I want to leverage our cluster to automate as much of the rebuilds as I > can, but could not find the right tool. I tried to run sbuild in a > Singularity image and this failed. However, I do not need the whole > power of engines like

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Simon Richter writes: > 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 ou

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

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: > >> > >> > Hence, I am not really looking for philosophical discussions or >

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

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

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

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' download and extract things into /tmp, as in the mmdeboot

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On Wed, 8 May 2024 at 09:03, Jun MO wrote: > 1) I hope there will still be the original > w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1) > tools which can still read *old* format utmp/wtmp/lastlog in Debian at > least for > a while after switch to Y2038-safe replacements. Those tools can read > I c

Re: Y2038-safe replacements for utmp/wtmp and lastlog

Dear Developers, A bit from a Debian user. Please note that I am not come to here to blame/complain against the Upstream/Maintainer of the pam package and the Maintainer of the shadow package, or come to here to request something. I just come to here to present some of my hope. I often use t

Tool to build Debian packages not requiring root in containers ?

Hello everybody, I just re-suscribed :) At work I have access to a nice cluster with plenty of nodes rich of 128 cores and 512 Gb RAM. The nodes do not run Debian but Singularity is available for virtualisation (https://en.wikipedia.org/wiki/Singularity_(software)). And in Debian I am part of

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Richard Lewis writes: > btw, i'm not trying to argue against the change, but i dont yet > understand the rationale (which id like to be put into the > release-notes): is there perhaps something more compelling than "other > distributions and upstream already do this"? It sounds like that is what

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Am 07.05.2024 22:56 schrieb Richard Lewis :Luca Boccassi writes: > qwhat would > break where, and how to fix it? Another one for you to investigate: I believe apt source and 'apt-get source' download and extract things into /tmp, as in the mmdebootstap example mentioned by someone else, t

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

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' download and extract things into /tmp, as in the mmdebootstap > example mentioned by someone else, this will create "old"

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Holger Levsen writes: > I'm a bit surprised how many people seem to really rely on data in /tmp > to survive for weeks or even months. I wonder if they backup /tmp? I use /tmp for things that fall somewhere between "needs a backup" and "unimportant, can be deleted whenever". I think all of the i

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Luca Boccassi writes: > qwhat would > break where, and how to fix it? Another one for you to investigate: I believe apt source and 'apt-get source' download and extract things into /tmp, as in the mmdebootstap example mentioned by someone else, this will create "old" files that could immediately

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, May 07, 2024 at 09:49:17PM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Andrey Rakhmatullin (2024-05-06 19:14:40) > > On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote: > > > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_, > > > > > >

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Quoting Andrey Rakhmatullin (2024-05-06 19:14:40) > On Mon, May 06, 2024 at 04:50:50PM +0100, 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. > > > > For whatever reason, a lo

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hi, Quoting Holger Levsen (2024-05-07 17:22:48) > On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote: > > Consider a long running task, which will take days or weeks (which is the > > norm in simulation and science domains in general). System emitted a warning > > after three days, tha

Bug#1070719: ITP: ppa-dev-tools -- command line client for managing PPAs in Launchpad

Package: wnpp Severity: wishlist Owner: Benjamin Drung X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org * Package name: ppa-dev-tools Version : 0.5.0 Upstream Contact: Bryce Harrington * URL : https://launchpad.net/ppa-dev-tools * License : GPL

Re: how to upgrade testing

On Tue, 7 May 2024 20:54:39 +0200 Jérémy Lal wrote: Hello Jérémy, >could we have a hint when it's "safe" to upgrade testing ? I'm not Debian developer, so do what you will with what I say; I've been upgrading testing daily for a couple of weeks. Due, in part, to cut the amount of packages upd

Bug#1070718: ITP: python-gfloat -- Python module of generic floating point encode/decode logic

Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-gfloat Version : 0.1 Upstream Contact: Andrew Fitzgibbon * URL : https://github.com/graphcore-research/gfloat * License : Expat Program

Re: how to upgrade testing

On Tue, May 07, 2024 at 08:54:39PM +0200, Jérémy Lal wrote: > could we have a hint when it's "safe" to upgrade testing ? It was always safe... > Currently I get for a full-upgrade: > 2338 mis à jour, 362 nouvellement installés, 715 à enlever et 41 non mis à > jour. alias e='LC_ALL=C' e apt full-up

how to upgrade testing

Hi, could we have a hint when it's "safe" to upgrade testing ? Currently I get for a full-upgrade: 2338 mis à jour, 362 nouvellement installés, 715 à enlever et 41 non mis à jour. Thanks ! Jérémy

Re: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

I guess sometimes when people discuss technical matters, good ideas pop up. (Although I still think that its problematic interactions with lengthy suspends makes the whole idea of auto-deletion based purely on timestamps problematic. I can imagine more coherent mechanisms, which doesn't count time

Re: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Barak A. Pearlmutter wrote: > You know, that's a pretty good idea! > > Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the > default deletion policy, the policy in place if it's not the default, > and a pointer to info about altering it. "/tmp's contents are deleted > at boot whi

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

It is not "abuse of /tmp" to put files there, even if they need to be there for a long time. That is an unnecessary characterization.  Yes, /tmp gets backed up along with the rest of the system on every VM in my environment.  Sometimes "temporary" CAN mean "weeks or even months." That's not som

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Early in this meta-thread it was suggested to separate /tmp-is-tmpfs from cleanup-of-{,/var}/tmp. I am really surprised that nobody has suggested the obvious separation of new installs from upgrades. Changing the local configuration for either feature is trivial either way. I think the proposed

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hakan Bayındır writes: > The applications users use create these temporary files without users' > knowledge. They work in their own directories, but applications create > another job dependent state files in both /tmp and /var/tmp. These are > different programs and I assure you they’re not creat

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> "Luca" == Luca Boccassi writes: Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis Luca> wrote: >> >> Luca Boccassi writes: >> >> > Hence, I am not really looking for philosophical discussions or >> lists > of personal preferences or hypotheticals, but for fact

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Sent from my iPhone > On 7 May 2024, at 18:39, Holger Levsen wrote: > > On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote: >> Consider a long running task, which will take days or weeks (which is the >> norm in simulation and science domains in general). System emitted a warning

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> On 7 May 2024, at 18:57, Russ Allbery wrote: > > Hakan Bayındır writes: >> Dear Russ, > >>> If you are running a long-running task that produces data that you >>> care about, make a directory for it to use, whether in your home >>> directory, /opt, /srv, whatever. > >> Sorry but, cluster

Bug#1070709: ITP: primtux-multiples -- graphic representation of multiplications as grid patterns

Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: primtux-multiples Version : 3.0 Upstream Contact: Arnaud Champollion * URL : https://forge.apps.education.fr/educa

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hakan Bayındır writes: > Dear Russ, >> If you are running a long-running task that produces data that you >> care about, make a directory for it to use, whether in your home >> directory, /opt, /srv, whatever. > Sorry but, clusters, batch systems and other automated systems doesn't > work that w

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote: > Consider a long running task, which will take days or weeks (which is the > norm in simulation and science domains in general). System emitted a warning > after three days, that it'll delete my files in three days. My job won't be >

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Dear Russ, It's not *me* using /var/tmp for my own temporary files, it's the applications other people use. I just logged in one of the nodes we have and there were job-dependent files created by a particular, high end scientific application (which is developed by another prominent company).

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

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? >

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> "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? >> > >> > As documented in tmpfiles.d(5), if mmdebstrap takes ou

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote: > On the other hand, if we need to change the configuration 99% of the time, [citation needed] -- WBR, wRAR signature.asc Description: PGP signature

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hakan Bayındır writes: > Consider a long running task, which will take days or weeks (which is > the norm in simulation and science domains in general). System emitted a > warning after three days, that it'll delete my files in three days. My > job won't be finished, and I'll be losing three days

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> ...3) I would put a file in any auto-cleaned space named "1-AUTOCLEAN.txt" > that contains some verbage explaining that things in this directory will be > wiped based on rules set in (wherever). You know, that's a pretty good idea! Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly s

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> Consider a long running task, which will take days or weeks (which is > the norm in simulation and science domains in general). System > emitted a > warning after three days, that it'll delete my files in three days. > My > job won't be finished, and I'll be losing three days of work unless I

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

The /tmp/ as tmpfs discussion is funny to me because while we've been kicking around the idea of whether or not to clean /tmp/, having /tmp/ as a tmpfs makes that whole argument moot. It all goes away at boot time! Problem solved! :D Honestly, I see this one as a much easier topic, assuming that

Re: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Maybe putting the cleanup task for /var/tmp on a longer timer and warning users ahead of time of impending deletion (maybe 3 days before, 2 days, etc) would help with files of unsuspecting users getting deleted. A log entry could also be emitted. I could see a gentle warning on ssh login (minimal,

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

I'm always in favor of logging system changes.  Notification at run time is really tricky. No one ever logs into several of my Debian servers. Other systems have interactive GUI or CLI users, some of whom are admins and others not.  I don't know if login notices are terribly reliable as no one

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Consider a long running task, which will take days or weeks (which is the norm in simulation and science domains in general). System emitted a warning after three days, that it'll delete my files in three days. My job won't be finished, and I'll be losing three days of work unless I catch that

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Perhaps ones *intentions* are good, but when you're making decisions for someone else, it is often necessary to take a step back and look at the bigger picture of what one is doing.  I do not consider myself to be immune to the effects of this thought process. I have kids. They remind me consta

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Similarly, I’m following the thread for a couple of days now, and wondering about its implications. When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, 07 May 2024 at 07:34:54 -0500, r...@neoquasar.org wrote: > possibly convince those applications to use their own > scratch space such as /tmp// that is more easily identifiable This would be a denial of service at best, and a privilege escalation vulnerability at worst. To be safe, it woul

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Maybe putting the cleanup task for /var/tmp on a longer timer and warning users ahead of time of impending deletion (maybe 3 days before, 2 days, etc) would help with files of unsuspecting users getting deleted. A log entry could also be emitted. I could see a gentle warning on ssh login (minima

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

This, in my opinion, is the correct view.  If the users/admins of a system are putting files somewhere, those are their files and therefore their responsibility. It is not up to anyone else to claim they know better and clean up after them.  If the files are abandoned by applications that don't

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Rhys, I think you're being unfair. We have a *technical* disagreement here. But our hearts are all in the same place: Luca, myself, and all the other DDs discussing this, all want what's best for our users, we all want to build the best OS possible, and are all discussing the issue in good faith.

Bug#1070697: ITP: rtl-ais -- simple AIS tuner and generic dual-frequency FM demodulator

Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rtl-ais Version : 0.3+git20240507+ds Upstream Authors: dgiardini Kyle Keen Peter Schultz 2013 Astra Paging

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Luca Boccassi writes: > 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

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote: > Luca Boccassi writes: > > > Defaults are defaults, they are trivially and fully overridable where > > needed if needed. Especially container and VM managers these days can > > super trivially override them via SMBIOS Type11 stri

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Luca Boccassi writes: > Defaults are defaults, they are trivially and fully overridable where > needed if needed. Especially container and VM managers these days can > super trivially override them via SMBIOS Type11 strings or > Credentials, ephemerally and without changing the guest image at all