bug#59423: Invalid 'location' field generated in dovecot configuration

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

 That generates two accessors called ‘namespace-configuration-location’.
 The second one shadows the first one.
>>>
>>> Yes.  You didn't address my question directly though, so let me ask it
>>> again: where is this %location field access (named "location") used?
>
> [...]
>
>> … the field is accessed via its accessor,
>> ‘name-configuration-location’.  We can kinda see it here:
>
> [...]
>
>> Each  record has a ‘getter’ field that refers to
>> the accessor.  In the case of ‘location’, that’s the “wrong”
>> accessor—the accessor of ‘%location’.
>>
>> I hope that addresses your question!
>
> No :-).  I meant why do we even set a default accessor for the *source
> location* information (in the (gnu service configuration) macros); it's
> that one that doesn't seem to get used (or I'm blind to it!), at least
> via this accessor.  If it's not strictly necessary, we can stop
> producing it, and that would solve the problem.

Like I wrote, I think it’s necessary, even if not used now.

We’ve been knowingly shipping a broken Dovecot for two weeks now.  As I
wrote, and as Pierre suggested, can we just revert the ‘%location’ field
shuffling for now?  I can even do it on your behalf.

After that we can continue that discussion (though I don’t have much to
add to be honest).

Thanks in advance!

Ludo’.

bug#59160: Acknowledgement (Fritzing parts are missing)

[Gabriel Wicki]

Resending this to debbugs since the mail previously was only sent to Tobias


Hi Tobias

Thanks for the review!

The line in question will make all functions return prematurely that are
intended to use libgit2 (that's why the git_libgit2_init is
patched).  Fritzing still reports "Sorry, we have a problem with the
swapping mechanism.
Fritzing still works, but you won't be able to change parts
properties.Error 1", but seems to work fine apart from that.

Since the content of the returned String doesn't seem to matter (as long
as it's not an empty string) I've adjusted it to a less ugly "true".


I'm sorry i don't have the capacity to provide a more satisfying
solution ATM but at least Fritzing is back to a usable state.


Best wishes,
g


> From 242f0f785843560030a811635c0c4a72d81b Mon Sep 17 00:00:00 2001
From: Gabriel Wicki 
Date: Tue, 22 Nov 2022 00:35:19 +0100
Subject: [PATCH] gnu: fritzing: Update to 0.9.6.

