Hello.
My plan for base-files is to stop overriding the PATH in /etc/profile.
Ubuntu did that a long time ago and it's probably the right thing to do.
I'd like to do this for trixie, but only after the t64 transition is finished
and the usr-merge patch from Helmut Grohne is implemented.
Also,
On Wed, May 1, 2024 at 6:13 PM Alban Browaeys wrote:
> So you were right that reverting commit ccecd9c9 would fix your issue,
> but not because gdm added a bug but because it stopped hiding an
> underlying "bug" (well wrong default PATH value in systemd for Debian).
> It could be that systemd
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?
>
> - tmux stores sockets in
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?
>
> cleaning /tmp or /var/tmp: users
Processing control commands:
> tag -1 pending
Bug #1070499 [src:systemd] systemd: Please update Homepage
Added tag(s) pending.
--
1070499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070499
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Source: systemd
Version: 255.5-1
Severity: minor
debian/control:Homepage: https://www.freedesktop.org/wiki/Software/systemd
This page has been obsoleted and replaced. All the new contents are on the new
website: https://systemd.io/.
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 override them via SMBIOS Type11
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 override them via SMBIOS Type11 strings or
Credentials, ephemerally and without changing the
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
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 packages/programs needing an update
Am 05.05.24 um 22:04 schrieb Luca Boccassi:
This will be mentioned in NEWS (and I guess in the release notes when
the time comes), together with the instructions to override for anybody
wanting to keep the old behaviour, which is as trivial as:
..
touch /etc/tmpfiles.d/tmp.conf
This
Processing commands for cont...@bugs.debian.org:
> clone 966621 -1
Bug #966621 [systemd] systemd: tmpfiles.d not cleaning /var/tmp by default
Bug 966621 cloned as bug 1070482
> reassign -1 release-notes
Bug #1070482 [systemd] systemd: tmpfiles.d not cleaning /var/tmp by default
Bug reassigned
clone 966621 -1
reassign -1 release-notes
thanks
On Mon, May 06, 2024 at 10:40:00AM +0200, 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.
very much
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 options:
"mode=1777,strictatime,nosuid,nodev,size=50%"
In the past
Luca Boccassi writes:
> we should bring the
> defaults in line with upstream and other distributions
This is not an argument. Why can't "upstream and other distributions" be
in line with Debian? That would obviously be the sane thing for then to
strive for on most technical subjects.
Please
15 matches
Mail list logo