Am 13.05.24 um 11:42 schrieb Johannes Schauer Marin Rodrigues:
If we want to try and weigh cost against benefit, do the benefits really
outweigh the cost? How costly is it to carry a patch in Debian and deviate from
upstream versus all the problems that participants of this thread now listed?
My
Unless somebody's already put it there, I'm going to move these
suggestions to a wishlist bug against systemd. Not sure if it should
be one bug or a few, one for each suggestion.
Currently discussion about reaping /var/tmp/ is in
https://bugs.debian.org/966621 and
Hi,
Quoting Barak A. Pearlmutter (2024-05-13 10:47:43)
> > I'd like to hear some arguments *in favour* of making this change.
> > Alignment with systemd-upstream, reduced package maintenance burden
> > are two that I can think of, but perhaps I've missed more. These two,
> > IMHO, are
> I'd like to hear some arguments *in favour* of making this change.
> Alignment with systemd-upstream, reduced package maintenance burden
> are two that I can think of, but perhaps I've missed more. These two,
> IMHO, are significantly outweighed by the risks.
Let me see if I understand the
Hi Nilesh,
On 2024-05-10 21:04, Nilesh Patra wrote:
On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote:
Do you mean bugs on bugs.d.o, or are there other issues?
As you may have seen in the other emails, there are performance issues. Other
than that, there are 2 open RC bugs right
hat this opens things up for bugs
could be fixed by having common code in a debhelper script that
re-generates all of the autoconf and related files. This address your
"tedious" and "fragile" argument.
And if you are always regenerating those files, you don't need to
audit the c
Ansgar writes:
> In ecosystems like NPM, Cargo, Golang, Python and so on pinning to
> specific versions is also "explicitly intended to be used"; they just
> sometimes don't include convenience copies directly as they have tooling
> to download these (which is not allowed in Debian).
Yeah,
Hi,
On Sun, 2024-05-12 at 08:41 -0700, Russ Allbery wrote:
> "Theodore Ts'o" writes:
> > And yet, we seem to have given a pass for gnulib, probably because it
> > would be too awkward to enforce that rule *everywhere*, so apparently
> > we've turned a blind eye.
>
> No, there's an explicit
"Theodore Ts'o" writes:
> The best solution to this is to try to promote people to put those
> autoconf macros that they are manually maintaining that can't be
> supplied in acinclude.m4, which is now included by default by autoconf
> in addition to aclocal.m4.
Or use a subdirectory named
arballs that are
free from vendored or pre-generated files. That's the case for most
upstream tarballs in Debian today (including e2fsprogs, openssh,
coreutils). Without filtering that tarball we won't fulfil the goals I
mentioned in the beginning of my post. The downsides with not filtering
i
On Sat, May 11, 2024 at 04:09:23PM +0200, Simon Josefsson wrote:
>The current approach of running autoreconf -fi is based on a
>misunderstanding: autoreconf -fi is documented to not replace certain
>files with newer versions:
>
On 5/11/24 8:47 PM, John Paul Adrian Glaubitz wrote:
export PYTHONPATH = $(CURDIR)
Try setting it to the build_dir path:
PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1
On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote:
I would assume that (some stripped down
version of) git is a requirement to do any useful work on any platform
these days, so maybe it isn't a problem
Yes, my impression also is that Git has migrated into the realm of
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
> * 'cargo fetch' for Rust
Simon Josefsson wrote:
> Finally, while this is somewhat gnulib specific, I think the practice
> goes beyond gnulib
Yes, gnulib-tool for modules written in C is similar to
* 'npm install' for JavaScript source code packages [1],
* 'cargo fetch' for Rust source code packages [2],
except that
Am Samstag, 11. Mai 2024, 10:21:55 CEST schrieb Aditya Garg:
> Hello
>
> I wanted to create a custom ISO of Debian, with the following
> customisations:
>
> 1. I want to add a custom kernel that supports my Hardware.
> 2. I want to add my own Apt repo which hosts various software packages to
>
On 5/11/24 16:21, Aditya Garg wrote:
Hello
I wanted to create a custom ISO of Debian, with the following customisations:
1. I want to add a custom kernel that supports my Hardware.
2. I want to add my own Apt repo which hosts various software packages to
support my hardware.
I am not able to
* Aditya Garg [240511 05:15]:
> Hello
>
> I wanted to create a custom ISO of Debian, with the following customisations:
>
> 1. I want to add a custom kernel that supports my Hardware.
> 2. I want to add my own Apt repo which hosts various software packages to
> support my hardware.
>
> I am
Le Mon, May 06, 2024 at 11:15:35AM +0100, Barak A. Pearlmutter a écrit :
> > We have two separate issues here:
>
> > a/ /tmp-on-tmpfs
Note that /tmp-on-tmpfs and cleanup-tmp-at-boot are not equivalent.
With cleanup-tmp-at-boot, if your system crashes, you can still backup
/tmp before
Le Fri, May 10, 2024 at 10:47:29PM +0500, Andrey Rakhmatullin a écrit :
> - The most paradoxical thing is the recently "discovered" combination of
> "old lintian falsely reports a problem in certain packages", "lintian
> runs as a part of the package acceptance process and some problems are
>
On 10.05.2024 14:53, Bill Allombert wrote:
Le Mon, May 06, 2024 at 11:09:14PM +0200, Preuße, Hilmar a écrit :
Hi Bill,
thanks for the answer!
during the preparation of a new version of package "nq" (via NMU) it was
found that there exists a file conflict with package "fq" (#1005961), which
Niels,
On Friday, May 10, 2024 3:18:29 AM MST Niels Thykier wrote:
> Soren Stoutner:
> > I would like to respectfully disagree will some of the opinions expressed
in
> > this email.
> Hi Soren
>
> Not sure if we disagree all that much to be honest. :)
Yes, I think we do agree.
From a
Hi Andrius,
On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote:
> Do you mean bugs on bugs.d.o, or are there other issues?
As you may have seen in the other emails, there are performance issues. Other
than that, there are 2 open RC bugs right now (fixed in salsa but not uploaded
I
My 1.83 RUB:
lintian is one of those things that are very important and useful when you
know how to use them, which quirks to apply and which parts to ignore, and
without that knowledge are maybe useful, maybe useless, maybe harmful, and
nobody will tell you that knowledge unless you ask
Hello,
On 2024-05-10 17:35, Nilesh Patra wrote:
On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote:
Lintian is important for me. For the past few months, I have been reviewing and
merging MRs and pushing small fixes of my own. I am not a proficient perl
programmer and hence I am not
On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote:
> > If lintian is important to you, I strongly recommend that you do put *some*
> > of your volunteer time into it.
>
> +1
> for Soren and everybody else reading this.
Lintian is important for me. For the past few months, I have been
Hi,
I am currently working on this package [0].
I would need a sponsor to review and upload the package.
Thanks
Manuel
[0] https://salsa.debian.org/manut/cozy
ould start. You mentioned `debputy` and I admit I
need to check this out in the near future. If I imagine some policy
checking debhelper-like tool that is fired up after dh_clean step I'd
be all for it and it really could save some time.
However, I'd consider it unfair against lintian to blame it ab
Le Mon, May 06, 2024 at 11:09:14PM +0200, Preuße, Hilmar a écrit :
> Hi all,
>
> during the preparation of a new version of package "nq" (via NMU) it was
> found that there exists a file conflict with package "fq" (#1005961), which
> was incorrectly solved in the past. For now I unarchived and
Le Wed, May 08, 2024 at 08:41:47PM +0200, Paul Gevers a écrit :
> Hi,
>
> On 08-05-2024 6:06 p.m., Bill Allombert wrote:
> > Agreed, but gap does not actually breaks anything, it is just the tests
> > in testing that are broken. So I can do that but that seems a bit
> > artificial.
>
> Aha,
Soren Stoutner:
I would like to respectfully disagree will some of the opinions expressed in
this email.
Hi Soren
Not sure if we disagree all that much to be honest. :)
First, I should say that I am painfully aware of how long it takes to run
lintian on large
packages. When working on
Hi
On 2024-05-10 08:29:28 +0300, Andrius Merkys wrote:
> I care for tree packages which still have open "NMU diff for 64-bit time_t
> transition" bugs: libccp4, macromoleculebuilder and rdkit. All of them have
> NMU diffs applied in experimental, but not in unstable yet. What should I do
> about
I also think that Lintian is one of the most important tools in Debian
packaging ecosystem. I'm not a Debian Developer, but have built packages
for our Debian derivative distribution (Pardus, which I tech-led it for
some time). The first step was to get the package "Lintian-clean (TM)"
before
On Thu, 09 May 2024 13:57:28 -0700, Soren Stoutner
wrote:
>However, I personally find lintian to be one of the most helpful tools in
>Debian packaging.
+1.
The fact that it doesn perform well on large packages is bad, but that
doesnt make it less useful for smaller packages.
Greetings
Marc
On 09/05/24 at 13:57 -0700, Soren Stoutner wrote:
> First, I should say that I am painfully aware of how long it takes to run
> lintian on large
> packages. When working on qtwebengine-opensource-src it takes my system
> (Ryzen 7
> 5700G) about 2 hours to build the package and about half an
I would like to respectfully disagree will some of the opinions expressed in
this email.
First, I should say that I am painfully aware of how long it takes to run
lintian on large
packages. When working on qtwebengine-opensource-src it takes my system (Ryzen
7
5700G) about 2 hours to build
Hi,
this mail is a private response from Niels to my mail to the Debian Perl
team where I explicitly asked for people helping out with lintian. So
far the answer from Niels is the only response. Since he gave explicit
permission to quote him in public I'm doing so hereby. Niels assumed
that
Hi Charles,
* Charles Plessy [2024-05-08 07:27]:
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 sbuild, as
Le mar. 7 mai 2024, 20:18, a écrit :
> Even after a reboot, I would be upset to lose the debug files that I've
> been accumulating for several days while trying to track down an
> intermittent problem with this stupid VPN...
>
At reboot, /tmp isautomatically flushed. It's the default behaviour
Le Wed, May 08, 2024 at 08:02:41AM -0700, Otto Kekäläinen a écrit :
>
> I read the docs on how Singularity is able to pull Docker images of Debian
> Sid and build on top of them, and run and exec just like Docker/Podman.
> Unfortunately it has its own Containerfile format (
>
Hi,
On 08-05-2024 6:06 p.m., Bill Allombert wrote:
Agreed, but gap does not actually breaks anything, it is just the tests
in testing that are broken. So I can do that but that seems a bit artificial.
Aha, that wasn't at all clear to me. If you don't want to do the
artificial thing (which is
"Jonathan Dowland" writes:
> Else-thread, Russ begs people to stop doing this. I agree people
> shouldn't! We should also work on education and promotion of the
> alternatives.
Also, helping people use better tools for managing workloads like this
that make their lives easier and have better
On Wed, May 08, 2024 at 03:21:12PM +, Graham Inggs wrote:
> Hi Bill
>
> On Wed, 8 May 2024 at 13:58, Bill Allombert wrote:
> > The problem is that all the debs in testing and sid are correct, it is the
> > autopkgtest in
> > testing which are wrong (they are relying on undocumented
On Mon May 6, 2024 at 5:01 PM BST, Luca Boccassi wrote:
> On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter
> wrote:
> > For whatever reason, a lot of people who process large data use
> > /var/tmp/FOO/ as a place to store information that should not be
> > backed up, but also should not just
Hi Bill
On Wed, 8 May 2024 at 13:58, Bill Allombert wrote:
> The problem is that all the debs in testing and sid are correct, it is the
> autopkgtest in
> testing which are wrong (they are relying on undocumented behaviour).
> They are fixed in sid.
I think an upload of gap, with Breaks on the
Hi!
ti 7. toukok. 2024 klo 23.01 Charles Plessy kirjoitti:
> 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
> >
Le Sat, May 04, 2024 at 02:32:22PM +0200, Paul Gevers a écrit :
> Hi,
>
> On 04-05-2024 11:39 a.m., Jerome BENOIT wrote:
> > What would be the best way to unblock the migration of gap and gap-io ?
>
> If gap isn't going to change (which might be the easiest solution), then
> file bugs and fix
On Wed, 8 May 2024 at 09:21:35 +1000, Craig Small wrote:
> I can only speak for w. It currently prefers what it gets from
systemd or
> elogind, effectively
> iterating over the sessions coming from sd_get_sessions() if sd_booted()
> returns true.
>
> If sd_booted() returns false, then it
Hi,
On 2024-05-07 09:43, Russ Allbery wrote:
> I understand your point, which is that this pattern is out there in the
> wild and Debian is in danger of breaking existing usage patterns by
> matching the defaults of other distributions. This is a valid point, and
> I appreciate you making it.
On Tue, 07 May 2024 22:29:30 +0100, Richard Lewis
wrote:
>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"
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
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
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
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
>
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
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
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
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
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
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,
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
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
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
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_,
> > >
> > >
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
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,
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
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
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
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
the debug files that I've been
accumulating for several days while trying to track down an intermittent
problem with this stupid VPN...
Sent from my mobile device.
From: Holger Levsen
Sent: Tuesday, May 7, 2024 10:22
To: debian-devel@lists.debian.org
Subject: Re: Make
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
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
> "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
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
> 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,
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
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
>
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).
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?
>
> "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
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
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
> ...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
> 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
Boccassi; Peter Pentchev
Subject: 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
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,
nt from my mobile device.
From: Alexandru Mihail
Sent: Tuesday, May 7, 2024 07:59
To: debian-devel@lists.debian.org
Subject: 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]
May
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
obile device.
From: "Barak A. Pearlmutter"
Sent: Tuesday, May 7, 2024 07:18
To: r...@neoquasar.org
Cc: Luca Boccassi; debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d no
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
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
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
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
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.
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
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
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
.
From: Luca Boccassi
Sent: Monday, May 6, 2024 08:20
To: Barak A. Pearlmutter
Cc: debian-devel@lists.debian.org
Subject: 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 Mon, 6
Luca Boccassi writes:
> Richard Lewis wrote:
>> - tmux stores sockets in /tmp/tmux-$UID
>> - I think screen might use /tmp/screens
>> I suppose if you detached for a long time you might find yourself
>> unable to reattach.
>> I think you can change the location of these.
> And those are
1 - 100 of 172674 matches
Mail list logo
