bug#55709: R texinfo documents are not showing up for me
I had a really hard time getting ~guix gc --verify=contents,repair~ to actually fix the problem and get commands like emacs to run. Nothing worked until I mounted /gnu/store as read write and removed the zeroed file completely for that particular gtk+3.24.30 folder, removed the ~guix/store/.links~ folder, and then finally reran the ~guix gc ...~ command. That was after doing a fsck as well. Hat tip to Tobias for spending a good chunk of saturday helping me through this. He though this might be related to issue 50121 after I referred him to it. Cheers, Kyle Liliana Marie Prikler writes: > Am Dienstag, dem 31.05.2022 um 10:37 +0200 schrieb Maxime Devos: >> (Is there a method to verify and repair a _single_ store item instead >> of the whole store?). > I think the syntax for that'd be ‘[sudo] guix build --repair > STORE_ITEM’. > > Cheers
bug#55488: bug#55707: syslogd logging kernel messages slowly?
Ludovic Courtès skribis: > 2. Explicitly disable syncing for some of the log files by prepending > a hyphen right before the file name in syslogd.conf (info > "(inetutils) syslogd invocation"). Tried this (in addition to ‘fdatasync’): --8<---cut here---start->8--- (define %default-syslog.conf (plain-file "syslog.conf" " # Log all error messages, authentication messages of # level notice or higher and anything of level err or # higher to the console. # Don't log private authentication messages! *.alert;auth.notice;authpriv.none -/dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages *.=debug -/var/log/debug # Same, in a different place. *.info;mail.none;authpriv.none -/dev/tty12 # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog ")) --8<---cut here---end--->8--- In addition to the hyphens, notice that now only debugging info goes to /var/log/debug (previously everything going to /var/log/messages would also go to /var/log/debug, which is kinda silly). This halves the number of ‘fdatasync’ calls and thus doubles the throughput, but we’re still spending ~0.1s on ‘fdatasync’ for each line, which is slow. So the next solution is to not ‘fdatasync’ on /var/log/messages either: --8<---cut here---start->8--- (define %default-syslog.conf (plain-file "syslog.conf" " # Log all error messages, authentication messages of # level notice or higher and anything of level err or # higher to the console. # Don't log private authentication messages! *.alert;auth.notice;authpriv.none -/dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none -/var/log/messages # Log \"debug\"-level entries and nothing else. *.=debug -/var/log/debug # Same, in a different place. *.info;mail.none;authpriv.none -/dev/tty12 # The authpriv file has restricted access. # 'fsync' the file after each line. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog ")) --8<---cut here---end--->8--- With this, the system boots much more quickly. I’m tempted to commit the above syslog.conf. From a look at the code and doc, it seems that neither rsyslog nor systemd-journald does anything like “fsync after each logged line”, so the config above sounds like a reasonable default (at any rate, the current default is definitely unreasonable on slow spinning disks). I’m curious to see if it fixes your other boot-up issues, timeouts and all, Luis. Ludo’.
bug#55707: syslogd logging kernel messages slowly?
Ludovic Courtès skribis:
> 1. Use ‘fdatasync’ rather than ‘fsync’;
Turns out ‘fdatasync’ is about as expensive:
--8<---cut here---start->8---
1234:301 19:22:00 fdatasync(6) = 0 <0.398749>
1236:301 19:22:01 fdatasync(5) = 0 <0.198520>
1243:301 19:22:01 fdatasync(6) = 0 <0.231935>
1245:301 19:22:01 fdatasync(5) = 0 <0.183503>
1252:301 19:22:01 fdatasync(6) = 0 <0.230854>
1254:301 19:22:02 fdatasync(5) = 0 <0.248839>
1261:301 19:22:02 fdatasync(6) = 0 <0.181513>
1263:301 19:22:02 fdatasync(5) = 0 <0.141267>
1270:301 19:22:02 fdatasync(6) = 0 <0.131548>
1272:301 19:22:02 fdatasync(5) = 0 <0.124369>
1279:301 19:22:02 fdatasync(6) = 0 <0.121414>
--8<---cut here---end--->8---
Tested with:
--8<---cut here---start->8---
(define inetutils/fdatasync
(package/inherit inetutils
(version (string-append (package-version inetutils) ".fdatasync"))
(source (origin
(inherit (package-source inetutils))
(modules '((guix build utils)))
(snippet
'(substitute* "src/syslogd.c"
(("fsync") "fdatasync")))
--8<---cut here---end--->8---
It still makes more sense than ‘fsync’ though.
Ludo’.
bug#55707: bug#55488: GDM, GNOME: Can't start desktop session after upgrade
Hi,
Ludovic Courtès skribis:
> Here’s another debugging trick; would be great if you could try this:
>
> (define strace-syslogd
> (program-file "strace-syslogd"
> #~(apply execl #$(file-append strace "/bin/strace")
> "strace" ;argv[0]
> "-f" "-Tt" "-o" "/syslogd.log" "-s" "80"
> #$(file-append inetutils "/libexec/syslogd")
> (cdr (command-line)
>
>
> and then:
>
> (modify-services %desktop-services
> (syslog-service-type
>_ => (syslog-configuration
> (syslogd strace-syslogd
>
> This creates a log file, /syslogd.log, which will allow us to see the
> time it takes syslogd to read from /proc/kmsg and hopefully to determine
> the origin of delays.
I tried this on a machine I have access to that exhibits this slowness,
and here’s what I get (excerpt that spans 2+ seconds of syslogd
activity):
--8<---cut here---start->8---
328 18:46:13 openat(AT_FDCWD, "/dev/console", O_WRONLY|O_CREAT|O_APPEND,
0644) = 4 <0.99>
328 18:46:13 openat(AT_FDCWD, "/var/log/messages", O_WRONLY|O_CREAT|O_APPEND,
0644) = 5 <0.75>
328 18:46:13 ioctl(5, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate
ioctl for device) <0.000261>
328 18:46:13 openat(AT_FDCWD, "/var/log/debug", O_WRONLY|O_CREAT|O_APPEND,
0644) = 6 <0.000201>
328 18:46:13 ioctl(6, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate
ioctl for device) <0.000138>
328 18:46:13 openat(AT_FDCWD, "/dev/tty12", O_WRONLY|O_CREAT|O_APPEND, 0644)
= 7 <0.001059>
328 18:46:13 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0
<0.000101>
328 18:46:13 openat(AT_FDCWD, "/var/log/secure", O_WRONLY|O_CREAT|O_APPEND,
0644) = 8 <0.77>
328 18:46:13 ioctl(8, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate
ioctl for device) <0.39>
328 18:46:13 openat(AT_FDCWD, "/var/log/maillog", O_WRONLY|O_CREAT|O_APPEND,
0644) = 9 <0.70>
[…]
328 18:46:13 read(3, "<5>[0.00] Linux version 5.17.11-gnu (guix@guix)
(gcc (GCC) 10.3.0, GNU l"..., 1024) = 981 <0.83>
328 18:46:13 rt_sigprocmask(SIG_BLOCK, [HUP ALRM], [], 8) = 0 <0.59>
322 18:46:13 +++ exited with 0 +++
328 18:46:13 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444,
st_size=2962, ...}, 0) = 0 <0.49>
328 18:46:13 writev(7, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\r\n", iov_len=2}], 6) = 152
<0.86>
328 18:46:13 fsync(7) = -1 EINVAL (Invalid argument)
<0.36>
328 18:46:13 writev(6, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\n", iov_len=1}], 6) = 151
<0.63>
328 18:46:13 fsync(6) = 0 <0.380857>
328 18:46:13 writev(5, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\n", iov_len=1}], 6) = 151
<0.79>
328 18:46:13 fsync(5) = 0 <0.131763>
328 18:46:13 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000213>
328 18:46:13 rt_sigprocmask(SIG_BLOCK, [HUP ALRM], [], 8) = 0 <0.000160>
328 18:46:13 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444,
st_size=2962, ...}, 0) = 0 <0.49>
328 18:46:13 writev(7, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Command line:
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314},
{iov_base="\r\n", iov_len=2}], 6) = 342 <0.000123>
328 18:46:13 fsync(7) = -1 EINVAL (Invalid argument)
<0.40>
328 18:46:13 writev(6, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Command line:
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314}, {iov_base="\n",
iov_len=1}], 6) = 341 <0.74>
328 18:46:13 fsync(6) = 0 <0.23>
328 18:46:13 writev(5, [{iov_base="Jun 4 18:46:13", iov_len=15}, {iov_base="
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1},
{iov_base="vmunix: [0.00] Command line:
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314}, {iov_base="\n",
iov_len=1}], 6) = 341 <0.000156>
328 18:46:13 fsync(5) = 0 <0.099143>
328 18:46:14 r
bug#55793: Issue with elfutils libdw pkg-config's inputs
Hi,
there appears to be an issue with the elfutils package that is missing
a dependency after it is installed.
To reproduce, on a profile without `xz' installed:
$ guix install elfutils
$ pkg-config --cflags libdw
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libdw', not found
or using gstreamer which depends on elfutils
$ guix shell --check gstreamer pkg-config --pure
$ pkg-config --cflags libdw
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libdw', not found
This is because elfutils has discovered an installation of the `xz'
library during the configure phase (log @
http://ci.guix.gnu.org/log/jp6027624wl2f4xx5yz1vjzd2b9yvwl9-elfutils-0.183)
...
checking for library containing gzdirect... -lz
checking for library containing BZ2_bzdopen... -lbz2
checking for library containing lzma_auto_decoder... -llzma
checking for library containing ZSTD_decompress... no
...
even though it is not part of the package inputs
gnu/packages/elf.scm:
(define-public elfutils
(package
(name "elfutils")
(version "0.183")
;; ...
(native-inputs (list m4))
(inputs (list zlib))
;; ...
))
The `xz' package is most likely coming as an implicit input from the
commencement module's %final-inputs and thus picked up by the
configure script, but is never propagated.
Assuming the above analysis is correct, potential solutions could be:
1. Declare `xz` as a propagated input in elfutils.
2. Pass --without-lzma to the configure script.
3. Change the build scripts so that build inputs that are only used
for unpacking sources are only visible to unpack phase.
Looking closer at the configure output, it appears there is an
additional implicit input that is picked up by the configure script
`bzip2`, thus this should also be considered.
Furthermore, the configure script recommends that all compression
methods should be installed
RECOMMENDED FEATURES (should all be yes)
gzip support : yes
bzip2 support : yes
lzma/xz support: yes
zstd support : no
libstdc++ demangle support : yes
File textrel check : yes
Symbol versioning : yes
so perhaps option#1 above should be the preferred solution, and should
also include zstd as a dep? If so, I've created the following draft
to demonstrate its use
>From 158b3f67fdd43b4e9b6ac1d46d27169e4f67c4de Mon Sep 17 00:00:00 2001
Subject: [PATCH] Include elfutils recommended inputs for libdw pc
---
gnu/packages/elf.scm | 4
1 file changed, 4 insertions(+)
diff --git a/gnu/packages/elf.scm b/gnu/packages/elf.scm
index 414d6a2856..cfe3bd466a 100644
--- a/gnu/packages/elf.scm
+++ b/gnu/packages/elf.scm
@@ -109,6 +109,10 @@ (define-public elfutils
(native-inputs (list m4))
(inputs (list zlib))
+;; libdw dependencies
+(propagated-inputs `(("xz" ,xz)
+ ("lbzip2" ,lbzip2)
+ ("zstd:lib" ,zstd "lib")))
(home-page "https://sourceware.org/elfutils/";)
(synopsis "Collection of utilities and libraries to handle ELF files and
DWARF data")
--
2.34.0
Testing with gstreamer
$ pre-inst-env guix shell --check gstreamer pkg-config --pure
guix shell: checking the environment variables visible from shell '/bin/bash'...
guix shell: All is good! The shell gets correct environment variables.
$ pkg-config --cflags libdw
-I/gnu/store/yvf3j3gd3321k9n1wd9ycfaz7blbp8v6-elfutils-0.183/include
-I/gnu/store/aggsb6j1svxp70xlll4rqnx5f2pzz794-xz-5.2.5/include
-I/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib/include
-I/gnu/store/yvf3j3gd3321k9n1wd9ycfaz7blbp8v6-elfutils-0.183/include
-I/gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11/include
Thanks
bug#55657: libgccjit is unusable
Am Samstag, dem 04.06.2022 um 14:25 + schrieb Tobias Geerinckx- Rice: > Meant to include link to > https://github.com/flatwhatson/guix-channel/blob/657da22f0229b978b7bf4e4d476f59f17f6a175f/flat/packages/gcc.scm#L27 > which is where the majic happens I'm not personally using that channel, but I noticed this issue by trying to adapt that recipe towards master. Now there's a chance that I've made an error in my copypasta game, but I'm pretty sure the current state of libgccjit is not a good one regardless. Cheers
bug#55776: maven-core fails to build
Julien Lepiller writes: > What I did instead is, since jdom wants to set more features than > supported in the driver, to add dummy support for all these additional > features by just not throwing the exception. It's not very satisfying, > but it works and we don't keep a vulnerable jdom around. With the > attached patch, I built up to maven. Thank you! The patch looks clear enough — will you push it? Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
bug#55776: maven-core fails to build
2022/06/04 15:47, Julien Lepiller: > So I figured I could fix java-plexus-component-metadata that we use to > generate some xml files during the build of maven. jdom is one of its > inputs. Adding another jdom to the native inputs would probably not fix > the issue. Reverting the jdom upgrade patch, I did get mave-core to build. I admit I did not try running it. My interest in maven is as a dependency to clojure-tools, I don't really know how to test maven is actually working by itself. > What I did instead is, since jdom wants to set more features than > supported in the driver, to add dummy support for all these additional > features by just not throwing the exception. It's not very satisfying, > but it works and we don't keep a vulnerable jdom around. With the > attached patch, I built up to maven. Smart! I look forward to seeing your patch land in the main branch. Cheers, Remco
bug#55657: libgccjit is unusable
Meant to include link to https://github.com/flatwhatson/guix-channel/blob/657da22f0229b978b7bf4e4d476f59f17f6a175f/flat/packages/gcc.scm#L27 which is where the majic happens Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
bug#55657: libgccjit is unusable
Lily, I think a lot of people are using emacs-native-comp from here: https://github.com/flatwhatson/guix-channel/blob/master/flat/packages/emacs.scm I don't know if I've updated mine since your failed experiments, but it has worked forever... Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
bug#55657: libgccjit is unusable
2022/05/26 15:07, Liliana Marie Prikler: > Hi Guix, > > with the release of Emacs 28.1, there has been some demand to enable > native-compilation. While trying to set that up, I've come to realize > that no matter how I slice it, I can't make libgccjit usable. The guixrus channel has an emacs which seems to support gccjit. I have not tried it myself. https://git.sr.ht/~whereiseveryone/guixrus/ Especially: https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/emacs.scm https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/gcc.scm Maybe you can borrow some knowledge there? ;-) Cheers, Remco
bug#55776: maven-core fails to build
Le Sat, 04 Jun 2022 12:25:21 +0200,
Remco van 't Veer a écrit :
> I did some digging and found this regression is caused by commit:
>
> 6068b83b82475566acd4162467bcf54270f338f9
> "gnu: java-jdom: Update to 2.0.6.1 [fixes CVE-2021-33813]."
>
> Apparently the fix for this issue causes jdom to be very strict;
>
> > java.io.IOException: Invalid input descriptor for merge:
> > /tmp/plexus-metadata3957336728290309540xml -->
> > http://xml.org/sax/features/external-general-entities feature
> > http://xml.org/sax/features/external-general-entities not supported
> > for SAX driver org.codehaus.plexus.metadata.merge.Driver
>
> Which sound familiar when looking at that CVE
> (https://github.com/advisories/GHSA-2363-cqg2-863c):
>
> > An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to
> > cause a denial of service via a crafted HTTP request. At this time
> > there is not released fixed version of JDOM. As a workaround, to
> > avoid external entities being expanded, one can call
> > builder.setExpandEntities(false) and they won't be expanded.
>
> I dunno how to fix this though, I'm just a curious guixer. Easiest
> path seems to be to make a new java-jdom-2.0.6 var and use that as a
> native-input for maven. Would that be an acceptable solution?
>
> Cheers,
> Remco
>
Like you say, the issue is with the new jdom. Believe it or not, but
between 2.0.6 and 2.0.6.1 there's some breakage (and > 1 year of
changes, too)!
So I figured I could fix java-plexus-component-metadata that we use to
generate some xml files during the build of maven. jdom is one of its
inputs. Adding another jdom to the native inputs would probably not fix
the issue.
What I did instead is, since jdom wants to set more features than
supported in the driver, to add dummy support for all these additional
features by just not throwing the exception. It's not very satisfying,
but it works and we don't keep a vulnerable jdom around. With the
attached patch, I built up to maven.
>From 2523b6c6b3f81f8a86b7c768dfed9dae97978e93 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Sat, 4 Jun 2022 15:41:41 +0200
Subject: [PATCH] gnu: java-plexus-component-metadata: Fix package.
* gnu/packages/java.scm (java-plexus-component-metadat): Apply fix for
newer jdom.
---
gnu/packages/java.scm | 8
1 file changed, 8 insertions(+)
diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 336e84e3e5..f475f7c270 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -4537,6 +4537,14 @@ (define-public java-plexus-component-metadata-1.7
(copy-recursively "src/main/resources"
"build/classes/")
#t))
+ (add-before 'build 'fix-jdom
+ (lambda _
+ ;; The newer version of jdom now sets multiple features by default
+ ;; that are not supported.
+ ;; Skip these features
+ (substitute* "src/main/java/org/codehaus/plexus/metadata/merge/MXParser.java"
+ (("throw new XmlPullParserException\\(\"unsupporte feature \"\\+name\\);")
+"// skip"
(add-before 'check 'fix-test-location
(lambda _
(substitute* '("src/test/java/org/codehaus/plexus/metadata/DefaultComponentDescriptorWriterTest.java"
--
2.35.1
bug#55776: maven-core fails to build
I did some digging and found this regression is caused by commit: 6068b83b82475566acd4162467bcf54270f338f9 "gnu: java-jdom: Update to 2.0.6.1 [fixes CVE-2021-33813]." Apparently the fix for this issue causes jdom to be very strict; > java.io.IOException: Invalid input descriptor for merge: > /tmp/plexus-metadata3957336728290309540xml --> > http://xml.org/sax/features/external-general-entities feature > http://xml.org/sax/features/external-general-entities not supported > for SAX driver org.codehaus.plexus.metadata.merge.Driver Which sound familiar when looking at that CVE (https://github.com/advisories/GHSA-2363-cqg2-863c): > An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to > cause a denial of service via a crafted HTTP request. At this time > there is not released fixed version of JDOM. As a workaround, to avoid > external entities being expanded, one can call > builder.setExpandEntities(false) and they won't be expanded. I dunno how to fix this though, I'm just a curious guixer. Easiest path seems to be to make a new java-jdom-2.0.6 var and use that as a native-input for maven. Would that be an acceptable solution? Cheers, Remco
bug#55449: [PATCH] gnu: recutils: Use correct bash headers.
* gnu/packages/databases.scm (recutils)[arguments]: Convert to G-Expressions.
Drop gratuitous dirname.
[native-inputs]: Drop labels. Move bash:include...
[inputs]: ... here. Also add regular bash.
---
gnu/packages/databases.scm | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 09d825af3e..5cd8cc2fa3 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -1527,20 +1527,17 @@ (define-public recutils
(build-system gnu-build-system)
(arguments
(list #:configure-flags
- '(list "--disable-static"
- (string-append "--with-bash-headers="
- (dirname (search-input-directory
- %build-inputs
- "include/bash"))
+ #~(list "--disable-static"
+ (string-append "--with-bash-headers="
+ (search-input-directory %build-inputs
+ "include/bash")
(native-inputs
- ;; XXX Without labels, the default 'configure phase picks the wrong
"bash".
- `(("bc" ,bc)
- ("bash:include" ,bash "include")
- ("check" ,check-0.14)
- ("pkg-config" ,pkg-config)))
+ (list bc check-0.14 pkg-config))
(inputs
;; TODO: Add more optional inputs.
- (list curl
+ (list bash ; /bin/bash for native compilation
+ `(,bash "include")
+ curl
libgcrypt
`(,util-linux "lib")))
(synopsis "Manipulate plain text files as databases")
--
2.36.1
