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 /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you
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 very moment. What I
> > am
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 tmpfiles.d(5), if mmdebstrap takes out an exclusive
flock(2)
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
Luca Boccassi writes:
> 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?
>>
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 very moment. What I
> am looking for right now is packages or internal infrastructure that need an
> update to
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 lot of people who process large data use
> /var/tmp/FOO/ as a
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
> 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 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
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" !=
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 in a dropdown, and /tmp is one
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
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
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
>
On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:
> >> I'm not sure if we have software on long running servers which place
> >> files in /tmp and /var/tmp and expect files to not be deleted during
> >> runtime, even if not accessed for a long time. This is certainly an
> >> issue to
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
deleted from the working tree as deliberate changes to be committed,
and
Andrey Rakhmatullin writes:
> On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
>> I'm not sure if we have software on long running servers which place
>> files in /tmp and /var/tmp and expect files to not be deleted during
>> runtime, even if not accessed for a long time. This is
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
> >
> 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
> and at least file a bug, if not a MR. Thanks.
Okay.
git and other
On Mon, 06 May 2024 at 13:41:58 +0100, Barak A. Pearlmutter wrote:
> As someone who regularly deals with large datasets, and keeps them in
> the "approved" don't-back-these-up location /var/tmp
Independent of whether we make the change Luca is suggesting or not,
I don't think /var/tmp is a good
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 may lose files if they dont realise a
directory tmp can be
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
> 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/.
The root issue here is that deleting not-read-in-a-while
* Michael Biebl [240506 07:15]:
> 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 explicitly
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
* Simon Richter [240506 06:51]:
> 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
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
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
On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
> I'm not sure if we have software on long running servers which place files
> in /tmp and /var/tmp and expect files to not be deleted during runtime, even
> if not accessed for a long time. This is certainly an issue to be aware of
>
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 explicitly configures tmpfs as a separate file
system, then that should be
On 26/04/2024 15:57, Jonathan Carter wrote:
Hi Debian Developers
In January, bcachefs[1] finally made it into the mainline Linux kernel as an
experimental filesystem in to Linux 6.7
In 2022 something odd happened and the versions releases were 23 and 24
(previously we had alpha versions in
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
Barak A. Pearlmutter, le lun. 06 mai 2024 11:15:35 +0100, a ecrit:
> To me, the purpose of /var/tmp/ when I have my "user" hat on is: a
> place to put files I don't want backed up, particularly large ones,
> and which if I run out of disk space is a place to look for stuff to
> delete. it's not "a
Am 06.05.24 um 12:15 schrieb Barak A. Pearlmutter:
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 people will be annoyed
with
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,
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
> 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 people will be annoyed
with it for some reason and can then change it back.
>
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
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
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 to cope
with these changes, or any other issue, please let me know
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
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: 245.7-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Debian systemd implementation does not clean
> > /var/tmp by
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 those reverse dependencies. Those bugs are RC and in
due time will cause
On Thu, May 02, 2024 at 10:37:57AM -0600, Trevor Howard wrote:
> How do I unsubscribe from these emails?
>
> On Wed, May 1, 2024 at 11:15 PM Andreas Tille wrote:
>
> > Hi,
> >
> > keeping my promise for monthly bits, here's a quick snapshot of my first
> > ten days as DPL.
> >
> > Special
How do I unsubscribe from these emails?
On Wed, May 1, 2024 at 11:15 PM Andreas Tille wrote:
> Hi,
>
> keeping my promise for monthly bits, here's a quick snapshot of my first
> ten days as DPL.
>
> Special thanks to Jonathan for an insightful introduction that left less
> room for questions.
Johannes Schauer Marin Rodrigues wrote...
> speaking of mirroring problematic debian.org services [1] by adding more
> copies
> of terabytes of data [2]: is there an update of the situation regarding
> snapshot.d.o? I do not see any activity in bugs like #1050815 and #1029744.
> And
> bug
On Sun, 2024-04-28 at 07:04 +0200, Johannes Schauer Marin Rodrigues wrote:
> speaking of mirroring problematic debian.org services [1] by adding more
> copies
> of terabytes of data [2]: is there an update of the situation regarding
> snapshot.d.o? I do not see any activity in bugs like #1050815
Hello,
On Thu 18 Apr 2024 at 09:44pm +02, Jonas Smedegaard wrote:
> I am unaware if I am alone in maintaining Haskell packages outside of
> the team giant-git-repo thingy.
I wouldn't maintain libraries outside of the monorepo but typically
programs are maintained outside of it.
I maintain
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already
On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote:
> > Can you please look at libproxy<->glib-networking? libproxy excuses show
> > glib-networking tests failing, but they are working in sid.
>
> And that's not missing a versioned Depends and/or Breaks? I.e. this is a
> test only
Hi,
On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote:
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid.
And that's not missing a versioned Depends and/or Breaks? I.e. this is a
test only failure?
Paul
Hi,
Quoting Adam D. Barratt (2024-04-28 01:09:28)
> > Seeing mirror functionality being uncertain, I have started to track
> > archive.debian.org as a Git-LFS repository on gitlab.com.
> Please don't. If there's a problem with debian.org services then we should
> fix that, not start adding more
On Sun, 2024-04-28 at 00:09 +0100, Adam D. Barratt wrote:
> [As a general note, the primary contact point for possible mirror
> issues is mirrors@d.o, not debian-devel]
>
> On Sat, 2024-04-27 at 12:16 +0200, Simon Josefsson wrote:
>
>
[...]
> > Further it seems mirrors are out of sync. I
[As a general note, the primary contact point for possible mirror
issues is mirrors@d.o, not debian-devel]
On Sat, 2024-04-27 at 12:16 +0200, Simon Josefsson wrote:
> it should be possible to reach archive.debian.org via rsync, however
> this fails for me. Is this intentional, or can this be
On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote:
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> >
On Sat, Apr 27, 2024 at 12:16:04PM +0200, Simon Josefsson wrote:
> Hi
>
> According to the mirror list
>
> https://www.debian.org/distrib/archive
>
> it should be possible to reach archive.debian.org via rsync, however
> this fails for me. Is this intentional, or can this be fixed?
>
Chris Hofstaedtler writes:
> 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 Kukuk and others have been working on replacements for
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
> "Chris" == Chris Hofstaedtler writes:
Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog
Hi,
On 24-04-2024 7:42 p.m., Jérémy Lal wrote:
Inform the Release Team and we can either schedule the combination
manually, add a hint or both.
Isn't it processed automatically ? What needs manual intervention and
what doesn't ?
Well, the migration software *tries* to figure out
Hi,
On 24-04-2024 7:38 p.m., Paul Gevers wrote:
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems
with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit :
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems
> with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> >
Hi,
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Release Team and we can either schedule the
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote:
> If you wonder how you are able to help with the migration, here are
> some things to do:
> * Fix FTBFS bugs
> * Check the status of autopkgtests [1] and report or fix any issues
> related to failing tests.
> * Check if
On Wed, Apr 24, 2024 at 9:42 AM Andreas Tille wrote:
> Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands:
> > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
> >
> > Might I suggest that the link goes the other way, so that the symlink
> > lives in /usr/bin? That way the
Hi,
Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands:
> >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin? That way the existence of the lib directory is
> somewhat self-documenting.
Hi,
dpkg and gcc with t64 enabled migrated to trixie last night. The other
packages will slowly migrate as we fix the remaining blockers
(autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary
removals from trixie may occur to get packages (especially key packages)
unstuck as we work
On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote:
> Hello Go and Rust packagers,
>
> On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote:
>
> > With the increasing amount of programs in Debian that Build-Depend and
> > statically link with Golang and Rust libraries, it's
On 22/4/24 21:29, Steve Langasek wrote:
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote:
I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting
^^^
BS. It just doesn't work like this. A regular citizen can't communicate
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote:
> I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting
> it crystal clear that it was a long time ago the lawsuit to Universitat
> Oberta de Catalunya and British Council had to be solved.
>
> "Kinda or
Am 21.04.2024 um 18:31 schrieb Mathias Gibbens:
Currently, Midnight Commander is packaged for Debian as `mc`. I am
looking at packaging the MinIO Client (needed for a future release of
Incus), which also unfortunately names its binary `mc`. MinIO upstream
has been pretty clear that they don't
* Simon McVittie [240422 05:02]:
> On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> > Philip Hands writes:
> > > Might I suggest that the link goes the other way, so that the symlink
> > > lives in /usr/bin? That way the existence of the lib directory is
> > > somewhat
On Sun Apr 21, 2024 at 5:37 PM BST, Marco d'Itri wrote:
> Go for it, I think that there is no good solution for this case.
> Everybody who cares then will manually create a mc -> mcli symlink.
Indeed, they will: so I would suggest that the chosen binary name for
minio-client should *not* be mcli,
On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> Philip Hands writes:
> > Might I suggest that the link goes the other way, so that the symlink
> > lives in /usr/bin? That way the existence of the lib directory is
> > somewhat self-documenting.
Having the real executable in
Philip Hands writes:
> Mathias Gibbens writes:
>
>> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> ...
>>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin? That way the existence of the
Mathias Gibbens writes:
> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
...
>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 22 Apr 2024 05:42:43 +
Source: python-re-assert
Built-For-Profiles: noudeb
Architecture: source
Version: 1.1.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team
Changed-By: Jeroen Ploemen
Changes
I don't want to exacerbate the off-topic-message problem, but I'm hoping
that by saying the following I may perhaps be able to prevent further
messages to the list about this.
First, can we please be very careful, when we're throwing around talk
about banning people from lists, to make it
Could this guy be blacklisted from Debian lists, please?
Am 21. April 2024 22:23:10 MESZ schrieb Jose Luis Alarcon Sanchez
:
>On abr. 21 2024, at 10:02 pm, José Luis González González
> wrote:
>
>> En mi teléfono móvil Samsung Galaxy A13 no puedo borrar ahora el
>> idioma Alemán del telclado y
On abr. 21 2024, at 10:02 pm, José Luis González González
wrote:
> En mi teléfono móvil Samsung Galaxy A13 no puedo borrar ahora el
> idioma Alemán del telclado y la corrección ortográfica.
>
Y que puede tener esto que ver con Debian o con Linux???. Llévalo a un
punto de Servicio Técnico de
And by the way, I was also unable to subscribe to debian-users-spanish either.
I know the emails reach, in any case.
On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> Marco d'Itri writes:
>
> > On Apr 21, Mathias Gibbens wrote:
> >
> > > While that might work for them, it obviously doesn't at a higher
> > > packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
> > > for any
Marco d'Itri writes:
> On Apr 21, Mathias Gibbens wrote:
>
>> While that might work for them, it obviously doesn't at a higher
>> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
>> for any comments or suggestions on my plan for packaging the MinIO
>> Client. Following
On Apr 21, Mathias Gibbens wrote:
> While that might work for them, it obviously doesn't at a higher
> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
> for any comments or suggestions on my plan for packaging the MinIO
> Client. Following what several other
Hi Andreas,
please stop reopening the time_t bugs where transitions are staged in
experimental. When we eventually start those transitions, they do not
need to change the package name again as they will enter unstable with a
new SONAME and built with the 64 bit time_t ABI.
Cheers
--
Sebastian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 14 Apr 2024 18:45:38 +
Source: python-re-assert
Binary: python3-re-assert
Architecture: source all
Version: 1.1.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team
Changed-By: Dale Richards
Lists updated to omit packages not in testing:
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include
On 18.04.24 21:22, Sebastian Ramacher wrote:
Hi,
as the progress on the t64 transition is slowing down, I want to give an
overview of some of the remaining blockers that we need to tackle to get
it unstuck. I tried to identify some clusters of issues, but there might
be other classes of issues.
All missing bugs about wrong deps are now filed.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi
thanks for checking all the packages and filing bugs!
On 2024-04-20 00:43:30 +0500, Andrey Rakhmatullin wrote:
> On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues
Hi Andreas
On 2024-04-19 10:49:15 +0200, Andreas Tille wrote:
> I've spotted these Debian Med packages.
>
> > gentle
gentle required a rebuild for wxwidgets3.2 on mips64el. Done
> > jellyfish
The t64 changes were reverted. crac needs to rebuilt for this change so
that libjellyfish-2.0-2t64
On 2024-04-19 10:34:45 +0200, Simon Josefsson wrote:
> Sebastian Ramacher writes:
>
> > Hi,
> >
> > as the progress on the t64 transition is slowing down, I want to give an
> > overview of some of the remaining blockers that we need to tackle to get
> > it unstuck. I tried to identify some
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS
On Fri, 19 Apr 2024 10:09:26 +0200
José Luis González González wrote:
> On Fri, 19 Apr 2024 09:59:57 +0200
> José Luis González González wrote:
>
> > On Fri, 19 Apr 2024 09:39:02 +0200
> > José Luis González González wrote:
> >
> > > Good day,
> > >
> > > There's an issue with the dash
Hi Sebastian,
Andreas Tille, on 2024-04-19:
> I've spotted these Debian Med packages.
[…]
> Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
[…]
> > jellyfish
> > quorum
[…]
> No idea how we can help here. Please let us know if we can do
> something.
About these two
You've written a lot of text here in a few mails, replying to yourself
several times. This is not a positive pattern.
On Fri, Apr 19, 2024 at 11:58:18AM +0200, José Luis González González wrote:
>> There are similar issues with boa and dhttpd, and it seems Apache is going
>> that way.
>
>nvi
301 - 400 of 172870 matches
Mail list logo
