bug#36634: ATTENTION REQUIRED

[Raghav Gururajan]

Hello Guix!

I posted the bug on libvirt mail list few days ago (https://www.redhat.
com/archives/libvir-list/2019-July/msg01309.html). It appears the bug
has now been fixed (https://github.com/libvirt/libvirt/commit/759bf903a
6c24a8efa25c7cf4b099d952eda9bd3).

Could anyone please update the libvirt package/service to this latest
build?

Thank you!

Regards,
RG.

bug#36379: ATTENTION REQUIRED

[Raghav Gururajan]

Hello Guix!

I am not sure whether someone patched this bug. There has been changes.

REPORTED ISSUE: After running first `guix pull` as "root" user, the
output for `which guix` and `hash guix` for that "root" user are always
`/run/current-system/profile/bin/guix` instead of being
`/root/.config/guix/current/bin/guix`.

PREVIOUSLY: The issue happens *both* when running guix pull by logging
in as root user from gdm and when doing `su && guix pull` as regular
user.

NOW: It happens only when doing `su` and `guix pull` in terminal as
regular user.

Regards,
RG.

bug#36784: Cannot generate key pair with GnuPG

[Ricardo Wurmus]

Raghav Gururajan  writes:

> I still suggest that there should be a default/fallback option for
> this. After reviewing guix repository, I found pinentry, emacs-
> pinentry, pinentry-tty, pinentry-qt, pinentry-gtk2, pinentry-gnome3,
> pinentry-emacs and pinentry-efl, as available pinentry programs.
>
> Out of all, I suggest pinentry to be set as default/fallback option for
> gnupg in guix, as it is platform-independent and provides both CUI
> (console) and GUI.

I think it would be good to have a sensible default.  Is there a good
reason not to include pinentry-tty or somemthing similarly small?

-- 
Ricardo

bug#36784: Cannot generate key pair with GnuPG

[Raghav Gururajan]

> Is there a good
> reason not to include pinentry-tty or somemthing similarly small?

It appears pinentry-tty is only console-based. If graphical
applications like MUA, Key Managers etc require pinentry-program, it
usually uses pop-up (gui) for passphrase input. Since pinentry provides
both console and gui, I suggested it as it will be well-rounded
solution. :)

Regards,
RG.

bug#36784: Cannot generate key pair with GnuPG

[Ricardo Wurmus]

Raghav Gururajan  writes:

>> Is there a good
>> reason not to include pinentry-tty or somemthing similarly small?
>
> It appears pinentry-tty is only console-based. If graphical
> applications like MUA, Key Managers etc require pinentry-program, it
> usually uses pop-up (gui) for passphrase input. Since pinentry provides
> both console and gui, I suggested it as it will be well-rounded
> solution. :)

I guess the reason for not adding a graphical pinentry is that this
would increase the package closure of the gnupg package.

Perhaps we should add gnupg-minimal for use in other package
definitions.

--
Ricardo

bug#36784: Cannot generate key pair with GnuPG

[Raghav Gururajan]

> Perhaps we should add gnupg-minimal for use in other package
> definitions.

That would actually be wise.

Regards,
RG.

bug#36753: The GUI installer throws an error

[Ludovic Courtès]

Hello Jan,

Jan  skribis:

> What I did:Ran guix system installer from a DVD.When the system
> started I switched to tty3 mounted a flash drive and a partition in
> folders I made in /mnt/.Then I unmounted these disks and removed
> folders.Then I tried installing the system without any DE/WM.The
> installer asked me what network something I want to have, I picked
> DHCP.Then installation failed - "failed to build openssh".It asked me
> if I want to try again, I pressed yes and the installer threw an error
> I attached below.Guix version: 1.0.1System: amd64 --Jan

This looks a lot like this bug:

  https://issues.guix.gnu.org/issue/35690

In a nutshell, currently the installer cannot be restarted upon failure,
and this is why you got this ugly backtrace.

However, “failed to build openssh” looks like another failure worth
investigating.  Do you have more info as to what happened exactly, what
was printed?  Can you reproduce it?  It would be great if you could post
a picture of the screen at that point.

Thanks,
Ludo’.

bug#36757: AMD-Vi IOMMU bug, kernel crashes using GuixSD 1.0.1"

[Ludovic Courtès]

Hello romulasry,

romulasry  skribis:

> https://ibb.co/kyBrwRc

