bug#51258: [PATCH] gnu: emacs: Handle pdump filenames that contain a fingerprint
From: Morgan Smith * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Add regex to handle filenames that have a fingerprint in them --- Fixed your problem. Well it was also my problem. The regex is pretty simple but probably a little intimidating if you've never done it before. I highly recommend reading up on ERE's and BRE's from the POSIX specification if you have time. I still don't exactly know how guile does regex but knowing POSIX regex has served me quite well. I've tested this patch and it works great for me on the latest emacs commit. It should also be backwards compatible so that's nice. gnu/packages/emacs.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index 6d9950d068..6ebcfecbc7 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -183,9 +183,10 @@ (define* (emacs-byte-compile-directory dir) (let* ((libexec (string-append (assoc-ref outputs "out") "/libexec")) ;; each of these find-files should return one file -(pdmp (find-files libexec "^emacs\\.pdmp$")) +;; there might be a fingerprint in the name +(pdmp (find-files libexec "^emacs(-[[:xdigit:]]+)?\\.pdmp$")) (pdmp-real (find-files libexec - "^\\.emacs\\.pdmp-real$"))) + "^\\.emacs(-[[:xdigit:]]+)?\\.pdmp-real$"))) (for-each (lambda (wrapper real) (delete-file wrapper) (rename-file real wrapper)) -- 2.33.0
bug#50977: digital-ocean-environment-type fails
I've done some more digging. There are various issues with the script
that actually converts the Debian 9 Droplet to Guix.
1. The SSL certificates of gnu.org fail on Debian 9 (since end of Sep).
This appears to be related to a change in LetsEncrypt root certificates
2. The guix binary used is rather old
I don't have time to submit a merge request now. I have adapted the
included script to work on Debian 9 (uncomment 1x line), 11 and Ubuntu
21.04. This should be good until the bug has been resolved.
```
#!/bin/bash
# Guix 1.3.0 on DigitalOcean
# Convert Debian 11 or Ubuntu 21.04
## MODIFY
TIMEZONE="Europe/Berlin"
LOCALE="en_US.utf8"
USERNAME="guix"
USER_COMMENT="guix's account"
USER_PASSWORD="Gq2M6JqNS2W6mgkY"
## MODIFY END
CONFIG=/etc/bootstrap-config.scm
CRYPT='$6$abc'
apt-get update -y
apt-get install curl xz-utils -y
# Uncomment this for Debian 9
# sed -i '/^mozilla\/DST_Root_CA_X3/s/^/!/' /etc/ca-certificates.conf
&& update-ca-certificates -f wget
https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz cd
/tmp tar --warning=no-timestamp -xf
~/guix-binary-1.3.0.x86_64-linux.tar.xz mv var/guix /var/ && mv gnu /
mkdir -p ~root/.config/guix
ln -sf /var/guix/profiles/per-user/root/current-guix
~root/.config/guix/current export GUIX_PROFILE="`echo
~root`/.config/guix/current" ; source $GUIX_PROFILE/etc/profile
groupadd --system guixbuild
for i in `seq -w 1 10`;
do
useradd -g guixbuild -G guixbuild \
-d /var/empty -s `which nologin` \
-c "Guix build user $i" --system \
guixbuilder$i;
done;
cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service
/etc/systemd/system/ systemctl start guix-daemon && systemctl enable
guix-daemon mkdir -p /usr/local/bin
cd /usr/local/bin
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
mkdir -p /usr/local/share/info
cd /usr/local/share/info
for i in /var/guix/profiles/per-user/root/current-guix/share/info/*; do
ln -s $i; done
guix archive --authorize <
~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub # guix pull
guix package -i glibc-utf8-locales
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
guix package -i openssl
HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
PUBLIC_IPV4=$(curl -s
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
NETMASK=$(curl -s
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/netmask)
GATEWAY=$(curl -s
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/gateway)
function write_server_config() {
cat >> $CONFIG <
bug#51227: failed build of ghc-8.8.4 (on guix c27c196)
Hi Lars-Dominik, Lars-Dominik Braun writes: > Hi, > >> I'm trying to upgrade one of my profiles to guix c27c196 but I get this >> error: >> […] >> cannot build derivation >> `/gnu/store/jvmn4djjbi1hy1zwrwn5g50d94xazlhc-ghc-8.10.7.drv': 1 dependencies >> couldn't be built > is this still an issue and if so what architecture are you on? no, I tried again minutes ago and now the installation is OK; I'm on x86_64 AFAIU this time the package ghc-8.10.7 was installed as a substitute and not locally compiled. Anyway, I also tried to build ghc-8.8.4: --8<---cut here---start->8--- giovanni@roquette: guix build --no-substitutes ghc@8.8.4 The following derivation will be built: /gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv process 6024 acquired build slot '/var/guix/offload/batondor:22/0' normalized load on machine 'batondor' is 0.00 building /gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv... guix offload: sending 0 store items (0 MiB) to 'batondor'... offloading '/gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv' to 'batondor'... offloading build of /gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv to 'batondor' substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% @ substituter-started /gnu/store/15lwllr6c41awp5hlj4yjgd4msznfm8v-ghc-8.8.4-doc substitute Downloading https://ci.guix.gnu.org/nar/lzip/15lwllr6c41awp5hlj4yjgd4msznfm8v-ghc-8.8.4-doc... ghc-8.8.4-doc 4.2MiB 2.5MiB/s 00:02 [##] 100.0% @ substituter-succeeded /gnu/store/15lwllr6c41awp5hlj4yjgd4msznfm8v-ghc-8.8.4-doc @ substituter-started /gnu/store/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4 substitute Downloading https://ci.guix.gnu.org/nar/lzip/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4... ghc-8.8.4 113.9MiB 2.8MiB/s 00:41 [##] 100.0% @ substituter-succeeded /gnu/store/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4 retrieving 1 store item from 'batondor'... importing file or directory '/gnu/store/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4'... found valid signature for '/gnu/store/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4' registering 1 items done with offloaded '/gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv' successfully built /gnu/store/sa6hi6kwnvyk4a63rs1q86cimgzi4zpp-ghc-8.8.4.drv /gnu/store/15lwllr6c41awp5hlj4yjgd4msznfm8v-ghc-8.8.4-doc /gnu/store/18jgsy1xvds5xplmrj8wngdb69chzisg-ghc-8.8.4 --8<---cut here---end--->8--- I really don't understand why on Friday the very same build failed. Anyway I'm going to close this bug report: thanks! Happy hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#51261: Guix from qcow2 image refuses to boot after reconfigure
It's because `/dev/vda1` is mounted to `/`. If I change that to `/dev/vda2` it works again :)
bug#50977: digital-ocean-environment-type fails
I just ran into the same issue on a droplet in a different region. The only detail that stands out is that 'private_networking' as seen here [1] has been depreciated on the DO API [2]. I doubt that is the reason this is failing though. > This parameter has been deprecated. Use vpc_uuid instead to specify a > VPC network for the Droplet. If no vpc_uuid is provided, the Droplet > will be placed in your account's default VPC for the region. [1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/machine/digital-ocean.scm#n339 [2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/machine/digital-ocean.scm#n339 Here's the related config: (list (machine (operating-system %system) (environment digital-ocean-environment-type) (configuration (digital-ocean-configuration (region "fra1") (size "s-1vcpu-1gp") (ssh-key "/home/franz/.ssh/do_staging") (tags (list "pantherx" "staging")) (enable-ipv6? #f)
bug#51259: Cannot build Guix from source (error messages about the translations)
On Mon, Oct 18, 2021 at 07:23:40AM -0400, Julien Lepiller wrote: > Hi Leo, > > Looks like something is wrong with your setup… are you running in "guix > environment guix"? What's your $LANG? Yes, it's in a "pure" environment. Normally LANG=en_US.UTF-8, but in the pure environment, LANG is unset. In both cases, LC_ALL is unset.
bug#51259: Cannot build Guix from source (error messages about the translations)
I managed to reproduce the issue on fedora, in a broken pure environmert. In a pure environment, fedora gives error messages about software that doesn't exist, and asks if I want to install them. If I ^C at that point, I enter the environment, but some things are missing. There are litteral ?? in manuals that don't use ascii, and this is especially visible in the korean manual. Po4a works fine in my experimentation, but it looks like the po parser or regular expression matching is broken at the POXREF phase, and everything is copied as literal ??. Maybe setting LANG to a UTF-8 locale in the poxref rule would help? It didn't hix the issue in my case, but I think that's because I'm missing even more variables. Le 18 octobre 2021 07:54:08 GMT-04:00, Tobias Geerinckx-Rice via Bug reports for GNU Guix a écrit : >Leo Famulari 写道： >> ./doc/guix.ko.texi:431: here is the previous definition as @node >> ./doc/guix.ko.texi:2065: @node `??' previously defined > >This seems to hint at a locale error, and indeed it was: when I >check out a fresh guix.git and build it in a recent ‘guix >environment guix’ on Guix System, I get the same error as you. > >When I repeat the exact same steps but first set > > $ export LC_ALL=en_IE.utf8 > >in the environment, the build goes swimmingly. > >I only ran each test once so it could be a coincidence, but I >doubt it. > >As for the actual error… > >> ./doc/guix.ko.texi:431: here is the previous definition as @node >> ./doc/guix.ko.texi:2065: @node `??' previously defined > >At the risk of being naive: could it simply be that the missing >locale turns the Korean UTF-8 into a literal ‘??’, which of >course matches another mangled @node string of the same length? > >Kind regards, > >T G-R
bug#51259: Cannot build Guix from source (error messages about the translations)
Leo Famulari 写道： ./doc/guix.ko.texi:431: here is the previous definition as @node ./doc/guix.ko.texi:2065: @node `??' previously defined This seems to hint at a locale error, and indeed it was: when I check out a fresh guix.git and build it in a recent ‘guix environment guix’ on Guix System, I get the same error as you. When I repeat the exact same steps but first set $ export LC_ALL=en_IE.utf8 in the environment, the build goes swimmingly. I only ran each test once so it could be a coincidence, but I doubt it. As for the actual error… ./doc/guix.ko.texi:431: here is the previous definition as @node ./doc/guix.ko.texi:2065: @node `??' previously defined At the risk of being naive: could it simply be that the missing locale turns the Korean UTF-8 into a literal ‘??’, which of course matches another mangled @node string of the same length? Kind regards, T G-R signature.asc Description: PGP signature
bug#51259: Cannot build Guix from source (error messages about the translations)
Hi Leo, Looks like something is wrong with your setup… are you running in "guix environment guix"? What's your $LANG? Le 18 octobre 2021 00:01:28 GMT-04:00, Leo Famulari a écrit : >I noticed today that I can't build Guix from a fresh Git checkout in the >usual manner. Something goes wrong while building the Korean language >info manual. I tested it several times and on two different computers, >both x86_64. > >-- >$ guix describe >Generation 23 Oct 18 2021 00:23:51(current) > guix 473ea16 >repository URL: https://git.savannah.gnu.org/git/guix.git >branch: master >commit: 473ea161a15a13e7d5e7e0724693c1931ff8daaa >$ git describe >v1.3.0-7022-g473ea161a1 >$ guix environment --pure guix >$ ./bootstrap && ./configure --localstatedir=/var && make -j1 >[... bootstrap and configure succeed ...] >Updating ./doc/version.texi > MAKEINFO doc/guix.de.info > MAKEINFO doc/guix.es.info >./doc/guix.es.texi:16554: warning: `.' or `,' must follow @xref, not p >./doc/guix.es.texi:37439: warning: `.' or `,' must follow @xref, not p > MAKEINFO doc/guix.fa.info > MAKEINFO doc/guix.fr.info >./doc/guix.fr.texi:12628: warning: `.' or `,' must follow @xref, not p > MAKEINFO doc/guix.it.info > MAKEINFO doc/guix.ko.info >Use of uninitialized value in hash element at >/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm > line 639. >Use of uninitialized value in hash element at >/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm > line 639. >Use of uninitialized value in hash element at >/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm > line 639. >./doc/guix.ko.texi:604: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:2065: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:2538: @node `?? ??' previously defined >./doc/guix.ko.texi:2262: here is the previous definition as @node >./doc/guix.ko.texi:2739: @node `' previously defined >./doc/guix.ko.texi:884: here is the previous definition as @node >./doc/guix.ko.texi:2940: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >./doc/guix.ko.texi:2973: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:4933: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:5459: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:10011: @node `' previously defined >./doc/guix.ko.texi:884: here is the previous definition as @node >./doc/guix.ko.texi:13272: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >./doc/guix.ko.texi:14606: @node `' previously defined >./doc/guix.ko.texi:884: here is the previous definition as @node >./doc/guix.ko.texi:31230: @node `?? ?' previously defined >./doc/guix.ko.texi:13804: here is the previous definition as @node >./doc/guix.ko.texi:35444: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >./doc/guix.ko.texi:35642: @node `?? ?' previously defined >./doc/guix.ko.texi:13804: here is the previous definition as @node >doc/contributing.ko.texi:1: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >doc/contributing.ko.texi:31: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >doc/contributing.ko.texi:229: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >doc/contributing.ko.texi:318: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >doc/contributing.ko.texi:423: @node `? ?? ?' previously >defined >./doc/guix.ko.texi:2623: here is the previous definition as @node >doc/contributing.ko.texi:690: @node `? ??' previously defined >./doc/guix.ko.texi:2029: here is the previous definition as @node >doc/contributing.ko.texi:777: @node `?? ?' previously defined >./doc/guix.ko.texi:13804: here is the previous definition as @node >doc/contributing.ko.texi:796: @node `??? ??' previously defined >doc/contributing.ko.texi:762: here is the previous definition as @node >doc/contributing.ko.texi:833: @node `??' previously defined >./doc/guix.ko.texi:431: here is the previous definition as @node >doc/contributing.ko.texi:869: @node `?? ??' previously defined >./doc/guix.ko.texi:2262: here is the previous definition as @node >doc/contributing.ko.texi:883: @node
bug#51258: emacs-next/git-master broken due to pdmp file naming changes
As of Emacs commit e81f1faca4382ed5c8f15fec84fb7c900a5468f9, building
emacs-next
with the git-master branch will cause some problems on Guix. The
"emacs-next"
build itself will work without any errors, but it will complain whenever
you try
run it:
> emacs: could not load dump file
> "/gnu/store/a5bx5v96snvgiv9r1b7i1im5ccn5mz54-emacs-next-git.master/libexec/emacs/29.0.50/x86_64-pc-linux-gnu/emacs-66e6890a5565f2bed1ee56075d21e0051d891a59200cdd092c0946403fb84ac2.pdmp":
> not a dump file
This will also cause new builds of packages that use
emacs-next/git-master as an
input to fail as well, with a version of the same error. Here's a
(failed) build
log for emacs-pdf-tools:
> [top part snipped]
>
> make[1]: Leaving directory
> '/tmp/guix-build-emacs-pdf-tools-0.90-2.5f77dae.drv-0/source/server'
> phase `install' succeeded after 0.3 seconds
> starting phase `patch-shebangs'
> phase `patch-shebangs' succeeded after 0.0 seconds
> starting phase `strip'
> stripping binaries in
> "/gnu/store/swfjir05k1bg22l50yawhibbv0y5qhr9-emacs-pdf-tools-0.90-2.5f77dae/bin"
> with "strip" and flags ("--strip-debug" "--enable-deterministic-archives")
> phase `strip' succeeded after 0.0 seconds
> starting phase `validate-runpath'
> validating RUNPATH of 1 binaries in
> "/gnu/store/swfjir05k1bg22l50yawhibbv0y5qhr9-emacs-pdf-tools-0.90-2.5f77dae/bin"...
> phase `validate-runpath' succeeded after 0.0 seconds
> starting phase `validate-documentation-location'
> phase `validate-documentation-location' succeeded after 0.0 seconds
> starting phase `delete-info-dir-file'
> phase `delete-info-dir-file' succeeded after 0.0 seconds
> starting phase `patch-dot-desktop-files'
> phase `patch-dot-desktop-files' succeeded after 0.0 seconds
> starting phase `install-license-files'
> installing 0 license files from '.'
> phase `install-license-files' succeeded after 0.0 seconds
> starting phase `reset-gzip-timestamps'
> phase `reset-gzip-timestamps' succeeded after 0.0 seconds
> starting phase `compress-documentation'
> phase `compress-documentation' succeeded after 0.0 seconds
> starting phase `enter-lisp-dir'
> phase `enter-lisp-dir' succeeded after 0.0 seconds
> starting phase `emacs-patch-variables'
> emacs: could not load dump file
> "/gnu/store/rv72rvqa3vh2vw7jpkm3d9ww0xb4ibxv-emacs-next-git.master/libexec/emacs/29.0.50/x86_64-pc-linux-gnu/emacs-4588128eef9937d195927b0cccee280697619db43041dd08b620788b8dd59b77.pdmp":
> not a dump file
I think this is because of some recent changes made to the naming of the
Emacs
pdmp file in the master branch. Previously, it just made a file called
"emacs.pdmp" but now it appends the version or commit hash, i.e.
"emacs-4588128eef9937d195927b0cccee280697619db43041dd08b620788b8dd59b77.pdmp".
This new naming scheme started with Emacs commit
e81f1faca4382ed5c8f15fec84fb7c900a5468f9.
This might be confusing Guix's Emacs package recipe, which has a regexp
that
simply looks for "emacs.pdmp" when it does some cleanup after building
Emacs.
guix/gnu/packages/emacs.scm:182 and following:
> (lambda* (#:key outputs target #:allow-other-keys)
> (let* ((libexec (string-append (assoc-ref outputs "out")
> "/libexec"))
> ;; each of these find-files should return one file
> (pdmp (find-files libexec "^emacs\\.pdmp$"))
> (pdmp-real (find-files libexec
> "^\\.emacs\\.pdmp-real$")))
So I think that regexp might need to be changed a little to accommodate
those
recent Emacs changes. That's as far as I'm able to get with it, though,
as I'm
not very good at Guile or regexps.
-paxton
bug#51114: Owncloud client error message
Hi Cayetano, this should be fixed in the current version of owncloud-client. See also https://issues.guix.gnu.org/47672 and https://issues.guix.gnu.org/51117. Best Daniel
bug#51261: Guix from qcow2 image refuses to boot after reconfigure
Imagine follow scenario: wget https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2 Boot the VM: qemu-system-x86_64 -enable-kvm -m 4G -device e1000,netdev=net0 \ -netdev user,id=net0,hostfwd=tcp::5522-:22 \ -drive file=guix-system-vm-image-1.3.0.x86_64-linux.qcow2,if=virtio,cache=writeback,werror=report Inside the VM do a: sudo su guix system reconfigure /run/current-system/configuration.scm reboot Boot fails (see attached image: failed_boot.png). Its the same if I do: sudo su guix pull GUIX_PROFILE="$HOME/.config/guix/current" . "$GUIX_PROFILE/etc/profile" hash guix guix system reconfigure /run/current-system/configuration.scm reboot ~Jonathan
bug#51141: guix home reconfigure does not apply changes to shepherd services
On 2021-10-16 18:06, Oleg Pykhalov wrote: > Hi Andrew, > > Andrew Tropin writes: > >> On 2021-10-12 01:53, Oleg Pykhalov wrote: >> >>> After changing a home shepherd service I tried to reconfigure with 'guix >>> home reconfigure'. >>> >>> Process started by a service did not restart. Assuming home shepherd is >>> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the >>> process restarted but without changes in a service definition. >> >> It's intentional, only `herd load root new-config.conf` called on >> activation, so existing services are not affected to prevent situations, >> where emacs daemon or other important process killed in the middle of >> unsaved work. > > If I change something inside a system service definition > SERVICE-shepherd-service and then invoke 'guix system reconfigure', the > service will not restart and not produce any effect until I invoke 'sudo > herd restart SERVICE'. > > After herd restart the service will be running with applied changes and > does not require 'herd unload root SERVICE_NAME'. > E.g. nginx-service-type. > > I think this behaviour should be the same for home services. WDYT? Yes, make sense. According to what I see in the shepherd tests: https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61 and how it's implemented in home-shepherd: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59 It should work as you expect it. Tried to do the following: I updated documentation field for a shepherd service, reconfigured and it got loaded after I restarted a service. --8<---cut here---start->8--- ~ $ herd doc state Init, update and maybe destroy state. ~ $ herd restart state Service state has been stopped. Service state has been started. ~ $ herd doc state Really init, update and maybe destroy state. --8<---cut here---end--->8--- Didn't check if start action gexp is updated too, but I expect it was. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
