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

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> 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".
>
> Thank you.
>
> It wasn’t my preferred solution¹ but I think it’s a good one.
>
> ¹ https://issues.guix.gnu.org/59423#15-lineno81
>
>> 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).
>
> Right, especially given that ‘match-record’ was added in 2017.  :-)

Hehe!  I had started adapting all the match-lambda, and got overwhelmed
by the changes needed.  So I think progressively (i.e., small) be easier
to review or revert in case of errors.

> We’ll have to discuss the implications of a possible move to
> ‘define-configuration’.  For example, ‘define-configuration’ cannot
> report missing field values (for fields that lack a default value) at
> macro-expansion time, contrary to plain ‘define-record-type*’.  Anyway,
> future work!

OK.  That's optimization work rather than an impediment to migrate
though, right?  If so, I think the value for users of having errors on
invalid field types outweighs run time efficiency :-).

-- 
Thanks,
Maxim

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

[Hugo Buddelmeijer]

On Sat, 3 Dec 2022 at 20:11, Hugo Buddelmeijer  wrote:

>
> But maybe 59771 (this bug), 59772 (also due to sudo), and 59776 (hardcoded
> paths), all three could be resolved in a more guix-y way. The problem in
> these three bugs is that "conda init" wants to add something to ~/.bashrc
> that adds some bash functions to the environment (and the sole purpose of
> those bash functions seems to be to update PS1). However, I was wondering,
> would it be possible to have guix itself add those bash functions to the
> environment?
>
> As in, we add some code to the guix conda package that ensures that if
> guix enters an environment with conda, that it somehow adds the necessary
> bash functions to the environment. So "conda init" and changes to ~/.bashrc
> would not even be necessary (thus fixing these bugs). That is, that the
> shell spawned through "guix shell -C conda" would have these bash functions
> directly in the environment. Would something like this be possible?
>

No, adding bash functions automatically to a Guix environment seems
impossible. The guile function load-profile allows packages to add
path-like environment variables through the search-path-specification
declaration, but not any other environment variables, let alone shell
functions.

That seems reasonable enough. One reason I'd like to move away from conda
is that I don't think the way conda handles environment variables is
tenable. So maybe it is worthwhile to make sure that "conda init" does what
it is expected to do (that is, add the code that loads these bash functions
to .bashrc), even though it is not really guix-y.

bug#59823: an installer dump was sent

[So'n Typ im Internet]

Hello,
I just sent an installer dump to you. The name is "installer-dump-2a14e489"

best regards

bug#58247: Using guix time-machine results in unsupported manifest format error

[Ludovic Courtès]

Hi,

zimoun  skribis:

> This issue is about the upgrade of manifest version from 3 to 4.  For
> references,
>
> 
>
> On Mon, 03 Oct 2022 at 00:10, zimoun  wrote:
>
>> Well, I do not know if a fix is possible.  The issue is a
>> backward compatibility issue.
>
> Ludo, what is your insight on that matter?  Is it fixable?  Or do we
> mark the issue as ’wontfix’?

David wrote:

> Im on commit 729ce5f and Im running: guix time-machine
> --commit=7e8e070 -- package -i hello
>
> and it outputs:
>
>   guix package: error: unsupported manifest format

This use case cannot be fixed: you cannot use an old Guix (one that only
understood manifest version 3) to manipulate a “new” profile (manifest
version 4).  That’s a fundamental limitation of old software being
unable to deal with new formats in general.

One way to work around it is to have that old ‘guix’ operate on a fresh
profile (thus it’ll be version 3):

  rm -f /tmp/old-stuff
  guix time-machine --commit=7e8e070 -- package -i hello -p /tmp/old-stuff

or, better yet, to use ‘guix shell’ or ‘guix environment’:

  guix time-machine --commit=7e8e070 -- \
environment --ad-hoc hello -- hello

I’m closing this bug.

Thanks,
Ludo’.

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

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> 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".

Thank you.

It wasn’t my preferred solution¹ but I think it’s a good one.

¹ https://issues.guix.gnu.org/59423#15-lineno81

> 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).

Right, especially given that ‘match-record’ was added in 2017.  :-)

We’ll have to discuss the implications of a possible move to
‘define-configuration’.  For example, ‘define-configuration’ cannot
report missing field values (for fields that lack a default value) at
macro-expansion time, contrary to plain ‘define-record-type*’.  Anyway,
future work!

Ludo’.

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

[pelzflorian (Florian Pelz)]

Having the installer show a warning here would *not* be appropriate.

These r8169 issues are so rare, I haven’t met one since.

Even though I believe the r8169 Ethernet was at fault, and guix
substitute freezing also had happened to me in the past with it, and
even though Linux-libre reports it as DEBLOBBED on every boot, I am
closing.  We don’t warn about sub-par nouveau graphics either.

Regards,
Florian

bug#59466: Kernel panic when installing with Ventoy

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

Hi Josselin,

Josselin Poiret via Bug reports for GNU Guix 写道：
Ventoy is not supported currently. It is up to them to add 
support for
Guix, not the other way around: we have some peculiarities with 
the boot

process that Ventoy completely ignores.


Ah.  This is true of most dime-a-dozen ‘universal’ ISO booters, 
which merely source a GRUB .cfg and expect distributions to do all 
the work.  I'd shame them by name if they were memorable.  Guix 
indeed doesn't ‘support’ that!


Ventoy actually put some thought & effort into the process.  Like 
all clever hacks, there's some dependence on moon phase and luck, 
but it's not snake oil.


It injects some code into the boot process to expose the ISO file 
as a block device through Linux's device mapper.  Any distribution 
with dm-mod support, including Guix[0] (through dm-crypt), will 
see a ‘real’ block device straight from the kernel.  No distro 
cooperation is required beyond ‘please don't be too clever and 
peek behind the curtain’.  IME, Guix does not do so, and just 
works.


(So why does it fail here…?)

Kind regards,

T G-R

[0]: https://www.ventoy.net/en/distro_iso/gnu_guix.html but do 
note who submitted it ;-)


signature.asc
Description: PGP signature

bug#59466: Kernel panic when installing with Ventoy

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

Hi Panos,

Guix and Ventoy should work out of the box.

Panos Alevropoulos via Bug reports for GNU Guix 写道：
It seems that I can't install Guix 1.3.0 with Ventoy. After 
starting installation from Guix GRUB, I get kernel panic.


Thanks for including the exact panic message.  That's very 
helpful.


It's odd: Guix is trying to compile /ventoy/init as a SCM file.

- What is the sha256sum of the 1.3.0 ISO image you used?
- Could you try the ‘latest’[0] ISO and report the result?

Kind regards,

T G-R

[0]: https://guix.gnu.org/en/download/latest/


signature.asc
Description: PGP signature

bug#59466: Kernel panic when installing with Ventoy

[Josselin Poiret via Bug reports for GNU Guix]

Hi Panos,

Panos Alevropoulos via Bug reports for GNU Guix 
writes:

> Hello,
>
> It seems that I can't install Guix 1.3.0 with Ventoy. After starting 
> installation from Guix GRUB, I get kernel panic. Ventoy works well otherwise 
> with other distros.
> Image checksum is good.

Ventoy is not supported currently. It is up to them to add support for
Guix, not the other way around: we have some peculiarities with the boot
process that Ventoy completely ignores.  By the way, you should try
using the latest installer image instead of 1.3.0, as a lot of bugs have
been fixed since then.

Best,
-- 
Josselin Poiret