* gnu/packages/engineering.scm (fritzing): Update to 0.9.6.
[arguments]<#:phases>{'configure}: Modify to work with
new version.
---
 gnu/packages/engineering.scm | 34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 43e23e30a8..edfef77a5c 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -669,7 +669,7 @@ (define-public fasthenry
 (define-public fritzing
   (package
 (name "fritzing")
-(version "0.9.3b")
+(version "0.9.6")
 (source (origin
   (method git-fetch)
   (uri (git-reference
@@ -678,7 +678,7 @@ (define-public fritzing
   (file-name (git-file-name name version))
   (sha256
(base32
-"0hpyc550xfhr6gmnc85nq60w00rm0ljm0y744dp0z88ikl04f4s3"
+"083nz7vj7a334575smjry6257535h68gglh8a381xxa36dw96aqs"
 (build-system gnu-build-system)
 (arguments
  `(#:phases
@@ -687,24 +687,18 @@ (define-public fritzing
(lambda* (#:key inputs outputs #:allow-other-keys)
  (copy-recursively (assoc-ref inputs "fritzing-parts-db")
"parts")
- ;; Make compatible with libgit2 > 0.24
- (substitute* "src/version/partschecker.cpp"
-   (("error = git_remote_connect\\(remote, GIT_DIRECTION_FETCH, 
&callbacks\\)")
-"error = git_remote_connect(remote, GIT_DIRECTION_FETCH, 
&callbacks, NULL, NULL)"))
-
  ;; Use system libgit2 and boost.
  (substitute* "phoenix.pro"
-   (("^LIBGIT2INCLUDE =.*")
-(string-append "LIBGIT2INCLUDE="
-   (assoc-ref inputs "libgit2") "/include\n"))
-   (("^LIBGIT2LIB =.*")
-(string-append "LIBGIT2LIB="
-   (assoc-ref inputs "libgit2") "/lib\n")))
- ;; This file checks for old versions of Boost, insisting on
- ;; having us download the boost sources and placing them in the
- ;; build directory.
- (substitute* "pri/utils.pri"
-   (("error\\(") "message("))
+   (("^LIBGIT_STATIC.*")
+(string-append "LIBGIT2INCLUDE=" (assoc-ref inputs "libgit2") 
"/include\n"
+   "LIBGIT2LIB=" (assoc-ref inputs "libgit2") 
"/lib\n"
+   "INCLUDEPATH += $$LIBGIT2INCLUDE\n"
+   "LIBS += -L$$LIBGIT2LIB -lgit2\n"))
+   (("^.*pri/libgit2detect.pri.") ""))
+ ;; Trick the internal mechanism to load the parts
+ (substitute* "src/version/partschecker.cpp"
+   ((".*git_libgit2_init.*")
+"return \"true\";"))
 
  (let ((out (assoc-ref outputs "out")))
(invoke "qmake"
@@ -723,11 +717,11 @@ (define-public fritzing
(method git-fetch)
(uri (git-reference
  (url "https://github.com/fritzing/fritzing-parts";)
- (commit version)))
+ (commit (string-append "release_" version
(file-name (git-file-name "fritzing-parts" version))
(sha256
 (base32
- "1d2v8k7p176j0lczx4vx9n9gbg3vw09n2c4b6w0wj5wqmifywhc1"))
+ "0wsvn57v6n0ygnhk2my94rrfzb962z1cj4d1xmp1farwck3811h6"))
 (home-page "https://fritzing.org";)
 (synopsis "Electronic circuit design")
 (description
-- 

2.38.0

bug#59771: Conda 22.9.0 needs "sudo" as dependency

[Hugo Buddelmeijer]

Hi all,

Conda 22.9.0 needs "sudo" as a dependency:

$ guix shell -C conda

[env]$ conda --version
conda 22.9.0

[env]$ conda init bash
[...]
Traceback (most recent call last):
[...]
  File
"/gnu/store/lvip6h5pamjwmvnkwg60sjb63ph8698k-python-3.9.9/lib/python3.9/subprocess.py",
line 18
21, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'sudo'


The problem goes away when sudo is added to the guix shell command. This
results in another error though; I'll report another bug for that.

As for why sudo is needed, I don't know. (Not sure I want to know.)

Background: if conda works well in guix, then we can get more conda users
and package maintainers on board with guix.

Greetings,
Hugo

bug#59772: conda 22.9.0 breaks "conda init bash"

[Hugo Buddelmeijer]

Hi all,

Conda 22.9.0 breaks "conda init bash". Conda requires some functions to be
present in ~/.bashrc (or equivalent dot file for other shells) in order to
function as intended [*]. These functions are added there through "conda
init bash", which each conda user should run once.

$ guix shell -C conda sudo

[env]$ conda --version
conda 22.9.0

[env]$ conda init bash
[..]
  File
"/gnu/store/lvip6h5pamjwmvnkwg60sjb63ph8698k-python-3.9.9/lib/python3.9/subprocess.py",
line 19
59, in _communicate
input_view = memoryview(self._input)
TypeError: memoryview: a bytes-like object is required, not 'str'
[...]

However, it seems that this is a conda problem (not sure), and not a guix
problem. E.g. see
   https://github.com/conda/conda/issues/11885
   "conda 22.9.0 breaks bash command prompt"
The suggested solution there is to do "sudo $(which conda) init bash",
which is not really acceptable for us.

Also, "conda init bash" does seem to actually do what it is supposed to do:
add conda functions to ~/.bashrc; the error occurs after that. So maybe we
can just wait this out, or try to see whether it works with conda 22.11.0.

Greetings,
Hugo

[*] There are also some problems in the interplay between guix and the
conda functions in .bashrc. I'll report those later.

bug#59771: Conda 22.9.0 needs "sudo" as dependency

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Hugo,

Hugo Buddelmeijer 写道：
As for why sudo is needed, I don't know. (Not sure I want to 
know.)


Indeed, this sounds like something to report and fix upstream.


$ guix shell -C conda sudo


Won't work, because sudo needs to be setuid — that is, provided by 
the OS.


On Guix Systems, that means /run/setuid-programs/sudo.  It cannot 
be run from the store, where setuid programmes are not allowed.


I tried --expose'ing /run/setuid-programs, but then sudo fails to 
find libsudo_util.so.0.  I didn't test further but don't expect 
that to suffice: sudo simply makes too many assumptions about the 
system, because of the special job it needs to do.


While it would be nice to figure out how to provide 
setuid-programs to a containers, Conda's pointless use of sudo is 
the bug here.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59774: Activating conda environments breaks the prompt because bash eats PS1

[Hugo Buddelmeijer]

Hi all,

### Summary 

Activating a conda environment on guix will break your bash prompt, because
guix' binary-replacing-bash-script eats PS1.


### Reproduce 

E.g.:

# Start a container with conda
hugo@alex ~/t $ guix shell -C conda sudo bash

# Add conda functions to ~/.bashrc. This raises errors but does work.
hugo@alex ~/t [env]$ conda init bash
# ignore the errors

# Add the functions to bash. This activates the conda environment called
"base".
hugo@alex ~/t [env]$ source ~/.bashrc
sh: dirname: command not found
sh: dirname: command not found
(base)

# Deactivate the environment.
(base) conda deactivate


### Actual and expected behaviour ###

The prompt is now empty. The expected result is that the "(base)" string is
prefixed to the prompt when activating an environment (or replaced when
switching environments). "base" is the default environment. The string
should be removed when the environment is deactivated.

However, instead, upon activating an environment, the entire prompt is
replaced with "(base)". Deactivating the environment removes the string,
resulting in an empty prompt.


### Cause ###

The cause of the disappearing prompt is due to an interplay between conda
and guix and bash. Normally, "conda" is either a binary executable, or a
bash function, but in guix it can also be a bash script.

What normally happens after installing conda is:
- The user calls "conda init bash". This is the binary executable "conda",
which adds the "conda" bash function to ~/.bashrc. This is only done once
for each user, after which the shell is restarted.

What normally happens in a user session is:
- The shell implicitly calls "conda activate base" through ~/.bashrc, or
the user calls it explicitly (usually not with "base", but with their own
environment). This "conda" is the conda bash function.
- The conda bash function calls the conda binary, passing PS1 (and other
variables).
- The conda binary uses PS1 to construct a new string to be used as a
prompt, and returns that to the conda bash function.
- The conda bash function uses the output from the conda binary to set PS1.
It also makes a backup of PS1 in CONDA_PS1_BACKUP.

But in guix, the conda binary is renamed to conda_real, and is replaced
with [by?] the conda bash script. Therefore this happens:
- The conda shell function is called through "conda activate base".
- The conda shell function calls the conda bash script. The conda bash
script eats PS1 because it is non-interactive.
- The conda bash script calls the conda_real binary, specifying an empty
PS1.
- The conda_real binary adds the "(base)" prefix to the empty string and
returns the string to the conda bash script.
- The conda bash script returns the string to the conda bash function.
- The conda bash function sets PS1 to the new string, which is just
"(base)".


### Workaround ###

My personal workaround is to skip the "conda init bash" step entirely, but
do something equivalent manually:
- Call "conda shell.bash hook" and store the output in ~/.
conda_shell.bash_hook.sh .
- Replace the "$CONDA_EXE" at the top of the file with
"${HOME}/.guix-profile/bin/conda"; otherwise it contains an absolute path,
including a guix hash. (This is another problem, I now realize.)
- Add "--norc -i" to every "$CONDA_EXE" call in that file.
- Add ". ~/.conda_shell.bash_hook.sh" to ~/.bash_profile (has to be
.bash_profile and not .bashrc because otherwise it would be called from the
conda bash script, leading to recursion).

The crux is that now it calls the conda bash script (created by guix) with
the -i flag (interactive mode), which prevents PS1 from being eaten. The
--norc prevents .bash_profile from being read again, thereby preventing
recursion.


### Proper Solution ###

I can see two possible proper solutions; but I cannot vouch for the
feasibility in guix.

1) Use another shell than bash for the executable-replacing-script of the
conda package. Only bash eats PS1, other POSIX-compliant shells do not;
e.g. dash. Is it possible to use another shell than bash for guix packages?

2) "conda shell.bash hook" uses the contents of /etc/profile.d/conda.sh to
create the conda bash function. Perhaps it would be possible to patch that
file to include the "--norc -i" flags. Maybe this would also require
placing the "conda init" output in ".bash_profile"
 instead of ".bashrc", not sure.


### Disclaimer ###

My ultimate goal is to ditch conda altogether and use guix instead.
However, it will take a while to convince everyone. In the meantime it
would help to have conda running well. That would also make it easier to
attract conda package maintainers.


Cheers,
Hugo

bug#59775: Conda requires coreutils as a runtime dependency

[Hugo Buddelmeijer]

Hi all,

Conda requires coreutils as a runtime dependency:

hugo@alex ~/t $ guix shell -C conda
hugo@alex ~/t [env]$ conda init bash
# ignore errors
hugo@alex ~/t [env]$ source ~/.bashrc
sh: dirname: command not found
sh: dirname: command not found

The "dirname" errors go away when coreutils is added to the "guix shell"
command.

(Note, several other errors appear, those are reported in different bug
reports. These also explain the above set of commands.)

Cheers,
Hugo

bug#59776: Conda hardcodes guix hash in .bashrc

[Hugo Buddelmeijer]

Hi all,

Conda adds some bash functions to ~/.bashrc, but those contain a hardcoded
guix hash. That means that conda will break between upgrades:

hugo@alex ~/t$ guix shell -C conda
hugo@alex ~/t [env]$ conda init bash
# ignore errors
hugo@alex ~/t [env]$ echo "$(<~/.bashrc)" # no coreutils

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/gnu/store/kihiw0r9r595jwhxlydkl0f5vvn53r1z-conda-22.9.0/bin/conda'
'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f
"/gnu/store/kihiw0r9r595jwhxlydkl0f5vvn53r1z-conda-22.9.0/etc/profile.d/conda.sh"
]; then
.
"/gnu/store/kihiw0r9r595jwhxlydkl0f5vvn53r1z-conda-22.9.0/etc/profile.d/conda.sh"
else
export
PATH="/gnu/store/kihiw0r9r595jwhxlydkl0f5vvn53r1z-conda-22.9.0/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<


It seems that the contents of ~/.bashrc are based on the file
conda/core/initialize.py:
https://github.com/conda/conda/blob/main/conda/core/initialize.py

It refers to a conda_prefix (and conda_exe) variable. These should somehow
refer to the guix profile, not to the packages in the store.

I'm not yet experienced enough to propose how to tackle this. It seems hard
to do this in a generic way, because guix and conda kinda collide here.
E.g. different guix profiles (with different conda packages) could share
the same home directory.

However, it would already be nice if conda would work (between updates) for
the scenario of only one guix profile per user. That is, perhaps we can
simply refer to "${HOME}/.guix-profile" as conda_prefix.



This is the last of the conda-related bugs I planned to submit. My goal is
to get conda to work well enough within guix so we can convince conda-users
to try guix, and then, over time, hopefully switch over to guix entirely.

Hugo

bug#59512: gtk-4.8.1 grafting fails

[Ludovic Courtès]

Hi,

Marek Paśnikowski  skribis:

> I should be able to heal the system by deleting the bit-flipped
> file and reinstalling gtk.  Does Guix have the ability to remove or
> rewrite a specific file in its store?  The file is rooted in the
> system configuration - not in a profile.

‘guix gc --verify=repair’ can do that, but only for items that are
substitutable (grafts are not substitutable).

Closing the bug, thanks!

Ludo’.

bug#48602: Grafted python2 packages gets erroneous package names

[Marius Bakke]

Maxim Cournoyer  skriver:

> Hi,
>
> Marius Bakke  writes:
>
>> Hello,
>>
>> 'guix build python2-urllib3' currently gives:
>>
>>   /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4
>>
>> Adding '--no-grafts' gives the expected file name.
>>
>> Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the
>> store file name was actually '...-python2-python2-python2-urllib3-...'!
>>
>> Not sure if this is a recent regression, or what may be causing it.
>
> Since we virtually have no more python2 packages, I suggest we cut our
> losses and close this issue.

Definitively.  Closed!


signature.asc
Description: PGP signature

bug#58690: [PATCH] gnu: emacs-ess: Update to 18.10.2-1.01e7f5b.

[zimoun]

Hi Ricardo,

On Wed, 30 Nov 2022 at 22:55, Ricardo Wurmus  wrote:
> * gnu/packages/statistics.scm (emacs-ess): Update to 18.10.2-1.01e7f5b.
> [source]: Update snippet; remove patch.
> [arguments]: Use gexp; add phase "patch-test-suite"; run tests conditionally.
> [inputs]: Drop package labels.
> * gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch: Remove 
> file.
> * gnu/local.mk (dist_patch_DATA): Remove it.

LGTM.  But then,

./pre-inst-env guix shell emacs emacs-ess r \
  -- emacs -q /tmp/example.R

and after starting the *R* session, Emacs is frozen.  Does it work for
you?


Cheers,
simon

bug#59748: task init:1 blocked

[Christopher Howard]

For additional troubleshooting, I modified my system profile by adding (kernel 
(specification->package "linux-libre@5.15")) to use the older kernel version. I 
am able to boot into that modified profile without issues. So clearly there is 
something broken in relationship to the upgrade to linux-libre 6.0.10.

Christopher Howard

bug#59780: [version 1.4.0rc1] reconfigure fails

[pelzflorian (Florian Pelz)]

Having installed the 1.4.0rc1 installer image: After guix pull, it
failed to reconfigure, because master is an unrelated commit.

Regards,
Florian

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[pelzflorian (Florian Pelz)]

Could you make install.sh add bordeaux to /etc/guix/acl?  It is
important especially on ARM.

Regards,
Florian

bug#59782: [version 1.4.0rc1] Add r8169 to unsupported hardware

[pelzflorian (Florian Pelz)]

Installation (guix substitute) sometimes gets stuck on my Beebox mini
PC with r8169 Ethernet controller.

For the x86_64 graphical installer, I selected everything.
After it had downloaded plenty of other substitutes, installation
printed this and got stuck:

substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
22,2 MB werden heruntergeladen
  cairo-1.16.0-doc  135KiB 616KiB/s 00:00 [##] 
100.0%

I waited 10 minutes.  Booting the installer image again, it does not
again get stuck.  Installation was successful now.  I propose this
patch, but will retry some more if installation really never freezes
with USB Ethernet.

IIRC I had had similar problems with this Ethernet socket in the past.

Note: I still need to test the patch.

Regards,
Florian

From: Florian Pelz 
Date: Fri, 2 Dec 2022 18:25:11 +0100
Subject: [PATCH] installer: Warn about r8169 Ethernet controller.

Because guix substitute sometimes freezes.

* gnu/installer/hardware.scm (%unsupported-linux-modules): Add it.
---
 gnu/installer/hardware.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/installer/hardware.scm b/gnu/installer/hardware.scm
index cd1a1767d8..8e92949977 100644
--- a/gnu/installer/hardware.scm
+++ b/gnu/installer/hardware.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2022 Ludovic Courtès 
+;;; Copyright © 2022 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -55,7 +56,11 @@ (define %unsupported-linux-modules
 "radeon"
 
 ;; Multimedia.
-"ivtv"))
+"ivtv"
+
+;; Manual additions.
+"r8169"  ;works, but guix substitutes occasionally freezes
+))
 
 (define unsupported-pci-device?
   ;; Arrange to load the module alias database only once.

base-commit: 020184fd39c6244e0336db3c608d3946b8d20490
-- 
2.38.1

bug#59783: [version 1.4.0rc1] Suggested window managers don't work out of the box

[pelzflorian (Florian Pelz)]

Once there was a commit

commit 3ad3c55842dd34adc4b1a1b65ba0abfbdf5b92ee
Author: Ludovic Courtès 
Date:   Wed Apr 17 00:27:04 2019 +0200

installer: Desktop environment page now includes window managers.

* gnu/installer/services.scm ()[snippet]: Change to be a
list of sexps and add default value.
[packages]: New field.
(%system-services): Adjust 'snippet' fields to be lists of sexps.
Add Openbox, awesome, i3, and ratpoison.
(system-services->configuration): Adjust 'snippet' handling.  Honor
'packages' field.

Maybe openbox and ratpoison services should not be suggested by the
Guix System graphical installer, because they apparently are unusable
without further config files.  Note that sway is not among the
suggested desktop environments either.  WDYT?

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

I aborted graphical system installation (Ctrl-C), retried the
installation and got this:

shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
guix system: Fehler: opening file 
`/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such file or 
directory
Befehl ("guix" "system" "init" "--fallback" "/mnt/etc/config.scm" "/mnt") hat 
mit Exit-Code 1 geendet
Drücken Sie die Eingabetaste, um fortzufahren.

(It told me to press Enter to continue.)  I did so; retried; but again
it did not really retry the installation, I always get this same error
message.

Sorry in case this is a duplicate bug.

Regards,
Florian

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

pelzflorian (Florian Pelz) 写道：

Could you make install.sh add bordeaux to /etc/guix/acl?  It is
important especially on ARM.


If you mean guix-install.sh: I did so ages ago, but something 
(valid) stopped me from pushing it.


Now I can't for the life of me remember what it was…

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

pelzflorian (Florian Pelz) 写道：
Having installed the 1.4.0rc1 installer image: After guix pull, 
it

failed to reconfigure, because master is an unrelated commit.


Hah.  This should indeed be mentioned in calls for -RC testing, 
but probably doesn't deserve a bug report, since there's no bug. 
WDYT?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[pelzflorian (Florian Pelz)]

Tobias Geerinckx-Rice  writes:
> pelzflorian (Florian Pelz) 写道：
>> Having installed the 1.4.0rc1 installer image: After guix pull, it
>> failed to reconfigure, because master is an unrelated commit.
>
> Hah.  This should indeed be mentioned in calls for -RC testing, but
> probably doesn't deserve a bug report, since there's no bug. WDYT?

Huh I don’t understand. :)  Had this been the 1.4.0 release, reconfigure
would be impossible, unless --allow-downgrades.  Is the actual release
commit always on master; do I overlook something?  Then feel free to
close.

Regards,
Florian

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[pelzflorian (Florian Pelz)]

Tobias Geerinckx-Rice  writes:
> If you mean guix-install.sh:

Yes I mean guix-install.sh. :)

Regards,
Florian

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi'gain,

pelzflorian (Florian Pelz) 写道：
Huh I don’t understand. :)  Had this been the 1.4.0 release, 
reconfigure

would be impossible, unless --allow-downgrades.


I don't follow.  Could you explain?


Is the actual release commit always on master


Yes.  Does this cancel out the previous question?  If so, I'll let 
you close the bug to avoid misunderstandings.


(But it's worth noting in future calls for testing, absolutely! 
Thanks for noticing.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：

Is the actual release commit always on master


Yes.


Actually, that is what's known as ‘complete nonsense’ and the 
correct answer is, of course, ‘no’.


Hmm.  I'll have to actually test the RC to see what you mean. 
Sorry for the noise.


Kind regs,

T G-R


signature.asc
Description: PGP signature

bug#59423: Invalid 'location' field generated in dovecot configuration

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Maxim Cournoyer  skribis:

[...]

>> No :-).  I meant why do we even set a default accessor for the *source
>> location* information (in the (gnu service configuration) macros); it's
>> that one that doesn't seem to get used (or I'm blind to it!), at least
>> via this accessor.  If it's not strictly necessary, we can stop
>> producing it, and that would solve the problem.
>
> Like I wrote, I think it’s necessary, even if not used now.

To complement this answer: key high-level record types usually have a
‘location’ field: , , , ,
, etc.  The rationale is that it allows us to report
accurate location info for errors and warnings, to jump to their
definition, and so on.

For configuration records this is not a common pattern, but the
rationale holds.  ‘zabbix-front-end-config’ uses the ‘%location’ field,
but it seems to be the only one so far.

Ludo’.

bug#59423: Invalid 'location' field generated in dovecot configuration

[Maxim Cournoyer]

Hi Pierre,

Pierre Langlois  writes:

> Hi all!
>
> As suggested by mirai off-list, it would be nice to have a test that
> would have caught the issue. How do people feel about something along
> the following patch? The idea is to use namespaces in the dovecot config
> to declare the INBOX and another additional mailbox.
>
> The bug is quite obscure and not really about dovecot itself, so I don't
> think adding such a test is strictly necessary, maybe more tests for the
> configuration macro would be good instead. But I figured expanding the
> dovecot system test can't hurt. Let me know if you agree and I'll format
> it properly.

Thanks for the diff!  I've turned it into a patch and was ready to apply
it, but 2 tests are always failing, even after addressing this issue;
could you look into why?  It looks good otherwise.

>From 149790c4bd264d81938596cdbfa3376f31f9182f Mon Sep 17 00:00:00 2001
From: Pierre Langlois 
Date: Fri, 2 Dec 2022 14:17:25 -0500
Subject: [PATCH] tests: Expound Dovecot test suite.

Relates to .

* gnu/tests/mail.scm (%dovecot-os) [services] : Add two
namespaces.
(run-dovecot-test) : New syntax.
: New test.
: Use with-imap-connection.
: New test.
: Adjust test.
: New test.

Signed-off-by: Maxim Cournoyer 
---
 gnu/tests/mail.scm | 79 +++---
 1 file changed, 60 insertions(+), 19 deletions(-)

diff --git a/gnu/tests/mail.scm b/gnu/tests/mail.scm
index f13751b72f..8a2dbd798f 100644
--- a/gnu/tests/mail.scm
+++ b/gnu/tests/mail.scm
@@ -301,8 +301,19 @@ (define %dovecot-os
  (auth-anonymous-username "alice")
  (mail-location
   (string-append "maildir:~/Maildir"
- ":INBOX=~/Maildir/INBOX"
- ":LAYOUT=fs"))
+ ":LAYOUT=fs"))
+ (namespaces
+  (list
+   (namespace-configuration
+(name "INBOX")
+(inbox? #t)
+(separator "/")
+(location "maildir:~/Maildir/INBOX"))
+   (namespace-configuration
+(name "guix-devel")
+(separator "/")
+(prefix "guix-devel/")
+(location "maildir:~/Maildir/guix-devel"
 
 (define (run-dovecot-test)
   "Return a test of an OS running Dovecot service."
@@ -351,9 +362,10 @@ (define message "From: t...@example.com\n\
   (marionette-eval `(file-exists? (string-append "/proc/" ,pid))
marionette)))
 
-  (test-assert "accept an email"
+  (define-syntax-rule (with-imap-connection imap exp ...)
 (let ((imap (socket AF_INET SOCK_STREAM 0))
-  (addr (make-socket-address AF_INET INADDR_LOOPBACK 8143)))
+  (addr (make-socket-address AF_INET INADDR_LOOPBACK 8143))
+  (body (lambda (imap) exp ...)))
   (connect imap addr)
   ;; Be greeted.
   (read-line imap) ;OK
@@ -362,6 +374,43 @@ (define message "From: t...@example.com\n\
   (read-line imap) ;+
   (write-line "c2lyaGM=" imap)
   (read-line imap) ;OK
+
+  (let ((ok (body imap)))
+;; Logout
+(write-line "a LOGOUT" imap)
+(close imap)
+ok)))
+
+  (define (marionette-read-new-mail mailbox marionette)
+(marionette-eval
+ `(begin
+(use-modules (ice-9 ftw)
+ (ice-9 match))
+(match (scandir ,mailbox)
+  (("." ".." message-file)
+   (call-with-input-file
+   (string-append ,mailbox message-file)
+ get-string-all
+ marionette))
+
+  (test-assert "accept an email"
+(with-imap-connection imap
+  ;; Append a message to the INBOX mailbox
+  (write-line (format #f "a APPEND INBOX {~a}"
+  (number->string (message-length message)))
+  imap)
+  (read-line imap) ;+
+  (write-line message imap)
+  (read-line imap) ;OK
+  #t))
+
+  (test-equal "mail arrived"
+message
+(marionette-read-new-mail "/home/alice/Maildir/INBOX/new/"
+  marionette))
+
+  (test-assert "accept an email in fresh mailbox"
+(with-imap-connection imap
   ;; Create a TESTBOX mailbox
   (write-line "a CREATE TESTBOX" imap)
   (read-line imap) ;OK
@@ -372,24 +421,16 @@ (define message "From: t...@example.com\n\
   (read-line imap) ;+
   (wri

bug#59423: Invalid 'location' field generated in dovecot configuration

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> Maxim Cournoyer  skribis:
>
> [...]
>
>>> No :-).  I meant why do we even set a default accessor for the *source
>>> location* information (in the (gnu service configuration) macros); it's
>>> that one that doesn't seem to get used (or I'm blind to it!), at least
>>> via this accessor.  If it's not strictly necessary, we can stop
>>> producing it, and that would solve the problem.
>>
>> Like I wrote, I think it’s necessary, even if not used now.
>
> To complement this answer: key high-level record types usually have a
> ‘location’ field: , , , ,
> , etc.  The rationale is that it allows us to report
> accurate location info for errors and warnings, to jump to their
> definition, and so on.
>
> For configuration records this is not a common pattern, but the
> rationale holds.  ‘zabbix-front-end-config’ uses the ‘%location’ field,
> but it seems to be the only one so far.

Thanks for this extra bit of information and for spotting this usage.  I
think "location" is likely to conflict for the general purpose
'define-configuration' generated records, so I've renamed the "location"
*accessor* to "source-location".

In the near future I want to migrate more service configurations to the
'define-configuration' machinery, to benefit from its useful
self-validating property.  For now I wouldn't feel at ease doing so
unless raw record matching (not yet using 'match-record') works the same
way, since we still have many occurrences making use of that (often via
match-lambda).  For that reason, I prefer to not revert the record
layout until we've gotten rid of all the match-lambda matching record
fields directly (which will take some time).

I've applied the rename fix to master.

-- 
Thanks,
Maxim