Re: readutmp backlog

[Thorsten Kukuk]

On Mon, Sep 11, Paul Eggert wrote:

> On 9/10/23 11:27, Thorsten Kukuk wrote:
> > So from my view, I currently don't see something better than wtmpdb and
> > I don't see anybody working on a different solution.
> 
> Thanks for the heads-up.
> 
> I now also see that the latest Linux-PAM release (1.5.3) deprecated 
> pam_lastlog and has suggested using pam_lastlog2 or pam_wtmpdb instead. 
> I assume Gnulib should not worry about pam_lastlog2 since it doesn't map 
> well into either utmp or wtmp.
> 
> Do any of the GCC compile farm machines[1] use wtmpdb? That would be 
> useful for testing Gnulib. I briefly looked at cfarm188 and cfarm118 
> (the two SUSE machines listed) and they didn't seem to be using wtmpdb, 
> though I don't know how to tell for sure. Is there some other easy way 
> to test changes to Gnulib that would use wtmpdb?

If the command "wtmpdb" is installed, they are using wtmpdb.
But the two listed SUSE machines are using openSUSE Leap 15.x, that's too
old.
But wtmpdb can be installed in parallel to any other solution, you  just
need to add the pam_wtmpdb module to your PAM configuration.
There is no impact to /var/log/wtmp or anything else (as long as you
don't install the last compat symlink).

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, 
Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

Re: readutmp backlog

[Paul Eggert]

On 9/10/23 11:27, Thorsten Kukuk wrote:

So from my view, I currently don't see something better than wtmpdb and
I don't see anybody working on a different solution.


Thanks for the heads-up.

I now also see that the latest Linux-PAM release (1.5.3) deprecated 
pam_lastlog and has suggested using pam_lastlog2 or pam_wtmpdb instead. 
I assume Gnulib should not worry about pam_lastlog2 since it doesn't map 
well into either utmp or wtmp.


Do any of the GCC compile farm machines[1] use wtmpdb? That would be 
useful for testing Gnulib. I briefly looked at cfarm188 and cfarm118 
(the two SUSE machines listed) and they didn't seem to be using wtmpdb, 
though I don't know how to tell for sure. Is there some other easy way 
to test changes to Gnulib that would use wtmpdb?


[1]: https://cfarm.tetaneutral.net/machines/list/

Re: Fix some g++ warnings "has a different exception specifier"

[Bruno Haible]

On 2023-09-04 I did:
> 2023-09-04  Bruno Haible  
> 
>   Fix some g++ warnings "has a different exception specifier".
>   * m4/gnulib-common.m4 (gl_COMMON_BODY): Make _GL_ATTRIBUTE_NOTHROW
>   effective in C++ mode.
>   * lib/attribute.h (ATTRIBUTE_NOTHROW): Add a comment.
>   * lib/malloc.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback definition.
>   (memalign): Invoke _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.
>   * lib/stdio.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback definition.
>   (fdopen): Invoke _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.
>   * lib/stdlib.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback definition.
>   (aligned_alloc, calloc, canonicalize_file_name, malloc, realloc): Invoke
>   _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.
>   * lib/string.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback definition.
>   (strdup, strndup): Invoke _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.
>   * lib/sys_stat.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback
>   definition.
>   (getumask): Invoke _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.
>   * lib/wchar.in.h (_GL_ATTRIBUTE_NOTHROW): Provide fallback definition.
>   (wcsdup): Invoke _GL_FUNCDECL_SYS with _GL_ATTRIBUTE_NOTHROW.

Oops, this patch fixed warnings on glibc systems, but causes compilation
errors on FreeBSD and OpenBSD, which use clang as compiler. Seen while
compiling GNU gettext's libasprintf.

glibc is the only system that declares these functions with
noexcept(true) / throw().

And the "has a different exception specifier" condition is a warning with g++,
but a compilation error with clang++.

This patch fixes it.


2023-09-10  Bruno Haible  

Fix clang errors "different exception specifier" (regr. 2023-09-04).
* lib/malloc.in.h (memalign): Don't use _GL_ATTRIBUTE_NOTHROW on
platforms other than glibc systems.
* lib/stdio.in.h (fdopen): Likewise.
* lib/stdlib.in.h (aligned_alloc, calloc, canonicalize_file_name,
malloc, realloc): Likewise.
* lib/string.in.h (strdup, strndup): Likewise.
* lib/sys_stat.in.h (getumask): Likewise.
* lib/wchar.in.h (wcsdup): Likewise.

diff --git a/lib/malloc.in.h b/lib/malloc.in.h
index af94064e79..de0967b591 100644
--- a/lib/malloc.in.h
+++ b/lib/malloc.in.h
@@ -149,10 +149,16 @@ _GL_CXXALIAS_RPL (memalign, void *, (size_t alignment, 
size_t size));
 #  if @HAVE_MEMALIGN@
 #   if __GNUC__ >= 11
 /* For -Wmismatched-dealloc: Associate memalign with free or rpl_free.  */
+#if __GLIBC__ + (__GLIBC_MINOR__ >= 14) > 2
 _GL_FUNCDECL_SYS (memalign, void *,
   (size_t alignment, size_t size)
   _GL_ATTRIBUTE_NOTHROW
   _GL_ATTRIBUTE_DEALLOC_FREE);
+#else
+_GL_FUNCDECL_SYS (memalign, void *,
+  (size_t alignment, size_t size)
+  _GL_ATTRIBUTE_DEALLOC_FREE);
+#endif
 #   endif
 _GL_CXXALIAS_SYS (memalign, void *, (size_t alignment, size_t size));
 #  endif
@@ -163,10 +169,16 @@ _GL_CXXALIASWARN (memalign);
 #else
 # if __GNUC__ >= 11 && !defined memalign
 /* For -Wmismatched-dealloc: Associate memalign with free or rpl_free.  */
+#  if __GLIBC__ + (__GLIBC_MINOR__ >= 14) > 2
 _GL_FUNCDECL_SYS (memalign, void *,
   (size_t alignment, size_t size)
   _GL_ATTRIBUTE_NOTHROW
   _GL_ATTRIBUTE_DEALLOC_FREE);
+#  else
+_GL_FUNCDECL_SYS (memalign, void *,
+  (size_t alignment, size_t size)
+  _GL_ATTRIBUTE_DEALLOC_FREE);
+#  endif
 # endif
 # if defined GNULIB_POSIXCHECK
 #  undef memalign
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
index 684c7a2826..118874d877 100644
--- a/lib/stdio.in.h
+++ b/lib/stdio.in.h
@@ -367,11 +367,18 @@ _GL_CXXALIAS_MDA (fdopen, FILE *, (int fd, const char 
*mode));
 # else
 #  if __GNUC__ >= 11
 /* For -Wmismatched-dealloc: Associate fdopen with fclose or rpl_fclose.  */
+#   if __GLIBC__ + (__GLIBC_MINOR__ >= 2) > 2
 _GL_FUNCDECL_SYS (fdopen, FILE *,
   (int fd, const char *mode)
   _GL_ATTRIBUTE_NOTHROW
   _GL_ARG_NONNULL ((2)) _GL_ATTRIBUTE_DEALLOC (fclose, 1)
   _GL_ATTRIBUTE_MALLOC);
+#   else
+_GL_FUNCDECL_SYS (fdopen, FILE *,
+  (int fd, const char *mode)
+  _GL_ARG_NONNULL ((2)) _GL_ATTRIBUTE_DEALLOC (fclose, 1)
+  _GL_ATTRIBUTE_MALLOC);
+#   endif
 #  endif
 _GL_CXXALIAS_SYS (fdopen, FILE *, (int fd, const char *mode));
 # endif
@@ -379,11 +386,18 @@ _GL_CXXALIASWARN (fdopen);
 #else
 # if @GNULIB_FCLOSE@ && __GNUC__ >= 11 && !defined fdopen
 /* For -Wmismatched-dealloc: Associate fdopen with fclose or rpl_fclose.  */
+#  if __GLIBC__ + (__GLIBC_MINOR__ >= 2) > 2
 _GL_FUNCDECL_SYS (fdopen, FILE *,
   (int fd, const char *mode)
   _GL_ATTRIBUTE_NOTHROW
   _GL_ARG_NONNULL ((2)) _GL_ATTRIBUTE_DEALLOC (fclose, 1)
  

Re: readutmp backlog

[Thorsten Kukuk]

On Sat, Sep 09, Bruno Haible wrote:

> [CCing Sven and Thorsten; the thread starts here:
> https://lists.gnu.org/archive/html/bug-gnulib/2023-09/msg00064.html ]
> 
> Paul Eggert wrote:
> > On 2023-09-09 04:13, Bruno Haible wrote:
> > 
> > >What's the right replacement?
> > >- wtmpdb ? [3]
> > >- journalctl --list-boots ? [4][5]
> > >- last ? [4]
> > 
> > This depends on what platforms using systemd will do (if anything) about 
> > the information currently stored in /var/log/wtmp on GNU/Linux.
> > 
> > As I understand it, systemd currently has no support for wtmp after 
> > 2038, with the idea being that wtmp will go away by then. I also 
> > understand that 'last' simply does what GNU 'who' does, so it'll stop 
> > working too.

Yes, systemd as currently no support for wtmp, except writing the boot
time record if enabled.
And unlike utmp, I don't see any advantage of teaching systemd wtmp
support. There is nothing to "manage", it's just a database with
entries. Since I will be speaking at All Systems Go! the next days I
will hear around what others think, but I doubt that anybody of the
systemd developers will be in favor of implementing wtmp support.

> > As near as I can tell, journalctl isn't really a substitute for 
> > /var/log/wtmp; for that, wtmpdb seems to be the only viable approach 
> > that's implemented.

My first idea was to use journalctl for this, and write a PAM module
which creates appropriate entries. But there are too many problems, like
e.g. the journald database is rotated partly too quick on some systems,
and on others like Raspberry Pi it's far too slow.

wtmpdb was the best I could think about, and it's compatible to last
with a compat symlink (some few last features are missing, but WiP).

> > For what it's worth, Debian is looking into possibly adopting wtmpdb; 
> > see . So if we need advice about what 
> > Gnulib should do, Sven and Thorsten look like they'd be good people to ask.

openSUSE switched to wtmpdb meanwhile, and only one person noticed until
now, because I haven't implemented all last features yet.
But we still have /var/log/wtmp, because we glibc still implements the
functions and we don't want to patch all applications writing wtmp
entries.
ALP, our next code base for our enterprise products, made the switch
already, too.

So from my view, I currently don't see something better than wtmpdb and
I don't see anybody working on a different solution. 

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, 
Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

Re: Code indentation?

[Bruno Haible]

Simon Josefsson wrote:
> what do you think about
> automating running 'indent' on gnulib source code?  Or clang-format,

It would be a bad idea.

There are different things that one can do to a source code:
  (a) Adding or removing spaces at the beginning of lines,
  (b) Reformatting: Changing the position of line breaks.
  (c) Reformatting and removing all comments.

All of these are bad ideas.

Why? Because the indentation levels, the position of line breaks, and
the comments all reflect the author's thoughts.

For this reason, I generally think and respect this rule:

  ** Only the author of some code is entitled to reformatting it. **

If someone reformats someone else's code (without understanding the
author's thoughts), it shows a lack of respect.

It's like going through a city and repainting every art work and
every sculpture in blue.

That's for manual reformatting.

Automated reformatting is even worse. I've seen tools reformatting

  tmp_length =
(unsigned int) (sizeof (unsigned long int) * CHAR_BIT)
+ 1; /* turn floor into ceil */

to

  tmp_length =
(unsigned int) (sizeof (unsigned long int) * CHAR_BIT) + 1; /* turn
   floor
   into
   ceil 
*/

and the corresponding developer then committed this change. I hope you will
acknowledge that this is 1. ugly, 2. does not reflect the author's thoughts.

> some projects have switched because it behaves better for them

That may be the case for projects with contributors who directly commit
code without following the agreed-upon coding style (in this case: GNU style).
But I find it better to tell contributors to change and format their
contribution according to our style, before we accept it, than to later
reformat their code without asking them for permission.

> at least we would then have a process for code indentation style
> conformance in gnulib.

What would it be good for?

If you find parts of gnulib source code hard to read, then please tell us
about it. In an honest, respectful face-to-face manner. But when someone
asks for process changes that disrespect the authors, and that without
mentioning a rationale or a benefit, guess how that feels?

Bruno

Code indentation?

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> * Commit b93de66735cd6f935ee0970f8cb26908d113e09d introduced mcel.h, but
>   it has tabs. Can we untabify
> mcel.h
> mountlist.c
> verify.h
>   (as we do with all source files that are not shared with glibc)?

We may have discussed this before, but what do you think about
automating running 'indent' on gnulib source code?  Or clang-format,
some projects have switched because it behaves better for them, and GNU
indent releases are far between (which may be a good thing because then
we don't have to re-indent code with every new release).

One way forward could be to:

- Somehow set up a way to identify non-indented code - 'make
  indent-check'?

- Run it continously, maybe through some CICD step with output to a web
  page.

- Have an exclusion list to opt out of the report.

- Manually go through each identified indentation mis-match and propose
  a fix and check if the module maintainer agrees with it, then either
  commit the indentation fix or add the file to the exclusion list.

This will take a long time, and I'm not sure it is a good idea, but at
least we would then have a process for code indentation style
conformance in gnulib.

Maybe there are other approaches to this too.

/Simon


signature.asc
Description: PGP signature