I don’t actually see a crash on this picture, just repeated messages
like:

  AMD-Vi: Event logged [IO_PAGE_FAULT …]

Did the system actually crash or hang?

I suppose it would be worth reporting the issue to the kernel developers
because that doesn’t seem to be Guix-specific.

Thanks,
Ludo’.

bug#36763: `guix search` does unexpected logical and

[Ludovic Courtès]

Hi Simon,

zimoun  skribis:

> As discussed here [1], the `relevance` in `guix/ui.scm` does not match
> "inter-field".
>
> Attached a fix.
> Now,  the example from the manual
>   $ guix search crypto library | \
> recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
> outputs the expected crypto libraries as `libb2`.

Nice!

> Then, please indicate me how the commit has to be filled.
> The commit 8874fc665100a095ef25e39c9a389f5a397f introducing the
> logical AND says:
>
> ui: 'relevance' considers regexps connected with a logical and.
>
> * guix/ui.scm (relevance)[score]: Change to return 0 when one of REGEXPS
> doesn't match.
> * tests/ui.scm ("package-relevance"): New test.

Yes, you can provide a commit log along these lines.

> Should another test be added?

Yes please, that would be perfect!

> +  (define (update relevance weight scores)
> +(map + relevance
> +   (map (lambda (score)
> +  (* weight score))
> +scores)))
> +
> +  (let ((scores (fold (lambda (metric relevance)
> +(match metric
> +  ((field . weight)
> +   (match (field obj)
> + (#f  relevance)
> + ((? string? str)
> +  (update relevance weight (score str)))
> + ((lst ...)
> +  (update relevance weight
> +  (fold (lambda (elem prev)
> +  (if (zero? (length elem))
> +  prev
> +  (map + elem prev)))
> +(make-list (length regexps) 0)
> +(map score lst)))
> +  )
> +  (make-list (length regexps) 0)
> +  metrics)))

I don’t have a clear mind on that, but I feel like this could be
simplified somehow.  For instance,

  (fold p (make-list …) metrics)

looks a lot like:

  (map (lambda (x) (fold p x metrics)) regexps)

Well, something like that.  :-)

Thanks for working on it!

Ludo’.

bug#36772: feature request: checked variant of "substitute*"

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

>> I think it would be great to have the following variant of substitute*:
>>
>> (substitute*-once filename (pattern vars) body)
>>
>> which acts like the usual substitute-*, except it also asserts that the
>> substitution applies to exactly one line in the file, causing a build
>> failure otherwise.
>
> I agree that the effect of substitute* should be checked.  I think
> substitute* should fail when one of its clauses failed to match
> anything.
>
> Each clause could also accept an optional argument to make them only
> match one location.  We wouldn’t have to duplicate the macro for that
> and it’s a simple extension to failing on zero matches.
>
> What do you think?

That’d be a useful extension.

Ludo’.

bug#36634: ATTENTION REQUIRED

[Tobias Geerinckx-Rice]

Raghav,

On Thu, Jul 25, 2019 at 11:46 AM, Raghav Gururajan 
 wrote:

Hello Guix!

I posted the bug on libvirt mail list few days ago 
(https://www.redhat.

com/archives/libvir-list/2019-July/msg01309.html). It appears the bug
has now been fixed 
(https://github.com/libvirt/libvirt/commit/759bf903a

6c24a8efa25c7cf4b099d952eda9bd3).

Could anyone please update the libvirt package/service to this latest
build?


I will do so swiftly since I updated libvirt to the 'broken' version 
(although I never had any troubles like yours).  Thank you for 
reporting this upstream.




A personal note: I find this new wave of 'ATTENTION REQUIRED' messages 
quite the opposite of motivating and pleasant.  I'm honestly not sure 
what result you expect from them.  I fear it may backfire.


You are very welcome to contribute patches yourself!  I don't mean 
'patches or GTFO', I mean 'please dive in, the water's great'.  The 
reviewers don't bite.  You don't need to be a programmmer; I'm not.


You've been part of our discussions for a while, you obviously care 
about Guix and Free software, and particularly about certain Gnome and 
'desktop-demographic' packages that are clearly under-maintained or 
even missing because we're missing people like you.  Learning to create 
and maintain them yourself is hardly more work than trying to herd 
volunteers like this -- and a hell of a lot more fun.


Kind regards,

T G-R

bug#36634: ATTENTION REQUIRED

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice 写道：
Could anyone please update the libvirt package/service to this 
latest

build?


I will do so swiftly since I updated libvirt to the 'broken' 
version

(although I never had any troubles like yours).  Thank you for
reporting this upstream.


I have applied ‘your’ patch in 
41097b2dee9367974c6dd16ac1ba2ee945457237.


I'm closing this bug for now.  However, could you update and 
confirm that this actually solves the problem?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#36781: Website manual generation stopped

[Ludovic Courtès]

Hi,

Julien Lepiller  skribis:

> Hi guix, it seems that the devel version of the manual is not regenerated as 
> intended. The website says that it's still from July 18th.

Indeed it fails like this:

--8<---cut here---start->8---
ludo@berlin ~$ sudo su - static-web-site -c 
/gnu/store/9w4bbd6gqya2g9zvwgs6qab6aqgbjbd3-update-guix-manual-devel
Backtrace:
   7 (primitive-load "/gnu/store/9w4bbd6gqya2g9zvwgs6qab6aqg…")
In ice-9/eval.scm:
619:8  6 (_ #f)
   626:19  5 (_ #)
In unknown file:
   4 (_ # #<…> …)
In guix/git.scm:
   240:29  3 (update-cached-checkout "https://git.sv.gnu.org/git/gu…"; …)
In ice-9/boot-9.scm:
841:4  2 (with-throw-handler _ _ _)
In git/clone.scm:
 41:8  1 (_ _ _ _)
In ice-9/boot-9.scm:
   752:25  0 (dispatch-exception _ _ _)

ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
Git error: cross host redirect not allowed
--8<---cut here---end--->8---

So I think we have to change the repo URL in berlin.scm.

Ludo’.

bug#36782: Website manual language links

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Wed, Jul 24, 2019 at 01:13:44PM +0200, Julien Lepiller wrote:
>> Hi guix,
>> 
>> The online manual says it is available in other languages on its index page, 
>> with links to… the current page. Can we fix that so one can switch to that 
>> other language?

We should apply the patch at

to our Texinfo package, or at least the one used in doc/build.scm.

Any takers?  :-)

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> I gave a small tutorial to someone today, where we installed guix on top of a 
> foreign distro. We used the script and everything went smoothly, and after 
> finding out that we were going to build php (we were trying to define a VM 
> that would serve one of their services), we tried to run guix pull:
>
> sudo guix pull —commit=…
>
> However the command failed immediately with:
>
> Migrating profile generations to '/var/guix/profiles/per-user/root'...
> Guix pull: error: symlink: File exists: 
> "/var/guix/profiles/per-user/root/current-guix"
>
> Indeed, the file exists and everything looks good. Why does guix try to 
> migrate a profile that's already good?
>
> I was able to work around that situation, but it's not great for our users.

I’m guessing the machine had remnants of a previous Guix installation,
no?  See:

  ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
  ;; them to %PROFILE-DIRECTORY.
  (unless (string=? %profile-directory
(dirname (canonicalize-profile %user-profile-directory)))
(migrate-generations %user-profile-directory %profile-directory))

Ludo’.

bug#36786: Warn of AMD GPUs unusable with Guix System

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> pelzflorian (Florian Pelz)  writes:
>
>> On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
>>> We could make a list of known bad GPUs.
>>>
>>
>> When thinking about it, a list of known bad GPUs might be legally
>> safer than saying AMD GPUs are often bad.
>
> I sympathize with the frustration that comes along with the realization
> that hardware you own cannot be used with free software.  I would like
> to alert people to the fact that certain GPUs won’t be usable with
> linux-libre.
>
> I just think that there might be a better distro-independent place for
> this kind of information.  Some free distros suggest checking for free
> software compatibility on h-node.org, a shared resource.  That’s also
> where we could record known bad GPUs.
>
> (h-node.org isn’t the prettiest resource out there, but perhaps this can
> be changed.)

What about adding a few words under “Hardware Considerations”?

Ludo’.

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Jakob L. Kreuze]

Hi,

I believe there is an issue with 'lower-gexp'. Running the following
snippet to lower a G-Expression for "i686-linux" yields output that
references store paths built for x86_64. In this case, the Guile
interpreter used is an x86_64 binary.

#+BEGIN_SRC scheme
(define (display-exp exp)
  (mlet* %store-monad ((lowered (lower-gexp exp
#:system "i686-linux"
#:target "i686-linux"))
   (to-build -> (cons (lowered-gexp-guile lowered)
  (lowered-gexp-inputs lowered)))
   (_ (built-derivations to-build)))
(return (format #t "~a~%" (lowered-gexp-sexp lowered)

(with-store store
  (run-with-store store
(display-exp #~(primitive-load #$(switch-system-program %system)
#+END_SRC

jakob@Epsilon ~ $ guile ~/test.scm 
(primitive-load 
/gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm)
jakob@Epsilon ~ $ cat 
/gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm
#!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile 
--no-auto-compile
!#
...
jakob@Epsilon ~ $ file 
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile: ELF 64-bit 
LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, not stripped

This doesn't seem to be an issue if '%current-system' is parameterized,
as in the following.

#+BEGIN_SRC scheme
(parameterize ((%current-system "i686-linux"))
  (with-store store
(run-with-store store
  (display-exp #~(primitive-load #$(switch-system-program %system))
#+END_SRC

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36634:

[Raghav Gururajan]

> I will do so swiftly since I updated libvirt to the 'broken' version 
> (although I never had any troubles like yours).  Thank you for 
> reporting this upstream.

About that, it appears I misunderstood the patch. That recent build was
not to fix the bug I reported. Anyway, I have been told by one of the
libvirt maintainers (pavel) that they are working on a fix for the bug
I reported.

So once I come to know about the new patch, I will update you and this
mail list. :)

> A personal note: I find this new wave of 'ATTENTION REQUIRED'
> messages 
> quite the opposite of motivating and pleasant.  I'm honestly not
> sure 
> what result you expect from them.  I fear it may backfire.

Yeah, sorry about that. It was not intentional. I thought that sending
replies directly to `#b...@debbugs.gnu.org` will not use the subject
line, so just went with something top of my head. I will defer to do
this, moving forward. :)

Regards,
RG.

signature.asc
Description: This is a digitally signed message part

bug#36634:

[Raghav Gururajan]

> I have applied ‘your’ patch in 
> 41097b2dee9367974c6dd16ac1ba2ee945457237.
> 
> I'm closing this bug for now.  However, could you update and 
> confirm that this actually solves the problem?

Oh Shoot! I just saw your previous reply and replied to it. Sorry for
the delay. Anyway that patch fixes something, so good.

You do not have to close the bug. I will update this mail list once I
receive the correct patch. :)

Regards,
RG.

signature.asc
Description: This is a digitally signed message part

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

On Fri, Jul 26, 2019 at 01:04:40AM +0200, Ludovic Courtès wrote:
> What about adding a few words under “Hardware Considerations”?
> 

While my patch before addresses AMD-specific tweaks in the manual
under Hardware Considerations, it is not enough if on the *download
page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
machine“ without saying linux-libre *on some hardware, is not
supported* and referencing the Hardware Considerations section and
h-node, I think.

Regards,
Florian

bug#36785: Impossible to pull on foreign distro

[Julien Lepiller]

Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès"  a écrit 
:
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>> I gave a small tutorial to someone today, where we installed guix on
>top of a foreign distro. We used the script and everything went
>smoothly, and after finding out that we were going to build php (we
>were trying to define a VM that would serve one of their services), we
>tried to run guix pull:
>>
>> sudo guix pull —commit=…
>>
>> However the command failed immediately with:
>>
>> Migrating profile generations to
>'/var/guix/profiles/per-user/root'...
>> Guix pull: error: symlink: File exists:
>"/var/guix/profiles/per-user/root/current-guix"
>>
>> Indeed, the file exists and everything looks good. Why does guix try
>to migrate a profile that's already good?
>>
>> I was able to work around that situation, but it's not great for our
>users.
>
>I’m guessing the machine had remnants of a previous Guix installation,
>no?  See:
>
>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>Move
>  ;; them to %PROFILE-DIRECTORY.
>  (unless (string=? %profile-directory
>  (dirname (canonicalize-profile %user-profile-directory)))
>(migrate-generations %user-profile-directory %profile-directory))
>
>Ludo’.

Not at all, this was the first install on that machine. The OS was even 
installed recently, so there can't be any remnant of the 0.15 era :). 
Installation went smoothly and /root/.config/guix/current was already a symlink 
to /var/guix/profiles/per-user/root. We ran guix pull as user just before and 
it worked perfectly well (with the message about migrating, although 
~/.config/guix/current didn't exist).

Could there be some veird interaction between sudo and these %profile-directory 
and %user-profile-directory variables?