bug#36687: guix gc: error: executing SQLite statement: database disk image is malformed

2023-12-29 Thread pkill9 via Bug reports for GNU Guix

Hi, I fixed this issue using sqlite3's built-in recover command:

sudo mv /var/guix/db/db.sqlite /var/guix/db/db.sqlite.bak
sqlite3 /var/guix/db/db.sqlite.bak ".recover" | sudo sqlite3 
/var/guix/db/db.sqlite


Solution was found at 





bug#58508: gtg package (Getting Things GNOME) doesn't run

2022-10-14 Thread Pkill9
This is the error I get when running:

guix environment --ad-hoc gtg -- gtg

```
Traceback (most recent call last):
  File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", 
line 76, in 
gi.require_version('GtkSource', '4') 
  File 
"/gnu/store/vbms7iz53dpdz5iz8ik2blr77w17imva-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
 line 126, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace GtkSource not available

```





bug#58207: Bug: Package Celluloid generates an icon cache which overwrites the profile's icon cache

2022-09-30 Thread Pkill9
The Celluloid package generates it's own icon cache at
share/icons/hicolor/icon-theme.cache. When you install the Celluloid, I
believe this overwrites the profile's icon-theme.cache, which causes
none of the other icons to show up in launchers that use this, for
example gnome shell's application launcher.

Perhaps also it is an issue that the profile's generated files do not
have priority over all the files within all the packages installed to
the profile, i.e. none of the packages should be able to overwrite the
files generated with the profile hooks. 





bug#47201: sbcl-cl-webkit doesn't protect webkitgtk from garbage collection

2021-03-16 Thread pkill9
I have nyxt installed, which has sbcl-cl-webkit as an input, which has
webkitgtk as an input, and recently it produced an error which was
fixed by building webkitgtk, so it wasn't in the store.

sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
be, so it seems it's not protected from garbage collection by
sbcl-cl-webkit. Am I wrong in this?





bug#46861: `guix deploy` permission denied error

2021-03-03 Thread pkill9
Ok, I just did `guix pull` on the machine deploying to the remote host,
which had the same problem before, and it created last-expiry-cleanup
and the file is owned by root, and changing it to my user fixed it. Not
sure what happened the first time around, I'm so confused...

My only guess is that I did a guix pull as root, which put that there
like suggested, but that guix deploy also relies on it, so when I
deleted that file, `guix deploy` didn't recreate it because it doesn't
handle it. The thing is, it didn't say no such file or directory, it
said permission denied. I dunno.. I worked myself up into confusion... 





bug#46861: `guix deploy` permission denied error

2021-03-02 Thread pkill9
It does this with guix pull too, and it's on the machine that is doing
the deploying that gui pull causes the error, but guix pull worked fine
on the machine being deployed to.





bug#46861: `guix deploy` permission denied error

2021-03-01 Thread pkill9
When I run Guix deploy, I get this error:
```
guix deploy: error: open-file: Permission denied:
"/home/itsme/.cache/guix/checkouts/last-expiry-cleanup"
```

I've tried deleting ~/.cache/guix, and creating a chmod 777'd
~/.cache/guix directory, but I still get that error.





bug#46760: guix deploy doesn't seem to be authorizing the machine that is deploying to the remote

2021-02-24 Thread pkill9
I'm using the machine-ssh-configuration, I set `(authorize? #t)` which
the manual states should authorize the deploying machine onto the
remote host, but I get an error:
```
guix deploy: error: unauthorized public key: (public-key...
```

So I add to the OS definition:

```
 (guix-configuration
   (authorized-keys (append `(,(local-file
"/etc/guix/signing-key.pub")) %default-authorized-guix-keys

```

Which makes the error go away. I'm under the impression however that
the 'authorize? #t' field should be doing this without me needing to
add it to the OS configuration.





bug#46757: Guix deploy doesn't seem to be respecting (build-locally? #f)

2021-02-24 Thread pkill9



With (build-locally? #f) set, it should build on the remote, but it
starts building guix on the local machine. Maybe it should be doing
that? I'm not sure.





bug#46756: guix deploy not copying remote-gexp.scm

2021-02-24 Thread pkill9
I keep getting this error:

```
(system-error "open-file" "~A: ~S" ("No such file or directory"
"/gnu/store/p3ahdfcwa5yd65l5nzsnzshw9s7x3xc7-remote-exp.scm") (2))
```

when I try to run `guix deploy`. This is on the remote machine. I can
get it to work by using `guix copy` to copy that file from my local
machine to the remote, but i don't know why it isn't copying it over
automatically.





bug#46389: Guix says it will download an output that is already downloaded

2021-02-09 Thread pkill9
> ‘guix build qtbase’ said it would download both the “out” and the
> “debug” output of qtbase, is that correct?

Yep

> It would be ideal if you could send precisely what’s on your terminal.
> 
> Thanks,
> Ludo’.

In this example, I've checked the store path
"/gnu/store/vpvnd6593mjncvyir2rbgp3k83cr7w0a-qtbase-5.15.2" exists, and
I've run `guix gc --delete
/gnu/store/f2s8ql1x9d9890qrrf9qq4nix3f5aii3-qtbase-5.15.2-debug`:

```
itsme@antelope ~> guix build -n qtbase
209.5 MB would be downloaded:
   /gnu/store/f2s8ql1x9d9890qrrf9qq4nix3f5aii3-qtbase-5.15.2-debug
   /gnu/store/vpvnd6593mjncvyir2rbgp3k83cr7w0a-qtbase-5.15.2
```
 I can't test it with `guix build qtbase` because my internet keeps
 cutting off while downloading qtbase-5.15.2-debug, but iirc
after it downloads the debug output, it just returns both store paths.





bug#46389: Guix says it will download an output that is already downloaded

2021-02-08 Thread pkill9
I had qtbase downloaded to the store as a reference for another store
path, but `guix build qtbase` said it will download it, but it only
downloaded the debug output of qtbase, plus the other dependencies, so
maybe guix doesn't omit package outputs that have already been
downloaded?





bug#46283: `guix system delete-generations` deletes generation before regenerating GRUB menu

2021-02-03 Thread pkill9
Cancelling the operation before the grub menu is rebuilt makes it kind
of incomplete, as the entries will still be in the GRUB menu but won't
work.





bug#45978: kodi-cli error: "show_help: command not found"

2021-01-19 Thread pkill9
Building with `--with-branch=kodi-cli=master` fixed this, so just needs
an update.





bug#45978: kodi-cli error: "show_help: command not found"

2021-01-19 Thread pkill9
kodi-cli is a bash script, and the 'show_help' function is called
before it's defined. Not really something that can be fixed in Guix,
Probably just needs an update.





bug#45051: Guix pull fails: `In procedure put-string: Wrong type argument in position 1 (expecting open output port): #`

2020-12-11 Thread pkill9
Hi Ludovic,

> Could it be that your substitute URL is ?
> 
> If so, could you try:
> 
>   guix build inkscape --substitute-urls=https://ci.guix.gnu.org

This works, thanks.





bug#45051: Acknowledgement (Guix pull fails: `In procedure put-string: Wrong type argument in position 1 (expecting open output port): #`)

2020-12-05 Thread pkill9
It's actually doing this for *any* package I build, and it's not
because it can't get substitutes, as running `guix weather hello`
reports that a substitute is available, but it still does this issue
with the `hello` package.





bug#45051: Acknowledgement (Guix pull fails: `In procedure put-string: Wrong type argument in position 1 (expecting open output port): #`)

