bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Brendan Tildesley]

Issue was fixed and Tobias explained the hash issue.

bug#58559: Rust 1.58.1 fails to build

[Brendan Tildesley]

bug was due to an unofficial channel. case closed.

bug#58559: Rust 1.58.1 fails to build

[Brendan Tildesley]

On 20/10/22 20:36, Ludovic Courtès wrote:

Hi Brendan,

Brendan Tildesley  skribis:

My apologies. Thanks to the power of rollbacks and the guix cli I was 
able to determine it was a rust variant defined in a channel

I was using, and is no longer an issue any more. so case closed.
Thanks.


Thanks,
Ludo’.

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Brendan Tildesley]

On October 16, 2022 4:39:16 PM GMT+11:00, phodina  
wrote:
>Hi,
>
>unfortunately incorrect hash was pushed in the last patchset.
>
>The patch is already part of the next patch series [1].
>
>Also it's tracked here [2].
>
>1 
>https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
>2 https://issues.guix.gnu.org/57608#8
>
>
>Petr
>
>
>
>
>Sent with Proton Mail secure email.
>
>--- Original Message ---
>On Sunday, October 16th, 2022 at 6:33 AM, 'Brendan Tildesley 
> wrote:
>
>
>> From: Brendan Tildesley m...@brendan.scot
>> 
>> 
>> * gnu/packages/kde.scm (akregator)[phases]: Fix finding
>> QtWebEngineProcess path.
>> ---
>> gnu/packages/kde.scm | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
>> index 37125b1d0b..d0ffb28505 100644
>> --- a/gnu/packages/kde.scm
>> +++ b/gnu/packages/kde.scm
>> @@ -167,9 +167,8 @@ (define-public akregator
>> (lambda* (#:key inputs outputs #:allow-other-keys)
>> (let* ((out (assoc-ref outputs "out"))
>> (bin (string-append out "/bin/akregator"))
>> - (qt-process-path (string-append
>> - (assoc-ref inputs "qtwebengine-5")
>> - "/lib/qt5/libexec/QtWebEngineProcess")))
>> + (qt-process-path (search-input-file
>> + inputs "/lib/qt5/libexec/QtWebEngineProcess")))
>> (wrap-program bin
>> `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)
>> (native-inputs
>> --
>> 2.37.2

I think the correct way is to use something like search-input-file instead 
ungexping qtwebengine-5, right? Input transformations well not work otherwise?

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

['Brendan Tildesley]

From: Brendan Tildesley 

* gnu/packages/kde.scm (akregator)[phases]: Fix finding
QtWebEngineProcess path.
---
 gnu/packages/kde.scm | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 37125b1d0b..d0ffb28505 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -167,9 +167,8 @@ (define-public akregator
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let* ((out (assoc-ref outputs "out"))
 (bin (string-append out "/bin/akregator"))
-(qt-process-path (string-append
-   (assoc-ref inputs "qtwebengine-5")
-   "/lib/qt5/libexec/QtWebEngineProcess")))
+(qt-process-path (search-input-file
+  inputs 
"/lib/qt5/libexec/QtWebEngineProcess")))
(wrap-program bin
  `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)
 (native-inputs
-- 
2.37.2

bug#58561: [PATCH 1/2] gnu: akregator: Correct source hash.

['Brendan Tildesley]

From: Brendan Tildesley 

* gnu/packages/kde.scm (akregator): Use correct hash.
---
 gnu/packages/kde.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 1d4321237a..37125b1d0b 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -158,7 +158,7 @@ (define-public akregator
(uri (string-append "mirror://kde/stable/release-service/" version
"/src/akregator-" version ".tar.xz"))
(sha256
-(base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
+(base32 "08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g"
 (build-system qt-build-system)
 (arguments
  `(#:phases
-- 
2.37.2

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Brendan Tildesley]

I'm getting this after the recent updates:

sha256 hash mismatch for 
/gnu/store/iv6ixlrvh0swq22fjal0cbfbr9ayaq7m-akregator-22.04.3.tar.xz:

  expected hash: 1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8
  actual hash: 08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g


However what concerned me more is that when I look in the source code it 
looks like this:


(sha256
    (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))


Notice how at the start its a '9', not a '1'?

I've tried with both guix pull local repo and building from source.


Is there a bug with how guix is reading/writing sha256 hashes?

bug#58560: Inconsistent test failure in mutter

[Brendan Tildesley]

It didn't fail the second time though:




94/107 mutter:core+mutter/stacking / set-parent RUNNING
>>> G_TEST_BUILDDIR=/tmp/guix-build-mutter-42.4.drv-0/build 
MUTTER_TEST_PLUGIN_PATH=/tmp/guix-build-mutter-42.4.drv-0/build/src/compositor/plugins/libdefault.so 
MALLOC_PERTURB_=247 
G_TEST_SRCDIR=/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src 
/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py 
/tmp/guix-build-mutter-42.4.drv-0/build/src/tests/mutter-test-runner 
/tmp/guix-build-mutter-42.4.drv-0/build/../mutter-42.4/src/tests/stacking/set-parent.metatest
― ✀ 
―

Starting D-Bus daemons (session & system)...
Starting mocked services...
Running test case...
# random seed: R02S542f1e4fb657b24556bc18339672aff5
# libmutter-MESSAGE: Running Mutter Test (using mutter 42.4) as a 
Wayland display server
libmutter-Message: 01:38:04.142: Running Mutter Test (using mutter 42.4) 
as a Wayland display server
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
memory (GMemorySettingsBackend) for ‘gsettings-backend’

Failed to create //.cache for shader cache (Permission denied)---disabling.
# libmutter-MESSAGE: Created surfaceless renderer without GPU
libmutter-Message: 01:38:04.273: Created surfaceless renderer without GPU
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
local (GLocalVfs) for ‘gio-vfs’
# libmutter-MESSAGE: Disabling DMA buffer screen sharing (not hardware 
accelerated)
libmutter-Message: 01:38:04.330: Disabling DMA buffer screen sharing 
(not hardware accelerated)
# libmutter-MESSAGE: Disabling DMA buffer screen sharing (implicit 
modifiers not supported)
libmutter-Message: 01:38:04.331: Disabling DMA buffer screen sharing 
(implicit modifiers not supported)
# libmutter-DEBUG: WL: loaded 
/gnu/store/rdlkxcp52i1sz3qhajdxjc7a7gkgdq0v-egl-wayland-1.1.11/lib/libnvidia-egl-wayland.so.1:wl_eglstream_controller.
# libmutter-MESSAGE: Using public X11 display :512, (using :513 for 
managed services)
libmutter-Message: 01:38:04.332: Using public X11 display :512, (using 
:513 for managed services)

# libmutter-MESSAGE: Using Wayland display name 'mutter-test-display'
libmutter-Message: 01:38:04.333: Using Wayland display name 
'mutter-test-display'
Window manager warning: Failed to set environment variable 
GNOME_SETUP_DISPLAY for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable DISPLAY for 
gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: 
Name "org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable XAUTHORITY 
for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable 
WAYLAND_DISPLAY for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist

1..1
# libmutter-MESSAGE: Added virtual monitor Meta-0
libmutter-Message: 01:38:04.397: Added virtual monitor Meta-0
# libmutter-INFO: Acquired name org.gnome.Mutter.ScreenCast
# libmutter-INFO: Acquired name org.gnome.Mutter.RemoteDesktop
# libmutter-MESSAGE: Removed virtual monitor Meta-0
libmutter-Message: 01:38:04.779: Removed virtual monitor Meta-0
ok 1 stacking/set-parent.metatest
Traceback (most recent call last):
  File 
"/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py", 
line 184, in 

    test_case.wrap_call(rest[1:])
  File 
"/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py", 
line 171, in wrap_call

    self.assertEqual(p.wait(), 0)
  File 
"/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/unittest/case.py", 
line 837, in assertEqual

    assertion_func(first, second, msg=msg)
  File 
"/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/unittest/case.py", 
line 830, in _baseAssertEqual

    raise self.failureException(msg)
AssertionError: -11 != 0
――
 94/107 mutter:core+mutter/stacking / set-parent FAIL    
1.67s   exit status 1

bug#58559: Rust 1.58.1 fails to build

[Brendan Tildesley]

   Compiling toml v0.5.7

error: use of deprecated associated function `std::array::IntoIter::N>::new`: use `IntoIterator::into_iter` instead

    --> src/bootstrap/lib.rs:1046:31
 |
1046 | std::array::IntoIter::new(options).flatten()
 |   ^^^
 |
 = note: `-D deprecated` implied by `-D warnings`

error: could not compile `bootstrap` due to previous error
failed to run: 
/gnu/store/njjhb4ql1bpb1qj5ksmjgnhaxmy093nz-rust-1.60.0-cargo/bin/cargo 
build --manifest-path 
/tmp/guix-build-rust-1.58.1.drv-0/rustc-1.58.1-src/src/bootstrap/Cargo.toml 
--frozen

Build completed unsuccessfully in 0:00:12
error: in phase 'build': uncaught exception:
%exception #< program: "./x.py" arguments: ("-j16" "build" 
"library/std" "src/tools/cargo" "src/tools/rustfmt") exit-status: 1 
term-signal: #f stop-signal: #f>

phase `build' failed after 12.3 seconds
command "./x.py" "-j16" "build" "library/std" "src/tools/cargo" 
"src/tools/rustfmt" failed with status 1

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley]

PING. Could the patch I sent get reviewed please? This would apply to
core-updates. It's been a while so I don't remember much about it myself
actually.

bug#53204: [patch] font-cns11643: Open_Data hash changed

[Brendan Tildesley]

PING... Is the previous patch I sent OK?>

bug#53842: XFCE sets wallpapers to gc'd store paths.

[Brendan Tildesley]

Backgrounds in XFCE get set to their store path that over time get gc'd killing 
the background. Perhaps somehow making them point to 
/run/current-system/profile/share/backgrounds/xfce somehow would be better.

/home/b/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml
22:  
27:  
32:  
37:  
60:  
65:  
70:  
75:  
80:  

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

> On 01/31/2022 1:35 PM Maxime Devos  wrote:
> 
>  
> Brendan Tildesley schreef op ma 31-01-2022 om 12:23 [+0100]:
> > I just noticed there is also this:
> > 
> > starting phase `install-locale'
> > warning: failed to install 'en_US.utf8' locale: Invalid argument
> > 
> > 
> > It occurs for other font-build-system fonts too. Adding glibc-utf8-locales 
> > or glibc-locales didn't fix it.
> > I don't understand it because its just based off gnu-build-system which 
> > doesn't have that issue.
> > 
> > It doesn't GUIX_LOCPATH either
> 
> Perhaps the cause is that font-build-system doesn't have glibc among
> its (implicit) native-inputs, and hence there's no GUIX_LOCPATH search
> path (see <https://issues.guix.gnu.org/22138>)?
> 
> Adding glibc to the native-inputs might work.
> 
> Greetings,
> Maxime. 

Fixed it (attached).From 7af44a6109dae1c056abb10d18e8eecb7113e836 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Mon, 31 Jan 2022 12:55:23 +1100
Subject: [PATCH] gnu: font-cns11643: Update to 98.1.20220104.

* gnu/packages/fonts.scm (font-cns11643): Update to 98.1.20220104.
Use stable archive.org link.
Only extract the files we need, and fix an error caused by unzip
"missmatch local filename" warnings.
---
 gnu/packages/fonts.scm | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 8afb453970..e3a974b6b0 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -18,7 +18,7 @@
 ;;; Copyright © 2017 José Miguel Sánchez García 
 ;;; Copyright © 2017 Alex Griffin 
 ;;; Copyright © 2017 Clément Lassieur 
-;;; Copyright © 2017 Brendan Tildesley 
+;;; Copyright © 2017, 2022 Brendan Tildesley 
 ;;; Copyright © 2017, 2018, 2019, 2020 Arun Isaac 
 ;;; Copyright © 2017 Mohammed Sadiq 
 ;;; Copyright © 2018 Charlie Ritter 
@@ -530,17 +530,26 @@ (define-public font-adobe-source-han-sans
 (define-public font-cns11643
   ;; Since upstream doesn't provide any version numbers, the date of the last
   ;; edit is used, taken from https://data.gov.tw/dataset/5961
-  ;; XXX: The source is also updated in-place, so it may be desirable to mirror
-  ;; it elsewhere to avoid suddenly losing the current source file.
+  ;; Use the archive.org mirror since the source is updated in place.
   (package
 (name "font-cns11643")
-(version "98.1.20180605")
+(version "98.1.20220104")
 (source (origin
   (method url-fetch)
-  (uri "http://www.cns11643.gov.tw/AIDB/Open_Data.zip;)
+  (uri (string-append
+"https://web.archive.org/web/20220119072046/;
+"http://www.cns11643.gov.tw/AIDB/Open_Data.zip;))
   (sha256
(base32
-"000a9whrjr1cd4pjc23pbl60zwkq3wcb5g61p9qi7fn3hwkp0kyw"
+"0ygq7a0gb0nah74wlvf84kss68k514dml1wkcihv2s5v5j9rys0y"
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'unpack
+   (lambda* (#:key source #:allow-other-keys)
+ ;; Prevent filename warnings from causing an error, and only
+ ;; extract the .ttf files we need.
+ (invoke "unzip" "-j" source "Open_Data/Fonts/*ttf"))
 (build-system font-build-system)
 (home-page "http://www.cns11643.gov.tw/AIDB/welcome.do;)
 (synopsis "CJK TrueType fonts, TW-Kai and TW-Sung")
-- 
2.34.0

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

> On 01/31/2022 10:18 AM Maxime Devos  wrote:
> 
>  
> Brendan Tildesley schreef op ma 31-01-2022 om 02:59 [+0100]:
> > I tried updating it but came across an unzip error, maybe unicode related. 
> > I've also noticed in my Icecat there are all these icons that are showing 
> > as random korean characters, so I wonder if my configuration is wrong 
> > somehow??:
> 
> Maybe add glibc-utf8-locales to the native-inputs of the package
> definition, such that an UTF-8 locale can be installed?
> 
> Greetings,
> Maxime.

I just noticed there is also this:

starting phase `install-locale'
warning: failed to install 'en_US.utf8' locale: Invalid argument


It occurs for other font-build-system fonts too. Adding glibc-utf8-locales or 
glibc-locales didn't fix it.
I don't understand it because its just based off gnu-build-system which doesn't 
have that issue.

It doesn't GUIX_LOCPATH either

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

MapingTables/#U5730#U653f/#U9ad8#U96c4#U7e23.txt  
   creating: Open_Data/Properties/
  inflating: Open_Data/Properties/CNS_cangjie.txt  
  inflating: Open_Data/Properties/CNS_component.txt  
  inflating: Open_Data/Properties/CNS_component_word.txt  
  inflating: Open_Data/Properties/CNS_component_word.zip  
  inflating: Open_Data/Properties/CNS_phonetic.txt  
  inflating: Open_Data/Properties/CNS_pinyin_1.txt  
  inflating: Open_Data/Properties/CNS_pinyin_2.txt  
  inflating: Open_Data/Properties/CNS_radical.txt  
  inflating: Open_Data/Properties/CNS_radical_word.txt  
  inflating: Open_Data/Properties/CNS_source.txt  
  inflating: Open_Data/Properties/CNS_stroke.txt  
  inflating: Open_Data/Properties/CNS_strokes_sequence.txt  
Open_Data/Properties/#U5168#U5b57#U5eab#U5c6c#U6027#U8cc7#U6599#U8aaa#U660e#U6587#U4ef6.txt:
  mismatching "local" filename 
(Open_Data/Properties/?.txt),
 continuing with "central" filename version
  inflating: 
Open_Data/Properties/#U5168#U5b57#U5eab#U5c6c#U6027#U8cc7#U6599#U8aaa#U660e#U6587#U4ef6.txt
  
   creating: Open_Data/Voice/
  inflating: Open_Data/Voice/CNS_pinyin_voice.zip  
Open_Data/Voice/#U5168#U5b57#U5eab#U97f3#U6a94#U8aaa#U660e#U6587#U4ef6.txt:  
mismatching "local" filename (Open_Data/Voice/???.txt),
 continuing with "central" filename version
  inflating: 
Open_Data/Voice/#U5168#U5b57#U5eab#U97f3#U6a94#U8aaa#U660e#U6587#U4ef6.txt  
Open_Data/#U8cc7#U6599#U66f4#U65b0#U8aaa#U660e.txt:  mismatching "local" 
filename (Open_Data/??.txt),
 continuing with "central" filename version
  inflating: Open_Data/#U8cc7#U6599#U66f4#U65b0#U8aaa#U660e.txt  
error: in phase 'unpack': uncaught exception:
%exception #< program: "unzip" arguments: 
("/gnu/store/lcnarbk2vd6l1qj77i2s4ny92chzpbzg-Open_Data.zip") exit-status: 1 
term-signal: #f stop-signal: #f>From 81861618f25285f5acc85aafd461bd958ae0eb04 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Mon, 31 Jan 2022 12:55:23 +1100
Subject: [PATCH] gnu: font-cns11643: Update to 98.1.20220104.

* gnu/packages/fonts.scm (font-cns11643): Update to 98.1.20220104.
Also, use stable archive.org link.
---
 gnu/packages/fonts.scm | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 8afb453970..2955b98a4a 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -534,13 +534,15 @@ (define-public font-cns11643
   ;; it elsewhere to avoid suddenly losing the current source file.
   (package
 (name "font-cns11643")
-(version "98.1.20180605")
+(version "98.1.20220104")
 (source (origin
   (method url-fetch)
-  (uri "http://www.cns11643.gov.tw/AIDB/Open_Data.zip;)
+  (uri (string-append
+"https://web.archive.org/web/20220119072046/;
+"http://www.cns11643.gov.tw/AIDB/Open_Data.zip;))
   (sha256
(base32
-"000a9whrjr1cd4pjc23pbl60zwkq3wcb5g61p9qi7fn3hwkp0kyw"
+"0ygq7a0gb0nah74wlvf84kss68k514dml1wkcihv2s5v5j9rys0y"
 (build-system font-build-system)
 (home-page "http://www.cns11643.gov.tw/AIDB/welcome.do;)
 (synopsis "CJK TrueType fonts, TW-Kai and TW-Sung")
-- 
2.34.0

bug#52072: [core-updates-frozen] rust-bitflags 1.2.1 fails to build.

[Brendan Tildesley]

problem doesn't exist  anymore.

bug#52072: [core-updates-frozen] rust-bitflags 1.2.1 fails to build.

[Brendan Tildesley]

starting phase `configure'
bitflags-1.2.1/.gitignore
bitflags-1.2.1/build.rs
bitflags-1.2.1/Cargo.toml.orig
bitflags-1.2.1/Cargo.toml
bitflags-1.2.1/CHANGELOG.md
bitflags-1.2.1/CODE_OF_CONDUCT.md
bitflags-1.2.1/LICENSE-APACHE
bitflags-1.2.1/LICENSE-MIT
bitflags-1.2.1/README.md
bitflags-1.2.1/src/example_generated.rs
bitflags-1.2.1/src/lib.rs
bitflags-1.2.1/.cargo_vcs_info.json
phase `configure' succeeded after 0.0 seconds
starting phase `patch-generated-file-shebangs'
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `patch-cargo-checksums'
patch-cargo-checksums: generate-checksums for 
guix-vendor/rust-bitflags-1.2.1.crate
phase `patch-cargo-checksums' succeeded after 0.0 seconds
starting phase `build'
error: could not find `Cargo.toml` in 
`/tmp/guix-build-rust-bitflags-1.2.1.drv-0` or any parent directory
error: in phase 'build': uncaught exception:
%exception #< program: "cargo" arguments: ("build" "--release") 
exit-status: 101 term-signal: #f stop-signal: #f> 
phase `build' failed after 0.0 seconds
command "cargo" "build" "--release" failed with status 101

bug#50810: Some issues in the Submitting-Patches doc page.

[Brendan Tildesley]

In https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html 

1. It is advised to run:
guix build --rounds=2 my-package
However, I do not think this does anything unless --check is used. 
Even with --rounds=99, nothing occurs. Also, without --no-grafts, 
it will simply reapply the grafts, which is kinda pointless. So the 
command should probably be:
guix build --no-grafts --check --rounds=2 my-package


2. There is also the command:
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
This won't work due to authentication:
guix pull: error: Git error: cannot locate remote-tracking branch 
'origin/keyring'

One needs --disable-authentication, however if the user has channels
enabled, this will also disable authentication for that, which could
possibly create an attack vector against Guix devs?? Plus it will build
a Guix different to the default anyway, so one might need to run:

echo '%default-channels' > /tmp/default-channels
guix pull --channels=/tmp/default-channels --disable-authentication \
--url=/path/to/your/checkout --profile=/tmp/guix.master

3. I noticed a bug where if --url=. is used, the error:
guix pull: error: invalid name: `.-b10bd94'
occurs. Instead, ./ has to be used or the full path.

bug#50739: Wrong type argument in position 158 (expecting empty list): #

[Brendan Tildesley]

I have a Guix with a 100+ packages updated, and a ran a guix build command with 
a long list of packages, getting this backtrace just after building a package. 
Note that it took hours of sucessfully building packages to get to this one 
error, and I'm not sure it will reproduce.
The error appears to be in processing the long list of packages.

The branch: https://notabug.org/Brendan/guix/src/wip-kde-updates-21.08

Backtrace:

...
validating RUNPATH of 0 binaries in 
"/gnu/store/lhypns0s7y9vcrxsk2zvqfg6kj2iarm7-ytfzf-1.2.0/bin"...
phase `validate-runpath' succeeded after 0.0 seconds
starting phase `validate-documentation-location'
phase `validate-documentation-location' succeeded after 0.0 seconds
starting phase `delete-info-dir-file'
phase `delete-info-dir-file' succeeded after 0.0 seconds
starting phase `patch-dot-desktop-files'
phase `patch-dot-desktop-files' succeeded after 0.0 seconds
starting phase `install-license-files'
installing 1 license files from '.'
phase `install-license-files' succeeded after 0.0 seconds
starting phase `reset-gzip-timestamps'
phase `reset-gzip-timestamps' succeeded after 0.0 seconds
starting phase `compress-documentation'
phase `compress-documentation' succeeded after 0.0 seconds
successfully built /gnu/store/382mwvir2hq5rvlk4k2d4a3sawl9vbzh-ytfzf-1.2.0.drv
Backtrace:
In ice-9/eval.scm:
619:8 19 (_ #(#(#)))
In guix/ui.scm:
   2185:7 18 (run-guix . _)
  2148:10 17 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
800:4 15 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   658:37 13 (thunk)
   1320:8 12 (call-with-build-handler _ _)
   1320:8 11 (call-with-build-handler # …)
In guix/ui.scm:
464:3 10 (_)
In ice-9/boot-9.scm:
  1747:15  9 (with-exception-handler # …)
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In guix/ui.scm:
451:6  7 (_)
In guix/scripts/build.scm:
608:5  6 (_)
In srfi/srfi-1.scm:
   673:15  5 (append-map _ _ . _)
   586:17  4 (map1 ("x86_64-linux"))
In unknown file:
   3 (concatenate ((#) …))
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure append: Wrong type argument in position 158 (expecting empty 
list): #



Command: 
./pre-inst-env guix build sddm@0.19.0 fcitx-configtool@0.4.10 genimage@11 
sameboy@0.14.4 mupen64plus-rsp-z64@2.0.0 mupen64plus-video-arachnoid@2.0.0 
mednafen@1.27.1 mupen64plus-video-z64@2.0.0 emulation-station@2.0.1-1.9cc42ad 
nestopia-ue@1.48 bsnes@115 higan@110 mupen64plus-ui-console@2.5 blastem@0.6.2 
ioquake3@1.3.6-1.95b9cab libtcod@1.15.1 mrrescue@1.02e dhewm3@1.5.1 
supertuxkart@1.2 wesnoth-server@1.14.17 7kaa@2.15.4p1 xonotic@0.8.2 
0ad@0.0.23b-alpha stepmania@5.1.0-b2 openclonk@8.1 openrct2@0.3.3 lugaru@1.2 
endless-sky@0.9.14 vkquake@1.01.0 fizmo@0.8.5 astromenace@1.4.1 
arx-libertatis@1.2 freeorion@0.4.10 yamagi-quake2@7.45 
paperview@0.0.1-1.9f8538e megaglest@3.13.0 warzone2100@4.0.1 gzdoom@4.3.2 
quakespasm@0.93.2 bzflag@2.4.22 mygui@3.2.2 mrg@0.1.4 
jami-gnome@20210606.1.e2f9490 cl-sdl2@0.0.0-1.bb2aa2a ecl-sdl2@0.0.0-1.bb2aa2a 
zrythm@1.0.0-alpha.12.0.1 milkytracker@1.03.00 ocaml-tsdl@0.9.7 
qtgamepad@5.15.2 aseba@1.6.0-0.3b35de8 neverball@1.6.0-1.760a25d 
dosbox-staging@0.76.0 lure-de@1.1 sky@1.2 queen-it@1.0 queen-de@1.0 
queen-fr@1.0 lure-it@1.1 drascula@1.0 lure@1.1 lure-es@1.1 lure-fr@1.1 
queen@1.1 jumpnbump@1.61 ufoai@2.6.0_dev-0.a542a87 easyrpg-player@0.6.2.3 
taisei@1.3.2 julius@1.6.0 frotz-sdl@2.45pre chocolate-doom@3.0.1 
crispy-doom@5.8.0 odamex@0.9.3 augustus@2.0.1 tesseract-engine@20200615-2411 
python-pygame-sdl2@2.1.0-for-renpy-7.4.8 python-pyxel@1.4.3 meandmyshadow@0.5a 
widelands@1.0 pioneer@20210203 trigger-rally@0.6.6.1 colobot@0.2.0-alpha 
blobwars@2.00 tome4@1.7.4 abbaye@2.0.1 flare-game@1.12 wesnoth@1.14.17 
solarus-quest-editor@1.6.5 red-eclipse@2.0.0 edgar@1.34 freedink@109.6 
python-kivy@1.10.1 python2-kivy@1.10.1 gource@0.51 instead@3.3.5 
cdogs-sdl@0.8.0 cataclysm-dda@0.F-2 supertux@0.6.2 teeworlds@0.7.5 
unknown-horizons@2019.1 crawl-tiles@0.27.0 starfighter@2.4 raincat@1.2.1 
sdl2-cs@B1-1.1a35564 guile-sdl2@0.6.0 guile-chickadee@0.7.0 tsukundere@0.3.2 
ccextractor@0.88 tadbit@1.0.1 saga@7.9.0 nomacs@3.16.224 
libfreenect-opencv@0.6.2 moc@2.5.2 libvideogfx@1.0.9 theorafile@0.0.0-1.404b14d 
lightspark@0.8.5 stackistry@0.3.0 bs1770gain@0.7.0 audacity@2.4.2 ardour@6.8 
denemo@2.5.0 lmms@1.2.2 r-gganimate@1.0.7 reprotest@0.7.16 
emacs-telega-contrib@0.7.025 retroarch@1.9.4 mgba@0.9.2 
dolphin-emu@5.0-13178.a34823d pcsxr@1.9.95 ppsspp@1.11.3-1.69fa207 renpy@7.4.8 
warsow-qfusion@2.5-1.c4de15d oshu@2.0.1 corsix-th@0.65 hedgewars@1.0.0 
gnome-music@3.34.5 gnome-tweaks@3.34.1 gnome-photos@3.34.2 gnunet-gtk@0.13.1 

bug#50624: Importing (gnu packages lxqt) in gnu/packages/kde-frameworks.scm causes unbound variable error.

[Brendan Tildesley]

I want to use libdbusmenu-qt in kde-frameworks.scm, but just adding 
#:use-modules (gnu packages lxqt)
and running some guix package command results in this. What should I do? Thanks.



$ ./pre-inst-env guix show knotifications
;;; note: source file /home/b/code/guix-cryfs/gnu/packages/kde-frameworks.scm
;;;   newer than compiled 
/home/b/code/guix-cryfs/gnu/packages/kde-frameworks.go
;;; note: source file /home/b/code/guix-cryfs/gnu/packages/kde-frameworks.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/kde-frameworks.go
error: curl: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: gcc-4.9: unbound variable
hint: Did you forget a `use-modules' form?

error: python-2: unbound variable
hint: Did you forget a `use-modules' form?

error: tcc: unbound variable
hint: Did you forget a `use-modules' form?

error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?

error: unzip: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: perl: unbound variable
hint: Did you forget a `use-modules' form?

error: coreutils: unbound variable
hint: Did you forget a `use-modules' form?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding 
`~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace:
In ice-9/boot-9.scm:
  1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  18 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 17 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 16 (_ #(#(#)))
In guix/ui.scm:
   2185:7 15 (run-guix . _)
  2148:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/package.scm:
906:9 12 (_)
In srfi/srfi-1.scm:
634:9 11 (for-each # …)
In guix/scripts/package.scm:
   911:29 10 (_ _)
In gnu/packages.scm:
   292:55  9 (_ "knotifications" _)
In unknown file:
   8 (force #)
In gnu/packages.scm:
   239:33  7 (fold-packages # …)
In guix/discovery.scm:
   153:11  6 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  5 (fold # …)
In guix/discovery.scm:
   143:19  4 (_ _ ())
In srfi/srfi-1.scm:
   691:23  3 (filter-map # . #)
In guix/discovery.scm:
   118:22  2 (_ . _)
In guix/ui.scm:
324:2  1 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" 
(unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python 
(gnu packages python)) #f))'.

bug#48965: filter-dkimsign tarball not available

[Brendan Tildesley]

https://imperialat.at/releases/
works fine for me. Thanks.

bug#48965: filter-dkimsign tarball not available

[Brendan Tildesley]

> On 06/12/2021 11:36 AM Tobias Geerinckx-Rice  wrote:
> 
>  
> Brendan,
> 
> Brendan Tildesley 写道：
> > Yep. I downloaded 3000 source tarballs with -S and just this one 
> > didn't
> > work for some reason. I'm in Tasmania, Australia.
> 
> Wait, so libopensmtpd *did* work?  It uses the exact same server, 
> with HTTPS :-/

That one fails too. It seems to take 5-10 minutes + to time out.
There is a substitute available so my guix is able to download that.

bug#48965: filter-dkimsign tarball not available

[Brendan Tildesley]

> On 06/12/2021 10:17 AM Tobias Geerinckx-Rice  wrote:
> 
>  
> Brendan,
> 
> Brendan Tildesley 写道：
> > Starting download of 
> > /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
> > From https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz...
> > Throw to key `gnutls-error' with args `(# > Error in the pull function.> handshake)'.
> 
> ~ λ guix download 
> https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz
> […]
> /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
> 0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55
> 
> Can you guix download other https:// sources without problems?

Yep. I downloaded 3000 source tarballs with -S and just this one didn't
work for some reason. I'm in Tasmania, Australia.
Doesn't work with guix, wget, or curl. Just hangs after connected for a while.
We should have a mirror of it anyway as backup on the CI to ensure it works 
anyway.

bug#48967: No newline after substitution of ~a complete line.

[Brendan Tildesley]

I get output that looks like this:

substitution of 
/gnu/store/g26z8hhqagcsiwz611jwhyj7rk6zywqg-python-pybigwig-0.3.17 
completesubstituting 
/gnu/store/slxjk0sg8q85qk0l0dv5kv71z2l4pgv2-python-pybrowserid-0.14.0...
downloading from 
https://ci.guix.gnu.org/nar/lzip/slxjk0sg8q85qk0l0dv5kv71z2l4pgv2-python-pybrowserid-0.14.0
 ...

Also, could the value of (simultaneous-jobs status) change between invocations 
in the code? It's ok not to use let?
Adding a newline seems to fix it.From a2628f0565e0428af55ada53ac3826e9a855b022 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Sat, 12 Jun 2021 15:58:13 +1000
Subject: [PATCH] status: Add missing (newline).

* guix/status.scm: Add newline after substitution complete line.
---
 guix/status.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/status.scm b/guix/status.scm
index 1164c2a6e3..f351a56d92 100644
--- a/guix/status.scm
+++ b/guix/status.scm
@@ -558,7 +558,8 @@ substitutes being downloaded."
;; If there are no jobs running, we already reported download completion
;; so there's nothing left to do.
(unless (zero? (simultaneous-jobs status))
- (format port (success (G_ "substitution of ~a complete")) item))
+ (format port (success (G_ "substitution of ~a complete")) item)
+ (newline port))
 
(when (and print-urls? (zero? (simultaneous-jobs status)))
  ;; Leave a blank line after the "downloading ..." line and the
-- 
2.31.1

bug#48966: svt-hevc sha256 missmatch.

[Brendan Tildesley]

Since I don't know what in the files have changed and why I haven't submitted a 
patch to update it.
Tobias, are you able to figure out what changed?

Initialized empty Git repository in 
/gnu/store/83j8mz97smxm4frp6ax0k16j3zj8a8sp-svt-hevc-1.5.1-checkout/.git/
>From https://github.com/OpenVisualCloud/SVT-HEVC
 * tag   v1.5.1 -> FETCH_HEAD
Note: switching to 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at b65eba0 Update version to 1.5.1
r:sha256 hash mismatch for 
/gnu/store/83j8mz97smxm4frp6ax0k16j3zj8a8sp-svt-hevc-1.5.1-checkout:
  expected hash: 0rac70p6rpvdx9v0bdd8nphgr7imdxb7nz0x77n3p7h3180zz9x0
  actual hash:   1cv6vcf5yxcwdvj5yqcckbixqrvvdxk7ibincnnv80pz6wh527sv
hash mismatch for store item 
'/gnu/store/83j8mz97smxm4frp6ax0k16j3zj8a8sp-svt-hevc-1.5.1-checkout'
build of 
/gnu/store/51k6p67lw63kwwpmpx5mbxmlaxm2vaw7-svt-hevc-1.5.1-checkout.drv failed
View build log at 
'/var/log/guix/drvs/51/k6p67lw63kwwpmpx5mbxmlaxm2vaw7-svt-hevc-1.5.1-checkout.drv.bz2'.
note: keeping build directory `/tmp/guix-build-svt-hevc-1.5.1-checkout.drv-0'
guix build: error: build of 
`/gnu/store/51k6p67lw63kwwpmpx5mbxmlaxm2vaw7-svt-hevc-1.5.1-checkout.drv' failed

bug#48965: filter-dkimsign tarball not available

[Brendan Tildesley]

building 
/gnu/store/jvifq7l30l057x532qkw3w16aq0xb3r6-filter-dkimsign-0.5.tar.gz.drv...

Starting download of 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
>From https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz...
Throw to key `gnutls-error' with args `(# handshake)'.

Starting download of 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
>From 
>https://ci.guix.gnu.org/file/filter-dkimsign-0.5.tar.gz/sha256/0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55...
download failed 
"https://ci.guix.gnu.org/file/filter-dkimsign-0.5.tar.gz/sha256/0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55;
 404 "Not Found"

Starting download of 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
>From 
>https://tarballs.nixos.org/sha256/0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55...
download failed 
"https://tarballs.nixos.org/sha256/0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55;
 404 "Not Found"

Starting download of 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz
>From 
>https://archive.softwareheritage.org/api/1/content/sha256:a5b4ec3af5ecb42351a0b5459bdd0f32c00ec55c23050b5f46dfaed8e321974b/raw/...
download failed 
"https://archive.softwareheritage.org/api/1/content/sha256:a5b4ec3af5ecb42351a0b5459bdd0f32c00ec55c23050b5f46dfaed8e321974b/raw/;
 404 "Not Found"
Trying to use Disarchive to assemble 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz...
Assembling the directory filter-dkimsign-0.5
Downloading 
/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz from 
Software Heritage...
SWH vault: requested bundle cooking, waiting for completion...
In procedure fport_write: Broken pipe
Could not resolve directory reference
failed to download 
"/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz" from 
"https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz;
builder for 
`/gnu/store/jvifq7l30l057x532qkw3w16aq0xb3r6-filter-dkimsign-0.5.tar.gz.drv' 
failed to produce output path 
`/gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz'
build of 
/gnu/store/jvifq7l30l057x532qkw3w16aq0xb3r6-filter-dkimsign-0.5.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/jv/ifq7l30l057x532qkw3w16aq0xb3r6-filter-dkimsign-0.5.tar.gz.drv.bz2'.
guix build: error: build of 
`/gnu/store/jvifq7l30l057x532qkw3w16aq0xb3r6-filter-dkimsign-0.5.tar.gz.drv' 
failed
b@jiu ~/code/guix [env]$

bug#48868: VLC cant find libvdpau_radeonsi.so when playing video

[Brendan Tildesley]

The file exists at 
/gnu/store/mwcgqw9ggi02p8mhzac8cg0x671j7wd1-mesa-20.2.4/lib/vdpau/libvdpau_radeonsi.so
but it doesn't seem to be found (by libva?). 
Videos still play. Probably requires a Radeon card to reproduce.
I got confused trying to figure out where exactly its loaded.

libva info: VA-API version 1.10.0
libva info: Trying to open 
/gnu/store/gvncg7gzdzjx0gvyi4sm02m7qgnsmx5q-mesa-20.2.4/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
[7f6928001f80] glconv_vaapi_x11 gl error: vaDeriveImage: operation failed
[7f69240ba3a0] main video output error: video output creation failed
[7f69e8c929f0] main decoder error: failed to create video output
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
file: No such file or directory
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
file: No such file or directory

bug#48373: vice: processor dependency

[Brendan Tildesley via Bug reports for GNU Guix]

This is the build log from the server. there may be clues here if it differs 
from yours:

https://ci.guix.gnu.org/build/290428/log/raw

bug#48343: Cannot boot after installation

[Brendan Tildesley via Bug reports for GNU Guix]

If setting nomodeset is the answer, there is a trick you can use in GRUB to set 
it before boot.
Apparently in GRUB, you:

1. Press e
2. Edit the linux ... line to add nomodeset as an option
3. Press ctrl X

I just found the instructions here https://duckduckgo.com/?q=grub+nomode+set

At least give that a go and report back if it works.

bug#48373: vice: processor dependency

[Brendan Tildesley via Bug reports for GNU Guix]

I'm curious the guix version would also build differently on your computer.
You can run for example

guix build vice --no-grafts --check

to build it from source and check the difference. if its different, something 
like

guix gc -D $(guix build --no-grafts vice); guix build --no-substitutes vice

should delete it and built it from source without using the prebuilt binary.
If it's different then its a reproducibility bug. Some packages are actually
intended to be that way, like atlas, and have substitutable? #f set so that
they are always built and tuned to the cpu it's used on.

On my computer, AMD 5700X, the built is identical to the substitute:

b@jiu ~/code/guix [env]$ guix challenge vice

1 store items were analyzed:
- 1 (100.0%) were identical
- 0 (0.0%) differed
- 0 (0.0%) were inconclusive

bug#39527: Cannot log into LXQt DE

[Brendan Tildesley via Bug reports for GNU Guix]

Sorry for not responding to this bugreport earlier.
It is most likely the same issue as https://issues.guix.gnu.org/36508 
https://issues.guix.gnu.org/36508 .

Running this would most likely fix it for now, provided you have the gdm 
service installed.

sudo chmod -R gdm:gdm /var/lib/gdm

bug#40039: 'wrap-script' introduces spurious argument

[Brendan Tildesley via Bug reports for GNU Guix]

Same patch as before, but with a test case. Have a play with it and see if it 
makes sense.
From 21d5f4e01be7f9b86649f4176f53e14854b58d53 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Thu, 29 Apr 2021 20:33:08 +1000
Subject: [PATCH] utils: Fix wrap-script argument handling.

* guix/build/utils.scm (wrap-script):
Don't add (car cl) one too many times, cl its self contains it's car.
Split the aguments string with string-tokenize to avoid leaving an empty
string argument when there should be none. These two bugs seemed to
be partially cancelling each other out so that scripts still worked when
ran with no arguments.

* tests/build-utils.scm: Adjust wrap-script to above changes.
Add two tests to ensure the command line arguments appear identical to a
script and its wrapped version.
---
 guix/build/utils.scm  |  8 +++
 tests/build-utils.scm | 55 +++
 2 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index 419c10195b..cc2a020fbf 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2015, 2018 Mark H Weaver 
 ;;; Copyright © 2018 Arun Isaac 
 ;;; Copyright © 2018, 2019 Ricardo Wurmus 
+;;; Copyright © 2021 Brendan Tildesley 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1295,10 +1296,9 @@ not supported."
`(let ((cl (command-line)))
   (apply execl ,interpreter
  (car cl)
- (cons (car cl)
-   (append
-',(string-split args #\space)
-cl))
+ (append
+  ',(string-tokenize args char-set:graphic)
+  cl)
(template (string-append prog ".XX"))
(out  (mkstemp! template))
(st   (stat prog))
diff --git a/tests/build-utils.scm b/tests/build-utils.scm
index 654b480ed9..f3f31deaf6 100644
--- a/tests/build-utils.scm
+++ b/tests/build-utils.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2015, 2016, 2019, 2020 Ludovic Courtès 
 ;;; Copyright © 2019 Ricardo Wurmus 
+;;; Copyright © 2021 Brendan Tildesley 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -165,9 +166,7 @@ echo hello world"))
"/some/path:/some/other/path"
  '(let ((cl (command-line)))
 (apply execl "/anything/cabbage-bash-1.2.3/bin/sh"
-   (car cl)
-   (cons (car cl)
- (append '("") cl)
+   (car cl) cl)))
  script-contents)
 (call-with-temporary-directory
  (lambda (directory)
@@ -206,8 +205,7 @@ print('hello world')"))
  `(let ((cl (command-line)))
 (apply execl "/anything/cabbage-bash-1.2.3/bin/python3"
(car cl)
-   (cons (car cl)
- (append '("" "-and" "-args") cl)
+   (append '("-and" "-args") cl
  script-contents)
 (call-with-temporary-directory
  (lambda (directory)
@@ -241,4 +239,51 @@ print('hello world')"))
"/some/other/path")))
  #f)
 
+(define (arg-test bash-args)
+  (call-with-temporary-directory
+   (lambda (directory)
+ (let ((script-file-name (string-append directory "/bash-test.sh")))
+   (call-with-output-file script-file-name
+ (lambda (port)
+   (display (string-append "\
+#!" (which "bash") bash-args "
+echo \"$#$0$*${A}\"")
+port)))
+
+   (display "Unwrapped script contents:\n")
+   (call-with-input-file script-file-name
+ (lambda (port) (display (get-string-all port
+   (newline) (newline)
+   (chmod script-file-name #o777)
+   (setenv "A" "A")
+   (let* ((run-script (lambda _
+(open-pipe*
+ OPEN_READ
+ script-file-name "1" "2" "3 3" "4")))
+  (pipe (run-script))
+  (unwrapped-output (get-string-all pipe)))
+ (close-pipe pipe)
+
+ (wrap-script script-file-name `("A" = ("A\nA")))
+
+ (display "Wrapped script contents:\n")
+ (call-with-input-file script-file-na

bug#34016: Git checkouts managed by (guix git) grow indefinitely

[Brendan Tildesley via Bug reports for GNU Guix]

Since this bug report 1.1.0 was released. The Changelog includes this note:
"Repositories with a large number of packfiles no longer exhaust the
number of file descriptors."

https://github.com/libgit2/libgit2/pull/5396

May or may not be related to this.

bug#41138: IceDove

[Brendan Tildesley via Bug reports for GNU Guix]

Problem is gone for me now. (78.6.0)

bug#36508: GDM files have incorrect owner after temporarily removing service

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/14/2021 12:32 PM Ludovic Courtès  wrote:
> 
>  
> Hi Mark,
> 
> Mark H Weaver  skribis:
> 
> > Brendan Tildesley via Bug reports for GNU Guix 
> > writes:
> >
> >> I recently encountered what is likely the same bug. The directory 
> >> /var/lib/gdm
> >> had the correct permissions gdm:gdm, but all the files inside had 
> >> something like
> >> 973:gdm
> >
> > The underlying problem here, which I've also experienced, is that if you
> > reconfigure your system with fewer users/groups, and then later add
> > those users/groups back, there is no guarantee that they will be
> > assigned the same UIDs and GIDs.
> 
> Yes.
> 
> The patch Brendan posted LGTM (though I’m surprised the directory itself
> can have the right UID/GID while files inside it don’t; perhaps this was
> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns
> the home directory unconditionally.)
> 
> Note that there are other places, in addition to GDM, where we
> forcefully reset the UID/GID of the home directory (e.g., for the
> ‘knot-resolver’ service.)
> 
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation (for efficiency, it would be best if we
> could do that if and only if the home directory itself has wrong
> ownership).  Thoughts?
> 
I'm confused. It sounds like you're suggesting to add the very IF condition 
that my
patch removes from %gdm-activation in order to fix the problem.

bug#36508: GDM files have incorrect owner after temporarily removing service

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/13/2021 10:51 PM Mark H Weaver  wrote:
> 
>  
> Hi Brendan,
> 
> Brendan Tildesley via Bug reports for GNU Guix 
> writes:
> 
> > I recently encountered what is likely the same bug. The directory 
> > /var/lib/gdm
> > had the correct permissions gdm:gdm, but all the files inside had something 
> > like
> > 973:gdm
> 
> The underlying problem here, which I've also experienced, is that if you
> reconfigure your system with fewer users/groups, and then later add
> those users/groups back, there is no guarantee that they will be
> assigned the same UIDs and GIDs.
> 
> This problem is made much worse by the fact that files may be left
> around, e.g. in /var, with the old UIDs and GIDs.
> 
> In your case, I guess that the 'gdm' user was previously assigned UID
> 973, but now it has been given a different UID.
> 
> In my case, after reconfiguring to a minimal system and later switching
> back to a full GNOME-based desktop system, I found that many files and
> directories in /var had the wrong owner or group.  Here's what I saw
> before I cleaned things up:
> 
> --8<---cut here---start->8---
> root@jojen ~# ls -l /var/lib/
> total 4
> drwxr-xr-x 1 colord colord40 Mar 28  2017 colord
> drwx-- 1 995978   56 Sep  3 02:10 gdm
> drwx-- 1 root   root   30400 Dec 25 01:55 NetworkManager
> -rw--- 1 root   root 512 Dec 25 01:35 random-seed
> drwxr-xr-x 1 colord colord   164 Dec 28  2017 sddm
> drwx-- 1 tortor  178 Dec 19 21:28 tor
> drwx-- 1 root   root  20 Sep  5 01:32 udisks2
> drwxr-xr-x 1 root   root 274 Dec 25 01:55 upower
> drwxr-xr-x 1 root   root  86 Mar 28  2017 wicd
> root@jojen ~# ls -la /var/lib/gdm/
> total 4
> drwx-- 1  995978  56 Sep  3 02:10 .
> drwxr-xr-x 1 root root   750 Dec 25 01:59 ..
> drwxr-xr-x 1  994 colord  64 Sep  3 02:10 .cache
> drwx-- 1  994 colord  54 Sep  3 02:10 .config
> -rw--- 1  994 colord  16 Sep  3 02:10 .esd_auth
> drwxr-xr-x 1  994 colord  10 Sep  3 02:10 .local
> root@jojen ~# 
> --8<---cut here---end--->8---
> 
> Given the fact that existing files and directories in /var can
> *effectively* have their ownership changed, I think that this issue
> could be a security risk.

Yes and they could change for any reason under the sun, and so we have no
choice but to set them right on service activation.

Guix system rollbacks should be a supported feature of Guix, not just a gimmick
that falls out of its design. It should be that a Guix user could leave their
system for 5 years, and then do a guix pull; guix system reconfigure in the year
2026. Perhaps at that time the new system will break, and then its desirable
that they can rollback to the previous generation. So what fixes we put in to 
Guix services today need to consider not just how files could have changed in
the past, but how they might change in breaking ways in the future, within 
reason.
I don't know off the top of my head of any way that can be done other than to
have chmod -R gdm:gdm /var/lib/gdm always executed.
> 
> There's some discussion of this issue at <https://bugs.gnu.org/44944>,
> although I'm not sure that Danny's suggested solution is practical.
> 
> Here's one idea: when activating a system, *never* delete users or
> groups if files still exist that are owned by those users/groups.
> Checking all filesystems would likely be too expensive, but perhaps it
> would be sufficient to check certain directories such as /var, /etc, and
> possibly the top directory of /home.
> 
> What do you think

Wouldn't that imply that uids could be randomly different on different systems
with the same configuration, and then remain statically different permanently?
We want as little randomness and moving parts as possible. It's yet another
way the system is not actually Functional, but has state.

Seems this bug spans 3 or so different bug reports. In 
http://issues.guix.gnu.org/45571
I commented that Nix uses hard coded id's, sorta like how ports are allocated
for a purpose:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix

Perhaps you are thinking of other kinds of security issues that could be caused 
that
I'm not thinking of. In that case maybe Nix devs have already made the best 
choice by
making them static?

... After all, if the permissions can change, then it is possible another user 
could
actually modify the contents of /var/lib/gdm its self, thereby infecting other 
users,
if for some reason that other malicious user gets allocated that ID.
That further points towards static ID's like Nix has as a solution.

bug#36508: GDM files have incorrect owner after temporarily removing service

[Brendan Tildesley via Bug reports for GNU Guix]

I recently encountered what is likely the same bug. The directory /var/lib/gdm
had the correct permissions gdm:gdm, but all the files inside had something like
973:gdm

a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug
37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of
the files in it. This explains why in my case it failed to fix the permissions,
because the directory was gdm:gdm. How it got that way I don't know, and infact
it doesn't really matter. The directory is mutable, and thus can theoretically 
be
changed for any number of reasons. Therefore if we wish for Guix to be robust
with it's Functional design, and have meaningful rollbacks, we perhaps have no
choice but to assert the required invariants like these on mutable files.

A better solution may be to make it fully chown -R on reconfigure, but not each 
time
on boot?

I've attached an untested patch with a suggested solution of making
%gdm-activation operate every single time, instead of just after checking
/var/lib/gdm.


From 31cb6dbd756af695bd6a1f4d4c89b42367b13307 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Tue, 13 Apr 2021 23:04:28 +1000
Subject: [PATCH] services: gdm: Correctly set ownership on /var/lib/gdm.

* gnu/services/xorg.scm (%gdm-activation): Always chown /var/lib/gdm,
instead of only when it appears to be correct, because it's still
possible the files inside could be wrong and break GDM. I encountered
this once: https://issues.guix.gnu.org/36508 .

Perhaps it is with good intentions to try not running this code every
single time on boot, but when it fails, the consequence is that GDM can
break not just for the current revision, but all previous rollback
systems in GRUB will fail, and subsequent reconfigure-ings fail
too. That totally destroys a desktop system and our rollback
functionally, which is much much worse!
---
 gnu/services/xorg.scm | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 17d983ff8d..a206c7c93a 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -861,16 +861,11 @@ the GNOME desktop environment.")
 
 (let* ((gdm (getpwnam "gdm"))
(uid (passwd:uid gdm))
-   (gid (passwd:gid gdm))
-   (st  (stat "/var/lib/gdm" #f)))
-  ;; Recurse into /var/lib/gdm only if it has wrong ownership.
-  (when (and st
- (or (not (= uid (stat:uid st)))
- (not (= gid (stat:gid st)
-(for-each (lambda (file)
-(chown file uid gid))
-  (find-files "/var/lib/gdm"
-  #:directories? #t)))
+   (gid (passwd:gid gdm)))
+  (for-each (lambda (file)
+  (chown file uid gid))
+(find-files "/var/lib/gdm"
+#:directories? #t))
 
 (define dbus-daemon-wrapper
   (program-file
-- 
2.31.1

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/09/2021 7:39 PM Pierre Neidhardt  wrote:
> 
>  
> So if the path is already an absolute store path, then I suppose that
> the whole phase is superfluous, isn't it?
> 
> Couldn't we just delete it?

Do you mean delete the phase entirely or just from Racket? It's not always the 
case that they are absolute paths. Racket probably just has some code to 
generate them automatically.

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/09/2021 1:23 PM Pierre Neidhardt  wrote:
> 
>  
> Thanks for the investigation.  Would you like to send a patch?

I'm not sure what the right way to fix it is. I may have come up with a 
brilliant idea. Untested patch attached.From 64c200f3630de13ec3487cb5c756b47b133c6ecf Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Fri, 9 Apr 2021 21:43:54 +1000
Subject: [PATCH] build: gnu-build-system: Improve patch-dot-desktop-files.

* guix/build/gnu-build-system.scm (patch-dot-desktop-files):
When patching .desktop files, Exec= values beginning with '/', (or
spaces or newline characters) will result in the 'binary' symbol
matching an empty string. Changing *, meaning 0 or more, to +, meaning 1
or more ensures it will match a binary of atleast 1 length, or nothing.
---
 guix/build/gnu-build-system.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 2e7dff2034..99636c442a 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -725,9 +725,9 @@ which cannot be found~%"
  ;; UTF-8-encoded.
  (with-fluids ((%default-port-encoding "UTF-8"))
(substitute* files
- (("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^Exec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
   (string-append "Exec=" (which binary) rest))
- (("^TryExec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^TryExec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
   (string-append "TryExec="
  (which binary) rest)
 outputs)
-- 
2.31.1

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

The Exec paths in these files already refer to absolute paths, infact, 
/gnu/store paths
Thus the regex:

("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)

with binary = empty string and rest = everything after Exec=

Why? The second subexpression [^/[:blank:]\r\n]* is bound to binary, but it 
means anything
that is a series of anything that is not /, space, or newline. absolute paths 
start with /, so it matches nothing (empty string), and continues to call 
(which "").


I notice this phase hasn't been edited in 5 years and has other issues, for 
example:

1. patch-dot-desktop-files only searches the output of the package for paths, 
not the inputs. This means for example xfce4-settings fails to patch references 
to exo-open in desktop files.

The code should be remade to be more /correct/, and handle all unexpected 
inputs. In this case the phase is accidentally doing the right thing by failing 
in a harmless way and correctly not patching the files, but emitting a warning.

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Brendan Tildesley via Bug reports for GNU Guix]

I just had the same bug with flightgear as Ludo.

Running `guix build flightgear', guix showed it was downloading substitute 
information, and then errored with

guix build: error: integer expected from stream

Possibly helpful strace info:

write(14, 
"\36\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0?\0\0\0\0\0\0\0/gnu/store/ssdka48kwx9f2z54j63mjxvn6bg502mm-flightgear-2018.3.5\0@\0\0\0\0\0\0\0/gnu/store/pr6xy604hg7yhcinnlymrkc958kl0bnn-openscenegraph-3.4.1<\0\0\0\0\0\0\0/gnu/store/g8g4paw3q3z8hkl441ddhdn0in54gi3f-simgear-2018.3.5\0\0\0\0",
 232) = 232
read(14, "ptxc\0\0\0\0", 8) = 8
read(14, "\34\0\0\0\0\0\0\0", 8)= 8
read(14, "integer expected from stream\0\0\0\0", 32) = 32
read(14, "\1", 1)   = 1
read(14, "\0\0\0\0\0\0\0", 7)   = 7
close(14)

bug#45571: Support stable uids and gids for system accounts in a container

[Brendan Tildesley via Bug reports for GNU Guix]

It may be useful to see what Nix does.

Nix has many static id, with the comment:

# IMPORTANT!
# We only add static uids and gids for services where it is not feasible
# to change uids/gids on service start, in example a service with a lot of
# files. Please also check if the service is applicable for systemd's

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix

bug#47618: "guix upgrade" and "guix package -u ." inconsistency

[Brendan Tildesley via Bug reports for GNU Guix]

Below, --do-not-upgrade appears to be behaving like "--only-upgrade". I realised
this comes about because I didn't use '='. guix upgrade takes all other
arguments to be upgrade regex's, but it still seems. _wrong_.  Some long
arguments in guix require and = sign after them, and the cli help indicates as
much, but --do-not-upgrade seems to break that pattern and takes all arguments
after it to be regexes's to match and not upgrade.  flags that have this
behaviour of acting on all arguments after them should indicate clearly they do
that. and indicated if the '=' is optional using some intuitive notation.
The line:

--do-not-upgrade[=REGEXP] do not upgrade any packages matching REGEXP

suggest it must take either no argument or only '=something'.

guix upgrade --help says that it is an alias for 'guix package -u .'. My
understanding is that the meaning of alias is something that can be substituted
and it will behave the same, like Bash aliases.  We should change 'guix
upgrade''s behaviour to be like 'guix package -u', taking all arguments after
--do-not-upgrade as regex's to not upgrade.


b@jiu ~/code/guix [env]$ guix upgrade --do-not-upgrade '^[a-n]'
The following packages will be upgraded:
audacity  (dependencies or package changed)
cool-retro-term   (dependencies or package changed)
deluge(dependencies or package changed)
diffoscope170 → 171
emacs (dependencies or package changed)
eog   (dependencies or package changed)
evince(dependencies or package changed)
ffmpeg(dependencies or package changed)
git   2.31.0 → 2.31.1
git:send-email2.31.0 → 2.31.1
gnome-font-viewer (dependencies or package changed)
gnome-tweaks  (dependencies or package changed)
godot (dependencies or package changed)
ibus  (dependencies or package changed)
ibus-anthy(dependencies or package changed)
icecat(dependencies or package changed)
keepassxc (dependencies or package changed)
lm-sensors(dependencies or package changed)
lollypop  (dependencies or package changed)
mpv   (dependencies or package changed)
mumble(dependencies or package changed)

62.6 MB will be downloaded
^C
b@jiu ~/code/guix [env]$ guix package -u . --do-not-upgrade '^[a-n]'
The following packages will be upgraded:
obs(dependencies or package changed)
piper  (dependencies or package changed)
playonlinux(dependencies or package changed)
rhythmbox  (dependencies or package changed)
stellarium (dependencies or package changed)
syncthing-gtk  (dependencies or package changed)
tinc   (dependencies or package changed)
transmission:gui   (dependencies or package changed)
ungoogled-chromium (dependencies or package changed)
vlc(dependencies or package changed)
youtube-dl (dependencies or package changed)
zrythm (dependencies or package changed)

The following derivation will be built:
/gnu/store/6ldzv7ilcsg4ah8vyig9vyh9y79yz6m1-tinc-1.1pre17.drv

bug#38907: close?

[Brendan Tildesley via Bug reports for GNU Guix]

Since 38408 has been pushed, can you close this one if the issue has been fixed?

bug#35575: closing. bug has not reoccurred since

[Brendan Tildesley]

On 1/4/20 12:53 am, Marius Bakke wrote:

Is this still relevant?  I haven't heard reports about this in a long
time, nor experienced it (anymore) on my super-experimental systems that
switch LLVM and Mesa versions all the time.  So I think the issue might
have been fixed upstream?



Closing because the issue seems to have only occurred once  a long time 
ago and may have been fixed up stream.

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

[Brendan Tildesley]

On 19/10/20 3:03 am, Mathieu Othacehe wrote:

Hello Miguel & Brendan,


AFAIU from the code, the first partition should not be created by the
installer but it won't be removed if it was found on the disk
beforehand.  Tomorrow I'll give a try at the full installation process,
I must have overlooked something if it still being created in that
case...

Thanks for your help on this topic! Brendan is probably using a GPT
partitionned disk on a non-UEFI compatible machine. Hence, as you
noticed, the installer does not create a bios_grub partition.

This is a problem as this partition is necessary for GRUB and I think
that your patch is fixing the problem. The "auto-partition!" procedure
is also leaving a probably pre-existing ESP partition, but I don't
really understand how it appeared in the first place.

Brendan, did you use "manual partitioning" to create an ESP partition?
Hmm I forget what was on this drive. I used to have Windows 10 on it, 
then I can't
remember. I may have installed Arch Linux on it. What ever was on it, I 
just ran the
installer letting it do it's thing selecting Encrypted root with LVM 
because I wanted to
see if that worked. it didn't, then I tried the default, before posting 
the bug report.
Finally I went though with Miguel's patch selecting all the defaults and 
that was

the result.
I feel the installer should not care what was on the drive to begin 
with, it should just
format the drive how it sees fit. Why should the existing contents of 
the drive

affect the outcome when we are reformatting everything anyway?


Thanks,

Mathieu

bug#44054: [1.2 installer]: Kernel panic when attempting to reboot after install.

[Brendan Tildesley]

On 19/10/20 5:16 am, Mathieu Othacehe wrote:

Hello Brendan,


After the install completed I pulled out the USB as per instruction on the
screen, and pressed the Reboot button. The system then Kernel panic with the
following messages:

https://brendan.scot/p/IMG_20201018_140343.png

Sorry I don't have it in textual form.

Is the installed system functional? The kernel panic may come from the
fact that the installation support was removed while still needed.
Yes the system was functional. From memory, other distro installers 
recommend removing
the device and rebooting too. So its curious that Guix somehow has an 
issue with it.
Although this is only one data point. I'd like other people to test it 
to be sure.

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

[Brendan Tildesley]

On 17/10/20 11:09 pm, Miguel Ángel Arruga Vivas wrote:

[...]
The attached patch solves that.  What do you think?

Happy hacking,
Miguel


I have tested the patch and the Installer mostly worked. One thing I 
noticed is that the partition scheme I was given automatically looks 
like this:


1 537MB fat32 boot,esp /boot/efi EFI System Partition
2 3146Kb ext4 bios_grub
3 2001MB linux-swap
4 37.5GB ext4 /

It is creating the bios_grub partition, but the EFI is still being made 
also. Is that necessary?


---

After completing the install, I was able to make it to the next bug!: 
https://issues.guix.gnu.org/44054

bug#44054: [1.2 installer]: Kernel panic when attempting to reboot after install.

[Brendan Tildesley]

I generated an installer for myself from 
5d4ad8e1be6d60c38577e2f3d92cc5642b12eff0 + Miguel's patch (I think 
unrelated to this bug) here https://paste.debian.net/plain/1167398


After the install completed I pulled out the USB as per instruction on 
the screen, and pressed the Reboot button. The system then Kernel panic 
with the following messages:


https://brendan.scot/p/IMG_20201018_140343.png

Sorry I don't have it in textual form.

bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.

[Brendan Tildesley]

On 17/10/20 11:09 pm, Miguel Ángel Arruga Vivas wrote:

Hi,

Brett Gilio  writes:

Ludovic Courtès  writes:

Shouldn’t it create a “legacy” partition table rather than GPT since
we’re on an old, non-UEFI platform?

That is my thinking as well, it should create a legacy MBR table.

IMHO the old format should be avoided completely when possible.  Why
should we enforce it?

I think this problem involves having a previous ESP partition on the
disk (at least identified as such by parted), because auto-partition!
currently checks that before checking if the booted system has EFI
support.  When that's the case, it doesn't create the needed bios_grub
partition that might have been removed previously.

The attached patch solves that.  What do you think?

Happy hacking,
Miguel


I'm about to give it a test run. Unrelated to the patch, but, I'm 
building the installer (gnu/system/install.scm) on latest master and I 
get the following warnings/errors, although it doesn't stop the build 
from completing. is it a bug?


https://paste.debian.net/plain/1167398

bug#44027: 1.2-29a2eb3 Installer fails at final stage installing GRUB.

[Brendan Tildesley]

|Going through the GUI installer selecting all the defaults, and install 
with LVM and ecryption, AND for the normal option without encryption I 
get these errors on TWO different laptops, both ~10 years old with BIOS. 
Encrypted: Installing for i386-pc platform. grub-install: warning: this 
GPT partition label contains no BIOS Boot Partition; embedding won't be 
possible. grub-install: error: embedding is not possible, but this is 
required for RAID and LVM install. Unencrypted: ||Installing for i386-pc platform. grub-install: warning: this GPT 
partition label contains no BIOS Boot Partition; embedding won't be 
possible. grub-install: warning: Embedding is not possible. GRUB can 
only be installed in this setup by using blocklists. However, blocklists 
are UNRELIABLE and their use is discouraged.. grub-install: error: will 
not proceed with blocklists.|

||

bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

[Brendan Tildesley]

If I click the reply via email button in Icecat, it switches to icedove 
but does not open a reply email at all.
In ungoogled-chromium, it opens up a blank reply email, failing to fill 
the To, CC, Subject with anything.


If I click the equivalent mailto link on the issues page in Icecat, its 
the same
If I click the equivalent mailto link, but in chromium, it opens a 
new email, but only the Subject is filled out. No To or CC.


I've always thus replied to the mailing list by manually copy-pasting 
the the Subject, adding Re:, and trying to find the posters email 
address, and bug address to add in To/CC. Is this related to your bug?

bug#43446: Qt Apps cant make use of qtwayland due to QT_PLUGIN_PATH '= wrapping

[Brendan Tildesley]

On 4/10/20 10:43 pm, Ricardo Wurmus wrote:

Brendan Tildesley  writes:


qt-build-system wraps variables such as QT_PLUGIN_PATH  with  '=
instead of prefix, so when qtwayland is installed in a profile or
included in the environment, the application fails to see it. Programs
run with export QT_QPA_PLATFORM=wayland-egl will fail to launch.

We could:

1. Use 'prefix so that the parent environment's variables are appended
and users have to manually install qtwayland them selves.
2. Include qtwayland as an input to every qt package somehow. Can the
build system do that? Considering that Wayland seems to be the
future, I feel that Qt GUI applications should support it by
default. I mean, wayland is in the closure of qtbase anyway.
3. Both? Why is '= used anyway?

I can’t say why the Qt build system does this, but in other cases we
know that 'prefix causes problems because the application may end up
loading incompatible binaries leading to a crash.  That’s especially the
case on foreign distros, e.g. when the Guix-installed graphical
application loads a plugin from the system’s XDG_* directories.

Thanks for pointing that out. But, currently a Guix Qt program is unable 
to see plugins available in the environment/profile even if the variable 
is set because the wrapper just deletes that in its local environment. 
It can only see what's in it's inputs. How else can that be fixed?


cat `which nheko`|grep QT;

export 
QT_PLUGIN_PATH="/gnu/store/swqnld90m4gmmc1qaf4lg1psvf6q0rr0-qttools-5.14.2/lib/qt5/plugins:/gnu/store/j0b10r3djln34avx4qxh1kxzg70fn04r-qtbase-5.14.2/lib/qt5/plugins:/gnu/store/lh2yq7dlw3cfaf613h787drpy6f146n3-qtdeclarative-5.14.2/lib/qt5/plugins:/gnu/store/cz6lfbphrdqvgrbhgdq0hd7a50015i5h-qtmultimedia-5.14.2/lib/qt5/plugins:/gnu/store/r4h7w3zw02nc33bi7bjlqbl9b8kilh9r-qtsvg-5.14.2/lib/qt5/plugins"

bug#43446: [PATCH] guix: qt-build-system: Fix search-path wrapping.

[Brendan Tildesley]

>From 9c1d5b76c70ebf9942f6bb891677d260fe16cb62 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Sun, 4 Oct 2020 21:58:08 +1100
Subject: [PATCH] guix: qt-build-system: Fix search-path wrapping.

* guix/build/qt-build-system.scm: (variables-for-wrapping): Modify
qt-build-system's wrap-all-programs phase to prefix all wrapped
search-path variables instead of overwriting them with =. This allows Qt
applications to find plugins available in the environment.
---
 guix/build/qt-build-system.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/build/qt-build-system.scm b/guix/build/qt-build-system.scm
index 005157b0a4..93f512b5d6 100644
--- a/guix/build/qt-build-system.scm
+++ b/guix/build/qt-build-system.scm
@@ -60,7 +60,7 @@
(lambda (var-to-wrap) (not (null? (last var-to-wrap
(map
 (lambda (var-spec)
-  `(,(first var-spec) = ,(collect-sub-dirs base-directories (last var-spec
+  `(,(first var-spec) prefix ,(collect-sub-dirs base-directories (last var-spec
 (list
  ;; these shall match the search-path-specification for Qt and KDE
  ;; libraries
-- 
2.28.0

bug#43736: I think f43ffee... broke guix pull

[Brendan Tildesley]

I just got this running guix pull building guix-system-tests. looks 
kinda related to your patch since it mentions local-file




[  6/ 54] loading... 22.2% of 27 filesrandom seed for tests: 1601620953
[ 10/ 54] loading... 37.0% of 27 filesBacktrace:
In ice-9/eval.scm:
163:9 19 (_ #(#(#) #< 
kernel: # 
kernel-loadable-modules: ()?> ?))
   173:47 18 (_ #(#(#(#) 
#< kernel: # kernel-loadable-module?> ?) ?))
159:9 17 (_ #(#(#(#) 
#< kernel: # kernel-loadable-module?> ?) ?))
159:9 16 (_ #(#(#(#) 
#< kernel: # kernel-loadable-module?> ?) ?))
   293:34 15 (_ #(#(#) #< 
kernel: # 
kernel-loadable-modules: () ?>))
In srfi/srfi-1.scm:
   586:29 14 (map1 (#< type: # value: #t> 
#< type: # value: #< kmscon: 
# ?))
   586:29 13 (map1 (#< type: # value: 
#< kmscon: # v?> ?))
   586:29 12 (map1 (#< type: # value: #< 
motd: #< name: "motd" content: "\n\x1b[1;37mWelcome to the installation of GN?> ?))
   586:29 11 (map1 (#< type: # value: "tty2"> 
#< type: # value: #t> #< type?> ?))
   586:29 10 (map1 (#< type: # value: #t> 
#< type: # value: #< mi?> ?))
   586:29  9 (map1 (#< type: # value: 
#< mingetty: # 
tty: "tt?> ?))
   586:29  8 (map1 (#< type: # value: 
#< mingetty: # 
tty: "tt?> ?))
   586:29  7 (map1 (#< type: # value: 
#< mingetty: # 
tty: "tt?> ?))
   586:29  6 (map1 (#< type: # value: 
#< mingetty: # 
tty: "tt?> ?))
   586:29  5 (map1 (#< type: # value: 
#< syslogd: # ?))
   586:17  4 (map1 (#< type: # value: 
#< guix: #?> ?))
In ice-9/eval.scm:
   196:43  3 (_ #(#(#(#) #< type: 
# value: #< guix: #) #))
   293:34  2 (_ #(#(#(#) #< type: 
# value: #< guix: #) #))
In gnu/packages/package-management.scm:
   549:20  1 (_)
In guix/gexp.scm:
405:0  0 (%local-file _ _ _ #:literal? _ #:location _ #:recursive? _ 
#:select? _)

guix/gexp.scm:405:0: In procedure %local-file:
Invalid keyword: "guix-current"

bug#38414: Bug not relevant anymore.

[Brendan Tildesley]

I'm trying to run guix pull after 4  months. This is guix on Arch.


Is this bug report  still relevant? It looks like you have binarysubstitutes disabled, is 

that on purpose?

They were never intentionally disabled. not sure what happened since i 
hadn't touched it in ages.


Closing since I haven't experienced this since. it wont be pursued.

bug#43446: Qt Apps cant make use of qtwayland due to QT_PLUGIN_PATH '= wrapping

[Brendan Tildesley]

qt-build-system wraps variables such as QT_PLUGIN_PATH  with  '= instead 
of prefix, so when qtwayland is installed in a profile or included in 
the environment, the application fails to see it. Programs run with 
export QT_QPA_PLATFORM=wayland-egl will fail to launch.


We could:

1. Use 'prefix so that the parent environment's variables are appended
   and users have to manually install qtwayland them selves.
2. Include qtwayland as an input to every qt package somehow. Can the
   build system do that? Considering that Wayland seems to be the
   future, I feel that Qt GUI applications should support it by
   default. I mean, wayland is in the closure of qtbase anyway.
3. Both? Why is '= used anyway?

How should this be done?

bug#40039: 'wrap-script' introduces spurious argument

[Brendan Tildesley]

Hi Ricardo, Ludovic... I was wondering if we could revisit and fix this. 
I believe there is more than 1 bug here.


Suppose we have the script test.sh

   #!/run/current-system/profile/bin/bash
   echo "$@"

./test.sh returns:

hi

Wrapping with wrap-script returns

 ./test.sh hi

(notice the extract space at the start.)

With Ludovic's change to char-set:graphicY

.test.sh hi

The leading space is gone at least. Finally, after removing one of the 
(car cl)'s, if finally just returns hi.

bug#41138: XML error opening IceDove Edit -> Preferences.

[Brendan Tildesley]

I also experience this bug, even with a fresh profile.

bug#43151: Resolve Calibre run-time dependency

[Brendan Tildesley]

Sorry I tried sending this with a typo in your gmail address so I'm 
resending just for you:


On 7/9/20 6:12 pm, Brendan Tildesley wrote:
There is actually a Bug report by Andreas for this very issue. I 
created a bug report just for updating, and fixed this issue after it 
while I could, without realising. Sorry for all the confusion with 
things happening in 3 different threads.


I created an updated patch just for this one here. 
https://issues.guix.gnu.org/43151#5


Your patch also works I think but it will wrap the programs twice, so 
you will get calibre, .calibre-real, and ..calibre-real-real, etc for 
every program, which seems ugly. My patch reproduces the same 
PYTHONPATH that is set in python-build-system in addition to wrapping 
PYTHONPATH (unless I made a mistake), although at the cost of code 
duplication. I leave it to you and who ever is reviewing this to 
decide which way is more correct and push one, haha.



Please continue any discussion of the QtWebEngine bug on issue 43121: 
43...@debbugs.gnu.org / https://issues.guix.gnu.org/43151

bug#43151: Resolve Calibre run-time dependency

[Brendan Tildesley]

There is actually a Bug report by Andreas for this very issue. I created 
a bug report just for updating, and fixed this issue after it while I 
could, without realising. Sorry for all the confusion with things 
happening in 3 different threads.


I created an updated patch just for this one here. 
https://issues.guix.gnu.org/43151#5


Your patch also works I think but it will wrap the programs twice, so 
you will get calibre, .calibre-real, and ..calibre-real-real, etc for 
every program, which seems ugly. My patch reproduces the same PYTHONPATH 
that is set in python-build-system in addition to wrapping PYTHONPATH 
(unless I made a mistake), although at the cost of code duplication. I 
leave it to you and who ever is reviewing this to decide which way is 
more correct and push one, haha.



Please continue any discussion of the QtWebEngine bug on issue 43121: 
43...@debbugs.gnu.org / https://issues.guix.gnu.org/43151

bug#43151: Calibre ebook-viewer requires QtWebEngine

[Brendan Tildesley]

On 6/9/20 6:25 pm, Andreas Enge wrote:

(cc-ing this and only this bug, the other one seems to have diverged towards
css and typescript)

On Fri, Sep 04, 2020 at 07:53:02PM +1000, Brendan Tildesley wrote:

I did not realise there was already an open ticket for updating calibre,
thanks for pointing it out. Indeed I do not think we need to wrap all
programs. I tried out the programs in ...calibre-4.18.0/bin, and only these
two fail with an error message:
 ebook-edit
 ebook-viewer
I did not try the different calibre-*; calibre itself starts. Then it can call
ebook-viewer, and I do not know the mechanism, so it might just call the
wrapped binary ebook-viewer, or it might need wrapping itself because of using
internal python mechanics. I would give it a try and not wrap it in the first
place.

All "binaries" are already wrappend with PYTHONPATH, so there is probably some
mechanic to avoid double wrapping (which your patch may already address).

Since it uses (replace 'wrap..., it won't run the old wrap phase any more.
Also I don't think it matters much that the other variables also have the Qt
variable wrapped, perhaps it is more correct anyway. Especially since the
wrap script uses '=, which wrap-program interprets as overwriting the
variable completely, so applying it twice won't make a difference anyway.

Well, I think we should not wrap more than absolutely necessary. And it would
even be easier to write (no need to look for all the binaries, just use these
two names). Would you like to create a patch maybe for the current calibre,
and handle the update following the other bug?

Andreas

It's actually a bit more complicated because every other executable 
still requires PYTHONPATH wrapping anyway as python-build-system does 
it. I just tested creating such a wrap phase that only sets 
QTWEBENGINEPROCESS_PATH for ebook-viewer and ebook-edit. It works when 
they are opened directly, but when they are opened via the calibre 
interface, they fail to find qtwebengine. so it does seem that calibre 
it's self needs that variable set anyway.


I've attached a patching fixing this one issue. For those I've emailed 
coming from the Issue I created for updating Calibre, since it looks 
like the update will be delayed until Mathjax 3 is packaged properly, 
would you mind just reviewing this fix to get it through for the current 
Calibre.


I think Ricardo was having a go at packaging swc to transpile typescript 
which is needed for mathjax, but it looks like quite a challenge.


>From 33b497cd3b8d21a76307b36729efb67baa08ac26 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Mon, 7 Sep 2020 01:05:37 +1000
Subject: [PATCH] gnu: calibre: Wrap QTWEBENGINEPROCESS_PATH.

* gnu/packages/ebook.scm (calibre): Wrap QTWEBENGINEPROCESS_PATH in
addition to wrapping PYTHONPATH as python-build-system does.
---
 gnu/packages/ebook.scm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/ebook.scm b/gnu/packages/ebook.scm
index aab4155d3d..38040c6f65 100644
--- a/gnu/packages/ebook.scm
+++ b/gnu/packages/ebook.scm
@@ -246,6 +246,29 @@
   (assoc-ref inputs "js-mathjax")
   "/share/javascript/mathjax"))
  (invoke "python2" "setup.py" "rapydscript")))
+ (replace 'wrap
+   ;; Here we wrap PYTHONPATH exactly as it would be in
+   ;; python-build-system, plus the addition of
+   ;; QTWEBENGINEPROCESS_PATH, fixing a bug where Calibre would not
+   ;; find Qtwebengine.
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(bin (string-append out "/bin"))
+(python (assoc-ref inputs "python"))
+(site-packages
+ (cons (string-append out "/lib/python"
+  (python-version python)
+  "/site-packages")
+   (search-path-as-string->list (getenv "PYTHONPATH"
+(qtwebengineprocess
+ (string-append (assoc-ref inputs "qtwebengine")
+"/lib/qt5/libexec/QtWebEngineProcess")))
+   (for-each (lambda (program)
+   (wrap-program program
+ `("QTWEBENGINEPROCESS_PATH" = (,qtwebengineprocess))
+ `("PYTHONPATH" prefix ,site-packages)))
+ (find-files bin ".")))
+ #t)) 
  (add-after 'install 'install-man-pages
(lambda* (#:key outputs #:allow-other-keys)
  (copy-recursively
-- 
2.28.0

bug#43151: Calibre ebook-viewer requires QtWebEngine

[Brendan Tildesley]

I created this patch which I think fixes it, copying the phase from 
Anki. https://issues.guix.gnu.org/issue/42885#4


Perhaps I should have only wrapped the ebook-viewer with qtwebengine 
instead of every program.

bug#41878: 'guix substitute' and 'guix pull' fail gracelessly on flaky networks

[Brendan Tildesley]

I have not looked closely but from observation I think currently guix 
first decides if it is going to commit to using a substitute, or falling 
back to building locally, by checking if substitutes are available then 
committing to a method. This differs from the concept of a fallback in 
my head, which would involve trying option B only after option A has 
been tried and failed. guix's way means there are a class of failures 
where guix simply gives up and stops instead of falling back.


In my experience, probably 10% of the time I try a guix pull; guix 
package -u ., there is some weird network error that doesn't happen the 
second time I run it. Perhaps it would be sufficient to simply try twice 
for every substitute; accumulate a list of failed substitutes and retry 
them after iterating through the list of substitutes to download, then 
if that fails try building from source. only then are we allowed to give up.

bug#42992: closed

[Brendan Tildesley]

bug was my own misconfiguration.

bug#42992: nix-channel refers to a non existent bash-minimal

[Brendan Tildesley]

I use nix for some libre software not available in guix yet. currently 
I'm getting the following error:


b@ui ~$ nix-channel --update

unpacking channels...
while setting up the build environment: executing 
'/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash': 
No such file or directory
builder for 
'/nix/store/vbcwq7qgz2372vhjg1mjzcmln5q2rihz-nixos-20.09pre239318.c59ea8b8a0e.drv' 
failed with exit code 1
error: build of 
'/nix/store/jimxjljq433dm5arwyps9yp0qap8n4rc-nixpkgs-20.09pre239803.909539e6a09.drv', 
'/nix/store/vbcwq7qgz2372vhjg1mjzcmln5q2rihz-nixos-20.09pre239318.c59ea8b8a0e.drv' 
failed
error: program 
'/gnu/store/ngk9ir0am97190hf4p9v0rwcvm8bcgn2-nix-2.3.6/bin/nix-env' 
failed with exit code 100

b@ui ~$
b@ui ~$ guix build nix
/gnu/store/ngk9ir0am97190hf4p9v0rwcvm8bcgn2-nix-2.3.6
b@ui ~$ rg bash-minimal 
/gnu/store/ngk9ir0am97190hf4p9v0rwcvm8bcgn2-nix-2.3.6
/gnu/store/ngk9ir0am97190hf4p9v0rwcvm8bcgn2-nix-2.3.6/share/nix/corepkgs/config.nix 

6:  shell = 
"/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash";

---

I am unsure where this bash-minimal comes from. it is not the latest 
bash-minimal returned by guix build bash-minimal. Adding bash-minimal to 
nix's inputs didn't fix it.

bug#33596: Closed since this random segfault will not be followed up after 2 years.

[Brendan Tildesley]

bug#40447:

[Brendan Tildesley]

Closing since it seems to unrelated. Sorry for wasting your time. I 
think it may have been my ext4 having too many files. i deleted all my 
system generations and gc'd a lot of stuff, and it seems to be miss 
behaving. perhaps it is a different kind of guix bug that it doesnt cope 
with this issue:



[ 7862.196231] EXT4-fs warning (device sdb1): ext4_dx_add_entry:2343: 
Directory (ino: 24903688) index full, reach max htree level :2
[ 7862.196241] EXT4-fs warning (device sdb1): ext4_dx_add_entry:2347: 
Large directory feature is not enabled on this filesystem

bug#40447: Acknowledgement (guix pull failure on master.)

[Brendan Tildesley]

Ok I may have jumped the gun a little. the first error I had looked like 
it was related to it but my battery died before i could post it, so i 
reran it and got another error, which didnt seem so related. It was odd 
that 8c88e2422 succeeded but later commits failed twice, and another irc 
user found their guix pull failing at the same time.
However, I had these errors in dmesg so I ran guix gc followed by guix 
pull and it worked. it may be because my ext4 is hitting limits and guix 
isnt coping with that well.


[ 7485.656995] EXT4-fs warning (device sdb1): ext4_dx_add_entry:2343: 
Directory (ino: 24903688) index full, reach max htree level :2
[ 7485.656998] EXT4-fs warning (device sdb1): ext4_dx_add_entry:2347: 
Large directory feature is not enabled on this filesystem







Another error I got building again:


guix offload: warning: '/etc/guix/machines.scm' did not return a list of 
build machines; ignoring it
building path(s) 
`/gnu/store/wx1wwqawh7193bvrrwqz41c2jr0c38gl-guix-packages-base'
|   setting up chroot environment in 
`/gnu/store/cgn8cvga3rsbyk0qqi334nqrq25g6kgk-guix-packages-base.drv.chroot'
|   executing builder 
`/gnu/store/5780x8w59lg898p9a45c2i18lx6r25yb-guile-next-3.0.2/bin/guile'
|   @ build-started 
/gnu/store/cgn8cvga3rsbyk0qqi334nqrq25g6kgk-guix-packages-base.drv - 
x86_64-linux 
/var/log/guix/drvs/cg//n8cvga3rsbyk0qqi334nqrq25g6kgk-guix-packages-base.drv.bz2 
7199

Backtrace:
   1 (primitive-load "/home/b/.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 struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f

bug#40447: Acknowledgement (guix pull failure on master.)

[Brendan Tildesley]

8c88e2422 builds successfull.

This is the error message with --debug=3


downloading from 
https://ci.guix.gnu.org/nar/lzip/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5...

 guix-4391fefc5 12KiB 2.3MiB/s 00:00 [##] 100.0%

linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/etc/bash_completion.d/guix’ 
to ‘/gnu/store/.links/0qqf3ra512hi0q7wcypyi3q77p5hl7zaha10s6g8ylxl86nr7lb6’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/etc/bash_completion.d/guix-daemon’ 
to ‘/gnu/store/.links/0hswry7194cymm6z7lwxaas4x67z9awscjxkxd8c5f24hgd1bqqp’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/share/fish/vendor_completions.d/guix.fish’ 
to ‘/gnu/store/.links/1jgbpimy1brxn96zcacw3s1hx8flcjjld9j890k3z9r5bdpyblg6’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/share/zsh/site-functions/_guix’ 
to ‘/gnu/store/.links/0p6y6hgk9f3smhw1alad44vrhvf9dqlrlp2vb5c8m9wc5yxfhapl’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/share/guix/berlin.guixsd.org.pub’ 
to ‘/gnu/store/.links/0yapygnwdhx6dyi0fz8dkpxlafz8mjkljrrsdpkcwvdpp4is162w’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/share/guix/ci.guix.info.pub’ 
to ‘/gnu/store/.links/0yapygnwdhx6dyi0fz8dkpxlafz8mjkljrrsdpkcwvdpp4is162w’
linking 
‘/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5/share/guix/ci.guix.gnu.org.pub’ 
to ‘/gnu/store/.links/0yapygnwdhx6dyi0fz8dkpxlafz8mjkljrrsdpkcwvdpp4is162w’
substitution of path 
`/gnu/store/cranhffh2ym9bdcr05xzpcqi9rf4mjsg-guix-4391fefc5' succeeded
building path(s) 
`/gnu/store/mh45f32sh1jgx2n93x6dvih9szgfrlhj-ca-certificate-bundle'
|   setting up chroot environment in 
`/gnu/store/5nr79x4mpq5fwy5b0y7njpsgcx38938g-ca-certificate-bundle.drv.chroot'
|   executing builder 
`/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile'
|   @ build-started 
/gnu/store/5nr79x4mpq5fwy5b0y7njpsgcx38938g-ca-certificate-bundle.drv - 
x86_64-linux 
/var/log/guix/drvs/5n//r79x4mpq5fwy5b0y7njpsgcx38938g-ca-certificate-bundle.drv.bz2 
5610
scanning for references inside 
`/gnu/store/mh45f32sh1jgx2n93x6dvih9szgfrlhj-ca-certificate-bundle'

building path(s) `/gnu/store/8nkjk7i7nrp8lmjwjkkfzcjd898nib55-fonts-dir'
|   setting up chroot environment in 
`/gnu/store/dyrnbchg0lywly7pgaw25krdp5lb32y8-fonts-dir.drv.chroot'
|   executing builder 
`/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile'
|   @ build-started 
/gnu/store/dyrnbchg0lywly7pgaw25krdp5lb32y8-fonts-dir.drv - x86_64-linux 
/var/log/guix/drvs/dy//rnbchg0lywly7pgaw25krdp5lb32y8-fonts-dir.drv.bz2 5621
scanning for references inside 
`/gnu/store/8nkjk7i7nrp8lmjwjkkfzcjd898nib55-fonts-dir'

building path(s) `/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir'
|   setting up chroot environment in 
`/gnu/store/shrlnaigds9j2w4z8cfbp4gkf5a40w83-info-dir.drv.chroot'
|   executing builder 
`/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile'
|   @ build-started 
/gnu/store/shrlnaigds9j2w4z8cfbp4gkf5a40w83-info-dir.drv - x86_64-linux 
/var/log/guix/drvs/sh//rlnaigds9j2w4z8cfbp4gkf5a40w83-info-dir.drv.bz2 5636
scanning for references inside 
`/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir'
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir.zh_CN’ 
to ‘/gnu/store/.links/1y68a5nnimmnjmc91dvizkswaprxj453pfpplqj4rniamqjf3dki’
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir.es’ 
to ‘/gnu/store/.links/11kg8i5p3c3hfz3550f0xwj7n4admbb8xvfz081p4q61axc4gwgg’
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir’ to 
‘/gnu/store/.links/1xf2pkw314q8ss02xx803ph7hkvylh8n7rlrg2pcp07zfw32il9n’
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir.de’ 
to ‘/gnu/store/.links/0xmywz6hn92r5m4ciimgdwvaja6ar6csmmgqaqbcj5ryzsnq5cnn’
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir.ru’ 
to ‘/gnu/store/.links/0nhppi8ghkay2sc81yd23nykndjmk64hchyikzslsr68fms71c4q’
|   linking 
‘/gnu/store/almrh1463h6ncn4vz7s140y0lay3ncz4-info-dir/share/info/dir.fr’ 
to ‘/gnu/store/.links/0xwkb3qbahsff75zmm4309m353i2dxlvs6cgcjd0vl14yk8d01j2’
building path(s) 
`/gnu/store/872s54736grg3k4r1g4p05i4l8i28614-manual-database'
|   setting up chroot environment in 
`/gnu/store/4gkwyizdwx52x8vgcb6divvw1xy8zzi9-manual-database.drv.chroot'
|   executing builder 
`/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile'
|   @ build-started 
/gnu/store/4gkwyizdwx52x8vgcb6divvw1xy8zzi9-manual-database.drv - 
x86_64-linux 
/var/log/guix/drvs/4g//kwyizdwx52x8vgcb6divvw1xy8zzi9-manual-database.drv.bz2 
5671

\Backtrace:
   1 (primitive-load "/home/b/.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 struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f

b@ui ~$

bug#40447: guix pull failure on master.

[Brendan Tildesley]

I'm getting this error running guix pull.

build of 
/gnu/store/yfy990mq3ikmkhawgc35z2f2ryqdxn09-guix-system-tests.drv failed



it appears to be caused by the latest commit. using --commit to switch 
to the previous commit work.


I've CC'd the author and commiter.



044d1478c9 master origin/master gnu: Add kernel-module-loader-service.

bug#33585: Closing; Bug is fixed.

[Brendan Tildesley]

This bug was fixed with ff46016e9040f6265e9875b07d362a787e1765b9 that 
adds the desktop files. Closing.

bug#35575: logo,Some graphical programs borked with Guix on Arch

[Brendan Tildesley]

To follow up on this old bug, I believe the issue may come from here: 
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/glsl/shader_cache.cpp#L144


Mesa calculates a sha1 based on some things they reason affect the 
output, but likely it is not truely a function of every parameter than 
can make a difference to the shader output. When we updated from llvm6 
to lvm7 I'm guessing it changed the shaders somehow, and the llvm 
version is not included in the hash. Since I have zero understanding 
mesa, I'm not capable of determining the best solution. One thought is 
that if we included the mesa /gnu/store path in the calculation, this 
would make the hash's truely unique for a given mesa version, but also 
cached shaders that /would/ work would be routinely discarded after an 
update (i assume?). Would this be sensible or completely break something 
else? Should we just add the llvm version, or just start a mesa bug 
report asking for input?


The code:



ralloc_asprintf_append(, "tf: %d ", prog->TransformFeedback.BufferMode);
   for (unsigned int i = 0; i < prog->TransformFeedback.NumVarying; i++) {
  ralloc_asprintf_append(, "%s ",
prog->TransformFeedback.VaryingNames[i]);
   }

   /* SSO has an effect on the linked program so include this when 
generating

    * the sha also.
    */
   ralloc_asprintf_append(, "sso: %s\n",
  prog->SeparateShader ? "T" : "F");

   /* A shader might end up producing different output depending on the 
glsl
    * version supported by the compiler. For example a different path 
might be

    * taken by the preprocessor, so add the version to the hash input.
    */
   ralloc_asprintf_append(, "api: %d glsl: %d fglsl: %d\n",
  ctx->API, ctx->Const.GLSLVersion,
  ctx->Const.ForceGLSLVersion);

   /* We run the preprocessor on shaders after hashing them, so we need to
    * add any extension override vars to the hash. If we don't do this the
    * preprocessor could result in different output and we could load the
    * wrong shader.
    */
   char *ext_override = getenv("MESA_EXTENSION_OVERRIDE");
   if (ext_override) {
  ralloc_asprintf_append(, "ext:%s", ext_override);
   }

   /* DRI config options may also change the output from the compiler so
    * include them as an input to sha1 creation.
    */
   char sha1buf[41];
   _mesa_sha1_format(sha1buf, ctx->Const.dri_config_options_sha1);
   ralloc_strcat(, sha1buf);

   for (unsigned i = 0; i < prog->NumShaders; i++) {
  struct gl_shader *sh = prog->Shaders[i];
  _mesa_sha1_format(sha1buf, sh->sha1);
  ralloc_asprintf_append(, "%s: %s\n",
_mesa_shader_stage_to_abbrev(sh->Stage), sha1buf);

bug#40039: 'wrap-script' introduces spurious argument

[Brendan Tildesley]

I'm currently packaging libratbag which provides the cli interface 
ratbagctl. when launched without arguments, it normally the current devices


##
## with wrap-program (correct):
b@ui ~/guix [env]$ ratbagctl
warbling-mara:   Logitech G102 Prodigy Gaming Mouse

b@ui ~/guix [env]$ head `which ratbagctl`
#!/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash
export 
PYTHONPATH="/gnu/store/88v8lvs02sdqgzv7w96g19fvh8hffzzp-libratbag-0.13/lib/python3.7/site-packages/:/gnu/store/h4jkr0qg86zjn1kq6iq8v33pcadj9r13-python-evdev-1.3.0/lib/python3.7/site-packages/:/gnu/store/z5fdc5aa9hs4c3p79ajzgxhazv7702y8-python-pygobject-3.28.3/lib/python3.7/site-packages/"
exec -a "$0" 
"/gnu/store/88v8lvs02sdqgzv7w96g19fvh8hffzzp-libratbag-0.13/bin/.ratbagctl-real" 
"$@"



##
## with wrap-script:
b@ui ~/guix [env]$ ratbagctl
usage: /gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl 


   {info,name,profile,resolution,dpi,rate,button,led} ...
/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl 
: error: invalid choice: 
'/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl' 
(choose from 'info', 'name', 'profile', 'resolution', 'dpi', 'rate', 
'button', 'led')


b@ui ~/guix [env]$ ratbagctl list
/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl 
: error: invalid choice: 
'/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl' 
(choose from 'info', 'name', 'profile', 'resolution', 'dpi', 'rate', 
'button', 'led')
b@ui ~/guix [env]$ ratbagctl info rastkasnts atkatkaf ftbaontb 
aesbtabtowf ~5qawylftarsnvbawlpfyq
usage: /gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl 


   {info,name,profile,resolution,dpi,rate,button,led} ...
/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl 
: error: invalid choice: 
'/gnu/store/754ylqjs68va7rswr3fscwa0kyazsbjq-profile/bin/ratbagctl' 
(choose from 'info', 'name', 'profile', 'resolution', 'dpi', 'rate', 
'button', 'led')

b@ui ~/guix [env]$

b@ui ~/guix [env]$ head `which ratbagctl`
#!/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile 
--no-auto-compile

#!#; Guix wrapper
#\-(begin (setenv "PYTHONPATH" 
"/gnu/store/1hcpppqc6268siki64vs1ygq1qsr8w35-libratbag-0.13/lib/python3.7/site-packages/:/gnu/store/h4jkr0qg86zjn1kq6iq8v33pcadj9r13-python-evdev-1.3.0/lib/python3.7/site-packages/:/gnu/store/z5fdc5aa9hs4c3p79ajzgxhazv7702y8-python-pygobject-3.28.3/lib/python3.7/site-packages/"))
#\-(let ((cl (command-line))) (apply execl 
"/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4/bin/python3" 
(car cl) (cons (car cl) (append (quote ("")) cl

#!/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4/bin/python3



Here I make a copy of the guix build utils module and modify the 
wrap-script, removing #\space as suggested, so it defaults to 
char-set:graphic. This results in the above guile wrapper chaging to:


#\-(let ((cl (command-line))) (apply execl 
"/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4/bin/python3" 
(car cl) (cons (car cl) (append (quote ()) cl


The behaviour changes somewhat. Now running ratbagctl prints the 
commants list, which is what should happen when the wrong arguments are 
provided, e.g., `ratbagctl qwfqwfqf`



b@ui ~/guix [env]$ ratbagctl
usage: ratbagctl [OPTIONS] list
   ratbagctl [OPTIONS]  {COMMAND} ...


b@ui ~/guix [env]$ ratbagctl list
usage: /gnu/store/fgl1w0lh1pzqg8j4gi8j1yi29aa122ja-profile/bin/ratbagctl 


   {info,name,profile,resolution,dpi,rate,button,led} ...
/gnu/store/fgl1w0lh1pzqg8j4gi8j1yi29aa122ja-profile/bin/ratbagctl 
: error: invalid choice: 'list' (choose from 'info', 'name', 
'profile', 'resolution', 'dpi', 'rate', 'button', 'led')


























>From 3b5db2c77598961b0b60c901a9bbed8f0524a93f Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Sun, 22 Mar 2020 22:40:18 +1100
Subject: [PATCH] WRAPSCRIPT

---
 gnu/packages/gnome.scm | 131 -
 my-wrap.scm| 162 +
 2 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 my-wrap.scm

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index a08cd00d72..d614677214 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -27,7 +27,7 @@
 ;;; Copyright © 2017, 2018 nee 
 ;;; Copyright © 2017 Chris Marusich 
 ;;; Copyright © 2017 Mohammed Sadiq 
-;;; Copyright © 2017 Brendan Tildesley 
+;;; Copyright © 2017, 2020 Brendan Tildesley 
 ;;; Copyright © 2017, 2018 Rutger Helling 
 ;;; Copyright © 2018 Jovany Leandro G.C 
 ;;; Copyright © 2018 Vasile Dumitrascu 
@@ -158,12 +158,14 @@
   #:use-module (gnu packages spice)
   #:use-module (gnu packages sqlite)
   #:use-module (gnu packages ssh)
+  #:use-module (gnu packages swig)
   #:use-module (gnu package

bug#40039: 'wrap-script' introduces spurious argument

[Brendan Tildesley]

It appears the repeated (car cl) results in the executable path getting 
sent to it's self as the first argument. I'm not sure how things managed 
to work up until now? I tested the following change and it fixed the one 
case I was using, but am not sure it is correct. why was the cons (car 
cl) there in the first place?



diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index b8be73ead4..9610f39d71 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -946,7 +946,7 @@ FILE are kept unchanged."
   "patch-shebang: ~a: 
changing `~a' to `~a'~%"
   file (string-append 
interp " " arg1) bin)

   (patch p bin rest))
-  (begin
+  (begin
 (format (current-error-port)
 "patch-shebang: ~a: 
changing `~a' to `~a'~%"

 file interp bin)
@@ -1292,11 +1292,10 @@ not supported."
    (_ vars
    `(let ((cl (command-line)))
   (apply execl ,interpreter
- (car cl)
- (cons (car cl)
-   (append
- ',(string-split args #\space)
-    cl))
+ (car cl) ;; The program.
+ (append
+  ',(string-tokenize args 
#\space)

+  cl)
    (template (string-append prog ".XX"))
    (out  (mkstemp! template))
    (st   (stat prog))

bug#38414: guix pull error while building gcc-core-mesboot-2.95.3

[Brendan Tildesley]

I'm trying to run guix pull after 4 months. This is guix on Arch.

guix (GNU Guix) fbeb92d7607dc1dc6c3a34a536352636274a69de
guix-daemon (GNU Guix) 1.0.0-1.326dcbf




...
build-@ build-log 3527328 6
gcc-co@ build-log 3527328 6
re-mes@ build-log 3527328 6
boot-2@ build-log 3527328 6
.95.3.@ build-log 3527328 6
drv-0/@ build-log 3527328 6
gcc-2.@ build-log 3527328 6
95.3/g@ build-log 3527328 4
cc'
@ build-log 3527328 13
make: *** [al@ build-log 3527328 15
l-gcc] Error 2
@ build-log 3527328 374
command "make" "CC=tcc -static -D __GLIBC_MINOR__=6" "OLDCC=tcc -static -D 
__GLIBC_MINOR__=6" "CC_FOR_BUILD=tcc -static -D __GLIBC_MINOR__=6" "AR=ar" 
"RANLIB=ranlib" "LIBGCC2_INCLUDES=-I 
/gnu/store/sdwpf8ai39y0hb98gd02qgx32s3las49-tcc-boot-0.9.27/include" 
"LANGUAGES=c" "BOOT_LDFLAGS= 
-B/gnu/store/sdwpf8ai39y0hb98gd02qgx32s3las49-tcc-boot-0.9.27/lib/" failed with 
status 2
builder for 
`/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv - 1 
builder for 
`/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/slnyk8gbnvfwy1m1was8myivpss58idd-gcc-mesboot0-2.95.3.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/2633565gzh4jqh7c5zf6i0iy9yxqigcv-glibc-mesboot0-2.2.5.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/2lpg626q4x8v7hgqajywpq1rc8y72hzx-binutils-mesboot-2.20.1a.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/7pllq0crksfkr7856y1pawcy4scc7l4q-gcc-mesboot1-4.7.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/lp6fycqqd8adndlfylh4mlihm0qakxzw-glibc-mesboot-2.16.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5ad88jy4a1gpbslzdiksk7zjyh28wzkr-make-mesboot-3.82.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5xh3f9lxl86imd56fk8n6wcqdcrzh2mb-binutils-cross-boot0-2.32.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/492grrzzhh8z7nv9vrh9vai6kk7zfj8i-diffutils-boot0-3.7.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/56xfnvjd2qv05vx3j0s6b30h9dg3dqcj-file-boot0-5.33.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/b1n16vi8ypfr1bsgrcgk67h6sixghy0c-findutils-boot0-4.6.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/h6pl88jbzlgan2majgy0z6kcphzp2x6q-gcc-cross-boot0-7.4.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5lcadggb83v1dfyza323lcw8ih199v1l-gcc-mesboot-wrapper-4.9.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rmfsg2dsb88b136arb40z3kgd57kcnzs-glibc-2.29.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/qcx5p89cac2ghvc4k6cq2c6dsm3xncp1-glibc-intermediate-2.29.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/djxlq3ilag624v2zr8ya3zivwcrpiji7-linux-libre-headers-4.19.56.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/88azrsd0d3axcp043yrd4pl78ifd5368-make-boot0-4.2.1.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/my4rsf2nhcxd9n106bjrdmw56k26cc2j-perl-boot0-5.30.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rhqqd8kmr1fqc9fkzpbh0qca4mwb03xa-texinfo-6.6.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv': 1 
dependencies couldn't be built
Backtrace:
In ./guix/gexp.scm:
859:2 19 (_ _)
720:2 18 (_ _)
In ./guix/monads.scm:
482:9 17 (_ _)
In ./guix/gexp.scm:
590:13 16 (_ _)
In ./guix/store.scm:
1699:8 15 (_ _)
In ./guix/gexp.scm:
859:2 14 (_ _)
720:2 13 (_ _)
In ./guix/monads.scm:
482:9 12 (_ _)
In ./guix/gexp.scm:
590:13 11 (_ _)
In ./guix/store.scm:
1699:8 10 (_ _)
In ./guix/gexp.scm:
859:2  9 (_ _)
720:2  8 (_ _)
In ./guix/monads.scm:
482:9  7 (_ _)
In ./guix/gexp.scm:
590:13  6 (_ _)
In ./guix/store.scm:
1699:8  5 (_ _)
1734:38  4 (_ #)
In ./guix/packages.scm:
948:16  3 (cache! # # ?)
1267:22  2 (thunk)
1200:25  1 (bag->derivation # # ?)
In srfi/srfi-1.scm:
592:17  0 (map1 (("source" # url: "?>) ?))

srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/gzmi7pv8pbfk91a2mrhxzybmbmhjjb3b-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"37515553b5678c61f59dd0efb2504c0ccc5152f2"; system: "x86_64-linux";

bug#35761: gnome-maps fails to find Goa

[Brendan Tildesley]

$ gnome-maps
Unsatisfied dependency: Goa

bug#35575: Some graphical programs borked with Guix on Arch

[Brendan Tildesley]

Wow you are a genius, that fixed it. How did you know? Sorry I got no
notification of your email, maybe because you emailed bug-guix instead
of 35...@debbugs.gnu.org.

So that's fixed my issue but I wonder how it can be fixed in general so
others don't have this issue.

bug#35575: Some graphical programs borked with Guix on Arch

[Brendan Tildesley]

With Guix on Arch, Running Guix's Godot and cool-retro-term programs
results in a completely garbled GUI. Godot ran with OpenGL ES2 instead
of ES3 looks a bit better except the fonts fail to render correctly.
Cool-retro-term complains about how using a variable width font may
cause display alignment issues, although I'm not sure that is related.
Perhaps it indicates it is a font issue? The Arch versions work just
fine. I haven't installed Guix System  on this machine yet so I'm not
sure if they would work that way.

I have seen this kind of graphical artefact before with  KDE when I've
suspended my machine and it's come back all broken.. It may be related
to the fact that I have an AMD Radeon Fury X graphics card. (I haven't
explicitly installed any proprietary drivers; I think AMDGPU is free).

Any one have any clues on how to debug such a thing?

https://brendan.scot/p/borked-godot.png

bug#35501: libplist 2.0.0 build failure: File does not exist.

[Brendan Tildesley]

=
   libplist 2.0.0: test/test-suite.log
=

# TOTAL: 29
# PASS:  26
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: largecmp
==

File does not exists
FAIL largecmp.test (exit status: 2)

FAIL: hugecmp
=

File does not exists
FAIL hugecmp.test (exit status: 2)

FAIL: bigarraycmp
=

File does not exists
FAIL bigarraycmp.test (exit status: 2)

bug#33962: Acknowledgement (guix pull fails on latest master)

[Brendan Tildesley]

Efraim fixed it:

bug#33962: guix pull fails on latest master

[Brendan Tildesley]

95bf2fb637ba4abb27efe94e0b671c1e93204e4f , which adds wl-clipboard fails
to build because it references meson-build-system without importing the
required module. I'm guessing adding  #:use-module (guix build-system
meson)   ; would fix it.

I'm curious to know how this error was made.

bug#33585: Ardour 5 not showing up under GNOME applications menu

[Brendan Tildesley]

If you look inside the package: `ls -lha $(guix build ardour)/share`,
you will see there is no applications directory, which contains .desktop
files. For some reason Ardour doesn't appear to be providing one, we may
have to add one manually. I'll have a look at it after work.

bug#33596: Segmentation fault in glibc build (after core-updates merge)

[Brendan Tildesley]

Ok so it built the second time I tried, so maybe it was just gremlins in
my computer, but im at least documenting this here.







gcc ibm1004.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef
-Wwrite-strings -fmerge-all-constants -fno-stack-protector
-frounding-math -g -Wstrict-prototypes -Wold-style-definition
-fno-math-errno   -fPIC -I../include
-I/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata 
-I/tmp/guix-build-glibc-2.28.drv-0/build 
-I../sysdeps/unix/sysv/linux/x86_64/64 
-I../sysdeps/unix/sysv/linux/x86_64 
-I../sysdeps/unix/sysv/linux/x86/include
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl 
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix 
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch 
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include
-I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch 
-I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/float128 
-I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 
-I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64 
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.
-nostdinc -isystem
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include
-isystem
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include-fixed
-isystem
/gnu/store/3c9a43ifhbjm8lsc1s183y8a8874fz01-linux-libre-headers-4.14.67/include 
-D_LIBC_REENTRANT -include
/tmp/guix-build-glibc-2.28.drv-0/build/libc-modules.h
-DMODULE_NAME=iconvdata -include ../include/libc-symbols.h  -DPIC
-DSHARED -DTOP_NAMESPACE=glibc -o
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1004.os -MD -MP -MF
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1004.os.dt -MT
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1004.os
gcc ibm1026.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef
-Wwrite-strings -fmerge-all-constants -fno-stack-protector
-frounding-math -g -Wstrict-prototypes -Wold-style-definition
-fno-math-errno   -fPIC -I../include
-I/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata 
-I/tmp/guix-build-glibc-2.28.drv-0/build 
-I../sysdeps/unix/sysv/linux/x86_64/64 
-I../sysdeps/unix/sysv/linux/x86_64 
-I../sysdeps/unix/sysv/linux/x86/include
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl 
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix 
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch 
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include
-I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch 
-I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/float128 
-I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 
-I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64 
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.
-nostdinc -isystem
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include
-isystem
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include-fixed
-isystem
/gnu/store/3c9a43ifhbjm8lsc1s183y8a8874fz01-linux-libre-headers-4.14.67/include 
-D_LIBC_REENTRANT -include
/tmp/guix-build-glibc-2.28.drv-0/build/libc-modules.h
-DMODULE_NAME=iconvdata -include ../include/libc-symbols.h  -DPIC
-DSHARED -DTOP_NAMESPACE=glibc -o
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1026.os -MD -MP -MF
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1026.os.dt -MT
/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata/ibm1026.os
gcc cp1125.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef
-Wwrite-strings -fmerge-all-constants -fno-stack-protector
-frounding-math -g -Wstrict-prototypes -Wold-style-definition
-fno-math-errno   -fPIC -I../include
-I/tmp/guix-build-glibc-2.28.drv-0/build/iconvdata 
-I/tmp/guix-build-glibc-2.28.drv-0/build 
-I../sysdeps/unix/sysv/linux/x86_64/64 
-I../sysdeps/unix/sysv/linux/x86_64 
-I../sysdeps/unix/sysv/linux/x86/include
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl 
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix 

bug#33343: Error bind mounting `/dev/full' to /gnu/store/... on reconfigure.

[Brendan Tildesley]

I'm trying to reconfigure with the latest guix after 2 months. I'm able

to build my system with guix system vm, but when I try to reconfigure I
get the following error. I tried removing ecryptfs-utils from my
configuration, but then I just get the same error with a different store
item. i have   80GiB of free space, and according to tune2fs, 50 million
free inodes.

|guix system: error: build failed: |   |   |   bind mounting `/dev/full' to 
`/gnu/store/6cnyn2ygaa4h4hmfvy4g4kriv6w61ci8-ecryptfs-utils-111.drv.chroot/dev/full'


I also encountered:

root@ui /home/b# guix gc --optimize
cannot link
`/gnu/store/.links/1a52zihpvvw40a3c4x7gqm91q8fwikxqn5c0ppfmk8xdzwnf0jh4' to 
`/gnu/store/19kffs6k7vq7a777icgwnzzwzqcjqwqa-python-2.7.14/lib/python2.7/site-packages/pip/models/__init__.pyc':
 No space left on device
cannot link 
`/gnu/store/.links/15zqnpjy710pql18r1y5kndp20iad49zjij2bmaswwg41zi30y69' to 
`/gnu/store/8qmkhdc7rkvhh1by90cgr0kjhwwl8b4q-util-macros-1.19.2.drv': No space 
left on device
cannot link 
`/gnu/store/.links/18d55pksvj1kg9bx5rhjqgz46xq4q1lpj4f9wc2bk9qrxycb7jjx' to 
`/gnu/store/cy0gyg5a6a0zcrmm74y4njv810kx3vlj-util-linux-2.31/bin/dmesg': No 
space left on device
cannot link 
`/gnu/store/.links/0avgw4kxgph7xvm94g76dzd8gfcc0085lw1wsn96jv94njnxdyfq' to 
`/gnu/store/n9ym4yl7s55pm57rnc5whjlzjgvxas32-linux-libre-4.16.2/lib/modules/4.16.2-gnu/kernel/drivers/tty/serial/8250/8250_mid.ko':
 No space left on device
cannot link 
`/gnu/store/.links/1a52zihpvvw40a3c4x7gqm91q8fwikxqn5c0ppfmk8xdzwnf0jh4' to 
`/gnu/store/nn4wfppsvqx9x6b53i8xav7nadqg02fj-python-2.7.14/lib/python2.7/site-packages/pip/models/__init__.pyc':
 No space left on device
cannot link 
`/gnu/store/.links/1gklhdk2jhwdf3mvhfzkj76d07b89djadbady6w7rdg9cpj8pa1w' to 
`/gnu/store/s28fmfrq8r0c688x59cj0fcyh2pv87nj-glibc-locales-2.27/lib/locale/2.27/en_SG.UTF-8/LC_TIME':
 No space left on device

I deleted all my backup profiles, ran guix gc, and these errors went
away after running it a few times.

bug#32313: Failed to boot after reconfiguring with a btrfs drive.

[Brendan Tildesley]

On 08/01/18 07:06, Danny Milosavljevic wrote:
> Probable fix:
>
> diff --git a/gnu/services/base.scm b/gnu/services/base.scm
> index 9fad9af99..921914ccd 100644
> --- a/gnu/services/base.scm
> +++ b/gnu/services/base.scm
> @@ -419,7 +419,7 @@ FILE-SYSTEM."
>   '((gnu build file-systems)))
> (shepherd-service
>  (provision (list (file-system->shepherd-service-name 
> file-system)))
> -(requirement `(root-file-system
> +(requirement `(root-file-system udev
> ,@(map dependency->shepherd-service-name 
> dependencies)))
>  (documentation "Check, mount, and unmount the given file 
> system.")
>  (start #~(lambda args
>
> To test, invoke
>
>   ./pre-inst-env guix system reconfigure /etc/config.scm
>
You're a genius! This appears to have fixed the problem, Although it
increases my boot time by 5 seconds or so. I guess shepherd doesn't have
the ability to load such things in parallel yet.

bug#24404: "calibre" package fails to build.

[Brendan Tildesley]

On 08/01/18 20:17, Efraim Flashner wrote:
> On Sun, Jul 22, 2018 at 11:49:14AM +0200, Andreas Enge wrote:
>> Hello,
>>
>> I ended up disabling tests (see comments in the patch).
>> Now the package builds, but tries to install into the Qt directory; at the
>> end of the cmake phase, it prints:
>>   -- Installing in the same prefix as Qt, adopting their path scheme.
>> The previous version of the package contains a phase to adapt this,
>> but the .pri files to be modified do not exist any more.
>>
>> I also tried to inherit from qtsvg like other qt* packages; but the
>> gnu-build-system does not work any more for qtwebkit, the build finishes
>> in a few seconds creating only the documentation and not compiling the 
>> code...
>>
>> At this point, I am giving up; it would be nice if someone else could take
>> a look, I am attaching the current patch.
> Thanks for getting the patch this far! I switched the 'configure phase
> from (invoke qmake) to fully cmake with some necessary configure-flags.
> It seemed easier than trying to convince qmake to install to the correct
> location.
>
> I also left the tests disabled, 7+ hours compiling on my fast aarch64
> board was quite long enough. I'm not opposed to re-enabling them but I
> don't want to debug failures.
>
>> If there is no progress during the next few days, I would suggest to re-add
>> pyqt@5.9 for calibre. What do you think?
> After fixing a bug in optipng (bundling outdated copies of libraries is
> definately a bug) I was able to compile calibre on aarch64. I run it
> headless, so I wasn't able to test it but hopefully it's back to
> working.
>
>> Andreas
>>
>> PS: There is a thread from 2016 in which the Calibre author states that he
>> will stick with qtwebkit and in the worst case take over the maintenance
>> of a fork:
>>https://www.mobileread.com/forums/showthread.php?t=270258
> If he's planning on going the same route as gnucash I assume its only a
> matter of time until he realizes distros will drop calibre rather than
> carry along his beloved cruft.
>
He doesn't care much about that because he believes people should use
the binary version of calibre that he distributes. He maintains python 2
for Windows and also intends to continue maintaining Python2 for
GNU/Linux himself. Calibre also uses some python2 dependencies that
haven't been ported to python3 at all. It would take a significant
amount of work to port it, although I feel like Calibre is the result of
years of poor programming practices. One should maintain that their
large program works with a simple gnu-build-system at all times.

---

The new qtwebkit fails to build for me. This is the tail of the output:



/__/DerivedSources/WebCore/InternalSettingsGenerated.cpp.o -c
/tmp/guix-build-qtwebkit-5.212.0-alpha2.drv-0/build/DerivedSources/WebCore/InternalSettingsGenerated.cpp
[ 82%] Linking CXX static library ../../lib/libWebCoreTestSupport.a
cd /tmp/guix-build-qtwebkit-5.212.0-alpha2.drv-0/build/Source/WebCore &&
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -P
CMakeFiles/WebCoreTestSupport.dir/cmake_clean_target.cmake
cd /tmp/guix-build-qtwebkit-5.212.0-alpha2.drv-0/build/Source/WebCore &&
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -E
cmake_link_script CMakeFiles/WebCoreTestSupport.dir/link.txt --verbose=1
/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/bin/ar crT
../../lib/libWebCoreTestSupport.a 
CMakeFiles/WebCoreTestSupport.dir/platform/mock/PlatformSpeechSynthesizerMock.cpp.o
CMakeFiles/WebCoreTestSupport.dir/platform/mock/mediasource/MockBox.cpp.o
CMakeFiles/WebCoreTestSupport.dir/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp.o
CMakeFiles/WebCoreTestSupport.dir/platform/mock/mediasource/MockMediaSourcePrivate.cpp.o
CMakeFiles/WebCoreTestSupport.dir/platform/mock/mediasource/MockSourceBufferPrivate.cpp.o
CMakeFiles/WebCoreTestSupport.dir/platform/mock/mediasource/MockTracks.cpp.o
CMakeFiles/WebCoreTestSupport.dir/testing/InternalSettings.cpp.o
CMakeFiles/WebCoreTestSupport.dir/testing/Internals.cpp.o
CMakeFiles/WebCoreTestSupport.dir/testing/MockPageOverlay.cpp.o
CMakeFiles/WebCoreTestSupport.dir/testing/MockPageOverlayClient.cpp.o
CMakeFiles/WebCoreTestSupport.dir/testing/js/WebCoreTestSupport.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSInternalSettings.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSInternals.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSMallocStatistics.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSMemoryInfo.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSMockContentFilterSettings.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSMockPageOverlay.cpp.o
CMakeFiles/WebCoreTestSupport.dir/__/__/DerivedSources/WebCore/JSTypeConversions.cpp.o

bug#30224: (no subject)

[Brendan Tildesley]

On 07/31/18 05:54, Gábor Boskovits wrote:
>
>
> Brendan Tildesley  <mailto:brendan.tildes...@openmailbox.org>> ezt írta (időpont: 2018.
> júl. 30., H, 17:44):
>  Could you elaborate on this a bit more?
> i.e. what was the commit fixing the issue?
> on which branch?
> or we just don't notice the behavior any more?
> Also, please add the title of the bug, so we can see what bug is
> closed without visiting the bugtracker.
>
Sorry, it's the first time I've closed a bug, I just learnt it could be
done by sending and email to NUMBER-close@... and sent a blank email.

The fix is contained in the commits

17a21bcf316d11bdf54ec2483abe15f60dbd7cb0

e8ec2dda08d36f3a8d17f840980ea82585d1fc38

and include only changes to the ecryptfs-utils package. I tried my best
to find all cases in the source with hard-coded paths. Feel free to
inspect it further if you like. For me at least, I'm able to mount my
ecryptfs folder with these patches.

bug#32313: Failed to boot after reconfiguring with a btrfs drive.

[Brendan Tildesley]

On 08/01/18 06:38, Danny Milosavljevic wrote:
> On Tue, 31 Jul 2018 01:25:22 +1000
> Brendan Tildesley  wrote:
>
>> I have a second btrfs drive that I normally manually mount as /mnt/1tb.
>> I decided to add it to my system config and it when I reconfigure it
>> mounts the drive correctly, but when I reboot I get the error:
>>
>> WARNING: failed to open /dev/btrfs-control, skipping device
>> registration: no such file or directory
>>
>> ERROR: there are 1 errors while registering devices
>>
>> File system check on /dev/sda1 failed; spawning Bourne-like REPL
> Please write ,bt and paste the output here
>
,bt shows that there is "nothing to debug"

bug#32313: Failed to boot after reconfiguring with a btrfs drive.

[Brendan Tildesley]

On 07/31/18 02:55, Danny Milosavljevic wrote:
> Hi,
>
> hmm, where's the "file-systems" form in your system config?
>
> The first important part is whether your file-system entry is 
> needed-for-boot? or not.
>
Sorry, I forgot to un-kill it before copying the whole definition. It's here

(file-systems
   (cons*
    (file-system
  (device (file-system-label "1tb"))
  (mount-point "/mnt/1tb/")
  (type "btrfs"))
    (file-system
  ;;(device
"/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S2PWNX0J204086P-part1")
  (device (file-system-label "1ssd"))
  (mount-point "/")
  (type "ext4"))
    %base-file-systems))

bug#30224: (no subject)

[Brendan Tildesley]

bug#32313: Failed to boot after reconfiguring with a btrfs drive.

[Brendan Tildesley]

I have a second btrfs drive that I normally manually mount as /mnt/1tb.
I decided to add it to my system config and it when I reconfigure it
mounts the drive correctly, but when I reboot I get the error:

WARNING: failed to open /dev/btrfs-control, skipping device
registration: no such file or directory

ERROR: there are 1 errors while registering devices

File system check on /dev/sda1 failed; spawning Bourne-like REPL

Here is my system config:

(use-modules (gnu)
 (gnu system nss)
 (guix packages))
(use-service-modules desktop
 ssh
 admin
 mcron
 xorg
 virtualization
 cups
 sddm
 networking
 ;; avahi
 ;; dbus
 )
(use-package-modules certs
 gnome
 bootloaders
 cups
 ;; libusb
 ;; networking
 )

(operating-system
  (kernel-arguments '("modprobe.blacklist=pcspkr,snd_pcsp"))
  (host-name "ui")
  (timezone "Australia/Hobart")
  (locale "en_AU.utf8")

  ;; (locale-definitions '("zh_TW.utf8"
  ;;   "zh_CN.utf8"
  ;;   "ja_JP.utf8"
  ;;   "en_DK.UTF-8"
  ;;   ))

  ;; Assuming /dev/sdX is the target hard disk, and "my-root"
  ;; is the label of the target root file system.
  (bootloader
   (grub-configuration
    ;;(device "/dev/disk/by-id/ata-Samsung_SSD_850_EVO_1TB_S2PWNX0J204086P")
    (target "/dev/sdc")))

 

  (users
   (cons*
    (user-account
 (name "b")
 (comment "ore")
 (group "users")
 (supplementary-groups
  '("wheel"   ; To use sudo
    "netdev"
    "audio"   ; To play sound
    "video" ; To access the webcam
    "kvm"
    "disk"
    ;; lp lpadmin, seen in other's configs
    ))
 (home-directory "/home/b"))

    (user-account
 (name "b2")
 (comment "ore too")
 (group "users")
 (supplementary-groups
  '("wheel"   ; To use sudo
    "netdev"
    "audio"   ; To play sound
    "video")) ; To access the webcam
 (home-directory "/home/b2"))
    %base-user-accounts))

  ;;System-wide packages.
  (packages
   (cons
    (specification->package+output "glib" "bin")
    (append
 (map specification->package
  '( "nss-certs" ; For HTTPS access
 "gvfs"  ; For user mounts
 ;"dconf" ; NOT SURE IF THIS IS ALSO NEEDED
 "glibc-locales" ; Locales

 "ecryptfs-utils"
 "exfat-utils"
 "ntfs-3g"
 "btrfs-progs"

 "setxkbmap" ; keyboard mappings
 "xmodmap"

 "i3-wm" "i3status";; "dmenu" ; tiling wm
 "dbus" "pcmanfm"
 ;; We cannot rsync over ssh unless rsync is in the system
profile
 "rsync"))
 %base-packages)))

  (services
   (cons*
    (console-keymap-service "en-latin9")
   
    ;; OpenSSH
    (service openssh-service-type
 (openssh-configuration
  (port-number 22)))
    ;; Probably does something useful
    (service rottlog-service-type)

    (service tor-service-type)
    ;; from the manual, this apparently this lets us emulate building on arm
    (service qemu-binfmt-service-type
 (qemu-binfmt-configuration
  (platforms (lookup-qemu-platforms "arm"))
  (guix-support? #t)))

    ;; Printer stuff
    (service cups-service-type
 (cups-configuration
  (web-interface? #t)
  (extensions
   (list cups-filters hplip

    ;; Colemak settings for Xorg that are valid for the login manager
    (let ((colemak
   "Section \"InputClass\"
    Identifier \"evdev keyboard catchall\"
    Driver \"evdev\"
    MatchIsKeyboard \"on\"
    Option \"xkb_layout\" \"us\"
    Option \"xkb_variant\" \"colemak\"
EndSection"))
 
  (modify-services %desktop-services
    ;; (remove-services
    ;;  (list
    ;;   ;ntp-service-type
    ;;   screen-locker-service-type)
    ;;  %desktop-services)

    ;; Enable Colemak layout in Slim login
    (slim-service-type config =>
   (slim-configuration
    (inherit config)
    (startx (xorg-start-command
 #:configuration-file
 (xorg-configuration-file
  #:extra-config
  (list colemak))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

bug#31773: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Brendan Tildesley]

On 06/10/18 19:01, Christopher Baines wrote:
> Hey,
>
> The Guix package for duplicity is failing to build, and I was wondering
> if there is a fix already? I've had a look on Launchpad, but didn't spot
> anything.
>
> [...]
The problem is due to changes in GPG causing it to error on some of the 
very old files included in the tests. The fix is already upstream and
will be in the next release. Somebody can include a patch if they'd like
to get it working asap. I don't know how far away the next release is:
https://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/revision/1358

bug#30224: 'mount -t ecryptfs ...' command refers to /bin/mount, bin/umount, etc

[brendan . tildesley]

I noticed this a while ago but probably won't get around to fixing it, so I'm 
just posting a bug report.
-
b@ui ~$ sudo mount -t ecryptfs encrypted-dir mount-dir
Passphrase:
Select cipher:
[...]
Selection [aes]:
Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [...]:
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=[...]
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=[...]
Failed to execute /bin/mount command: No such file or directory
Error mounting eCryptfs: [-2] No such file or directory
Check your system logs; visit 
-


There are many references  to /bin/ in the ecryptfs source code, even including 
 /bin/umount. for example:

-
b@ui ~/temp/ecryptfs-utils-111$ ag exec.*bin/
src/utils/mount.ecryptfs.c
417:execl("/bin/mount", "mount", "-i", "--no-canonicalize", "-t", 
"ecryptfs", fullpath_source, fullpath_target, "-o", opts, NULL);
421:perror("Failed to execute /bin/mount command");

src/desktop/ecryptfs-mount-private.desktop.in
4:Exec=/usr/bin/ecryptfs-mount-private

src/desktop/ecryptfs-setup-private.desktop.in
4:Exec=/usr/bin/ecryptfs-setup-private

src/utils/mount.ecryptfs_private.c
833:execl("/bin/umount", "umount", "-i", "-l", ".", NULL);

src/pam_ecryptfs/pam_ecryptfs.c
375:execl("/sbin/mount.ecryptfs_private",
389:execl("/sbin/umount.ecryptfs_private",

-

bug#27096: guix package -i ... fails when the internet is disconnected

[Brendan Tildesley]

Ludovic Courtès 於 2017-05-29 06:39 寫道:
> Hi Brendan,
>
> Brendan Tildesley <brendan.tildes...@openmailbox.org> skribis:
>
>> On GuixSD, I ran the following install command 3 times. The second time,
>> it showed "nothing to be done" as expected. However after that, I
>> disconnected my internet and ran it again with different results
>> including a guile type error. Just because there was no internet
>> connection, guix tries to download a variety of packages even though it
>> theoretically shouldn't need anything, and fails to handle the case
>> where there is no internet connection and a #f is returned somewhere in
>> the code. I think guix development has taken for granted that one always
>> has an internet connection. Some hackers may wish to try out hacking on
>> Guix for a few hours without an internet connection and see what doesn't
>> work.
> I even do that on the train from time to time.  :-)
>
>> [...]
> So you run the exact same command twice in a row and the second one
> starts downloading things, right?  Did you run ‘guix gc’ in the meantime
> or something?
No, I just noticed it when my connection failed, so I reproduced it by
running it with my internet on, pulling the cable out and running it
again immediately, and this is what happened.
>> Backtrace:
>>1 (primitive-load "/gnu/store/fza7573wpfm3alzdnnfw4g6f1ww…")
>> In guix/ui.scm:
>>1264:8  0 (run-guix-command _ . _)
>>
>> guix/ui.scm:1264:8: In procedure run-guix-command:
>> guix/ui.scm:1264:8: In procedure struct_vtable: Wrong type argument in
>> position 1 (expecting struct): #f
> That may come from (guix scripts substitute), but not sure where.
>
> Thanks,
> Ludo’.

bug#27096: guix package -i ... fails when the internet is disconnected

[Brendan Tildesley]

On GuixSD, I ran the following install command 3 times. The second time,
it showed "nothing to be done" as expected. However after that, I
disconnected my internet and ran it again with different results
including a guile type error. Just because there was no internet
connection, guix tries to download a variety of packages even though it
theoretically shouldn't need anything, and fails to handle the case
where there is no internet connection and a #f is returned somewhere in
the code. I think guix development has taken for granted that one always
has an internet connection. Some hackers may wish to try out hacking on
Guix for a few hours without an internet connection and see what doesn't
work.



b@ui ~$ guix package -i stellarium calibre icecat  duplicity mpv vlc
audacity transmission 0ad qtox weechat terminology leafpad --fallback
The following packages will be upgraded:
   stellarium0.15.1 → 0.15.1   
/gnu/store/qyxkrm2pawcl0lhkzhc5cm0zxzbph6xj-stellarium-0.15.1
   calibre2.85.1 → 2.85.1   
/gnu/store/igjgzg8qcss2wn9m4q7p4jz0w4d4cwp3-calibre-2.85.1
   icecat52.1.0-gnu1 → 52.1.0-gnu1   
/gnu/store/nb64j11jys7ijzlb4a5swgqmw228gjs9-icecat-52.1.0-gnu1
   duplicity0.7.12 → 0.7.12   
/gnu/store/sysrzmlsrrdprgv59f3g81lsxhfz70cv-duplicity-0.7.12
   mpv0.25.0 → 0.25.0   
/gnu/store/0pcmgd24v7p0wmccwsan1xw88dhkz4jl-mpv-0.25.0
   vlc2.2.6 → 2.2.6   
/gnu/store/hysbc89y541kwdrh5kr63xs2z6xfc3lk-vlc-2.2.6
   audacity2.1.3 → 2.1.3   
/gnu/store/vlp9fmbfzc6bxvcwkfns4m78wl1ai45i-audacity-2.1.3
   transmission2.92 → 2.92   
/gnu/store/9rw82dip670864ijy06k62jd1py2bfwb-transmission-2.92
   0ad0.0.21-alpha → 0.0.21-alpha   
/gnu/store/iikijc3g14k8lscjzqg7g7ca7ffn-0ad-0.0.21-alpha
   qtox1.10.1 → 1.10.1   
/gnu/store/g7qxq694lns87gmcz7jxs7mqs0vngc4v-qtox-1.10.1
   weechat1.8 → 1.8   
/gnu/store/8p0dkk2l4zh3gq185hjpbn1sf4z1nrbr-weechat-1.8
   terminology1.0.0 → 1.0.0   
/gnu/store/05s9nwhf6m7zq4gvx4kb9djcfqj401cs-terminology-1.0.0
   leafpad0.8.18.1 → 0.8.18.1   
/gnu/store/d630r7id7rr2r2wfdm4wc2jxlpv2m9k2-leafpad-0.8.18.1

nothing to be done
b@ui ~$ guix package -i stellarium calibre icecat  duplicity mpv vlc
audacity transmission 0ad qtox weechat terminology leafpad --fallback
The following packages will be upgraded:
   stellarium0.15.1 → 0.15.1   
/gnu/store/qyxkrm2pawcl0lhkzhc5cm0zxzbph6xj-stellarium-0.15.1
   calibre2.85.1 → 2.85.1   
/gnu/store/igjgzg8qcss2wn9m4q7p4jz0w4d4cwp3-calibre-2.85.1
   icecat52.1.0-gnu1 → 52.1.0-gnu1   
/gnu/store/nb64j11jys7ijzlb4a5swgqmw228gjs9-icecat-52.1.0-gnu1
   duplicity0.7.12 → 0.7.12   
/gnu/store/sysrzmlsrrdprgv59f3g81lsxhfz70cv-duplicity-0.7.12
   mpv0.25.0 → 0.25.0   
/gnu/store/0pcmgd24v7p0wmccwsan1xw88dhkz4jl-mpv-0.25.0
   vlc2.2.6 → 2.2.6   
/gnu/store/hysbc89y541kwdrh5kr63xs2z6xfc3lk-vlc-2.2.6
   audacity2.1.3 → 2.1.3   
/gnu/store/vlp9fmbfzc6bxvcwkfns4m78wl1ai45i-audacity-2.1.3
   transmission2.92 → 2.92   
/gnu/store/9rw82dip670864ijy06k62jd1py2bfwb-transmission-2.92
   0ad0.0.21-alpha → 0.0.21-alpha   
/gnu/store/iikijc3g14k8lscjzqg7g7ca7ffn-0ad-0.0.21-alpha
   qtox1.10.1 → 1.10.1   
/gnu/store/g7qxq694lns87gmcz7jxs7mqs0vngc4v-qtox-1.10.1
   weechat1.8 → 1.8   
/gnu/store/8p0dkk2l4zh3gq185hjpbn1sf4z1nrbr-weechat-1.8
   terminology1.0.0 → 1.0.0   
/gnu/store/05s9nwhf6m7zq4gvx4kb9djcfqj401cs-terminology-1.0.0
   leafpad0.8.18.1 → 0.8.18.1   
/gnu/store/d630r7id7rr2r2wfdm4wc2jxlpv2m9k2-leafpad-0.8.18.1

Backtrace:
   1 (primitive-load "/gnu/store/fza7573wpfm3alzdnnfw4g6f1ww…")
In guix/ui.scm:
   1264:8  0 (run-guix-command _ . _)

guix/ui.scm:1264:8: In procedure run-guix-command:
guix/ui.scm:1264:8: In procedure struct_vtable: Wrong type argument in
position 1 (expecting struct): #f
Downloading
https://mirror.hydra.gnu.org/guix/nar/6jr66c4dj5sgqi3qzqnqndz25vg1lpkd-alabaster-0.7.9.tar.gz
(10KiB installed)...
guix substitute: error: host name lookup error: Name or service not known
Downloading
https://mirror.hydra.gnu.org/guix/nar/gzip/529jffxlnzni6gnknxwj5aq5dqnnl5yr-python2-markupsafe-0.23
(87KiB installed)...
guix substitute: error: host name lookup error: Name or service not known
Downloading
https://mirror.hydra.gnu.org/guix/nar/gzip/mindszikwbq6q8kk43wlyhifw97lyzn7-python2-requests-2.13.0
(2.9MiB installed)...
guix substitute: error: host name lookup error: Name or service not known
Backtrace:
   1 (primitive-load "/gnu/store/fza7573wpfm3alzdnnfw4g6f1ww…")
In guix/ui.scm:
   1264:8  0 (run-guix-command _ . _)

guix/ui.scm:1264:8: In procedure run-guix-command:
guix/ui.scm:1264:8: In procedure struct_vtable: Wrong type argument in
position 1 (expecting struct): #f
Downloading
https://mirror.hydra.gnu.org/guix/nar/gzip/nhs83fqs3z54876rw4vakifk0czlrp95-pcre-8.40-bin
(209KiB installed)...
guix substitute: error: host name lookup error: Name or service not known
Downloading