Re: systemd version 256.7-2 on Debian testing disabled UTMP support

> I am guessing from the version number that this is on trixie/sid. On Correct, thanks for guessing. > November 4th, systemd 256.7-3 came through. Have you tested whether > that fixed the issue? Nothing has changed with that version (note the "-UTMP"): , | [~]$ systemctl --version | systemd

Re: systemd version 256.7-2 on Debian testing disabled UTMP support

On Wed, 6 Nov 2024 21:18:33 +0100 Jens Schmidt wrote: > [I hope this is the right way to address this question - apologies > if not or if I have overlooked an existing discussion ...] > > systemd version 256.7-2 on Debian disabled UTMP support (from the > Debian changelog): I am guessing from t

Re: systemd may silently break your system!

On 2024-08-01 23:17:42 -0400, Jeffrey Walton wrote: > The reference also says: > > Only pure stable release with security updates provides the best > stability. But stable does not mean bugless. Unfortunately stable sometimes has major bugs, and the only thing to do is to wait for the nex

Re: systemd may silently break your system!

On Thu, Aug 1, 2024 at 12:57 PM Dan Ritter wrote: > > Andy Smith wrote: > > This whole thing just seems like the normal process of developing > > and packaging a distribution. Poor interactions are found, reported, > > hopefully will be fixed. But once again there's people trying to use > > this a

Re: systemd may silently break your system!

On Friday, 02-08-2024 at 02:39 Dan Ritter wrote: > Andy Smith wrote: > > This whole thing just seems like the normal process of developing > > and packaging a distribution. Poor interactions are found, reported, > > hopefully will be fixed. But once again there's people trying to use > > this a

Re: systemd may silently break your system!

Andy Smith wrote: > This whole thing just seems like the normal process of developing > and packaging a distribution. Poor interactions are found, reported, > hopefully will be fixed. But once again there's people trying to use > this as a daily driver and having weird expectations. And then some

Re: systemd may silently break your system!

Am Do, Aug 01, 2024 at 14:08:21 + schrieb Andy Smith: I feel like we see it more and more, these expectations about sid, and I don't understand why. Maybe because these bugs have already reached testing? My testing system has this buggy version of procps. Interestingly /etc/sysctl.conf is

Re: systemd may silently break your system!

On Thu, Aug 01, 2024 at 16:03:32 +0200, Vincent Lefevre wrote: > so the silent breakage was known and done on purpose. ... OK, you're just living in a personal fantasy. There's nothing more to be gained by trying to interact with you on this topic, so I'm going to stop now.

Re: systemd may silently break your system!

Vincent Lefevre (12024-08-01): > so the silent breakage was known and done on purpose. Cutting yourself on Hanlon's Razor. -- Nicolas George

Re: systemd may silently break your system!

Hi, On Thu, Aug 01, 2024 at 09:37:54AM -0400, Greg Wooledge wrote: > I see NO reason to point fingers of blame at systemd (cf. Subject:). > > I see nothing amiss here in the order in which packages were uploaded. > > I see NO reason that these two packages have to be upgraded in a specific > ord

Re: systemd may silently break your system!

On 2024-08-01 09:37:54 -0400, Greg Wooledge wrote: > On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote: > > No, even for unstable, maintainers should ensure that packages are > > upgraded in the right order. > > Once again, here is my understanding of the current situation: > > 1) A

Re: systemd may silently break your system!

On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote: > No, even for unstable, maintainers should ensure that packages are > upgraded in the right order. Once again, here is my understanding of the current situation: 1) A new procps package was uploaded, which no longer has /etc/sysctl.

Re: systemd may silently break your system!

On 2024-07-29 23:36:02 -0500, David Wright wrote: > On Mon 29 Jul 2024 at 11:24:25 (+0200), Vincent Lefevre wrote: > > On 2024-07-28 22:26:10 -0500, David Wright wrote: > > > On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote: > > > > On 2024-07-28 00:07:56 -0500, David Wright wrote: > >

