Hi,
On 09-06-2024 1:56 p.m., rhys wrote:
So given that these no longer fit the "old and busted" description, is Debian
going to stick with the decision to not support them? Or is Debian going to continue to
support this processor, since it is still apparently a viable product, enough that
Hi,
On 6/11/24 07:40, Yogeswaran Umasankar wrote:
It appears that nanopb's use of the module name "proto" does not align
with the conventional identification of a Python module. Given this, it
might be plausible to make this module private within the nanopb
package. This adjustment could
Hi Laszlo and Yogeswaran,
I'm explicitly adding Laszlo to Cc to increase the chances of him
chiming in.
On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
> There is a file conflict between python3-proto-plus and nanopb. The
> conflict arises due to both packages has a file at
Hi!
On Mon, 2024-06-10 at 18:01:58 +0200, Helmut Grohne wrote:
> Ideally, we'd not just do a rebuild with the flags, but also do a
> rebuild without and then compare the binary .debs. In the event that we
> misguide configure, we expect the .debs to differ and otherwise to equal
> due to the work
Hi,
On 6/11/24 00:26, Simon McVittie wrote:
Reproducibility outside of sterile environments is however a problem for us
as a distribution, because it affects how well people are able to contribute
to packages they are not directly maintaining
If our package-building entry point sets up
On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
> There is a file conflict between python3-proto-plus and nanopb. The
> conflict arises due to both packages has a file at
> /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining
> python3-proto-plus, and I am
* Helmut Grohne [2024-06-10 18:01]:
> Ideally, we'd not just do a rebuild with the flags, but also do a
> rebuild without and then compare the binary .debs. In the event that we
> misguide configure, we expect the .debs to differ and otherwise to equal
> due to the work of the reproducible builds
On Mon, Jun 10, 2024 at 04:06:13PM +0500, Andrey Rakhmatullin wrote:
> Do you think it makes sense to add this a flag that enables -Werror=format
> to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> the MBF if we do one?
I think that a test rebuild and the MBF are
Hi!
On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > > Do you think it makes sense to add this a flag that enables -Werror=format
> > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> >
On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> > several important upstreams no longer consider i386 to be useful (and
> > especially i386-without-SSE2), so so the burden of supporting 32-bit
> > CPUs in modern
On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote:
> Reproducibility outside of sterile environments is however a problem for us
> as a distribution, because it affects how well people are able to contribute
> to packages they are not directly maintaining
If our package-building entry
On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> > The point here is that the Debian project is not intending to support
> > new hardware on the i386 architecture. The architecture is being kept
> > around primarily to
On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > Do you think it makes sense to add this a flag that enables -Werror=format
> > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > the MBF if we do one?
>
> If by adding you mean adding a new feature flag
On Mon, 10 Jun 2024 at 16:24:54 +0200, Guillem Jover wrote:
> In general I think it's good (in principle) to enable -Werror flags
> that detect actual bugs in code, the problem is always going to be
> the amount of fallout and work that creates
Yes. The difficult thing here is balancing "detect
On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> The point here is that the Debian project is not intending to support
> new hardware on the i386 architecture. The architecture is being kept
> around primarily to support running old i386 binaries.
... and the most appropriate
On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > > > We recently increased the time_t size on certain architectures and some
> > > > packages started failing to build because they were using a format
> > > > specifier too narrow for the wider time_t, e.g. #1067829.
> > > > But
Hi!
On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > > We recently increased the time_t size on certain architectures and some
> > > packages started failing to build because they were using a format
> > >
Hi The (2024.06.10_12:22:14_+)
> How to get access to the right parts of the waste stream to be able to
> pull out some working 64-bit hardware is another question, and one where
> I don't have an answer that wouldn't involve spending money (which would
> presumably make the proposed
On 2024-06-10 at 08:09, rhys wrote:
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin
> wrote:
>
>> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org
>> wrote:
>>> Reuse is better than recycle for complex things like electronics.
>>>
>> You were suggested to resuse an old amd64
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin wrote:
>
> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
It's not just a matter of "buy something better." That's easy.
>>
>>> Indeed, that is easier and cheaper.
>>
>> Of course, continuing to use a system I
On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > We recently increased the time_t size on certain architectures and some
> > packages started failing to build because they were using a format
> > specifier too narrow for the wider time_t, e.g. #1067829.
> > But the only reason
On Fri, Jun 07, 2024 at 12:19:28AM +0500, Andrey Rakhmatullin wrote:
> We recently increased the time_t size on certain architectures and some
> packages started failing to build because they were using a format
> specifier too narrow for the wider time_t, e.g. #1067829.
> But the only reason
ty, still in
>production use, etc.?
It is not enough to be willing. It is necessary to actually do. I
think that once i686 (re)qualifies as release arch, it will be (again)
one.
Greetings
Marc
--
Marc Haber |
On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
> >> It's not just a matter of "buy something better." That's easy.
>
> >Indeed, that is easier and cheaper.
>
> Of course, continuing to use a system I already have is cheaper still.
>
> > What's not easy is that a) that
>> It's not just a matter of "buy something better." That's easy.
>Indeed, that is easier and cheaper.
Of course, continuing to use a system I already have is cheaper still.
> What's not easy is that a) that adds another machine to the waste
> stream, instead of continuing to get use from
> Or is Debian going to continue to support this processor, since it is still
> apparently a viable product, enough that new systems are using it?
Considering the plans for i386 I don't think it makes sense to even ask
this question?
Of course it makes sense to ask. The plans are based on a
Hi,
On Sun, 2024-06-09 at 08:58 -0500, r...@neoquasar.org wrote:
> What it is is functional, and paid for. And likely, already installed
> and in use somewhere (like all of my 32-bit systems).
>
> It's not just a matter of "buy something better." That's easy.
Indeed, that is easier and
ust enough software training to be dangerous and may be able to help
carry some of the actual load here, instead of just asking for more free
support.
Sent from my mobile device.
From: Marc Haber
Sent: Monday, May 20, 2024 02:35
To: debian-devel@lists.debian.org
On Sun, Jun 09, 2024 at 06:56:00AM -0500, rhys wrote:
> The question right now is: Is this processor supported at all?
No.
> So given that these no longer fit the "old and busted" description, is Debian
> going to stick with the decision to not support them?
I'm sure we will, yes, though I'm
> On Jun 9, 2024, at 03:02, Marc Haber wrote:
>
> On Sat, 08 Jun 2024 07:25:49 +, Laszlo Merenyi
> wrote:
>> I was able to make sudo (and visudo) executable working on this CPU, by
>> recompiling the sudo-1.9.15p5 source code package on the target with
>> manually removed
On Sat, 08 Jun 2024 07:25:49 +, Laszlo Merenyi
wrote:
>I was able to make sudo (and visudo) executable working on this CPU, by
>recompiling the sudo-1.9.15p5 source code package on the target with manually
>removed "-fcf_protection" hardening option.
>
>I did not yet met any other program
https://www.compmall.de/VDX3-EITX-75S-505669 is in stock.I found a variety of other shops selling similar boards, some having them in stock, some not.Am 08.06.2024 13:29 schrieb rhys :Yes, this is a known issue. This is because Bookworm only supports 32-bit CPUs that are fully Intel compatible.
Yes, this is a known issue. This is because Bookworm only supports 32-bit CPUs
that are fully Intel compatible. You will find that there are other binaries
such as ffmpeg that fail with the same problem. (This is from memory. I have
a similar system that is "almost" Intel compatible, but
Message-id:
In-reply-to: <529d4728-d26f-43ff-a957-54b29652d...@neoquasar.org>
References: <529d4728-d26f-43ff-a957-54b29652d...@neoquasar.org>
Hello,
I encountered a similar sudo issue with Bookworm installed on a Vortex86DX3 CPU
based embedded computer.
Vortex86 series chips are less known
Hi,
On 6/8/24 00:42, Simon McVittie wrote:
Having an UTF-8 locale available would be a good thing, but allowing
packages to rely on the active locale to be UTF-8 based reduces our testing
scope.
I'm not sure I follow. Are you suggesting that we should build each
package *n* times (in a
On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote:
> I'm a non-native speaker, who has been involved
> in l10n for a long time, while at the same time I've pretty much
> always run my systems with either LANG=C.UTF-8 or before that LANG=C,
> LC_CTYPE=ca_ES.UTF-8 and
On Fri, 07 Jun 2024 at 23:22:46 +0900, Simon Richter wrote:
> On 6/7/24 22:40, Alexandre Detiste wrote:
> > Maybe a compromise would be to at least mandate some UTF-8 locale.
>
> Having an UTF-8 locale available would be a good thing, but allowing
> packages to rely on the active locale to be
Hi,
On 6/7/24 22:40, Alexandre Detiste wrote:
Maybe a compromise would be to at least mandate some UTF-8 locale.
Having an UTF-8 locale available would be a good thing, but allowing
packages to rely on the active locale to be UTF-8 based reduces our
testing scope.
Basically, we need to
On 07/06/24 14:32, Guillem Jover wrote:
Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env,
which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and
umask=0022.
That's great news!
But _iff_ we end up with dpkg-buildpackage being declared the only
supported entry
Maybe a compromise would be to at least mandate some UTF-8 locale.
On Fri, Jun 07, 2024 at 02:32:14PM +0200, Guillem Jover wrote:
> And I think forcing a locale on buildds makes perfect sense, because
> we want easy access to build logs. But forcing LC_ALL from the build
> tools implies that no tool invoked will get translated messages at
> all, and means that
Hi!
On Thu, 2024-06-06 at 15:31:55 +0100, Simon McVittie wrote:
> On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote:
> > C, or C.UTF-8 is not a universal locale which works
> > for all.
>
> Sure, and I don't think anyone is arguing that you or anyone else should
> set the locale for
On Thu, Jun 06, 2024 at 07:11:46PM +0200, Michael Biebl wrote:
> I would prefer that dpkg-buildpackage provides a "sane" build environment by
> default (which I think includes a LC_ setting pointing at a .UTF-8 locale)
> and fewer packages explicitly setting those things via debian/rules.
same
Hello,
On Thu 06 Jun 2024 at 11:25am -06, Gunnar Wolf wrote:
> Let me chime in with all of the people that have been amazed at your
> depth of analysis and your commitment to implementing the *properly
> right* situation. It cannot be overstressed that, for this release
> cycle, one of the main
On Thu, Jun 06, 2024 at 06:39:15PM +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie wrote:
>
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be
Simon McVittie writes:
> On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
>> Something did, because inn would start reporting ~1G available fds and
>> then explode, and that patch solved the issue. :-)
> It might be worthwhile to try to track down what larger component did
> this,
On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie wrote:
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffected
Hi Helmut,
Russ Allbery, on 2024-06-06:
> Marc Haber writes:
> > Helmut Grohne wrote:
>
> >> Thanks for bearing with me and also thanks to all the people (release
> >> team and affected package maintainers in particular) who support this
> >> work.
>
> > Thank you for doing this work. I have
Helmut Grohne dijo [Thu, Jun 06, 2024 at 09:28:52AM +0200]:
> Hello,
>
> I have just uploaded
> * base-files
> * bash
> * dash
> * glibc
> * util-linux
> to unstable. These were the last remaining packages shipping aliased
> files inside the package set relevant to debootstrap.
> (...)
>
Am 06.06.24 um 18:52 schrieb Andrey Rakhmatullin:
On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
Or whether we should switch the default and require that d/rules is run in an
environment (for example as set-up by dpkg-buildpackage) where these variables
are
Marc Haber writes:
> Helmut Grohne wrote:
>> Thanks for bearing with me and also thanks to all the people (release
>> team and affected package maintainers in particular) who support this
>> work.
> Thank you for doing this work. I have rarely seen a change of this
> magnitude in Debian that
On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Or whether we should switch the default and require that d/rules is run in an
> environment (for example as set-up by dpkg-buildpackage) where these variables
> are set?
(a previous discussion on this:
On Jun 06, Johannes Schauer Marin Rodrigues wrote:
> A question that goes in a similar direction is whether every d/rules that
> needs
> it should have to do this:
>
> export DPKG_EXPORT_BUILDFLAGS=y
> include /usr/share/dpkg/buildflags.mk
>
> Or whether we should switch the default and
On Jun 06, Simon McVittie wrote:
> I believe the change Luca describes is increasing rlim_max (hard limit)
> but not rlim_cur (soft limit), and the code touched by that patch is
> looking at rlim_cur, so it should be unaffected anyway - unless some larger
> component is raising rlim_cur.
Processing control commands:
> retitle -1 Dead keys stopped working in unspecified environment
Bug #1072491 [libglib2.0-0t64] libglib2.0-0t64: Dead keys stopped working,
again!
Changed Bug title to 'Dead keys stopped working in unspecified environment'
from 'libglib2.0-0t64: Dead keys stopped
On Thu, 06 Jun 2024 at 12:56:10 +0200, Johannes Schauer Marin Rodrigues wrote:
> If we imagine a hypothetical switch to LC_ALL=C.UTF-8 for all source
> packages by default, then there will be bugs.
Do you mean: there will be bugs that break the build of certain packages,
which previously built
I believe debhelper already sets LC_ALL=C.UTF-8 for the cmake, meson,
and ninja buildsystems; therefore many but definitely not all packages
are already built with LC_ALL=C.UTF-8.
Thank you,
Jeremy Bícha
On Thu, 06 Jun 2024 at 15:21:22 +0200, Marco d'Itri wrote:
> On Jun 06, Luca Boccassi wrote:
> > The last time this was tried some packages were still not ready, so it
> > was patched out to let them be fixed.
>
> I missed the venerable inn 1.x at the time, and I never noticed that it
>
On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote:
> C, or C.UTF-8 is not a universal locale which works
> for all.
Sure, and I don't think anyone is arguing that you or anyone else should
set the locale for your interactive terminal session, your GUI desktop
environment, or even your
On Thu, 06 Jun 2024 at 14:40:23 +0200, Daniel Gröber wrote:
> On Thu, Jun 06, 2024 at 11:32:33AM +0200, Simon Richter wrote:
> > If your package is not reproducible without it, then your package is
> > broken.
>
> At build-time, if a program doesn't call setlocale before using locale
> dependent
On Jun 06, Luca Boccassi wrote:
> The last time this was tried some packages were still not ready, so it
> was patched out to let them be fixed. Enough time has passed now, and
> it's time to let any unknown leftover just break and be fixed. In all
> known cases, the buggy pattern was to
On Thu, 6 Jun 2024 09:28:52 +0200, Helmut Grohne
wrote:
>Thanks for bearing with me and also thanks to all the people (release
>team and affected package maintainers in particular) who support this
>work.
Thank you for doing this work. I have rarely seen a change of this
magnitude in Debian that
Hi,
On 6/6/24 19:56, Johannes Schauer Marin Rodrigues wrote:
At the same time though, I also get annoyed of copy-pasting d/rules snippets
from one of my packages to the next instead of making use of a few more
defaults in our package build environment.
Same here -- I just think that such a
Hi,
Quoting Hakan Bayındır (2024-06-06 12:32:27)
> On 6.06.2024 ÖS 1:08, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Simon Richter (2024-06-06 11:32:33)
> >>> Would it be possible to set in stone that packages are supposed to always
> >>> be built in an environment where LC_ALL=C.UTF-8,
Hi,
On 6.06.2024 ÖS 1:08, Johannes Schauer Marin Rodrigues wrote:
Hi,
Quoting Simon Richter (2024-06-06 11:32:33)
Would it be possible to set in stone that packages are supposed to always
be built in an environment where LC_ALL=C.UTF-8, or, in other words, that
builders must set
Hi,
Quoting Simon Richter (2024-06-06 11:32:33)
> > Would it be possible to set in stone that packages are supposed to always
> > be built in an environment where LC_ALL=C.UTF-8, or, in other words, that
> > builders must set LC_ALL=C.UTF-8?
>
> This would be the opposite of the current rule.
>
Hi,
> Would it be possible to set in stone that packages are supposed to
> always be built in an environment where LC_ALL=C.UTF-8, or, in other
> words, that builders must set LC_ALL=C.UTF-8?
This would be the opposite of the current rule.
Setting LC_ALL=C in debian/rules is an one-liner.
If
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
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
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 aliased
> files inside the package set relevant to debootstrap.
thank you (and freexian for
Am Mon, Jun 03, 2024 at 04:34:08PM +0200 schrieb gregor herrmann:
> On Mon, 03 Jun 2024 11:00:34 +, Holger Levsen wrote:
> >
> > however, "costs to attend" are not the same as "costs while attending"...
ACK.
> Also & related, https://wiki.debian.org/HostingBSP#Sponsorships says
> (emphasis
On Mon, 03 Jun 2024 11:00:34 +, Holger Levsen wrote:
> On Sat, Jun 01, 2024 at 09:52:32AM +0200, Andreas Tille wrote:
> > in connection with MiniDebConf Berlin there was some discussion about
> > what expense per attendee of some in person meeting is OK. Quoting
> > Chris Lamb from his "Bits
Hi,
On 6/3/24 21:05, Colin Watson wrote:
From the d-i side we've generally preferred to have all the UI be part
of the installer (especially for translations etc.).
Makes sense, thanks!
Simon
On Mon, Jun 03, 2024 at 07:51:44PM +0900, Simon Richter wrote:
> On 6/3/24 15:33, Philipp Kern wrote:
>
> > > > * Package name : systemd-boot-installer
> > > Can this be merged into the normal systemd source package?
>
> > I feel like from a d-i perspective that'd be highly unusual? Having
Hi,
On 6/3/24 15:33, Philipp Kern wrote:
* Package name : systemd-boot-installer
Can this be merged into the normal systemd source package?
I feel like from a d-i perspective that'd be highly unusual? Having the
purely d-i-specific components be owned by d-i is the common setup.
If it
On Sat, Jun 01, 2024 at 09:52:32AM +0200, Andreas Tille wrote:
> in connection with MiniDebConf Berlin there was some discussion about
> what expense per attendee of some in person meeting is OK. Quoting
> Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:
>
> Debian is willing to
On 03.06.24 05:43, Simon Richter wrote:
On 6/3/24 09:33, Luca Boccassi wrote:
* Package name : systemd-boot-installer
Can this be merged into the normal systemd source package?
I feel like from a d-i perspective that'd be highly unusual? Having the
purely d-i-specific components be
Hi,
On 6/3/24 09:33, Luca Boccassi wrote:
* Package name: systemd-boot-installer
Can this be merged into the normal systemd source package?
Simon
https://lists.debian.org/debian-www/2015/01/msg00034.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490848
This problem has existed since 2015 and I will follow to see what the
outcome of this bug will be. Thanks! 樂
On Sun, Jun 02, 2024 at 04:49:46PM +0200, Computer Enthusiastic wrote:
> Hello everyone,
>
> The gstreamer1.0-alsa has been updated recently:
>
> $ apt -a list gstreamer1.0-alsa
> Listing... Done
> gstreamer1.0-alsa/stable-security,now 1.22.0-3+deb12u2 amd64
> [installed,automatic]
>
On Sun, Jun 2, 2024 at 11:50 AM Computer Enthusiastic
wrote:
>
> Hello everyone,
>
> The gstreamer1.0-alsa has been updated recently:
>
> $ apt -a list gstreamer1.0-alsa
> Listing... Done
> gstreamer1.0-alsa/stable-security,now 1.22.0-3+deb12u2 amd64
> [installed,automatic]
>
On Tue, 28 May 2024 11:00:34 +0200, Mathieu Malaterre
wrote:
> On Mon, May 27, 2024 at 10:26 PM Steve Langasek wrote:
> > On Thu, May 23, 2024 at 08:14:20PM +0200, Mathieu Malaterre wrote:
> > > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now)
> > > ?
> >
> > What
On Fri, 31 May 2024 18:35:53 +, nino He?i
wrote:
>My suggestion is regarding locales. Currently we get to chose locale based
>on choices of language and keyboard layout and here in lies the problem.
>Rather than offer locales based on our selections don't,just list all of
>them in
On Fri, May 31, 2024 at 06:35:53PM +, nino Heđi wrote:
> My suggestion is regarding locales. Currently we get to chose locale based
> on choices of language and keyboard layout and here in lies the problem.
> Rather than offer locales based on our selections don't,just list all of
> them in
On 2024-05-31 01:05:51 +0800, Jun MO wrote:
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
> example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
> depends on pam.
GNU Screen and
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 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote:
> wtmpdb takes over the "last" name. Unfortunately without support for
> reading the old files. Nobody wrote tooling to import them or so.
In the new versions of the package, "last" could have been installed
under another name (e.g.
Quoting Shengjing Zhu (2024-05-16 12:14:57)
> On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard wrote:
> >
> > Hi FTP-masters (cc d-devel list),
> >
> > A package, that I had initially introduced to Debian some months ago and
> > had been pending in NEW queue since, was rejected few days ago, like
* 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, maybe
it can be used to solve the Y2038 problem for wtmp?
* Jun MO [240530 19:09]:
> On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> > I agree, this may be useful. Unfortunately, the current status is
> > that one cannot have both: installing wtmpdb forces the upgrade of
> > util-linux to 2.40.1-3 (at least), where "last" is no longer
On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> I agree, this may be useful. Unfortunately, the current status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.
Thanks for the change
* Vincent Lefevre [240530 13:21]:
> On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> > For last(1) my concern is that it will be helped to keep the original
> > last(1) for back-compatibility to read old wtmp files.
>
> I agree, this may be useful. Unfortunately, the current status is
> that one
On Thu, 30 May 2024 at 15:41:50 +0200, Johannes Schauer Marin Rodrigues wrote:
> I also found another issue with this change in systemd. After the upload to
> unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to
> fail:
>
>
Hi,
Quoting Peter Pentchev (2024-05-30 10:33:08)
> > thank you for having discussed this change on d-devel and for adding
> > documentation to NEWS and release notes to announce this change. I also
> > think it is sensible to roll this only out on new installations and to keep
> > the behaviour
On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.
I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the
> On 30 May 2024, at 09:15, Marc Haber wrote:
>
> On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
> wrote:
>> I'll kindly disagree here. I'd rather not have to go back to every
>> system and make sure that they all behave the way I want after doing a
>> periodic, completely boring
On Thu, May 30, 2024 at 08:35:47AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi,
>
> Quoting Luca Boccassi (2024-05-28 01:54:08)
> > Thanks for the useful input, the following has been done:
> >
> > - existing installations pre-trixie will get an orphaned tmpfiles.d in
> > /etc/ that
Hi,
Quoting Luca Boccassi (2024-05-28 01:54:08)
> Thanks for the useful input, the following has been done:
>
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
> - openssh and tmux have been
On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
wrote:
>I'll kindly disagree here. I'd rather not have to go back to every
>system and make sure that they all behave the way I want after doing a
>periodic, completely boring "apt-get upgrade".
This change is likely to come to the majority of
> On 29 May 2024, at 17:33, Marvin Renich wrote:
>
> * Hakan Bayındır [240529 07:51]:
>> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
>>> On 2024-05-28 Luca Boccassi
>>> wrote:
>>> [...]
- existing installations pre-trixie will get an orphaned tmpfiles.d in
/etc/ that keeps the
1 - 100 of 172969 matches
Mail list logo
