bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

2022-02-21 Thread Jacob MacDonald
My description of the bug was hasty. The viewer is still broken in the
same way, but I realize now that the text is not invisible or
unselectable. Rather, selection still works but only displays
selection markers at the upper left corner of the screen. According to
a bug report about Calibre, similar things can happen if the fonts are
not properly installed
(https://www.mobileread.com/forums/showthread.php?t=315146). However,
I checked a working version and broken version of my Guix profile
against one another and the fonts appear to be installed correctly in
both trees.

While doing that, I also noticed that __pycache__ directories only
exist in the broken tree. Is that a signal of something going wrong or
just a change in Guix's Python?





bug#54097: go importer does not honor multi-module repositories

2022-02-21 Thread raingloom
On Mon, 21 Feb 2022 23:43:54 +0100
Björn Höfling  wrote:

> Go usually has the 1 repository=1 module convention. However, it
> is also allowed that one repository contains multiple go modules.
> 
> If repository "foo" contains only one module, then versions are tagged
> "v1.2.3".
> 
> However, if the repository "foo" contains modules "bar" and "baz",
> each in a sub-directory of "foo", the versions will be tagged with
> their respective prefix, i.e.:
> 
> foo/v1.2.3
> bar/v4.5.6
> 
> See here:
> 
> https://github.com/golang/go/wiki/Modules#publishing-a-release
> https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
> https://stackoverflow.com/questions/64701064/golang-separate-versioning-of-multiple-modules
> 
> However, our go-importer does not honor this. The Google Cloud API
> modules are structured into sub-modules, but our importer searches the
> wrong tag and raises an exception:
> 
> $ ./pre-inst-env guix import go cloud.google.com/go/storage
> URL FOR VERSIONS:
> https://proxy.golang.org/cloud.google.com/go/storage/@v/list
> FETCH_GO_MOD:
> https://proxy.golang.org/cloud.google.com/go/storage/@v/v1.21.0.mod
> Backtrace: In ice-9/boot-9.scm: 1752:10 17 (with-exception-handler _
> _ #:unwind? _ # _) In unknown file:
>   16 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 724:2 15 (call-with-prompt _ _ # default-prompt-handle?>) In ice-9/eval.scm:
> 619:8 14 (_ #(#(#)))
> In guix/ui.scm:
>2209:7 13 (run-guix . _)
>   2172:10 12 (run-guix-command _ . _)
> In guix/scripts/import.scm:
>124:11 11 (guix-import . _)
> In ice-9/boot-9.scm:
>   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/import/go.scm:
>116:29  9 (_)
> In ice-9/exceptions.scm:
>406:15  8 (go-module->guix-package* . _)
> In ice-9/boot-9.scm:
>   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/import/go.scm:
>525:18  6 (go-module->guix-package "cloud.google.com/go/storage" #
> ?) In guix/git.scm:
> 277:4  5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _
> ?) 266:18  4 (resolve _)
> In git/reference.scm:
>  60:8  3 (_ _ _)
> In git/bindings.scm:
>  77:2  2 (raise-git-error _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1683:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1683:16: In procedure raise-exception:
> Git error: reference 'refs/tags/v1.21.0' not found
> 
> 
> The correct git reference to look for is:
> 
> refs/tags/storage/v1.21.0
> 
> Björn
> 

I think this has been mentioned before, but I really think we should
use Go's built-in tooling to extract this info, instead of
reimplementing it in Guile. There is already some massive ineffeciency
introduced by the importer cloning whole repos, whereas `go get` is
smart enough to only download `go.mod` files.
Just my 2c.





bug#54094: frama-c doesn't start

2022-02-21 Thread raingloom
On Mon, 21 Feb 2022 22:22:14 +0100
Julien Lepiller  wrote:

> guix shell ocaml ocaml-findlib frama-c
> 
> Should work :)
> 
> Ocaml is needed to define OCAMLPATH, ocaml-findlib is what frama-c is
> missing. Should we wrap the binary?
> 
> On February 21, 2022 10:13:07 PM GMT+01:00, raingloom
>  wrote:
> >I was just idly messing around so I'm not super motivated to dig
> >deeper.
> >
> >```
> >guix shell frama-c -- frama-c
> >[kernel] User Error: [findlib] package 'ocamlgraph' not found
> >(required by `frama-c.kernel') [kernel] User Error: Deferred error
> >message was emitted during execution. See above messages for more
> >information. [kernel] Frama-C aborted: invalid user input. ```
> >
> >
> >  

> Should we wrap the binary?
Definitely. Binaries are supposed to just work as far as I know.





bug#54097: go importer does not honor multi-module repositories

2022-02-21 Thread Björn Höfling
Go usually has the 1 repository=1 module convention. However, it
is also allowed that one repository contains multiple go modules.

If repository "foo" contains only one module, then versions are tagged
"v1.2.3".

However, if the repository "foo" contains modules "bar" and "baz", each
in a sub-directory of "foo", the versions will be tagged with their
respective prefix, i.e.:

foo/v1.2.3
bar/v4.5.6

See here:

https://github.com/golang/go/wiki/Modules#publishing-a-release
https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
https://stackoverflow.com/questions/64701064/golang-separate-versioning-of-multiple-modules

However, our go-importer does not honor this. The Google Cloud API
modules are structured into sub-modules, but our importer searches the
wrong tag and raises an exception:

$ ./pre-inst-env guix import go cloud.google.com/go/storage
URL FOR VERSIONS: https://proxy.golang.org/cloud.google.com/go/storage/@v/list
FETCH_GO_MOD: 
https://proxy.golang.org/cloud.google.com/go/storage/@v/v1.21.0.mod
Backtrace:
In ice-9/boot-9.scm:
  1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  16 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 15 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 14 (_ #(#(#)))
In guix/ui.scm:
   2209:7 13 (run-guix . _)
  2172:10 12 (run-guix-command _ . _)
In guix/scripts/import.scm:
   124:11 11 (guix-import . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/go.scm:
   116:29  9 (_)
In ice-9/exceptions.scm:
   406:15  8 (go-module->guix-package* . _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/import/go.scm:
   525:18  6 (go-module->guix-package "cloud.google.com/go/storage" # ?)
In guix/git.scm:
277:4  5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ ?)
   266:18  4 (resolve _)
In git/reference.scm:
 60:8  3 (_ _ _)
In git/bindings.scm:
 77:2  2 (raise-git-error _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1683:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v1.21.0' not found


The correct git reference to look for is:

refs/tags/storage/v1.21.0

Björn



pgpzgjAVZvCCz.pgp
Description: OpenPGP digital signature


bug#54094: frama-c doesn't start

2022-02-21 Thread Julien Lepiller
guix shell ocaml ocaml-findlib frama-c

Should work :)

Ocaml is needed to define OCAMLPATH, ocaml-findlib is what frama-c is missing. 
Should we wrap the binary?

On February 21, 2022 10:13:07 PM GMT+01:00, raingloom  
wrote:
>I was just idly messing around so I'm not super motivated to dig
>deeper.
>
>```
>guix shell frama-c -- frama-c
>[kernel] User Error: [findlib] package 'ocamlgraph' not found (required by 
>`frama-c.kernel')
>[kernel] User Error: Deferred error message was emitted during execution. See 
>above messages for more information.
>[kernel] Frama-C aborted: invalid user input.
>```
>
>
>


bug#54094: frama-c doesn't start

2022-02-21 Thread raingloom
I was just idly messing around so I'm not super motivated to dig
deeper.

```
guix shell frama-c -- frama-c
[kernel] User Error: [findlib] package 'ocamlgraph' not found (required by 
`frama-c.kernel')
[kernel] User Error: Deferred error message was emitted during execution. See 
above messages for more information.
[kernel] Frama-C aborted: invalid user input.
```





bug#54082: bugreport

2022-02-21 Thread daniel . herzig
Hi!

I just noticed an error in my initial message.

The mentioned 'reconfigure' in the VM did not happen after the 'pull',
but before (I did not expect being on an 'old' commit, right after
entering the 'fresh' machine for the first time, so I thought this
might help -- that's how I found the 'bug').

However, the situation persists also pulling to 6cae4e.

Might this have something to do with 'guix system image' deliberatly
starting with guix a27e4?  After running the initial command as user (I
see guix a27e4 being pulled there):

image=$(guix system image --image-type=qcow2 --image-size=10G --save-
provenance vm-configs/nextcloud-barebone.scm)

A second execution of this command from the (updated) root guix, there
does not seem to happen any computation, which I would expect if it
would pull another guix.

Sorry for the possibly misleading intro & best,
Daniel


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


bug#54082: bugreport

2022-02-21 Thread daniel . herzig
Dear guix!

guix just told me to report a bug.

This happened on a 'guix pull' followed by 'guix system reconfigure'
inside a guix vm built on guix system with:

Generation 80 14. Februar 2022 01:43:41 (aktuell)
 guix 6bfb3fc
 Repository-URL: https://git.savannah.gnu.org/git/guix.git
 Branch: master
 Commit: 6bfb3fc1f450c7d618041303d0ff35691b5991c0

I built it with the command:

image=$(guix system image --image-type=qcow2 --image-size=10G --save-
provenance vm-configs/nextcloud-barebone.scm)
cp $image /tmp/my-image.qcow2
chmod +w /tmp/my-image.qcow2

And start up the machine like this:

qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 -net
nic -net user,hostfwd=tcp::-:,hostfwd=tcp::-:80

Attached you find the output and the definition of the image.

I wouldn't have felt the need to 'guix pull' inside the kvm, but a
'guix describe' inside of it showed me it was running on the (never-
updated) root-user's commit instead my user's one (although it starts
up with the kernel-version of the running system):

alice@komputilo ~$ guix describe
 guix a27e47f
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: a27e47f9d1e22dc32bb250cfeef88cfacb930e23

I now 'guix pulled' for root and my user to commit
45995eab3ae62ceef89ee223a1bc805738356c1f (and as user also reconfigured
system and home), but the problem persists.

If I just 'su', root keeps seing
a27e47f9d1e22dc32bb250cfeef88cfacb930e23 (from /run/current-
system/profile/bin/guix).  If I 'su -', root turns out to be the one
I'd wish it permanently to be (using 45995 from
/root/.config/guix/current/bin/guix).

It's quite possible, that I messed something up with various 'sudo',
'sudo -i', 'su', and 'su -' variations in the meantime.

It started with a not-(never)-updated root guix, and now there's still
enough of a not-updated root guix left, to keep me away from proceeding
with my vm in a sane way.

Any suggestions on that are highly appreciated,

Best,
Daniel

alice@komputilo ~$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 45995ea (1,601 new commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   45995ea
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 config.scm  501B   3KiB/s 00:00 
[##] 100.0%
 git.scm  101B219KiB/s 00:00 
[##] 100.0%
 hash.scm  130B   213KiB/s 00:00 
[##] 100.0%
 module-import  2KiB  1.7MiB/s 00:00 
[##] 100.0%
 module-import-compiled  1.2MiB   2.9MiB/s 00:00 
[##] 100.0%
 compute-guix-derivation  1015B   611KiB/s 00:00 
[##] 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 gnutls-3.7.2-doc  1.0MiB 1.1MiB/s 00:01 
[##] 100.0%
 expat-2.4.1  97KiB   151KiB/s 00:01 
[##] 100.0%
 gnutls-3.7.2-debug  4.4MiB   696KiB/s 00:06 
[##] 100.0%
 nghttp2-1.44.0-lib  86KiB 31KiB/s 00:03 
[##] 100.0%
 openssl-1.1.1l  1.6MiB   1.5MiB/s 00:01 
[##] 100.0%
 libgit2-1.3.0  590KiB6.2MiB/s 00:00 
[##] 100.0%
 mit-krb5-1.19.2  1.0MiB  1.4MiB/s 00:01 
[##] 100