Re: systemd may silently break your system!

On 2024-07-28 22:26:10 -0500, David Wright wrote: > On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote: > > On 2024-07-28 00:07:56 -0500, David Wright wrote: > > > It looks accidental to me that systemd did that tidying up before > > > procps had attempted to remove the file that it (pro

Re: systemd may silently break your system!

On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote: > On 2024-07-28 00:07:56 -0500, David Wright wrote: > > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > > > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent

Re: systemd may silently break your system!

On 2024-07-28 11:21:01 -0400, Greg Wooledge wrote: > On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote: > > More or less. In the systemd case, for each file, either one chooses > > it, i.e. one has all the current defaults, or one chooses to provide > > a replacement under /etc, i.e. on

Re: systemd may silently break your system!

On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote: > More or less. In the systemd case, for each file, either one chooses > it, i.e. one has all the current defaults, or one chooses to provide > a replacement under /etc, i.e. one entirely replaces the defaults by > one's own settings. A

Re: systemd may silently break your system!

On 2024-07-28 00:07:56 -0500, David Wright wrote: > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > > The configuration got broken by a *systemd* upgra

Re: systemd may silently break your system!

On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > The configuration got broken by a *systemd* upgrade: > > > > > > * Drop /etc/sysctl.d/99-sysctl.conf symli

Re: systemd may silently break your system!

Vincent Lefevre wrote: The /etc/sysctl.d/99-sysctl.conf symlink has been removed (currently in unstable) *without any announcement*, so that the /etc/sysctl.conf file (which is still documented, BTW) is no longer read. So, be careful if you have important settings there (security...). Thanks

Re: systemd may silently break your system!

On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > On Sun, Jul 28, 2024 at 01:04:14 +0200, Vincent Lefevre wrote: > > On 2024-07-27 10:23:01 +0200, Michel Verdier wrote: > > > /etc/sysctl.d/README.sysctl recommends to use a separate file such as > > > /etc/sysctl.d/local.conf > > > > No, it does

Re: systemd may silently break your system!

On Sun, Jul 28, 2024 at 01:04:14 +0200, Vincent Lefevre wrote: > On 2024-07-27 10:23:01 +0200, Michel Verdier wrote: > > /etc/sysctl.d/README.sysctl recommends to use a separate file such as > > /etc/sysctl.d/local.conf > > No, it does *not* recommend anything: > > ---

Re: systemd may silently break your system!

On 2024-07-27 09:26:49 -0400, Greg Wooledge wrote: > > On 2024-07-26, Vincent Lefevre wrote: > > > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > > (currently in unstable) *without any announcement*, so that > > > the /etc/sysctl.conf file (which is still documented, BTW) > > >

Re: systemd may silently break your system!

On 2024-07-27 10:23:01 +0200, Michel Verdier wrote: > On 2024-07-26, Vincent Lefevre wrote: > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > (currently in unstable) *without any announcement*, so that > > the /etc/sysctl.conf file (which is still documented, BTW) > > is no longe

Re: systemd may silently break your system!

On Sat 27 Jul 2024 at 09:26:49 (-0400), Greg Wooledge wrote: > > On 2024-07-26, Vincent Lefevre wrote: > > > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > > (currently in unstable) *without any announcement*, so that > > > the /etc/sysctl.conf file (which is still documented, B

Re: systemd may silently break your system!

> On 2024-07-26, Vincent Lefevre wrote: > > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > > (currently in unstable) *without any announcement*, so that > > the /etc/sysctl.conf file (which is still documented, BTW) > > is no longer read. > > > > So, be careful if you have important

Re: systemd may silently break your system!

On 2024-07-26, Vincent Lefevre wrote: > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*, so that > the /etc/sysctl.conf file (which is still documented, BTW) > is no longer read. > > So, be careful if you have important settings there

Re: systemd-cryptsetup

On 2024-07-14 13:17:45 +0200, Lists wrote: > On 2024-07-14 11:00, Nicolas George wrote: > > Hi. > > > > In case you are running unstable or testing and it recently started > > blocking at boot waiting for encrypted swap or something to do with > > encrypted disks: > > > > Check if systemd-cryptse

Re: systemd may silently break your system!

On Fri, Jul 26, 2024 at 10:00 AM Vincent Lefevre wrote: > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*, so that > the /etc/sysctl.conf file (which is still documented, BTW) > is no longer read. > > So, be careful if you have impor

Re: systemd may silently break your system!

I had already removed the symlink and migrated sysctl.conf to 99-sysctl.conf and it appears Debian deleted that file as well. On Fri, Jul 26, 2024 at 9:00 AM Vincent Lefevre wrote: > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*,

Re: systemd-cryptsetup

Lists (12024-07-16): > In that case you were correct. I had found posts online where people were > pointing in the direction of systemd and due to the problem with > systemd-cryptsetup you warned us about I was inclined to take those posts at > face value. It seems that was not "fair". That happen

Re: systemd-cryptsetup

On 2024-07-16 12:51, Nicolas George wrote: Lists (12024-07-16): That referred to a warning I got after booting up after d-i finished installing the system. The exact message shown was this: cryptsetup: WARNING nvme1n1p3_crypt: ignoring unknown option 'x-initrd.attach' This message comes from

Re: systemd-cryptsetup

Lists (12024-07-16): > That referred to a warning I got after booting up after d-i finished > installing the system. The exact message shown was this: > > cryptsetup: WARNING nvme1n1p3_crypt: ignoring unknown option > 'x-initrd.attach' This message comes from /usr/lib/cryptsetup/functions, a fil

Re: systemd-cryptsetup

On 2024-07-16 11:52, Nicolas George wrote: I do not know what you are referring to when you talk about x-initrd.attach, you were too terse. But I notice that you talked about it in the same paragraph that you reported the inaccurate information that systemd has its own implementation of cryptset

Re: systemd-cryptsetup

Lists (12024-07-15): > For the most part I understand your point of view. As a matter of fact I am > not even opposed to systemd as such [1], but over the years I have had my > share of problems that in the end proved to be caused by some transition to > systemd. This has made me a bit wary of it.

Re: systemd-cryptsetup

Hi Nicolas, Thanks for the explanation. For the most part I understand your point of view. As a matter of fact I am not even opposed to systemd as such [1], but over the years I have had my share of problems that in the end proved to be caused by some transition to systemd. This has made me a

Re: systemd-cryptsetup

Lists (12024-07-14): > When I researched the problem I encountered some posts stating that systemd > had its own implementation for cryptsetup This is not true. systemd-cryptsetup uses libcryptsetup, it is mostly only glue. > > Why the *&^%#@! it is necessary to have this borg-like behaviour of

Re: systemd-cryptsetup

On 2024-07-14, Erwan David wrote: > I have a "full" disk encryption as made by the installer, thus mounted in the > initramfs, so it may be a little different If "full disk" include /boot you should be ask for password by grub. Else it is initramfs and you should be ask by cryptsetup (package cry

Re: systemd-cryptsetup

On 2024-07-14 11:00, Nicolas George wrote: Hi. In case you are running unstable or testing and it recently started blocking at boot waiting for encrypted swap or something to do with encrypted disks: Check if systemd-cryptsetup is installed. HtH Thanks for the confirmation! I downloaded deb

Re: systemd-cryptsetup

Le 14/07/2024 à 11:44, Nicolas George a écrit : Erwan David (12024-07-14): You are a bit cryptic here : should it be installed or should it be removed Sorry. For me it was not installed and installing it fixed the problem. ? I am running testing without problem and systemd-cryptsetup is not i

Re: systemd-cryptsetup

Erwan David (12024-07-14): > You are a bit cryptic here : should it be installed or should it be removed Sorry. For me it was not installed and installing it fixed the problem. > ? I am running testing without problem and systemd-cryptsetup is not > installed. If I should install it I'd prefer to

Re: systemd-cryptsetup

Le 14/07/2024 à 11:00, Nicolas George a écrit : Hi. In case you are running unstable or testing and it recently started blocking at boot waiting for encrypted swap or something to do with encrypted disks: Check if systemd-cryptsetup is installed. HtH You are a bit cryptic here : should it be

Re: systemd-tmpfiles: file globbing?

On Thu, Jun 13, 2024 at 12:00:25PM +0200, Frank Van Damme wrote: > Is there a way to apply max lifetimes to files matching a pattern? I can't > find any way to tell it to, say, remove *.txt files older than a month from > /tmp/foo. If you're willing to turn away from systemd, find(1) can do this.

Re: systemd-resolved resolving fails sometimes on Debian12

On Mon, Mar 04, 2024 at 02:03:32PM +0800, jeremy ardley wrote: > I completely removed system-resolved as when it is installed it changes the > DNS configuration to be non-standard The issues described in this thread are related to libnss-resolve, which is no longer installed in the Debian 12 cloud

Re: systemd-resolved resolving fails sometimes on Debian12

Am 02.03.2024 um 15:06:01 Uhr schrieb Victor Sudakov: > In my case the problem seems related to IPv6. That is, when I disable > IPv6 via "sysctl net.ipv6.conf.all.disable_ipv6=1" the problem > disappears. Please run resolvectl that shows the resolvers available. Check each of them with dig exa

Re: systemd-resolved resolving fails sometimes on Debian12

On 3/3/24 22:39, Victor Sudakov wrote: jeremy ardley wrote: On 3/3/24 12:43, Victor Sudakov wrote: Not that I would use bind9 as a caching resolver but still, how do you pass the dynamically obtained AWS DNS server address from systemd-networkd to bind9 ? The AWS DNS resolver IPs are static

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 3/3/24 12:43, Victor Sudakov wrote: > > Not that I would use bind9 as a caching resolver but still, how > > do you pass the dynamically obtained AWS DNS server address from > > systemd-networkd to bind9 ? > > > The AWS DNS resolver IPs are static and are widely publis

Re: systemd-resolved resolving fails sometimes on Debian12

On 3/3/24 12:43, Victor Sudakov wrote: Not that I would use bind9 as a caching resolver but still, how do you pass the dynamically obtained AWS DNS server address from systemd-networkd to bind9 ? The AWS DNS resolver IPs are static and are widely published. It is permissible to not use AWS

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 2/3/24 23:06, Victor Sudakov wrote: > > You know, the official Debian 12 AMI for AWS is built on > > systemd-resolved and systemd-networkd. I'd prefer not to have to > > modify the official AMI if I can help it, because this would probably > > mean also replacing the sy

Re: systemd-resolved resolving fails sometimes on Debian12

On 2/3/24 23:06, Victor Sudakov wrote: You know, the official Debian 12 AMI for AWS is built on systemd-resolved and systemd-networkd. I'd prefer not to have to modify the official AMI if I can help it, because this would probably mean also replacing the systemd-networkd with some other network

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 1/3/24 17:47, Victor Sudakov wrote: > > Has anybody encountered this problem using systemd-resolved as a > > resolver on Debian12? A DNS request via systemd-resolved fails, but > > fails only occasionally. A failure can happen once per a hundred > > successful requests

Re: systemd-resolved resolving fails sometimes on Debian12

On 1/3/24 17:47, Victor Sudakov wrote: Has anybody encountered this problem using systemd-resolved as a resolver on Debian12? A DNS request via systemd-resolved fails, but fails only occasionally. A failure can happen once per a hundred successful requests or so. If I run: I recall a similar

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 1/9/24 03:15, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. Something similar to IBM's kludgiest relic of the early 1960s has appeared in linux? The unixoid commu

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Bret Busby (12024-01-09): > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list, one (and, only one) of the applications > of version numbers as part of file descriptors, with (in the case of > VAX/VMS) up to the last seven versions of a

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Bret Busby wrote: > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list But i found a premium excuse in the debian-cd and debian-live ISOs. :o) > the last seven versions of a file, being retained, was a > useful tool for software

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 9/1/24 16:02, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: The idea that we need version numbers embedded in filenames involuntarily may be "natural" to somebody. I have never seen any version other than ";1" (and ISOs which simply ignore the specs about file names). It's a non

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Nicholas Geovanis wrote: > You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. > Something similar to IBM's kludgiest relic of the early 1960s has appeared > in linux? The unixoid community added System Use Protocol and Rock

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On Mon, Jan 8, 2024, 11:38 AM Thomas Schmitt wrote: > Hi, > > Bret Busby wrote: > > > .; > > Jeremy Nicoll wrote: > > IBM's MVS & its successors, most recently z/OS, have something > > similar called a GDG (or Generation Data Group). > > The principle made it into ISO 9660 specifications. > > To

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 8 Jan 2024, at 9:17, Bret Busby wrote: > But, apart from the functionality that I have not seen in any other operating > system, of using an extra file descriptor of version number, so the whole > filename would be something like > .; > (I am not sure whether that syntax is correct - I have n

Re: systemd-timesyncd

On 2024-01-07, Andrew M.A. Cater wrote: > >> Take care, stay warm, well, and unvaxed. >> ^^^ > > Gene - no partisan opinions, please, as per Code of Conduct? Nothing sucks like a VAX! > All best, as ever, > > Andy

Re: systemd-timesyncd

On 1/7/24 19:39, Nicholas Geovanis wrote: On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" mailto:amaca...@einval.com>> wrote: > > Take care, stay warm, well, and unvaxed. > >   

Re: systemd-timesyncd

On 1/7/24 17:51, Charles Curley wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: Take care, stay warm, well, and unvaxed. ^^^ Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because Gene doesn't like cer

Re: systemd-timesyncd

Is it supposed to be installed by the net-installer? There does not seem > to be any man pages other than the bog std stuff. When I found the > /etc/systemd/timesyncd I immediately asked the system for man timesyncd, > got this: > gene@coyote:/etc$ man timesyncd > No manual entry for timesyncd >

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Bret Busby wrote: > > .; Jeremy Nicoll wrote: > IBM's MVS & its successors, most recently z/OS, have something > similar called a GDG (or Generation Data Group). The principle made it into ISO 9660 specifications. To make this thread relevant for Debian, let's assume that somebody asked abo

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On Mon, 8 Jan 2024, at 09:17, Bret Busby wrote: > But, apart from the functionality that I have not seen in any other > operating system, of using an extra file descriptor of version number, > so the whole filename would be something like > .; IBM's MVS & its successors, most recently z/OS, hav

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 8/1/24 08:44, The Wanderer wrote: On 2024-01-07 at 19:20, Nicholas Geovanis wrote: On Sun, Jan 7, 2024, 4:51 PM Charles Curley wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because

Re: systemd-timesyncd

> Quit using Google search. Use DuckDuckGo. Use StartPage instead, aka ixquick.com -- System Information GTK 3.24.39 / GLib 2.78.3 Locale: en_US.UTF-8 (charset: UTF-8) Operating System: Linux 6.6.9-amd64 (x86_64)

Re: systemd-timesyncd

On Mon, 8 Jan 2024 10:02:25 +0700 Max Nikulin wrote: > Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It > might be a reason why systemd-timesyncd did not follow configuration. It is indeed /etc/systemd/timesyncd.conf. However, there is also /etc/systemd/timesyncd.conf.d/, so

Re: systemd-timesyncd

On 08/01/2024 03:36, Andrew M.A. Cater wrote: On Sun, Jan 07, 2024 at 02:51:26PM -0500, gene heskett wrote: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd What package contains the manpages for a bookworm amd64 install I expect to do anything I might want to do? apt install man

Re: systemd-timesyncd

On 08/01/2024 02:51, gene heskett wrote: When I found the /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got this: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It might be a reason why

VAX emulation/simulation (was Re: systemd-timesyncd)

On 2024-01-07 at 19:20, Nicholas Geovanis wrote: > On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: > >> On Sun, 7 Jan 2024 20:36:12 + >> >> "Andrew M.A. Cater" wrote: >>> Gene - no partisan opinions, please, as per Code of Conduct? >> >> Oh, come on! Just because Gene doesn't like cer

Re: systemd-timesyncd

On Sun, Jan 7, 2024, 4:51 PM Charles Curley wrote: > On Sun, 7 Jan 2024 20:36:12 + > "Andrew M.A. Cater" wrote: > > > > Take care, stay warm, well, and unvaxed. > > > ^^^ > > > > Gene - no partisan opinions, please, as per Code of Conduct? > > Oh, come on!

Re: systemd-timesyncd

On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: > > Take care, stay warm, well, and unvaxed. > > ^^^ > > Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because Gene doesn't like certain ancient Digital Equipment

Re: systemd-timesyncd

Hi Gene, Am 07.01.2024 um 20:51 schrieb gene heskett: On 1/7/24 10:48, Max Nikulin wrote: ... systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured). Is it supposed to be installed by the net-inst

Re: systemd-timesyncd

On Sun, Jan 07, 2024 at 02:51:26PM -0500, gene heskett wrote: > On 1/7/24 10:48, Max Nikulin wrote: > > On 07/01/2024 02:17, gene heskett wrote: > > > Is it supposed to be installed by the net-installer? There does not seem to > be any man pages other than the bog std stuff. When I found the > /et

Re: systemd-timesyncd

On 1/7/24 11:24, John Hasler wrote: Gene writes: Lately, everytime I go anywhere near google or a gmail link I get attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You ac

Re: systemd-timesyncd

On 1/7/24 10:48, Max Nikulin wrote: On 07/01/2024 02:17, gene heskett wrote: If debian is going to supply systemd's timesyncd as a client, I expected a bookworm install to just work. It did not and without docs I have to pester the list, which has gotten me a bad rep because the lack of docs f

Re: systemd-boot not asking password, not resuming from hibernate

On 07.01.24 18:07, David Wright wrote: On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted dr

Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat 06 Jan 2024 at 02:57:53 (-0600), Nate Bargmann wrote: > * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: > > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used > > identifiers are based on cities: America/New_York. > > Ugghhh! > > I guess I'll be going to the legacy pa

Re: systemd-boot not asking password, not resuming from hibernate

On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: > I just tried out systemd-boot. What I noticed, it doesn't ask for my > decryption password to decrypt both my LUKS2 encrypted root and swap > partition. This kinda defeats the purpose of encrypted drives. How do > I have systemd-boot f

Re: systemd-timesyncd

Gene writes: > Lately, everytime I go anywhere near google or a gmail link I get > attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You acquired it by visiting an infected or

manpages package [WAS Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat, Jan 06, 2024 at 01:17:13PM -0600, John Hasler wrote: > Try manpages.org . > -- > John Hasler > j...@sugarbit.com > Elmwood, WI USA > If you're on a Debian system, this should already be installed but otherwise apt-get install manpages Also - manpages.debian.org gives you a searchable i

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 12:07, Max Nikulin wrote: On 06/01/2024 18:40, gene heskett wrote: Put all system clocks on UTC, and then /etc/timezone is the actual string specifying the local offset. No doubt some user confusion, but overall a lot simpler. I still do not see any connection with splitting a part

Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

Try manpages.org . -- John Hasler j...@sugarbit.com Elmwood, WI USA

SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 09:25, John Hasler wrote: The documentation for Chrony is: chrony.conf (5) - chronyd configuration file chronyc (1) - command-line interface for chrony daemon chronyd (8) - chrony daemon Also see /usr/share/doc/chrony . Don't use "pool" to sync to a single sour

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 06/01/2024 18:40, gene heskett wrote: Put all system clocks on UTC, and then /etc/timezone is the actual string specifying the local offset. No doubt some user confusion, but overall a lot simpler. I still do not see any connection with splitting a part of files and links into another pack

Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat, Jan 06, 2024 at 02:57:53AM -0600, Nate Bargmann wrote: > I really don't get the fascination with some city hundreds of miles > distant defining the time zone. Why Chicago for US/Central? There are > any number of cities in US/Central that could be referenced, but no, > pick the most notor

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

The documentation for Chrony is: chrony.conf (5) - chronyd configuration file chronyc (1) - command-line interface for chrony daemon chronyd (8) - chrony daemon Also see /usr/share/doc/chrony . Don't use "pool" to sync to a single source. Use "server". man chrony.conf

Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 04:15, Nate Bargmann wrote: * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: US/Eastern & Co has been moved to tzdata-legacy as well. Currently used identifiers are based on cities: America/New_York. Ugghhh! I guess I'll be going to the legacy package then until $WHOEVER_IS_IN_CHARG

was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 01:18, Max Nikulin wrote: On 06/01/2024 12:18, gene heskett wrote: On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium upstream backward file) were moved to tzdata-legacy. This include

Re: tzdata-legacy [was: Re: systemd and timezone]

* On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used > identifiers are based on cities: America/New_York. Ugghhh! I guess I'll be going to the legacy package then until $WHOEVER_IS_IN_CHARGE issues a decree that it too shall be

Re: tzdata-legacy [was: Re: systemd and timezone]

On 06/01/2024 13:02, Max Nikulin wrote: The change affects those who rely on POSIX-like EST5EDT timezones or on obsolete ones like Europe/Kyiv (recently renamed from Europe/Kiev). Europe/Kiev (moved to tzdata-legacy) was renamed to Europe/Kyiv. Sorry for confusion. US/Eastern & Co has been

tzdata-legacy [was: Re: systemd and timezone]

On 06/01/2024 12:18, gene heskett wrote: On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium upstream backward file) were moved to tzdata-legacy. This includes the What's wrong with NTP, too si

Re: systemd and timezone

On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium From 2023c-8 on the tzdata package ships only timezones that follow the current rules of geographical region (continent or ocean) and city n

Re: systemd and timezone

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: > tzdata (2023d-1) unstable; urgency=medium > > From 2023c-8 on the tzdata package ships only timezones that follow the > current rules of geographical region (continent or ocean) and city name. > All legacy timezone syml

Re: systemd and timezone

apt-listchanges: News - tzdata (2023d-1) unstable; urgency=medium From 2023c-8 on the tzdata package ships only timezones that follow the current rules of geographical region (continent or ocean) and city name. All legacy timezone symlinks (old or merged timezones

Re: mktime (was: Re: systemd and timezone)

On Sat, Dec 23, 2023 at 01:09:02PM -0500, Jeffrey Walton wrote: [...] > On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote: > Here's what someone on the libc mailing list suggested: [...] > The person also suggested using Gnulib. My project was not using > Gnulib, so it was not an option. Tha

Re: mktime (was: Re: systemd and timezone)

On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote: > > On 23/12/2023 02:41, Jeffrey Walton wrote: > > I've found lack of per-thread timezones and libc's inability to > > convert time between timezones a bigger problem than other issues, > > like explicitly setting a timezone for a process. > > F

mktime (was: Re: systemd and timezone)

On 23/12/2023 02:41, Jeffrey Walton wrote: I've found lack of per-thread timezones and libc's inability to convert time between timezones a bigger problem than other issues, like explicitly setting a timezone for a process. From my point of view the TZ environment variable makes timezone conve

Re: systemd and timezone

On 12/23/23 01:00, David Wright wrote: On Fri 22 Dec 2023 at 18:52:09 (-0500), Pocket wrote: On 12/22/23 18:04, David Wright wrote: On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote: On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote: 1. https://bugs.debian.org/803144 2. h

  1   2   3   4   5   6   7   8   9   10   >