2020-12-05 Thread pkill9
with --fallback it is building. It may be the result of the substitute
server not being available, the error may need to be caught.





bug#45051: Guix pull fails: `In procedure put-string: Wrong type argument in position 1 (expecting open output port): #`

2020-12-05 Thread pkill9
Using guix commit 243512d984e1b870d3b77b2759698a64ed723fea. Also fails
with previous guix revisions.

Full output:

Computing Guix derivation for 'x86_64-linux'... /@ substituter-started
/gnu/store/9ph7spq3b72fv4scqqzwxalb8n0wc6xn-graphviz-2.42.3-doc
substitute -following redirection to
`https://ci.guix.gnu.org/nar/lzip/9ph7spq3b72fv4scqqzwxalb8n0wc6xn-graphviz-2.42.3-doc'...
Backtrace: In ice-9/boot-9.scm: 1736:10  4 (with-exception-handler _ _
#:unwind? _ # _) In unknown file:
   3 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  1949:12  0 (run-guix-command _ . _)

guix/ui.scm:1949:12: In procedure run-guix-command:
In procedure put-string: Wrong type argument in position 1 (expecting
open output port): # @ substituter-failed
/gnu/store/9ph7spq3b72fv4scqqzwxalb8n0wc6xn-graphviz-2.42.3-doc 256
fetching path
`/gnu/store/9ph7spq3b72fv4scqqzwxalb8n0wc6xn-graphviz-2.42.3-doc'
failed with exit code 1 @ substituter-started
/gnu/store/adx3hrrgjs0n55zm4i4p5kv6yj0q3bhq-guile-ssh-0.13.1-debug
substitute killing process 4025 Backtrace: 11 (primitive-load
"/gnu/store/f2ymnsn7d0jv9p8alj4mrg4dpw2fr5vn-compute-guix-derivation")
In ice-9/eval.scm: 155:9 10 (_ _) 159:9  9 (_
#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ./guix/store.scm: 2049:24  8
(run-with-store # _
#:guile-for-build _ #:system _ #:target _) 1883:8  7 (_ _) In
./guix/gexp.scm: 258:18  6 (_ _) 1123:2  5 (_ _)
982:2  4 (_ _)
843:4  3 (_ _)
In ./guix/store.scm:
  1931:12  2 (_ #)
   1358:5  1 (map/accumulate-builds # _ _) 1369:15  0 (_ # 7fc0406ba5f0> _ _)

./guix/store.scm:1369:15: ERROR:
  1. :
  message: "some substitutes for the outputs of derivation
`/gnu/store/d879bxb47cnzkgsl37478aa4mmp7cjdg-graphviz-2.42.3.drv'
failed (usually happens due to networking issues); try `--fallback' to
build derivation from source " status: 1 guix pull: error: You found a
bug: the program
'/gnu/store/f2ymnsn7d0jv9p8alj4mrg4dpw2fr5vn-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"4cf3734c56d669ee2d78082e5d7c4d0a58e0f800"; system: "x86_64-linux";
host version: "243512d984e1b870d3b77b2759698a64ed723fea"; pull-version:
1). Please report it by email to .





bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

2020-10-16 Thread pkill9
> All I’m saying is that nothing can be done when the new name is longer
> than the old one: we just cannot graft.

If a symlink is used though, it wouldn't matter if the new name is
longer, the symlink would point to the new package, and the name of the
symlink would match the length of the old package.





bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

2020-10-15 Thread pkill9
> > Maybe if the length/version is different, then a symlink could be
> > created in the store pointing to the new dependency, with a
> > name/version that matches the length of the original dependency's
> > store name? Perhaps this new name/version could be something like
> > /gnu/store/...-original-dependency-name-gg, where 'g..' matches
> > the length of the version of the original dependency. The many 'g's
> > would make it clear that it is a graft. Then if someone looks in
> > the store, they would see it's a symlink too.  
> 
> That only works if the new name is shorter than the old name though.
> When the new name is longer (which is a more common case in our
> experience when introducing package replacements, typically because
> the new version string is longer), nothing can be done.

I'm confused about what you mean. Why would it matter if the new
name is longer than the old name?





bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

2020-10-13 Thread pkill9
As expected, if you attempt to graft a package's dependency, and it's
name + version is different length to the original dependency, then it
will fail to graft.

Maybe if the length/version is different, then a symlink could be
created in the store pointing to the new dependency, with a
name/version that matches the length of the original dependency's store
name? Perhaps this new name/version could be something like
/gnu/store/...-original-dependency-name-gg, where 'g..' matches the
length of the version of the original dependency. The many 'g's would
make it clear that it is a graft. Then if someone looks in the store,
they would see it's a symlink too.





bug#42688: Running a script with `guix repl` doesn't "see" additional channels using (%package-module-path)

2020-08-02 Thread pkill9
Running the following in `guix repl` returns additional channels:
```
itsme@antelope ~> guix repl
GNU Guile 3.0.4
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (use-modules (gnu packages))
scheme@(guix-user)> (%package-module-path)
$1 =
(("/gnu/store/kds0mq06qpin125gkikwzdm6mjfwjffc-guix-module-union/share/guile/site/3.0"
. "gnu/packages")
"/gnu/store/96pa4rc57zgqf36y2kv8z20p2jvlgypq-pkill9-free-channel-dependency/share/guile/site/3.0"
"/gnu/store/3ilx18ywdm6xk9f5l1mznrn45vcbncsq-pkill9-free/share/guile/site/3.0")
scheme@(guix-user)>
```

But running the following in "test.scm" with `guix repl /tmp/test.scm
doesn't return additional channels:
```
(use-modules (gnu packages))
(display (%package-module-path))
```

```
((/gnu/store/kds0mq06qpin125gkikwzdm6mjfwjffc-guix-module-union/share/guile/site/3.0
. gnu/packages))
```

fold-available-packages uses this to search for packages, which I am
using for a script. As a result, the script doesn't know about packages
from the additional channels.





bug#42420: git-fetch origins produce same store output when set recursive is set to true or false

2020-07-18 Thread pkill9
I built a source that uses git-fetch - by default (recursive? #f) - and
the package failed to build, then I remembered it uses submodules, so I
set (recursive? #t) but it failed with the same error. The problem is
that the store path of the source is the same for both, so it didn't
try to rebuild the git checkout with submodules checked out.

After garbage collecting the source so it rebuilds it, I can build the
package.





bug#42155: --with-source=PACKAGE=REPLACEMENT-SOURCE doesn't work recursively

2020-07-02 Thread pkill9
> I think what you're looking for is more of:
> 
> guix build --no-grafts mpv --with-input=youtube-dl=$(guix build
> --no-grafts youtube-dl
> --with-source=https://github.com/ytdl-org/youtube-dl/releases/download/2020.06.16/youtube-dl-2020.06.16.tar.gz)
> 
> This didn't work for me though, I got:
> guix build: error:
> /gnu/store/9ncacjhzwlchpr1y5fd8ahdq59dsya20-youtube-dl-2020.06.16:
> unknown package

Even if that worked, it doesn't fix the issue of the --with-source flag
not working on the specified package's inputs.

That command doesn't work because you're giving it a store path, not a
package specification.





bug#42156: Guix unnecessarily rebuilds packages when replacing a source with --with-git-url

2020-07-01 Thread pkill9
Running `guix build 
--with-git-url=youtube-dl=https://github.com/ytdl-org/youtube-dl mpv -n`
shows it will rebuild packages unecessarily:

```
The following derivations would be built:
   /gnu/store/3qhfgkacylwsvzxgz5fqdgxlx812c7nf-mpv-0.32.0.drv
   /gnu/store/2240y6fjiq2riiq1rj4apci5s7sl7rk6-youtube-dl-2020.06.16.1.drv
   /gnu/store/94dqd7xiy0sdmhzxikqrycllm921fcm5-libcaca-0.99.beta19.drv
   /gnu/store/r0p4y6b78x2lfdh51p8287al3i461pfr-ftgl-2.4.0.drv
   /gnu/store/an06c6fg9w0ja44sbmnssryklziyjsia-mpg123-1.26.1.drv
   /gnu/store/ddkwx46ksizbz59fc5xwfxb7bq5j246h-ffmpeg-4.3.drv
   /gnu/store/h28qpl97rs3fc2rc2n2vxcpy3pyxnbm8-frei0r-plugins-1.7.0.drv
   /gnu/store/nyk555wa6kjqz311ini6gji21vl9j6lz-sdl2-2.0.12.drv
   /gnu/store/5mh046xgl3qzdkmccvmi3g08cl2zh4g0-fcitx-4.2.9.7.drv
   /gnu/store/jxqzag3jb5jbj5z60md011gi4r6g97js-enchant-1.6.0.drv
   /gnu/store/mi4ris95502ixx7yybp8wxay4g53q0zn-ibus-1.5.22.drv
   /gnu/store/3vhw2hspgvskfq26zsk2iihjlavp16id-dconf-0.34.0.drv
   /gnu/store/aybh2nafr8v5k8w1ld28s1hzvg3mfjkg-libnotify-0.7.7.drv
   /gnu/store/jzxixdnm7cbfajfx901mypi1acidjj0i-orbit2-2.14.19.drv
   /gnu/store/cwm9rdd3c1l6j2x3gdkc6s8dxaba9hfb-libidl-0.8.14.drv
   /gnu/store/rams8llip6qlhw1w83sl7xmamy52fr68-gconf-3.2.6.drv
   /gnu/store/3s2isd4z1qzyansngg67ib0a5hswvjs0-dbus-glib-0.110.drv
   /gnu/store/pv6a3vfay83kzcszl0rcnv0d5v1v1cd7-openal-1.20.1.drv
   /gnu/store/ynpm7jd13yyciz2lpyr6q9rh2kx0g530-libass-0.14.0.drv
   /gnu/store/yyc2cqz28nh75h1zgvjsza2w1nkxn8ai-libva-2.7.1.drv
   /gnu/store/gh57iyp68zjs0xfwfcfp6a3jsshpgp2j-rsound-1.1.drv
   /gnu/store/hj1s2riv7zvyvmw1hbnzzkv2gfa0ncqn-ao-1.2.2-5-g20dc8ed.drv
   /gnu/store/k0g5pp30s1m32yii5fk9rbiy2h3jyjhy-vulkan-loader-1.2.140.drv
```

It can be seen that it's unnecessary by running `guix graph --path
youtube-dl ffmpeg` and it shows youtube-dl isn't in the package graph
for ffmpeg, yet it's still rebuilding it.





bug#42155: --with-source=PACKAGE=REPLACEMENT-SOURCE doesn't work recursively

2020-07-01 Thread pkill9
For example, `guix build --with-source=youtube-dl=blahblah mpv` builds
mpv normally, after giving a message: guix build: warning:
transformation 'with-source' had no effect on mpv@0.32.0





bug#40906: Acknowledgement (Downloading the incorrect sourceforge URL doesn't fail)

2020-04-27 Thread pkill9
Weird, it is opening URLs fine again...





bug#40906: Downloading the incorrect sourceforge URL doesn't fail

2020-04-27 Thread pkill9
running `guix download
mirror://sourceforge/Jamulus/3.4.4/jamulus-3.4.4.tar.gz` eventually
downloads a HTML page.





bug#40381: Guix shouldn't request substitutes for profile derivations

2020-04-26 Thread pkill9
Hi,

> Can you show more precisely what you mean by pasting a command and its
> output?

So it seems it tries to look for substitutes when the profile hooks are built,
not when profile.drv is built.

Here is the output without build hooks:
```
itsme@antelope ~> guix environment --ad-hoc hello
The following derivation will be built:
   /gnu/store/gkz9hzjpc9pj1np7vi5pwb4xhmssk55d-profile.drv
building profile with 1 package...
Welcome to fish, the friendly interactive shell
itsme@antelope ~ [Guix env: /gnu/store/nsi48y..]>
```

And here is output with build hooks:
```
itsme@antelope ~> guix environment --ad-hoc man-db hello
substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0%
substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/w623j5spid7kyxjdp6xbgxs2r5scpjkn-profile.drv
The following profile hooks will be built:
   /gnu/store/14d1mgn1mwz66mj28rwjmnkddskf4zm0-info-dir.drv
   /gnu/store/7rrkqrdpxahk8g0927d56lpgz3n1kl6z-manual-database.drv
   /gnu/store/8h76m85hiyilv0mj053i9n7k2nxb0wf1-ca-certificate-bundle.drv
   /gnu/store/ia5d18hpmza375dizljqi2x12zlirwqi-fonts-dir.drv
building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 2 packages...
Welcome to fish, the friendly interactive shell
itsme@antelope ~ [Guix env: /gnu/store/9qv380..]>
```






bug#40381: Guix shouldn't request substitutes for profile derivations

2020-04-26 Thread pkill9
Hi Ludovic

> Can you show more precisely what you mean by pasting a command and its
> output?
> 
> With the recent changes in the implementation of grafts, what happens
> is usually this:
> 
>   $ guix build foo
>   updating the list of substitutes…
>   The following things will be built/downloaded:
>   …
> 
>   updating the list of substitutes…
>   The following things will be built/downloaded:
>   …
> 
> The second stage here typically includes profile.drv as well as
> grafts. All this is expected behavior.

I think that since profile.drv is always produced locally on the
machine, then it's unnecessary to update the list of substitutes
when it's on that second stage.





bug#40870: Quassel IRC client trying to open links with xdg-open from a nonexisting store path

2020-04-26 Thread pkill9
From the output:

```
2020-04-26 16:45:17 [Warn ] Launch failed
(/gnu/store/jsqihy7z3bsbiixchk19dsnaj6bh9h2b-xdg-utils-1.1.3/bin/xdg-open
https://freenode.net)
```

I assume it is recording the absolute path to xdg-open somewhere when
it's first run or something, but I can't find any references to it in
the configuration directory.





bug#40825: Teeworlds fails to load sound files

2020-04-24 Thread pkill9
I've attached a log.

It seems to fail to load all the sound files, e.g.
```
[2020-04-24 19:09:35][sound/wv]: failed to open audio/music_menu.wv:
can't open file
```.

I don't think it is failing to find them, because they are in
/share/teeworlds/data/audio, and it successfully
finds another file in the data subdirectory from seeing that log:
```
[2020-04-24 19:09:35][datafile]: loading.
filename='ui/themes/winter_night.map'
```
[2020-04-24 19:09:35][engine]: running on unix-linux-amd64
[2020-04-24 19:09:35][engine]: arch is little endian
[2020-04-24 19:09:35][storage]: couldn't open storage.cfg
[2020-04-24 19:09:35][storage]: using standard paths
[2020-04-24 19:09:35][storage]: added path '$USERDIR' ('/home/itsme/.teeworlds')
[2020-04-24 19:09:35][storage]: added path '$DATADIR' ('/gnu/store/v8yyrqlvqqylk7zgqw9g7a7knjg8nazd-teeworlds-0.7.4/share/teeworlds/data')
[2020-04-24 19:09:35][storage]: added path '$CURRENTDIR' ('/home/itsme')
[2020-04-24 19:09:35][binds]: bound f1 (186) = toggle_local_console
[2020-04-24 19:09:35][binds]: bound f2 (187) = toggle_remote_console
[2020-04-24 19:09:35][binds]: bound tab (9) = +scoreboard
[2020-04-24 19:09:35][binds]: bound e (101) = +stats
[2020-04-24 19:09:35][binds]: bound u (117) = +show_chat
[2020-04-24 19:09:35][binds]: bound f10 (195) = screenshot
[2020-04-24 19:09:35][binds]: bound ctrl+s (115) = snd_toggle
[2020-04-24 19:09:35][binds]: bound a (97) = +left
[2020-04-24 19:09:35][binds]: bound d (100) = +right
[2020-04-24 19:09:35][binds]: bound space (32) = +jump
[2020-04-24 19:09:35][binds]: bound mouse1 (411) = +fire
[2020-04-24 19:09:35][binds]: bound mouse2 (412) = +hook
[2020-04-24 19:09:35][binds]: bound lshift (353) = +emote
[2020-04-24 19:09:35][binds]: bound rshift (357) = +spectate
[2020-04-24 19:09:35][binds]: bound right (207) = spectate_next
[2020-04-24 19:09:35][binds]: bound left (208) = spectate_previous
[2020-04-24 19:09:35][binds]: bound 1 (49) = +weapon1
[2020-04-24 19:09:35][binds]: bound 2 (50) = +weapon2
[2020-04-24 19:09:35][binds]: bound 3 (51) = +weapon3
[2020-04-24 19:09:35][binds]: bound 4 (52) = +weapon4
[2020-04-24 19:09:35][binds]: bound 5 (53) = +weapon5
[2020-04-24 19:09:35][binds]: bound mousewheelup (420) = +prevweapon
[2020-04-24 19:09:35][binds]: bound mousewheeldown (421) = +nextweapon
[2020-04-24 19:09:35][binds]: bound t (116) = chat all
[2020-04-24 19:09:35][binds]: bound y (121) = chat team
[2020-04-24 19:09:35][binds]: bound x (120) = chat whisper
[2020-04-24 19:09:35][binds]: bound f3 (188) = vote yes
[2020-04-24 19:09:35][binds]: bound f4 (189) = vote no
[2020-04-24 19:09:35][binds]: bound r (114) = ready_change
[2020-04-24 19:09:35][console]: executing 'settings07.cfg'
[2020-04-24 19:09:35][binds]: bound tab (9) = +scoreboard
[2020-04-24 19:09:35][binds]: bound space (32) = +jump
[2020-04-24 19:09:35][binds]: bound 1 (49) = +weapon1
[2020-04-24 19:09:35][binds]: bound 2 (50) = +weapon2
[2020-04-24 19:09:35][binds]: bound 3 (51) = +weapon3
[2020-04-24 19:09:35][binds]: bound 4 (52) = +weapon4
[2020-04-24 19:09:35][binds]: bound 5 (53) = +weapon5
[2020-04-24 19:09:35][binds]: bound a (97) = +left
[2020-04-24 19:09:35][binds]: bound d (100) = +right
[2020-04-24 19:09:35][binds]: bound t (116) = chat all
[2020-04-24 19:09:35][binds]: bound u (117) = +show_chat
[2020-04-24 19:09:35][binds]: bound y (121) = chat team
[2020-04-24 19:09:35][binds]: bound f1 (186) = toggle_local_console
[2020-04-24 19:09:35][binds]: bound f2 (187) = toggle_remote_console
[2020-04-24 19:09:35][binds]: bound f3 (188) = vote yes
[2020-04-24 19:09:35][binds]: bound f4 (189) = vote no
[2020-04-24 19:09:35][binds]: bound f10 (195) = screenshot
[2020-04-24 19:09:35][binds]: bound right (207) = spectate_next
[2020-04-24 19:09:35][binds]: bound left (208) = spectate_previous
[2020-04-24 19:09:35][binds]: bound lshift (353) = +emote
[2020-04-24 19:09:35][binds]: bound rshift (357) = +spectate
[2020-04-24 19:09:35][binds]: bound mouse1 (411) = +fire
[2020-04-24 19:09:35][binds]: bound mouse2 (412) = +hook
[2020-04-24 19:09:35][binds]: bound mousewheelup (420) = +prevweapon
[2020-04-24 19:09:35][binds]: bound mousewheeldown (421) = +nextweapon
[2020-04-24 19:09:35][binds]: unbound e (101)
[2020-04-24 19:09:35][binds]: unbound ctrl+s (115)
[2020-04-24 19:09:35][binds]: unbound x (120)
[2020-04-24 19:09:35][binds]: unbound r (114)
[2020-04-24 19:09:35][console]: failed to open 'autoexec.cfg'
[2020-04-24 19:09:35][console]: Info: only relative paths starting from the ones you specify in 'storage.cfg' are allowed
[2020-04-24 19:09:35][client]: starting...
[2020-04-24 19:09:35][sdl]: SDL version 2.0.12 (dll = 2.0.12)
[2020-04-24 19:09:35][render]: opengl max texture sizes: 8192, 2048(3D)
[2020-04-24 19:09:35][client/sound]: sound init successful
[2020-04-24 19:09:35][joystick]: No joysticks found
[2020-04-24 19:09:35][engine/mastersrv]: refreshing master server addresses
[2020-04-24 19:09:35][textrender]: loaded pFont from 

bug#40713: Guix fails to build a system when specifying an inferior package for the kernel

2020-04-19 Thread pkill9
Hi Marius,

> Can you provide a config.scm that reproduces this issue?

Yes, I've attached a basic config.scm that reproduces the error.
(use-modules (gnu)
 (guix inferior) (guix channels)
 (srfi srfi-1))   ;for 'first'

(define channels
  ;; This is the old revision from which we want to
  ;; extract guile-json.
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (commit
  "ea6594e08e2724c64bc07724a07479fc1633dede"

(define inferior
  ;; An inferior representing the above revision.
  (inferior-for-channels channels))

(define inferior-linux
  (first (lookup-inferior-packages inferior "linux-libre")))

(define-public base-system-config
  (operating-system

   (kernel inferior-linux)
   
   (host-name "antelope")

   (timezone "Europe/London")

   (bootloader
(bootloader-configuration
 (bootloader grub-efi-bootloader)))
   
   (file-systems
%base-file-systems)))

base-system-config


bug#40713: Guix fails to build a system when specifying an inferior package for the kernel

2020-04-19 Thread pkill9
I'm getting an error when trying to build a Guix system on the latest
Guix revision (commit ea6594e08e2724c64bc07724a07479fc1633dede):

```
Backtrace:
   1 (primitive-load "/root/.config/guix/current/bin/guix")
In guix/ui.scm:
  1936:12  0 (run-guix-command _ . _)

guix/ui.scm:1936:12: In procedure run-guix-command:
In procedure %package-replacement-real: Wrong type argument:
#
```

I can't find '%package-replacement-real' anywhere in the source.





bug#40544: Pulseaudio is not looking for user configuration

2020-04-16 Thread pkill9


> That's a known [0] (but AFAIK undocumented) side effect of the
> PulseAudio service, which was added to %desktop-services in January
> [1]. If you want PulseAudio to read your user configuration files
> you'll have to remove that service from your system services or unset
> PULSE_CONFIG and PULSE_CLIENT_CONFIG in ~/.profile [2].

Thank you very much for pointing that out, I've solved all my problems
with Pulseaudio now. Glad it was just a trivial misconfiguration and
not a bug.





bug#40675: Chromium doesn't start pulseaudio if pulseaudio isn't running

2020-04-16 Thread pkill9
It instead seems to use Alsa directly, because when I then run
Pulseaudio, it just creates a 'dummy output'. This is annoying with the
default Pulseaudio behaviour of exiting after 20 seconds of idling.





bug#40381: Guix shouldn't request substitutes for profile derivations

2020-04-01 Thread pkill9
I see that Guix is requesting substitutes from the build servers before
it builds a profile derivation. 





bug#40319: Minetest can't retrieve packages for additional content due to SSL certificate either invalid or not available

2020-03-29 Thread pkill9
To reproduce, run Minetest, then go to Content > Browse Online Content,
and it says 'No packages could be retrieved', and in the terminal it
returns `ERROR[Main]:
https://content.minetest.net/api/packages/?type=mod=game=txp_version=38=nonfree=desktop_default
not found (SSL peer certificate or SSH remote key was not OK) (response
code 0)`





bug#39272: `man -H` doesn't use absolute path to groff

2020-01-24 Thread pkill9
when running `man -H curl`, I get the following output:

```
man: command exited with status 255: (cd /tmp/hmanCnZGIK && 
/gnu/store/l9j6dsfs2i4spfkia492wnighplvhb1c-man-db-2.9.0/libexec/man-db/zsoelim)
 | (cd /tmp/hmanCnZGIK && 
/gnu/store/l9j6dsfs2i4spfkia492wnighplvhb1c-man-db-2.9.0/libexec/man-db/manconv 
-f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /tmp/hmanCnZGIK && 
/gnu/store/5sd2yanrfv9pq8mvnf4c6pga11r6x7qh-groff-minimal-1.22.4/bin/preconv -e 
UTF-8) | (cd /tmp/hmanCnZGIK && 
/gnu/store/5sd2yanrfv9pq8mvnf4c6pga11r6x7qh-groff-minimal-1.22.4/bin/tbl) | (cd 
/tmp/hmanCnZGIK && groff -mandoc -Thtml)
```

When I go into a guix environment containing groff however, it works.
Looking at the command `man -H` tries to use, it needs an absolute path
to groff.





bug#38795: "guix build" doesn't find modules from extra channels when building from an expression

2020-01-05 Thread pkill9
Hi Gábor,

> This is a possible duplicate of 37399. Can you confirm?

Is this the bug? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37399

If so, yes, it looks like it is caused by the same issue, as when I set
GUILE_LOAD_PATH to point to my repository, it finds the module.

Thanks





bug#38798: `guix pull --list-generations` fails ungracefully when it cannot find the path a repo URI used in a guix generation

2019-12-29 Thread pkill9
I get 'guix pull: error: Git error: failed to resolve path' during the output 
and then it stops. It should just ignore the news output for that entry and 
carry on.




bug#38795: "guix build" doesn't find modules from extra channels when building from an expression

2019-12-29 Thread pkill9
I have added my own repository to my ~/.config/guix/channels.scm 
(https://gitlab.com/pkill-9/guix-packages-free), but when I run `guix build 
--expression='(use-modules (pkill9 utils))' it returns "no code for module 
(pkill9 utils)".

It does find modules from the guix repository though, e.g. `guix build 
--expression='(use-modules (guix packages))` returns "guix build: error: 
#: not something we can build" without a "no code for module" 
error.




bug#37035: --with-graft tries to download source files and build them

2019-08-17 Thread pkill9
Hi,

> You asked Guix to build something, so it's not surprising to me that it
> might need to download some source code to do that.
> 
> Can you spell out more clearly what you expected to happen differently,
> and why you think Guix is acting improperly here?
> 
>  Thanks,
>Mark

Originally I expected it to attempt to graft mesa onto the love package, even 
though it's the exact same input, however after running `guix build --dry-run 
--with-graft=subversion=subversion git` I see that it shouldn't output anything 
(same as running `guix build` with a package you already have all substitutes 
for).

If I run `guix build --dry-run love` it shows that it will just download the 
substitute for "love", not build anything else from source, so grafting mesa 
onto it (even though it's the same input) shouldn't try to build anything from 
source.

Also just to note, in this example grafting "mesa" onto itself is just as an 
example, not for a useful reason. An example that doesn't try to build anything 
is running `guix build --dry-run --with-graft=subversion=subversion git`.

As an example of a graft that works, if you put this in a file and build it 
with `guix build -f `, it will successfully graft the "hello" package 
(with the name and version changed) onto the "git" package:

```
(use-modules (guix packages) (gnu packages base) (gnu packages version-control))

(define new-subversion
  (package (inherit hello)
   (name "subversion")
   (version (package-version subversion

(define new-subversion-graft
  (package (inherit subversion)
   (replacement new-subversion)))

(define with-new-subversion
  (package-input-rewriting
`((,subversion . ,new-subversion-graft

(with-new-subversion git)
```

You can see that it worked by running 
`/gnu/store/...-git-2.22.0-svn/libexec/git-core/git-svn`, and it will fail with 
a bunch of errors, unlike the ungrafted package.




bug#37035: --with-graft tries to download source files and build them

2019-08-15 Thread pkill9
When running `guix build --dry-run --with-graft=mesa=mesa love`, Guix shows 
that it will try to download a bunch of source files for quite a few packages:

```
$ guix build --dry-run --with-graft=mesa=mesa love
The following derivations would be built:
   /gnu/store/0lfws1b85h6lkv09pp7q0439pd41qirj-love-11.1.drv
   /gnu/store/2spqmdn4s13r0z9d9hym25h4nfcl1r5g-sdl2-2.0.9.drv
   /gnu/store/aknpb0pgslx9jaidgvh8wrzl7j6nl3nn-fcitx-4.2.9.6.drv
   /gnu/store/8pk7gncsr1cfph8km8dhwk67q9d58c0k-libepoxy-1.5.3.drv
   /gnu/store/w0wxk5f2a44hksrbvwqxn1d6sx96hdyw-gtk+-3.24.9.drv
   /gnu/store/ydx7mg4bni0lfckw0r3x65icmfhr194k-xorg-server-1.20.5.drv
   /gnu/store/xnc6a1fjwlwfjpg0lwai3aq51rw5qwrc-extra-cmake-modules-5.55.0.drv
   /gnu/store/jp29lhdwhs3znbsbznxq9nd9zp5l8ds0-qtbase-5.11.3.drv
   /gnu/store/sblg1v3yxf41b89aaj4r47zcyhxs3az4-ibus-1.5.20.drv
   /gnu/store/a4ynsy7ras28jlgmrhfilkc0lnin21mw-libnotify-0.7.7.drv
   /gnu/store/d8gvjnrl584wc5pavppa3m3yvm3jaxpk-dconf-0.32.0.drv
76.4 MB would be downloaded:
   /gnu/store/4vl3vkvqv0hhr0rlzciq55l4j8c5lgdz-ibus-1.5.20.tar.gz
   /gnu/store/jpxqw86l1gxkfrp66h5mc747xf881hjm-gettext-0.19.8.1
   /gnu/store/9dgbqa3m412prwadpwg0ah7a3kv6fh9p-libnotify-0.7.7.tar.xz
   /gnu/store/aaha1wfv58b83fwp0fqg8b5nlpkw1bva-libmng-2.0.3
   /gnu/store/6qy0ni5msmg93a55wi5qmj96729c1fcf-vulkan-headers-1.1.112
   
/gnu/store/3a3j7rnd49fr6papzd2r2i8f96ayxi1v-qtbase-everywhere-src-5.11.3.tar.xz
   /gnu/store/3n7yhbfl1gik3n64rmy1574djpc1w6m5-gperf-3.1
   /gnu/store/wkfsm7mv8rjawdkzi8chf7qy8l5dppkm-xorg-server-1.20.5.tar.xz
   /gnu/store/7w7fq1iy0jkap5np4q00cw4cllr0lkj5-libdmx-1.1.4
   /gnu/store/cc39n3mx1nswgwx7p8mbx7apy4j1w8yy-xtrans-1.3.5
   /gnu/store/l1nxv1asf958h9ww4iijypyk31mj3d3x-gtk+-3.24.9.tar.xz
   /gnu/store/9rzjddyd621n26av5hb6zn55r372fhnv-libepoxy-1.5.3.tar.xz
```




bug#36088: youtube-viewer-gtk stores the store path to the youtube-viewer CLI program in the user config file

2019-06-04 Thread pkill9
In GTK youtube-viewer, when I try to open a video in the terminal (by 
right-clicking the video and selecting "Play in terminal"), it fails with 
`Failed to execute child process "/gnu/store/.../bin/youtube-viewer" (No such 
file or directory)`

In ~/.config/youtube-viewer/gtk-youtube-viewer.conf I have a line specifying 
the path to youtube-viewer which was added automatically:

`youtube_viewer  => 
"/gnu/store/yhgrvdlq1ri9hd0qlyf6d5jvnr13bjy3-profile/bin/youtube-viewer"`

Changing it to just "youtube-viewer" works as a manual fix, but it would be 
good if this setting isn't generated by youtube-viewer and for the path to be 
hardcoded when compiled. I don't know if there's a configure flag or something 
to achieve this.




bug#35235: Godot bundles certificates

2019-04-11 Thread pkill9
During compilation, there is a line of output:
```
make_certs_header(["editor/certs_compressed.gen.h"],
["thirdparty/certs/ca-certificates.crt"])
```
In the package source is the
file "thirdparty/certs/ca-certificates.crt".

I assume we want Godot to
use the certificates provided by Guix.





bug#33862: "guix gc" failing to complete

2019-04-06 Thread pkill9
I'm also getting this problem.

`guix gc --verify` doesn't fix it for me.

Here is the output for each of the commands you (Danny Milosavljevic) suggested:

$ cp /var/guix/db/db.sqlite /tmp/
$ sqlite3 /tmp/db.sqlite
sqlite> .tables
DerivationOutputs  FailedPathsRefs   ValidPaths   

sqlite> .schema Refs
CREATE TABLE Refs (
referrer  integer not null,
reference integer not null,
primary key (referrer, reference),
foreign key (referrer) references ValidPaths(id) on delete cascade,
foreign key (reference) references ValidPaths(id) on delete restrict
);
CREATE INDEX IndexReferrer on Refs(referrer);
CREATE INDEX IndexReference on Refs(reference);

sqlite> .schema DerivationOutputs
CREATE TABLE DerivationOutputs (
drv  integer not null,
id   text not null, -- symbolic output id, usually "out"
path text not null,
primary key (drv, id),
foreign key (drv) references ValidPaths(id) on delete cascade
);
CREATE INDEX IndexDerivationOutputs on DerivationOutputs(path);

sqlite> .schema FailedPaths
CREATE TABLE FailedPaths (
path text primary key not null,
time integer not null
);

sqlite> .schema ValidPaths
CREATE TABLE ValidPaths (
id   integer primary key autoincrement not null,
path text unique not null,
hash text not null,
registrationTime integer not null,
deriver  text,
narSize  integer
);
CREATE TRIGGER DeleteSelfRefs before delete on ValidPaths
  begin
delete from Refs where referrer = old.id and reference = old.id;
  end;




bug#34402: Inferior channel (I believe 'inferior-for-channels' function specifically) sometimes fails

2019-02-09 Thread pkill9
Nope, there is nothing after the colon in the output when this error shows up.

Ok, I will run that next time I get this error.

On Sat, 09 Feb 2019 15:12:24 +0100, Ludovic Courtès  wrote:

> Hello,
> 
>  skribis:
> 
> > Often I'll get this output when building a manifest* with an inferior:
> >
> > ```
> > itsme@antelope /tmp$ guix package -n -m example-inferior.scm 
> > Updating channel 'guix' from Git repository at 
> > 'https://git.savannah.gnu.org/git/guix.git'...
> > guix package: error: failed to load 'example-inferior.scm':
> > ```
> 
> There’s nothing following the colon above?
> 
> > I believe this is the 'inferior-for-channels' function that fails.
> >
> > After investigating a while back, it seems removing the relevant checkout 
> > in ~/.cache/guix/checkouts temporarily fixes it, but the issue often comes 
> > back.
> 
> I wonder if it could be , though
> I’ve never experienced it in ~/.cache/guix, despite using ‘guix pull’ &
> co. a lot.
> 
> Next time this happens, could you run:
> 
>   strace -s 100 -o log guix package -n -m example-inferior.scm
> 
> and post the last few hundred lines of ‘log’?
> 
> Thanks,
> Ludo’.







bug#34402: Inferior channel (I believe 'inferior-for-channels' function specifically) sometimes fails

2019-02-09 Thread pkill9
Often I'll get this output when building a manifest* with an inferior:

```
itsme@antelope /tmp$ guix package -n -m example-inferior.scm 
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix package: error: failed to load 'example-inferior.scm':
```

I believe this is the 'inferior-for-channels' function that fails.

After investigating a while back, it seems removing the relevant checkout in 
~/.cache/guix/checkouts temporarily fixes it, but the issue often comes back.




* The manifest used is the example from the Guix manual in the section on 
Inferiors, with the guix commit in the manifest replaced with my guix revision:

```
(use-modules (guix inferior) (guix channels)
 (srfi srfi-1))   ;for 'first'

(define channels
  ;; This is the old revision from which we want to
  ;; extract guile-json.
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (commit
  "722ac64cd7dc1f09fb77e2ae780427fa13c03110"

(define inferior
  ;; An inferior representing the above revision.
  (inferior-for-channels channels))

;; Now create a manifest with the current "guile" package
;; and the old "guile-json" package.
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
   (specification->package "guile")))
```




bug#33719: Bug: Unable to use an inferior package as a kernel in the system configuration

2019-02-09 Thread pkill9
Fixed with guix commit bdc61ff97d26d5d87020d07dfd43c0a552bd3449




bug#34368: SDDM is hardcoded to run /usr/bin/X

2019-02-07 Thread pkill9
I first noticed this when setting sddm as my login session manager, however 
this bug can be reproduced without setting it as login session manager - Run 
`guix environment --ad-hoc sddm -- sddm` and one of the output lines is:

[11:05:41.156] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth 
/var/run/sddm/{9792578b-4782-4e04-ae8e-aead026c616c} -background none -noreset 
-displayfd 19 -seat seat0 vt7


This is on Guix commit version 9117d6df87f2c31c91a78b2969434880c3afad2c




bug#34107: kdenlive and mlt note

2019-01-16 Thread pkill9
Also note that mlt can be removed as a propagated input if it's bin directory 
is wrapped into kdenlive's wrapper's PATH environment variable (I think - mlt 
doesn't have any propagated inputs) for kdenlive to find 'melt'.




bug#34107: Kdenlive searched-for paths

2019-01-16 Thread pkill9
There are a few issues with Kdenlive I've found, mostly relating to finding 
paths for things:

It doesn't know where to look for mlt profiles by default, so it asks the user 
in a popup where to look for them - the default suggestion in the popup is 
incorrect (constructed like '/bin/share/mlt/profiles). The 
correct path is found with `$(guix build mlt)/share/mlt/profiles`.

It stores this path in the '[env]' section of ~/.config/kdenliverc, which it 
autogenerates. If it doesn't find the mlt profiles in this stored path when 
run, it asks the user to specify the path in the popup again.

It also stores other paths it needs that it finds, like the path to ffmpeg (to 
the relative guix profiles they're in, e.g. /run/current-system/profile and 
~/.guix-profile. I don't know if this is an issue, I think it will just try to 
find these other paths again if they're invalid when starting kdenlive.

One way to fix the mlt path not being found is by wrapping the kdenlive 
executable with an additional CLI flag `--mlt-path 
/share/mlt/profiles`. It would maybe better to use an environment 
variable (which could either be wrapped, or if propagated could allow 
additional mlt profiles to be added to the guix profile) but I couldn't find 
one for specifying the path to the mlt profiles.

-

Another issue is that it heavily uses the icons from the breeze-icons package 
(which it gives a warning if not found), and these need to be installed to the 
user's profile (not tested with system profile) as kdenlive doesn't find them 
when running `guix environment --ad-hoc kdenlive breeze-icons -- kdenlive`

It also gives the warning
```
No LADSPA plugins were found!

Check your LADSPA_PATH environment variable.
```
which is gotten rid of by running kdenlive with `LADSPA_PATH=$(guix build 
ladspa)/lib/ladspa kdenlive`. This environment variable could also be added to 
the kdenlive wrapper, and/or added as a search path.




bug#32167: Kernel 'build' directory in the store is a broken symbolic link

2018-07-16 Thread pkill9
Yes I agree with you, since it is a lot of space then it's probably best to 
just delete the symlink.

The reasoning behind my suggestion of keeping it is mostly for convenience in 
compiling/testing an external kernel module, i.e. just downloading the source 
and then compiling it with the currently running kernel, and then loading it to 
test it.

Come to think of it, could the build directory be put in another output of the 
linux-libre package?

On Mon, 16 Jul 2018 18:03:58 -0400, Mark H Weaver  wrote:

> Danny Milosavljevic  writes:
> 
> > On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
> >  wrote:
> >
> >> It would be good to keep the build directory though, since it's
> >> expected to exist, and it's easier to just download a module's
> >> source and compile it and test it.
> >
> > I agree.
> >
> > /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
> > anyway so it will be seen by the GC.
> >
> > The fix would be in linux-libre.
> 
> If we were to preserve the kernel build directory as a store item, and
> keep a link from the modules directory to the build directory, that
> would greatly increase the size of the most minimal system that users
> could build.
> 
> The unpacked linux-libre-4.17 source directory is 929 megabytes, and
> that's before building it.  So, keeping the build directory would surely
> increase the closure size of the most minimal system by more than a
> gigabyte.  I don't think it's okay to force all Guix users to pay that
> price.  Some users will need to build minimal systems.
> 
> I'd like to hear more specifics about what the original poster is trying
> to accomplish here.  It's possible that they simply noticed the broken
> links and wanted to let us know.  In that case, it's probably best to
> simply delete those broken symlinks.
> 
> If the intent here is to allow support for out-of-tree kernel modules,
> then fixing these symlinks would not solve the problem, and it's not
> clear to me that fixing them would be part of a proper solution on
> GuixSD.  GuixSD is not a system where you can simply compile a kernel
> module manually and install it, because our module directory is
> immutable.  If the goal is to support building out-of-tree kernel
> modules, that's a separate discussion that deserves its own "wishlist"
> bug report, I think.
> 
> Thoughts?
> 
>Mark







bug#32167: Kernel 'build' directory in the store is a broken symbolic link

2018-07-16 Thread pkill9
It would be good to keep the build directory though, since it's expected to 
exist, and it's easier to just download a module's source and compile it and 
test it.




bug#32167: Kernel 'build' directory in the store is a broken symbolic link

2018-07-15 Thread pkill9
/run/booted-system/kernel/lib/modules//build is a broken 
symbolic link.




bug#32112: feature request

2018-07-10 Thread pkill9
Feature request: a flag for `guix system init` to not copy any files over, so 
if grub fails to install due to a misconfiguration, you can try installing grub 
again without copying over all the files that the previous run of `guix system 
init` copied over.




bug#31302: `guix import json` doesn't handle inputs with the form 'package:output'

2018-04-28 Thread pkill9
For example, if you specify 'glib:bin' as an input, it will add only 'glib' as 
an input. (It's not recognising a specified output of a package recipe that 
produces multiple outputs.)




bug#29774: Compilation error on git master: `gzip: unbound variable`

2017-12-28 Thread pkill9


On Thu, 28 Dec 2017 18:48:04 +0100, Marius Bakke  wrote:

> pki...@runbox.com writes:
> 
> > Architecture: x86_64
> >
> > RAM: 4GB
> >
> > Filesystem: EXT4
> >
> > Guile version: 2.0.11
> >
> > Guile-Git (Guile module) was manually compiled and installed by me from
> > https://gitlab.com/guile-git/guile-git
> >
> > Operating system: Slackware 14.2
> >
> > `uname -a` output: Linux slack 4.4.88 #2 SMP Thu Sep 14 14:21:06 CDT 2017
> > x86_64 Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz GenuineIntel GNU/Linux
> >
> >
> > Compilation failure when running `make` (after running `./bootstrap` and
> > `./configure`) in latest git master and in latest source release tarball:
> > 'In procedure memoize-variable-access!: gzip: unbound variable'
> >
> > Full output (error is at line 172): http://paste.debian.net/1001510
> 
> This paste has expired.  Can you attach the log here instead?

Here is the log:

> itsme@slack:~/guix-0.14.0$ make && make installmake  all-recursive
> make[1]: Entering directory '/home/itsme/guix-0.14.0'
> Making all in po/guix
> make[2]: Entering directory '/home/itsme/guix-0.14.0/po/guix'
> make[2]: Leaving directory '/home/itsme/guix-0.14.0/po/guix'
> Making all in po/packages
> make[2]: Entering directory '/home/itsme/guix-0.14.0/po/packages'
> make[2]: Leaving directory '/home/itsme/guix-0.14.0/po/packages'
> make[2]: Entering directory '/home/itsme/guix-0.14.0'
> Compiling Scheme modules...
>   LOAD guix/base16.scm
>   LOAD guix/base32.scm
>   LOAD guix/base64.scm
>   LOAD guix/cpio.scm
>   LOAD guix/records.scm
>   LOAD guix/gcrypt.scm
>   LOAD guix/hash.scm
>   LOAD guix/pk-crypto.scm
>   LOAD guix/pki.scm
>   LOAD guix/progress.scm
>   LOAD guix/combinators.scm
>   LOAD guix/memoization.scm
>   LOAD guix/utils.scm
>   LOAD guix/sets.scm
>   LOAD guix/modules.scm
>   LOAD guix/download.scm
>   LOAD guix/discovery.scm
>   LOAD guix/git-download.scm
>   LOAD guix/hg-download.scm
>   LOAD guix/monads.scm
>   LOAD guix/monad-repl.scm
>   LOAD guix/gexp.scm
>   LOAD guix/profiles.scm
>   LOAD guix/serialization.scm
>   LOAD guix/nar.scm
>   LOAD guix/derivations.scm
>   LOAD guix/grafts.scm
>   LOAD guix/gnu-maintenance.scm
>   LOAD guix/upstream.scm
>   LOAD guix/licenses.scm
>   LOAD guix/git.scm
>   LOAD guix/graph.scm
>   LOAD guix/cache.scm
>   LOAD guix/cve.scm
>   LOAD guix/workers.scm
>   LOAD guix/zlib.scm
>   LOAD guix/build-system.scm
>   LOAD guix/build-system/ant.scm
>   LOAD guix/build-system/cargo.scm
>   LOAD guix/build-system/cmake.scm
>   LOAD guix/build-system/dub.scm
>   LOAD guix/build-system/emacs.scm
>   LOAD guix/build-system/font.scm
>   LOAD guix/build-system/go.scm
>   LOAD guix/build-system/meson.scm
>   LOAD guix/build-system/minify.scm
>   LOAD guix/build-system/asdf.scm
>   LOAD guix/build-system/glib-or-gtk.scm
>   LOAD guix/build-system/gnu.scm
>   LOAD guix/build-system/haskell.scm
>   LOAD guix/build-system/perl.scm
>   LOAD guix/build-system/python.scm
>   LOAD guix/build-system/ocaml.scm
>   LOAD guix/build-system/waf.scm
>   LOAD guix/build-system/r.scm
>   LOAD guix/build-system/ruby.scm
>   LOAD guix/build-system/scons.scm
>   LOAD guix/build-system/texlive.scm
>   LOAD guix/build-system/trivial.scm
>   LOAD guix/ftp-client.scm
>   LOAD guix/http-client.scm
>   LOAD guix/gnupg.scm
>   LOAD guix/elf.scm
>   LOAD guix/store.scm
>   LOAD guix/cvs-download.scm
>   LOAD guix/svn-download.scm
>   LOAD guix/i18n.scm
>   LOAD guix/ui.scm
>   LOAD guix/build/ant-build-system.scm
>   LOAD guix/build/download.scm
>   LOAD guix/build/download-nar.scm
>   LOAD guix/build/cargo-build-system.scm
>   LOAD guix/build/cmake-build-system.scm
>   LOAD guix/build/dub-build-system.scm
>   LOAD guix/build/emacs-build-system.scm
>   LOAD guix/build/meson-build-system.scm
>   LOAD guix/build/minify-build-system.scm
>   LOAD guix/build/font-build-system.scm
>   LOAD guix/build/go-build-system.scm
>   LOAD guix/build/asdf-build-system.scm
>   LOAD guix/build/git.scm
>   LOAD guix/build/hg.scm
>   LOAD guix/build/glib-or-gtk-build-system.scm
>   LOAD guix/build/gnu-build-system.scm
>   LOAD guix/build/gnu-dist.scm
>   LOAD guix/build/perl-build-system.scm
>   LOAD guix/build/python-build-system.scm
>   LOAD guix/build/ocaml-build-system.scm
>   LOAD guix/build/r-build-system.scm
>   LOAD guix/build/ruby-build-system.scm
>   LOAD guix/build/scons-build-system.scm
>   LOAD guix/build/texlive-build-system.scm
>   LOAD guix/build/waf-build-system.scm
>   LOAD guix/build/haskell-build-system.scm
>   LOAD guix/build/store-copy.scm
>   LOAD guix/build/utils.scm
>   LOAD 

bug#29774: Compilation error on git master: `gzip: unbound variable`

2017-12-19 Thread pkill9
Architecture: x86_64

RAM: 4GB

Filesystem: EXT4

Guile version: 2.0.11

Guile-Git (Guile module) was manually compiled and installed by me from
https://gitlab.com/guile-git/guile-git

Operating system: Slackware 14.2

`uname -a` output: Linux slack 4.4.88 #2 SMP Thu Sep 14 14:21:06 CDT 2017
x86_64 Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz GenuineIntel GNU/Linux


Compilation failure when running `make` (after running `./bootstrap` and
`./configure`) in latest git master and in latest source release tarball:
'In procedure memoize-variable-access!: gzip: unbound variable'

Full output (error is at line 172): http://paste.debian.net/1001510

My IRC username on freenode is pkill9, I am often in the #guix room on
freenode.

IRC chatlog for reference:

  2017-12-19 16:39:05 pkill9 I'm getting an error while compiling Guix,
  It
  says 'In procedure memoize-variable-access!: gzip: unbound variable'.
  Full output here: https://pastebin.com/wiNSZvXT
  2017-12-19 16:39:15 pkill9 anyone know what this means?
  2017-12-19 16:40:15 civodul pkill9: this was reported a couple of
  times
  before and i think it's been fixed (?)
  2017-12-19 16:40:26 pkill9 oh interesting
  2017-12-19 16:40:38 civodul can you paste to another site BTW, like
  paste.debian.net, which allows Tor users to access it
  2017-12-19 16:40:42 pkill9 ok
  2017-12-19 16:42:37 pkill9 http://paste.debian.net/1001510/
  2017-12-19 16:43:09 pkill9 I downloaded the source from the Guix
  downlaod
  page
  2017-12-19 16:46:24 pkill9 civodul: has the fix been added to the
  source
  downloadable from the download page?
  2017-12-19 16:46:51 pkill9 as in on this page
  https://www.gnu.org/software/guix/download/
  2017-12-19 16:47:03 pkill9 under 'GNU Guix 0.14.0 Source'
  2017-12-19 16:47:09 pkill9 in the tarball
  2017-12-19 16:47:28 pkill9 or is it very new and not yet been added
  to
  that?
  2017-12-19 16:51:18 bavier pkill9: iirc it was a more recent fix
  2017-12-19 17:02:20 civodul yes, it's in master i think
  2017-12-19 17:02:47 civodul though i still can't remember what that
  was,
  which is kinda annoying
  2017-12-19 18:57:21 lfam pkill9: From commit
  9a56cf2b5b4970843c215091ea9823a67e077310, the error is not
  reproduced.
  2017-12-19 19:08:54 pkill9 hmm i tried compiling with that commit
  (downloaded the tar.gz from
  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9a56cf2b5b4970843c215091ea9823a67e077310)
  and i still get that error
  2017-12-19 19:14:24 lfam pkill9: What is `guix --version`?
  2017-12-19 19:14:51 pkill9 i don't have it installed, that's why i'm
  compiling it
  2017-12-19 19:15:19 lfam How are you providing the dependencies?
  2017-12-19 19:15:39 pkill9 oh, slackware
  2017-12-19 19:16:03 lfam Okay, and what is the CPU architecture, how
  much
  RAM is there, what filesystem are you compiling on, any other details
  that might be relevant?
  2017-12-19 19:16:11 lfam Also the kernel version
  2017-12-19 19:17:18 pkill9 x86_64, about 4GB ram, EXT4 filesystem,
  kernel
  4.4.88
  2017-12-19 19:18:28 lfam pkill9: Okay, that all sounds good. What
  version
  of Guile are you using?
  2017-12-19 19:18:42 pkill9 2.0.11
  2017-12-19 19:20:05 lfam Okay, sounds like this should all work. If
  you
  don't get any other answer here, please compile all this information
  into
  a bug report and send it to <bug-guix@gnu.org>, first searching for
  previous reports of
  this issue