bug#71808: Fwd: same package name for unrelated packages

[Andy Tai]

in GNU Guix today:

$ guix show volk
name: volk
version: 3.0.0
outputs:
+ out: everything
systems: x86_64-linux i686-linux
dependencies: boost@1.80.0 python-mako@1.2.2 python-wrapper@3.10.7
location: gnu/packages/engineering.scm:1381:2
homepage: https://www.libvolk.org/
license: ASL 2.0, LGPL 3+
synopsis: Vector-Optimized Library of Kernels
description: VOLK (Vector-Optimized Library of Kernels) contains procedures with
+ machine-specific optimizations for mathematical functions.  It also provides a
+ machine-independent interface to select the best such procedures to
use on a given system.

name: volk
version: 1.3.280.0
outputs:
+ out: everything
systems: x86_64-linux i686-linux
dependencies: vulkan-headers@1.3.280.0
location: gnu/packages/vulkan.scm:565:2
homepage: https://github.com/zeux/volk
license: Expat
synopsis: Meta loader for Vulkan API
description: Volk is a meta-loader for Vulkan.  It allows you to
dynamically load entrypoints
+ required to use Vulkan without linking the Vulkan loader.
Additionally, volk simplifies the
+ use of Vulkan extensions by automatically loading all associated
entrypoints.  Finally, volk
+ enables loading Vulkan entrypoints directly from the driver which
can increase performance by
+ skipping loader dispatch overhead.


One would assume this can break things

bug#68439: [PATCH v2] gnu: icewm: Update to 3.4.6

[Andy Tai]

* gnu/packages/wm.scm (icewm): Update to 3.4.6
  [arguments]: Remove the deletion of gmo files as
  they are not regenerated correctly.

Change-Id: Ieff1fc5417cfe164fa7886774e8855fd95248c8f
---
 gnu/packages/wm.scm | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 7d21d04094..65378040e5 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -797,7 +797,7 @@ (define-public i3lock-fancy
 (define-public icewm
   (package
 (name "icewm")
-(version "3.4.5")
+(version "3.4.6")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -805,7 +805,7 @@ (define-public icewm
 version "/icewm-" version ".tar.lz"))
   (sha256
(base32
-"1wd5k0whh2b43a72223cy19pwc29fhrhd2dnc61fha2y5ndgw6ld"
+"1j4jd1fim12h8ry7jkx6y298kyn63pabih1m61rljbzvr3lyy1db"
 (build-system gnu-build-system)
 (native-inputs (list pkg-config))
 (inputs (list fontconfig
@@ -830,13 +830,6 @@ (define-public icewm
 (arguments
  (list #:phases
#~(modify-phases %standard-phases
-   (add-after 'unpack 'remove-gmo-files
- ;; gmo files are generated from .po files
- ;; so remove them before build to make sure
- ;; they are re-generated if needed
- (lambda _
-   (for-each delete-file
- (find-files "po" "\\.gmo$"
(add-after 'unpack 'skip-failing-test
  ;; strtest.cc tests failing due to $HOME and /etc setup
  ;; difference under guix

base-commit: 1415ea78c15043ddc9d3d3dfe9219a4160493bf1
-- 
2.34.1

bug#68439: icewm do not install MO files.

[Andy Tai]

I remember that was left over and kept from previous patches. If they
are not rebuilt there is a bug

I will remove these lines in the next update to the next version,
unless there is objection.

On Sat, Jan 13, 2024 at 7:08 PM Feng Shu  wrote:
>
>
> Hello:
>
> At the moment: icewm do not install MO files to
> 'share/locale//LC_MESSAGES', gmo files in tarball are removed, but
> do not re-generated, I try to add gettext-minimul to inputs, but can not
> re-generate gmo files successfully.
>
> Any reason we should remove gmo files in tarball?
>
> ```
>(add-after 'unpack 'remove-gmo-files
>  ;; gmo files are generated from .po files
>  ;; so remove them before build to make sure
>  ;; they are re-generated if needed
>  (lambda _
>(for-each delete-file
>  (find-files "po" "\\.gmo$"
> ```
>
>
> --
>

bug#65723: GCC/Clang toolchain package ld wrapper on utf8 paths with LANG enviroment variable not utf8

[andy]

This happens with both gcc-toolchain 12.3.0 or clang-toolchain 15.0.7.

$ echo $PWD
/home/testuser123/你好
$ echo $LANG
en_US.utf8
$ guile --version
guile (GNU Guile) 3.0.9
$ guix --version
guix (GNU Guix) 3335903d7d6d7ee93436d046b3037d433d06372b
$ ld --version
GNU ld (GNU Binutils) 2.38
...
$ clang --version
clang version 15.0.7
Target: x86_64-unknown-linux-gnu
...


To recreate write a hello world in C or C++ into main.cpp.


$ clang -c main.cpp -o main.o
$ ld main.o /gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so
This works fine
$ LANG="" ld main.o 
/gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so
And the above
$ ld main.o /gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so -o 
"$PWD/a.out"
And this works
But below fails
$ LANG="" ld main.o 
/gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so -o "$PWD/a.out"
ld: cannot open output file /home/testuser123/??/a.out: No such file or 
directory


The gcc-toolchain and clang-toolchain seem to have identical "ld" files as 
"diff"ing them shows no difference. ld is a Guile file so I would assume 
somehow the script somehow looks at the LANG environment variable which messes 
up the character encodings of paths and replacing them with the question marks.


The ld wrapper depending on the LANG environment variable having utf8 for 
handling filenames has some problems. Some build systems like Rust's Cargo 
unset the LANG environment variable, causing ld to output those question marks 
in place of the utf8 bytes, which will break for any path that has Unicode. I 
don't think it is intended behavior for a linker to depend on the LANG to 
handle filenames.

bug#65391: People need to report failing builds even

[Andy Tai]

On 2023-08-27 02:13, 宋文武 wrote:
> Maybe we can automatically report the failures as bugs, say every 7
> days, and remove a package if it still fail to build in 90 days?

Hi, maybe build failures should be limited to certain platforms that can
cause this treatment, such as (32-bit) x86, x86-64 and arm-64, so build
failures on other platforms would not make a package removed if build
failure not fixed

The reason is that most people do not have arm32, PowerPC or Risc-V
hardware so these platforms may be more likely to suffer build failures and
for most people x86 and 64-bit arm platforms are what they use.  Build
failures on the less common platforms can be fixed if there are people with
resources and interests, and wanting to fix them

bug#63526: ping on a build fix for a build failure (main branch)

[Andy Tai]

I did contact upstream, no response

On Fri, Jun 9, 2023 at 4:07 AM Andreas Enge  wrote:
>
> Hello Andy,
>
> Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> > Hi, following previous comments (thanks) I have submitted a patch to
> > correctly fix a build failure due to compiler warnings, instead of
> > avoiding not building tests, on this Guix bug issue:
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
> > Please review the patch (which shall be a simple and low risk fix).  Thanks!
>
> I have reworked a bit the punctuation of the commit message, shortened
> the patch file name and pushed. By this I am closing the two corresponding
> bug reports (it would have been enough to send a second version of the
> patch to the first bug).
>
> Did you contact upstream? Looking at the test, it looked wrong before and
> after your patch...
> if (len < token->data.character.len) {
>hubbub_token t = { 0 };
>t.type = HUBBUB_TOKEN_CHARACTER;
>t.data.character.ptr += len;
>t.data.character.len -= len;
> ...
> Adding to a previously undefined, now 0 pointer .ptr raised a warning
> for a reason, I think; and it looks like the t.data maybe should be
> token->data. But it is quite possible that this branch is not even
> reached by the test.
>
> Andreas
>


-- 
Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010
Year 2023 民國112年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

bug#63526: [PATCH v2] gnu (hubbub): Fix build

[Andy Tai]

Fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526

* gnu/packages/web.scm (hubbub): [source](patches): Add patch to fix build.
* 
gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch:
 New file
* gnu/local.mk  (dist_patch_DATA): Add it.
---
 gnu/local.mk  |  2 +
 ...aybe-uninitialized-build-failure-wit.patch | 40 +++
 gnu/packages/web.scm  |  4 +-
 3 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 
gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 18e8235140..e2b42ca676 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -58,6 +58,7 @@
 # Copyright © 2022 jgart 
 # Copyright © 2023 Zheng Junjie <873216...@qq.com>
 # Copyright © 2023 Ivana Drazovic 
+# Copyright © 2023 Andy Tai 
 #
 # This file is part of GNU Guix.
 #
@@ -1349,6 +1350,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/http-parser-CVE-2020-8287.patch \
   %D%/packages/patches/htslib-for-stringtie.patch  \
   %D%/packages/patches/hubbub-sort-entities.patch  \
+  
%D%/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
 \
   %D%/packages/patches/hueplusplus-mbedtls.patch   \
   %D%/packages/patches/hurd-add-without-rump-configure-option.patch \
   
%D%/packages/patches/hurd-fix-types-of-read-write-and-readables-methods-2.patch 
\
diff --git 
a/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
 
b/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
new file mode 100644
index 00..6f289a770e
--- /dev/null
+++ 
b/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
@@ -0,0 +1,40 @@
+From 69d81a8a4d4c223aad67cde0fdf64d64351b9802 Mon Sep 17 00:00:00 2001
+From: Andy Tai 
+Date: Sat, 27 May 2023 00:01:34 -0700
+Subject: [PATCH] prevent -Werror=maybe-uninitialized build failure with gcc 11
+ when building tests tokeniser2 and tokeniser3
+
+---
+ test/tokeniser2.c | 2 +-
+ test/tokeniser3.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/test/tokeniser2.c b/test/tokeniser2.c
+index c8ab9c0..4caae38 100644
+--- a/test/tokeniser2.c
 b/test/tokeniser2.c
+@@ -438,7 +438,7 @@ hubbub_error token_handler(const hubbub_token *token, void 
*pw)
+   /* Expected token only contained part of the data
+* Calculate how much is left, then try again with
+* the next expected token */
+-  hubbub_token t;
++  hubbub_token t = { 0 };
+ 
+   t.type = HUBBUB_TOKEN_CHARACTER;
+   t.data.character.ptr += len;
+diff --git a/test/tokeniser3.c b/test/tokeniser3.c
+index e33d018..b3be901 100644
+--- a/test/tokeniser3.c
 b/test/tokeniser3.c
+@@ -447,7 +447,7 @@ hubbub_error token_handler(const hubbub_token *token, void 
*pw)
+   /* Expected token only contained part of the data
+* Calculate how much is left, then try again with
+* the next expected token */
+-  hubbub_token t;
++  hubbub_token t = { 0 };
+ 
+   t.type = HUBBUB_TOKEN_CHARACTER;
+   t.data.character.ptr += len;
+-- 
+2.40.1
+
diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 3af4aa0b8d..387ceac058 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -5242,7 +5242,9 @@ (define-public hubbub
(sha256
 (base32
  "1dimfyblmym98qa1b80c5jslv2zk8r44xbdrgrsrw1n9wr9y4yly"))
-   (patches (search-patches "hubbub-sort-entities.patch"
+   (patches (search-patches
+ "hubbub-sort-entities.patch"
+ 
"hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch"
 (build-system gnu-build-system)
 (native-inputs
  (list netsurf-buildsystem

base-commit: b96b82bcd4bc24529941ff74a91432481f1a71b5
-- 
2.40.1

bug#63526: [PATCH] gnu: hubbub: Disable building tests

[Andy Tai]

Will do. Thanks

On Thu, May 25, 2023 at 6:35 AM Bruno Victal  wrote:
>
> On 2023-05-25 14:02, Greg Hogan wrote:

>
> > Based on the error, can we instead add
> > "-Wno-error=maybe-uninitialized" to the configure-flags?
>
> I'd report this upstream first, it can be the case that the error
> (which is being flagged by the compiler) is unmasking a real bug
> upstream.
>

bug#63526: [PATCH] gnu: hubbub: Disable building tests

[Andy Tai]

Fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526

* gnu/packages/web.scm (hubbub): [arguments] (tests): Set to #f to disable test 
build
---
 gnu/packages/web.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index fe52f673e2..203e3283cf 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -5252,7 +5252,9 @@ (define-public hubbub
perl))
 (propagated-inputs
  (list libparserutils)) ;for libhubbub.pc
-(arguments netsurf-buildsystem-arguments)
+(arguments
+ `(#:tests? #f  ;build error in building tests with gcc 11; skip for now
+   ,@netsurf-buildsystem-arguments))
 (home-page "https://www.netsurf-browser.org/projects/hubbub/;)
 (synopsis "HTML5 compliant parsing library")
 (description

base-commit: 3abcf1663b86bc075e29563140698d8bfae44992
-- 
2.40.1

bug#63526: hubbub build failure when doing guix package -u

[Andy Tai]

key lines:

COMPILE: test/tokeniser2.c
 COMPILE: test/tokeniser3.c
 COMPILE: test/tree.c
 COMPILE: test/tree2.c
 COMPILE: test/tree-buf.c
test/tokeniser2.c: In function ‘token_handler’:
test/tokeniser2.c:444:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
  444 | t.data.character.ptr += len;
  |  ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
  441 | hubbub_token t;
  |  ^
test/tokeniser2.c:445:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
  445 | t.data.character.len -= len;
  |  ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
  441 | hubbub_token t;
  |  ^
test/tokeniser3.c: In function ‘token_handler’:
test/tokeniser3.c:453:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
  453 | t.data.character.ptr += len;
  |  ^~
test/tokeniser3.c:450:38: note: ‘t’ declared here
  450 | hubbub_token t;
  |  ^
test/tokeniser3.c:454:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
  454 | t.data.character.len -= len;
  |  ^~
test/tokeniser3.c:450:38: note: ‘t’ declared here
  450 | hubbub_token t;
  |  ^
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_entities
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_csdetect
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_parser
cc1: all warnings being treated as errors
make: *** 
[/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem/makefiles/Makefile.top:631:
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser2.o]
Error 1
make: *** Waiting for unfinished jobs
cc1: all warnings being treated as errors
make: *** 
[/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem/makefiles/Makefile.top:631:
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser3.o]
Error 1

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test" "-j"
"31" "COMPONENT_TYPE=lib-shared" "CC=gcc" "BUILD_CC=gcc"
"PREFIX=/gnu/store/7fn6jxg1vpadm8rpa8rzbwqgipxlwync-hubbub-0.3.7"
"NSSHARED=/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.2 seconds
command "make" "test" "-j" "31" "COMPONENT_TYPE=lib-shared" "CC=gcc"
"BUILD_CC=gcc" "PREFIX=/gnu/store/7fn6jxg1vpadm8rpa8rzbwqgipxlwync-hubbub-0.3.7"
"NSSHARED=/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem"
failed with status 2

bug#63456: [PATCH] gnu: mesa-opencl: Remove reference to patch

[Andy Tai]

Fixes .

* gnu/packages/patches/mesa-opencl-all-targets.patch: Removed

* gnu/local.mk: Remove reference to mesa-opencl-all-targets.patch

* gnu/packages/gl.scm (mesa-opencl)[source]::Remove patch application of
mesa-opencl-all-targets.patch
---
 gnu/local.mk  |  1 -
 gnu/packages/gl.scm   |  4 +--
 .../patches/mesa-opencl-all-targets.patch | 25 ---
 3 files changed, 1 insertion(+), 29 deletions(-)
 delete mode 100644 gnu/packages/patches/mesa-opencl-all-targets.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 73db48f720..73180be88a 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1561,7 +1561,6 @@ dist_patch_DATA = 
\
   %D%/packages/patches/memtest86+-build-reproducibly.patch \
   %D%/packages/patches/mercurial-hg-extension-path.patch   \
   %D%/packages/patches/mercurial-openssl-compat.patch  \
-  %D%/packages/patches/mesa-opencl-all-targets.patch   \
   %D%/packages/patches/mhash-keygen-test-segfault.patch\
   %D%/packages/patches/mia-fix-boost-headers.patch \
   %D%/packages/patches/mia-vtk9.patch  \
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 235b386dad..030c828e5b 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -530,9 +530,7 @@ (define-public mesa-opencl
   (package/inherit mesa
 (name "mesa-opencl")
 (source (origin
-  (inherit (package-source mesa))
-  (patches (cons (search-patch "mesa-opencl-all-targets.patch")
- (origin-patches (package-source mesa))
+  (inherit (package-source mesa
 (arguments
  (substitute-keyword-arguments (package-arguments mesa)
((#:configure-flags flags)
diff --git a/gnu/packages/patches/mesa-opencl-all-targets.patch 
b/gnu/packages/patches/mesa-opencl-all-targets.patch
deleted file mode 100644
index 99d4abcea4..00
--- a/gnu/packages/patches/mesa-opencl-all-targets.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-This patch restores LLVM targets needed for OpenCL, *reverting* this
-upstream commit:
-
-  From 80817b6e344258ac9b955f824ebf9019a0fc1610 Mon Sep 17 00:00:00 2001
-  From: Jesse Natalie 
-  Date: Wed, 18 Nov 2020 18:30:30 -0800
-  Subject: [PATCH] meson: Adjust Clover's required LLVM modules
-
-diff --git a/meson.build b/meson.build
-index 6d1607c35a3..f828eb80faa 100644
 b/meson.build
-+++ a/meson.build
-@@ -1479,10 +1479,9 @@
- endif
- if with_gallium_opencl
-   llvm_modules += [
--'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
--'lto', 'option', 'objcarcopts', 'profiledata'
-+'all-targets', 'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
-+'lto', 'option', 'objcarcopts', 'profiledata',
-   ]
--  llvm_optional_modules += ['frontendopenmp']
- endif
- if with_microsoft_clc
-   llvm_modules += ['target', 'linker', 'irreader', 'option', 'libdriver']

base-commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
-- 
2.39.2

bug#63456: Acknowledgement (mesa build failure at guix package -u)

[Andy Tai]

the actual package failing to build is mesa-opencl, not mesa itself

bug#63456: mesa build failure at guix package -u

[Andy Tai]

When I do guix package -u from the current guix repo,

mesa build fails at  mesa,

key parts of build log:

mesa-23.0.3/subprojects/expat.wrap
mesa-23.0.3/subprojects/perfetto.wrap
mesa-23.0.3/subprojects/zlib.wrap
patching file meson.build
Hunk #1 FAILED at 1479.
1 out of 1 hunk FAILED -- saving rejects to file meson.build.rej
source is at 'mesa-23.0.3'
applying 
'/gnu/store/r0ipng37a0bvfbczhy791ayg4kx1wkld-mesa-opencl-all-targets.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/jz07f808827d1r0wn3rppv2i4lj…")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "mes…") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # ("/gnu/store/r0…"))
In guix/build/utils.scm:
812:6  0 (invoke "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-p…" …)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. :
  program: 
"/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input"
"/gnu/store/r0ipng37a0bvfbczhy791ayg4kx1wkld-mesa-opencl-all-targets.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f

bug#63156: Acknowledgement (guix package -u failure on pyopengl-accelerate-3.1.5)

[Andy Tai]

may be fixed by patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63168

bug#63156: Acknowledgement (guix package -u failure on pyopengl-accelerate-3.1.5)

[Andy Tai]

These may be the key error lines:

gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-fno-semantic-interposition -fPIC
-I/tmp/guix-build-python-pyopengl-accelerate-3.1.5.drv-0/PyOpenGL-accelerate-3.1.5/..
-I/tmp/guix-build-python-pyopengl-accelerate-3.1.5.drv-0/PyOpenGL-accelerate-3.1.5/src
-I/tmp/guix-build-python-pyopengl-accelerate-3.1.5.drv-0/PyOpenGL-accelerate-3.1.5
-I/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10
-c src/vbo.c -o build/temp.linux-x86_64-cpython-310/src/vbo.o
src/vbo.c: In function ‘__pyx_tp_dealloc_17OpenGL_accelerate_3vbo_VBO’:
src/vbo.c:11131:5: error: lvalue required as increment operand
11131 | ++Py_REFCNT(o);
  | ^~
src/vbo.c:11133:5: error: lvalue required as decrement operand
11133 | --Py_REFCNT(o);
  | ^~
src/vbo.c: In function ‘__pyx_tp_dealloc_17OpenGL_accelerate_3vbo_VBOOffset’:
src/vbo.c:11619:5: error: lvalue required as increment operand
11619 | ++Py_REFCNT(o);
  | ^~
src/vbo.c:11621:5: error: lvalue required as decrement operand
11621 | --Py_REFCNT(o);
  | ^~

bug#63156: guix package -u failure on pyopengl-accelerate-3.1.5

[Andy Tai]

doing guix package -u with the guix post merge of core-updates (thus
using the main branch,

gux package -u fails with

| 'build' phase2023-04-28 12:02:50,512 Error: cannot execute signal listener
2023-04-28 12:02:50,512  [Errno 2] No such file or directory: 'python3.9'
\ 'build' phasebuilder for
`/gnu/store/9clhgrmqzlvfawmshalg16imh15sjsmy-python-pyopengl-accelerate-3.1.5.drv'
failed with exit code 1
build of 
/gnu/store/9clhgrmqzlvfawmshalg16imh15sjsmy-python-pyopengl-accelerate-3.1.5.drv
failed
View build log at
'/var/log/guix/drvs/9c/lhgrmqzlvfawmshalg16imh15sjsmy-python-pyopengl-accelerate-3.1.5.drv.bz2'.

last part of this bug log:

In file included from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/unicodeobject.h:1046,
 from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/Python.h:83,
 from src/vbo.c:4:
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/cpython/unicodeobject.h:446:26:
note: declared here
  446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
  |  ^~
src/vbo.c:13032:25: warning: ‘PyUnicode_AsUnicode’ is deprecated
[-Wdeprecated-declarations]
13032 | (PyUnicode_GET_SIZE(**argname) !=
PyUnicode_GET_SIZE(key)) ? 1 :
  | ^
In file included from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/unicodeobject.h:1046,
 from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/Python.h:83,
 from src/vbo.c:4:
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/cpython/unicodeobject.h:580:45:
note: declared here
  580 | Py_DEPRECATED(3.3) PyAPI_FUNC(Py_UNICODE *) PyUnicode_AsUnicode(
  | ^~~
src/vbo.c:13032:25: warning: ‘_PyUnicode_get_wstr_length’ is
deprecated [-Wdeprecated-declarations]
13032 | (PyUnicode_GET_SIZE(**argname) !=
PyUnicode_GET_SIZE(key)) ? 1 :
  | ^
In file included from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/unicodeobject.h:1046,
 from
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/Python.h:83,
 from src/vbo.c:4:
/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/include/python3.10/cpython/unicodeobject.h:446:26:
note: declared here
  446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
  |  ^~
error: command '/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/gcc'
failed with exit code 1
error: in phase 'build': uncaught exception:
%exception #< program: "python" arguments: ("-c" "import
setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
open)(__file__);code=f.read().replace('\\r\\n',
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "build")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `build' failed after 10.4 seconds
command "python" "-c" "import setuptools,
tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
open)(__file__);code=f.read().replace('\\r\\n',
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "build" failed
with status 1

bug#62533: Gnucash: help window cannot show manual or content

[Andy Tai]

OK, that resolved it.  Thanks

On Fri, Apr 14, 2023 at 10:35 PM Maxim Cournoyer
 wrote:
>
> Hi,
>
> Andy Tai  writes:
>
> > guix install, and then run Gnucash (4.11 as the current version).
> > Select "help" from the drop down menu.
> >
> > the help window opens but shows an error that its content cannot be found
>
> Have you 'guix install gnucash:doc' as well ?
>
> --
> Thanks,
> Maxim

bug#62533: Gnucash: help window cannot show manual or content

[Andy Tai]

guix install, and then run Gnucash (4.11 as the current version).
Select "help" from the drop down menu.

the help window opens but shows an error that its content cannot be found

bug#52591: downloading from software archives as default even if version is wrong

[Andy Tai]

On Fri, Dec 17, 2021 at 4:10 PM Tobias Geerinckx-Rice  wrote:
> OK to close as NOTABUG?
sure

bug#52591: downloading from software archives as default even if version is wrong

[Andy Tai]

I was trying to update a package.   I updated the package definition:

---patch--
diff --git a/gnu/packages/mono.scm b/gnu/packages/mono.scm
index 6a7afbafbf..9eeb46ef16 100644
--- a/gnu/packages/mono.scm
+++ b/gnu/packages/mono.scm
@@ -38,7 +38,7 @@ (define-module (gnu packages mono)
 (define-public mono
   (package
 (name "mono")
-(version "4.4.1.0")
+(version "4.8.1")
 (source (origin
   (method url-fetch)
   (uri (string-append
--end of patch--

which at this time shall fail as I have not updated the hash checksum.  If I do

 ./pre-inst-env guix build  -k -K   mono

that actually succeeded but it shall have failed.

This log fragment show what happened:

log fragment--
The following derivations will be built:
   /gnu/store/cdqqdalqwl3m9bhnfyb0v6nfkzvfj0x1-mono-4.8.1.drv
   /gnu/store/qs8jgc33jpwwmzq7ppdiv49qll6q32sl-mono-4.8.1.tar.xz.drv
   /gnu/store/6aih7gpx3p1dpsbdhkri7mk3qqnqkk9x-mono-4.8.1.tar.bz2.drv
building /gnu/store/6aih7gpx3p1dpsbdhkri7mk3qqnqkk9x-mono-4.8.1.tar.bz2.drv...

Starting download of
/gnu/store/l6309vrm95cwpmcwgjj5xgdddp6vfly5-mono-4.8.1.tar.bz2
>From http://download.mono-project.com/sources/mono/mono-4.8.1.tar.bz2...
following redirection to
`https://download.mono-project.com/sources/mono/mono-4.8.1.tar.bz2'...
download failed
"https://download.mono-project.com/sources/mono/mono-4.8.1.tar.bz2;
404 "Not Found"

Starting download of
/gnu/store/l6309vrm95cwpmcwgjj5xgdddp6vfly5-mono-4.8.1.tar.bz2
>From 
>https://ci.guix.gnu.org/file/mono-4.8.1.tar.bz2/sha256/0jibyvyv2jy8dq5ij0j00iq3v74r0y90dcjc3dkspc
fbnn37cphn...
download failed
"https://ci.guix.gnu.org/file/mono-4.8.1.tar.bz2/sha256/0jibyvyv2jy8dq5ij0j00iq3v74r0y
90dcjc3dkspcfbnn37cphn" 404 "Not Found"

Starting download of
/gnu/store/l6309vrm95cwpmcwgjj5xgdddp6vfly5-mono-4.8.1.tar.bz2
>From 
>https://tarballs.nixos.org/sha256/0jibyvyv2jy8dq5ij0j00iq3v74r0y90dcjc3dkspcfbnn37cphn...
download failed
"https://tarballs.nixos.org/sha256/0jibyvyv2jy8dq5ij0j00iq3v74r0y90dcjc3dkspcfbnn37cph
n" 404 "Not Found"

Starting download of
/gnu/store/l6309vrm95cwpmcwgjj5xgdddp6vfly5-mono-4.8.1.tar.bz2
>From 
>https://archive.softwareheritage.org/api/1/content/sha256:165e7686b5cbb1ab671b4cb2069207999c3d700
44002190b6ec84bb1fdf62b4a/raw/...
downloading from
https://archive.softwareheritage.org/api/1/content/sha256:165e7686b5cbb1ab671b4cb2069
207999c3d70044002190b6ec84bb1fdf62b4a/raw/ ...

successfully built
/gnu/store/6aih7gpx3p1dpsbdhkri7mk3qqnqkk9x-mono-4.8.1.tar.bz2.drv
building /gnu/store/qs8jgc33jpwwmzq7ppdiv49qll6q32sl-mono-4.8.1.tar.xz.drv...
mono-4.4.1/
mono-4.4.1/test-driver
mono-4.4.1/support/
mono-4.4.1/support/syslog.c
mono-4.4.1/support/supportw.h


--end of log fratgment--


as seen above, somehow the old version was downloaded from a cached
copy at softwareheritage archives, and it proceeds to build.   This
should not proceed but fail for wrong checksum.

bug#49427: Acknowledgement (grpc build failure)

[Andy Tai]

guix --version
guix (GNU Guix) f7e14782025bf87aaef694a21f34010b1a95f7f6

On Mon, Jul 5, 2021 at 5:25 PM GNU bug Tracking System
 wrote:
>
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 49...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 49427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49427
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems

bug#49427: grpc build failure

[Andy Tai]

on an x86-64 virtual machine (kvm-qemu) running the current Guix,


guix package -u

fails at gprc.  The build log of grpc shows failure:

/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++
-DPB_FIELD_16BIT -Dgrpc___cronet_EXPORTS
-I/tmp/guix-build-grpc-1.16.1.drv-0/source/include
-I/tmp/guix-build-grpc-1.16.1.drv-0/source
-I/tmp/guix-build-grpc-1.16.1.drv-0/source/third_party/address_sorting/include
-I/tmp/guix-build-grpc-1.16.1.drv-0/source/third_party/nanopb
-I/tmp/guix-build-grpc-1.16.1.drv-0/build-shared/gens  -std=c++11
-fPIC   -o 
CMakeFiles/grpc++_cronet.dir/src/core/lib/iomgr/gethostname_sysconf.cc.o
-c 
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/core/lib/iomgr/gethostname_sysconf.cc
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:
In member function ‘virtual grpc::Status
grpc::ChannelzService::GetTopChannels(grpc::ServerContext*, const
grpc::channelz::v1::GetTopChannelsRequest*,
grpc::channelz::v1::GetTopChannelsResponse*)’:
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:41:44:
error: ‘OK’ is not a member of
‘google::protobuf::util::status_internal::Status’
   if (s != google::protobuf::util::Status::OK) {
^~
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:
In member function ‘virtual grpc::Status
grpc::ChannelzService::GetServers(grpc::ServerContext*, const
grpc::channelz::v1::GetServersRequest*,
grpc::channelz::v1::GetServersResponse*)’:
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:57:44:
error: ‘OK’ is not a member of
‘google::protobuf::util::status_internal::Status’
   if (s != google::protobuf::util::Status::OK) {
^~
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:
In member function ‘virtual grpc::Status
grpc::ChannelzService::GetChannel(grpc::ServerContext*, const
grpc::channelz::v1::GetChannelRequest*,
grpc::channelz::v1::GetChannelResponse*)’:
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:73:44:
error: ‘OK’ is not a member of
‘google::protobuf::util::status_internal::Status’
   if (s != google::protobuf::util::Status::OK) {
^~
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:
In member function ‘virtual grpc::Status
grpc::ChannelzService::GetSubchannel(grpc::ServerContext*, const
grpc::channelz::v1::GetSubchannelRequest*,
grpc::channelz::v1::GetSubchannelResponse*)’:
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:89:44:
error: ‘OK’ is not a member of
‘google::protobuf::util::status_internal::Status’
   if (s != google::protobuf::util::Status::OK) {
^~
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:
In member function ‘virtual grpc::Status
grpc::ChannelzService::GetSocket(grpc::ServerContext*, const
grpc::channelz::v1::GetSocketRequest*,
grpc::channelz::v1::GetSocketResponse*)’:
/tmp/guix-build-grpc-1.16.1.drv-0/source/src/cpp/server/channelz/channelz_service.cc:106:44:
error: ‘OK’ is not a member of
‘google::protobuf::util::status_internal::Status’
   if (s != google::protobuf::util::Status::OK) {

bug#49427: Acknowledgement (grpc build failure)

[Andy Tai]

Never mind; after a new

guix pull


this no longer happens.  Please close this bug

On Mon, Jul 5, 2021 at 5:26 PM Andy Tai  wrote:
>
> guix --version
> guix (GNU Guix) f7e14782025bf87aaef694a21f34010b1a95f7f6
>
> On Mon, Jul 5, 2021 at 5:25 PM GNU bug Tracking System
>  wrote:
> >
> > Thank you for filing a new bug report with debbugs.gnu.org.
> >
> > This is an automatically generated reply to let you know your message
> > has been received.
> >
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> >
> > Your message has been sent to the package maintainer(s):
> >  bug-guix@gnu.org
> >
> > If you wish to submit further information on this problem, please
> > send it to 49...@debbugs.gnu.org.
> >
> > Please do not send mail to help-debb...@gnu.org unless you wish
> > to report a problem with the Bug-tracking system.
> >
> > --
> > 49427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49427
> > GNU Bug Tracking System
> > Contact help-debb...@gnu.org with problems

bug#46666: package addition/update patch submissions

[Andy Tai]

Hi, I wonder if package patch submitter can in any way help to speed
up the review of such patches?   I sent some patches some of which
received quick feedback but some seem to be waiting for review for
quiet some time.  I understand all these are done by volunteers.   I
hope package patches can be applied more quickly to make Guix more "up
to date" as a GNU/Linux distribution.  Just curious if there is any
guideline to make package addition or update patches easier for the
reviewers to process, thus speeding up submission application.  Thanks

-- 
Andy Tai, a...@atai.org
Year 2021 民國110年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

bug#35872: messages that are redundant can be eliminated?

[Andy Tai]

Great, thanks.  Minor thing but good for end user experience.

On Tue, Mar 24, 2020 at 10:20 AM Ludovic Courtès  wrote:

> Hi,
>
> Ludovic Courtès  skribis:
>
> >> The following packages will be upgraded:
> >>glibc-locales 2.28 → 2.28
> >> /gnu/store/acl2wxzzkkcjv74rlqswdf9p8pwddlmk-glibc-locales-2.28
> >>meson 0.50.0 → 0.50.0
> >> /gnu/store/zc6r8b1rx3q7lqd8kvvpnm38ky925kmj-meson-0.50.0
> >>guile 2.2.4 → 2.2.4
> >> /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4
> >>font-adobe-source-han-sans:cn 1.004 → 1.004
> >>
> /gnu/store/zf59mg6g0afay9458aarh0rqcz852hhb-font-adobe-source-han-sans-1.004-cn
> >>fontconfig 2.13.1 → 2.13.1
> >> /gnu/store/cnafj0dn09qzy23xnrrjsq5zcdj4739j-fontconfig-2.13.1
> >>epiphany 3.28.3.1 → 3.28.3.1
> >> /gnu/store/n56bdjhqgq7a4a6ndqc3aymyrzvs12hl-epiphany-3.28.3.1
> >>gnome-terminal 3.28.2 → 3.28.2
> >> /gnu/store/r6i61wji0qmv9fqdyk65kx73nzxw8v80-gnome-terminal-3.28.2
> >>
> >> nothing to be done
> >
> > This is a bug where the presence of propagated inputs leads ‘guix
> > upgrade’ to assume something would be upgraded, even when that’s not the
> > case.  This can be reproduced with:
> >
> >   guix install -p foo guile
> >   guix upgrade -p foo
>
> With commit 3e5ab0a7a9399bb098b9ced46bf3cbf4085c6bab, ‘guix upgrade’
> writes “(dependencies changed)” instead of “2.28 → 2.28”, which should
> already be less confusing.
>
> Ludo’.
>


-- 
Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
andytai1010
Year 2019 民國108年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

bug#28211: Stack marking issue in multi-threaded code, 2020 edition

[Andy Wingo]

On Thu 12 Mar 2020 22:59, Ludovic Courtès  writes:

> I think I’ve found another race condition involving stack marking, as a
> followup to <https://issues.guix.gnu.org/issue/28211> (this time on
> 3.0.1+, but the code is almost the same.)
>
> ‘abort_to_prompt’ does this:
>
>   fp = vp->stack_top - fp_offset;
>   sp = vp->stack_top - sp_offset;
>
>   /* Continuation gets nargs+1 values: the one more is for the cont.  */
>   sp = sp - nargs - 1;
>
>   /* Shuffle abort arguments down to the prompt continuation.  We have
>  to be jumping to an older part of the stack.  */
>   if (sp < vp->sp)
> abort ();
>   sp[nargs].as_scm = cont;
>   while (nargs--)
> sp[nargs] = vp->sp[nargs];
>
>   /* Restore VM regs */
>   vp->fp = fp;
>   vp->sp = sp;
>   vp->ip = vra;
>
>
> What if ‘scm_i_vm_mark_stack’ walks the stack right before the ‘vp->fp’
> assignment?  It can determine that one of the just-assigned ‘sp[nargs]’
> is a dead slot, and thus set it to SCM_UNSPECIFIED.

I think you're right here.

Given that the most-recently-pushed frame is marked conservatively, I
think it would be sufficient to reset vp->fp before shuffling stack
args; that would make it so that the frame includes the values to
shuffle, their target locations, and probably some other crap in
between.  Given that marking the crap is harmless, I think that would be
enough.  WDYT?

In a more perfect world, initiating GC should tell threads to reach a
safepoint and mark their own stacks -- preserves thread locality and
prevents this class of bug.  But given that libgc uses signals to stop
threads, we have to be less precise.

Cheers,

Andy

bug#39646: GNOME desktop experience regressions

[Andy Wingo]

Hello all,

In January I upgraded my machine after a long time not doing so.  Mostly
things went fine, which is great!  Some things didn't, though, so I
started looking.

One is that if I Alt-F2 and then run "~/Documents", I expect Nautilus to
open the folder.  Instead Baobab does.  This is because GNOME has
multiple applications are registered for the directory mime type, but
doesn't express a preference between them: it leaves this to the
distro.

That is the reason for the gnome-default-applications package, which
used to be installed as part of (service gnome-desktop-service-type).
However that is no longer the case; since
a8cda7f57992e9ce9ae4a694eba54e3eab42c39b, the "gnome" meta-package,
which is installed by the GNOME desktop, no longer includes this
package.

That led me to look and I think there are a number of other regressions:

  * pinentry-gnome3 is no longer included; this breaks use of GPG and
GNOME

  * font-cantarell and font-dejavu are no longer included; probably not
a good idea?

  * xdg-user-dirs is no longer included, which means that fresh installs
likely no longer create the ~/Documents directories as they should;
see c20cd0d24d9b5e8a47b864db9799e0992ffd44b9

  * I suspect that the removal of gnome-themes-standard and
hicolor-icon-theme may also pose some problems but am not sure.

  * Likewise Guix users of the GNOME desktop service will probably want
pulseaudio and zenity.

Now, I understand wanting the "GNOME" package to reflect exactly what
upstream says is part of GNOME.  Great.  But the desktop is a separate
thing.  Perhaps what we did before was an error in conflating the gnome
meta-package with the desktop; should we define a different metapackage
or package list for the GNOME desktop service?

Regards,

Andy

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Andy Wingo]

On Fri 20 Dec 2019 22:08, Ricardo Wurmus  writes:

> zimoun  writes:
>
>>  - I propose the name "guix shell"
>
> This is not a bad idea, especially considering that “guix environment”
> was meant to get shebang support, so that you could use it as the
> interpreter in a script that handles the environment configuration.
>
> It is also shorter.

I like this idea.  It would also allow us to deprecate "guix
environment" over a period of a year or so, and we can probably show an
equivalent "guix shell" invocation in the deprecation message.

Andy

bug#35872: messages that are redundant can be eliminated?

[Andy Tai]

on my guix installation (on an Ubuntu system but that detail should not
matter)

after running

%guix pull && guix package -u

these were printed:

...
New in this revision:
  ...
hint: Run `guix pull --news' to view the complete list of package changes.

hint: After setting `PATH', run `hash guix' to make sure your shell refers
to `/home/.../.config/guix/current/bin/guix'.

guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following packages will be upgraded:
   glibc-locales 2.28 → 2.28
/gnu/store/acl2wxzzkkcjv74rlqswdf9p8pwddlmk-glibc-locales-2.28
   meson 0.50.0 → 0.50.0
/gnu/store/zc6r8b1rx3q7lqd8kvvpnm38ky925kmj-meson-0.50.0
   guile 2.2.4 → 2.2.4
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4
   font-adobe-source-han-sans:cn 1.004 → 1.004
/gnu/store/zf59mg6g0afay9458aarh0rqcz852hhb-font-adobe-source-han-sans-1.004-cn
   fontconfig 2.13.1 → 2.13.1
/gnu/store/cnafj0dn09qzy23xnrrjsq5zcdj4739j-fontconfig-2.13.1
   epiphany 3.28.3.1 → 3.28.3.1
/gnu/store/n56bdjhqgq7a4a6ndqc3aymyrzvs12hl-epiphany-3.28.3.1
   gnome-terminal 3.28.2 → 3.28.2
/gnu/store/r6i61wji0qmv9fqdyk65kx73nzxw8v80-gnome-terminal-3.28.2

nothing to be done

Now there seems nothing to be done during the guix package -u step so these
messages
glibc-locales 2.28 → 2.28...
were confusing and probably not necessary?

bug#35537: GUIX VM image not found

[Andy Tai]

per manual page
https://www.gnu.org/software/guix/manual/en/html_node/Running-Guix-in-a-VM.html

$ wget https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.0.system.xz
--2019-05-02 22:20:33--
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.0.system.xz
Resolving ftp.gnu.org (ftp.gnu.org)... 209.51.188.20, 2001:470:142:3::b
Connecting to ftp.gnu.org (ftp.gnu.org)|209.51.188.20|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-05-02 22:20:33 ERROR 404: Not Found.


-- 
Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat:
andytai1010
Year 2019 民國108年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Andy Wingo]

Hi!

On Wed 06 Feb 2019 15:48, Ludovic Courtès  writes:

> I drew the conclusion that our syntax parameter is redefined when we
> compile or when we load (guix monads), so there’s a chance that we get
> to see the wrong value when we expand (guix monads) (I’m not entirely
> sure about the exact sequence of events.)

You are a wizard

To be clear, here's the series of events.  Firstly, know that defining a
syntax parameter is like:

  (define name
(make-syntax-transformer 'name 'syntax-parameter (list f)))

So at the top level you end up with an association between a name and a
"syntax transformer" object (see macros.[ch]).  The syntax transformer
object itself consists of its name (for debugging), its syntax type, and
its syntax binding.

For syntax parameters, the binding is a list containing a single
element, the syntax transformer.  This list is later used as a key into
a compile-time environment, as it's a unique object associated with the
syntax parameter.

When (syntax-parameterize ((name f*)) exp) is seen, psyntax will look up
`name' in the current expansion-time environment.  It asserts that the
name is bound to a syntax transformer and that the syntax transformer is
indeed a syntax parameter, and extracts the associated binding `b'.
Keep in bind that `b' is the single-element list containing the
"default" syntax transformer `f'.

syntax-parameterize then does something weird: it adds an association
between the binding value `b' and `f*' to the expand-time environment.
It does this because the `b' is just a fresh object, so it's a unique
key that's usable for associations.  (The way this works is my fault
FWIW.)  To be clear, it doesn't add a new definition of `name'; it
instead establishes a new lexical binding for the unique object `b'.

Then when a use of `name' is seen within `exp', Guile finds that `name'
is a syntax parameter, extracts the binding from the syntax transformer
object, then does a second lookup of that binding.  If it finds
something bound, it uses that, otherwise it uses the default binding.

I think you see the race here.  For an initial state of

(define P (stx-param (list F)))

we have:

   thread A   thread B
time
resolve P |
extract B |
associate B and F*|
  |   define P (stx-param (list F**))
resolve P |
extract B (!) |
resolve B (!) |
see F** instead of F* (!) |
  v

> So I came up with ‘define-syntax-parameter-once’, which is like
> ‘define-once’ but for syntax parameters (note that we can’t use
> ‘define-once’ in ‘define-syntax-parameter-once’ because it expands to a
> reference to NAME, which doesn’t work for a macro):

Your fix is good!  But, it prevents redefinition of syntax parameters.

I would like to work on a solution that instead of using this
double-lookup, simply adds an association between P and F* in the
environment, instead of doing the double-lookup thing.  Probably that
will be 3.0-only.

For 2.2, we can probably update the compiler to trampoline through some
kind of "redefine-syntax" or something that will do (set-car! B F**)
instead of (define P (stx-param B*)).  I.e. redefinition keeps the
unique key there.

Andy

bug#25569: control message for bug #25569

[Andy Patterson]

owner 25569 !

bug#32769: Packaging Next browser (Common Lisp) [work in progress]

[Andy Patterson]

Hi Pierre,

On Mon, 15 Oct 2018 11:34:14 +0200
Pierre Neidhardt  wrote:

> Question: do we need both "out" and "lib" outputs?
> My understanding is that "lib" is useful when one wants to start the
> program from a REPL.  Correct?

"out" will always depend on "lib" for programs.  We want to build it
the same way as other systems so that all of the source for the
program remains inspect-able at run-time, even if it's just a
one-liner.

--
Andy

bug#32769: Packaging Next browser (Common Lisp) [work in progress]

[Andy Patterson]

Hi Pierre,

On Sun, 14 Oct 2018 10:27:46 +0200
Pierre Neidhardt  wrote:

> I won't have time this weekend, so you can go ahead.  Otherwise I'll
> do it next week.

I investigated the problem and I think the build-program procedure is
ok.  It has the option to specify which dependencies you want (maybe
that's what you used?), and I think that's the right option.

You said that you'd tried passing "next" in some way - in this case the
system that the executable will depend on is "next-gtk".  There's a
couple of things here - firstly we need a system for "next" and a
separate one for "next/gtk".  The other is that the resulting systems
will be normalized, so we'll end up with "next-gtk" as the system that
we want to use a dependency for the next-browser executable.

I made these changes and found that I still had problems building
next.  I managed to figure out that it's because next exercises some
less common asd options which makes the bundle that it outputs not
conform to the expectations of the build system.  We'll have to make
some changes to accommodate that, but for now, here's a patch that makes
next build.

I wasn't able to really test whether or not it works - it throws an
exception whenever I press a key.  I was able to find out that its
*active-buffer* variable is nil, which it expects not to be.  If you
want to debug the problems, I recommend doing something like 

$ guix environment --ad-hoc sbcl sbcl-slynk:image next-browser:lib &&
slynk.image
* (slynk:create-server :port 4545)

and then connecting from sly.  You might also pass
(sb-ext:enable-debugger) to the entry program if you prefer that
interface but I haven't tried.  You can then run

|> (asdf:load-system 'next-gtk)
|> (next:start)

to get started.

Hoping that helps,

--
Andy

From 452bb2919ab1db6d819973d655407b1a335b2741 Mon Sep 17 00:00:00 2001
From: Andy Patterson 
Date: Mon, 15 Oct 2018 01:59:25 -0400
Subject: [PATCH] gnu: next-browser: Fix the build.

* gnu/packages/web-browsers.scm (next-browser-core): New variable.
(next-browser): Inherit from next-browser-core.
---
 gnu/packages/lisp.scm |  1 +
 gnu/packages/web-browsers.scm | 59 ---
 2 files changed, 42 insertions(+), 18 deletions(-)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index fcd3156a7..1b390b66d 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -30,6 +30,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix hg-download)
   #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system gnu)
diff --git a/gnu/packages/web-browsers.scm b/gnu/packages/web-browsers.scm
index 0df9180d7..c6844c868 100644
--- a/gnu/packages/web-browsers.scm
+++ b/gnu/packages/web-browsers.scm
@@ -25,6 +25,7 @@
 (define-module (gnu packages web-browsers)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (gnu packages)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages databases)
@@ -324,10 +325,10 @@ access.")
 GUI.  It is based on PyQt5 and QtWebKit.")
 (license license:gpl3+)))
 
-(define-public next-browser
+(define-public next-browser-core
   (let ((commit "ccc289b44610ada4ae9c875910af7720e85b546b"))
 (package
-  (name "next-browser")
+  (name "next-browser-core")
   (version (git-version "0.0.8" "1" commit))
   (source (origin
 (method git-fetch)
@@ -338,11 +339,11 @@ GUI.  It is based on PyQt5 and QtWebKit.")
  (search-patches "next-fix-duplicate-function.patch"))
 (sha256
  (base32
-  "1pcpb274zb0qm26rrglgcgzg2d2v7j2aja5685swwyq9rcqlbdf4"
+  "0rccs9w49p577l12kgykccxrjkr03rf1cfz9mvxbjzc8g82dya2k"))
+(file-name (git-file-name name version
   (build-system asdf-build-system/sbcl)
   ;; TODO: Move Common Lisp libraries to "native-inputs"?
   ;; TODO: Does runtime depends on gsettings-desktop-schemas and 
glib-networking?
-  (outputs '("out" "lib"))
   (inputs
`(("alexandria" ,sbcl-alexandria)
  ("cl-strings" ,sbcl-cl-strings)
@@ -352,26 +353,48 @@ GUI.  It is based on PyQt5 and QtWebKit.")
  ("cl-sqlite" ,sbcl-cl-sqlite)
  ("parenscript" ,sbcl-parenscript)
  ("cl-json" ,sbcl-cl-json)
- ("unix-opts" ,sbcl-unix-opts)
- ("cl-cffi-gtk" ,sbcl-cl-cffi-gtk)
- ("cl-webkit" ,sbcl-cl-webkit)
- ("lparallel" ,sbcl-lparallel)))
+ ("unix-opts" ,sbcl-unix-opts)))
   (argument

bug#32769: Packaging Next browser (Common Lisp) [work in progress]

[Andy Patterson]

Hi,

On Fri, 12 Oct 2018 08:44:35 +0200
Pierre Neidhardt  wrote:

> Let me know if you'd like to do it or if I should give it a shot :)
> 

Please feel free.  I'll probably get around to it this weekend if you
don't have time before then, if that's ok with you.

Thanks,

--
Andy

bug#32769: Packaging Next browser (Common Lisp) [work in progress]

[Andy Patterson]

Hi Pierre,

On Thu, 11 Oct 2018 12:44:43 +0200
Pierre Neidhardt  wrote:

> You were right, this was the issue.  I've posted a patch upstream, it
> should be fixed soon.
> 
> Now Next compiles.  Hurray!!! :D

Nice.

> 
> There is one last step though: the .asd bunble works, but not the
> "build-program".
> See the wip-nextbrowser for what I've tried.  I've re-used the code
> from Stumpwm.
> 
> I narrowed down the issue to the "generate-executable" function:
> 
> [...]
> 
> The problem is that Next's system is called "next/gtk", but we cannot
> use that as an out-file.  If I use something else, say "next", then
> compilation fails with
> 
> --8<---cut here---start->8---
>   Component :NEXT not found, required by #
> --8<---cut here---end--->8---
> 
> I guess there is a flaw in the logic here.  The system name should be
> 
>   #:asd-system-name
> 
> and not
> 
>   (name (basename out-file))
> 
> What shall we do?
> 

That seems right.  I guess we'll need to update that and then maybe
also normalize the generated asd.  Doesn't seem like it'd be too
difficult; there just weren't enough examples of program-generating
systems for this to get caught.

Thanks for the update,

--
Andy

bug#32769: Packaging Next browser (Common Lisp) [work in progress]

[Andy Patterson]

Hi,

On Wed, 10 Oct 2018 15:21:26 +0200
Pierre Neidhardt  wrote:

> The good news: all Next browser dependencies are now packaged under
> the branch wip-nextbrowser.
> 
> The bad news: Next browser fails to build.
> 
> [...]
> 
> Andy, any clue on this?

It's probably the

> ; caught WARNING:
> ;   Duplicate definition for SET-URL-NEW-BUFFER found in one file.

since sbcl (at least on guix?) treats some warnings as errors for some
reason.

Hoping that helps,

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi Pierre,

On Fri, 05 Oct 2018 15:30:03 +0200
Pierre Neidhardt  wrote:

> > In “guile-sly”, for example, the configure script accepts
> > “--with-libfreeimage-prefix=” and “--with-libgslcblas-prefix=”,
> > which are then used to construct a full path to the libraries.  In
> > other cases where the build system does not provide a mechanism for
> > this we need to patch the sources such as in “guile-dbi”.  
> 
> But as far I know of, most Common Lisp packages don't provide a
> configure script.  So can this apply here?
> 

I was suggesting that lisp packages should adopt some configuration
mechanism, either through scripts or by something that asdf could take
care of.  It's something that I think we could discuss with the
upstream communities once we have a good grasp on our use case.

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi Pierre,

I've seen your later e-mail but I'd still like to answer some of your
questions here.

On Thu, 04 Oct 2018 10:37:08 +0200
Pierre Neidhardt  wrote:

> CC-ing Ludovic and Ricardo if they want to chime in.
> 
> Thanks for the feedback, Andy, so invaluable as always.
> 
> > I've been using a cffi consumer for a while now, and my approach for
> > that package was to update references to library and header files
> > with the full paths to their respective store items.  
> 
> Cool!  Can you share this package?  Or provide an example?
> Can't wait to get this up and running!

Sure, I'll append it.

> 
> > Adding to *foreign-library-directories* at compile time may allow a
> > package to compile, but I get the feeling that it may not have the
> > desired effect when you try to load the package later on.  
> 
> Why?  In my experience it works for a compiled Next executable.

I assume that you created this executable by saving the lisp image?  If
that's the case, then it probably saved your
*foreign-library-directories* with the values you added to it.  What
I'm considering is consumers of the libraries which should still work
if you load them from a fresh lisp session with no configuration.

I haven't looked into it yet but I don't think loading the library
would work in that case.

> 
> > I guess another approach we could take if replacement is undesirable
> > would be to modify the cffi package to honour some environment
> > variable for its default, and then add that variable to the search
> > path for cffi.  
> 
> The cffi:*foreign-library-directories* approach got recommended to me
> on the CFFI mailing list.  I find it similar to what you want, a sort
> of environment variable (a search-path global variable).  I haven't
> looked into Nix.
> 
> > I personally tend to favour replacement, but others could chime in
> > here as well since this problem isn't specific to lisp packaging.  
> 
> Could this be automated?  What I like with
> cffi:*foreign-library-directories* is that we could automatically push
> 
> (string-append (assoc-ref inputs "foo") "/lib)
> 
> to it so that packages only have to write something like
> 
> #:cffi-packages (list ,cl-sqlite ,cl-foo...)
> 

Based on what you've written here, I guess that you're thinking of
adding to the *foreign-library-directories* for the consumers of
cffi-based packages.  I thought you meant to do it for those packages
themselves.  I think that might require some packages to propagate the
c libraries that they depend on.

In terms of automating things, it might be possible to do something
with *foreign-library-directories* in the asd files that we generate.

To be honest though, I think the fact that replacement can't be
automated is more of a bug in the libraries' build tooling.  What I'm
thinking of is something like a configure script to set the library
paths before building is done.  I think there are some examples of
guile projects which do just that.  It might be something that we could
discuss with the lisp and asdf community.

--
Andy

---
I think this package might include some dependencies that aren't
upstreamed yet but it should provide the gist of it.

(define sbcl-cl-freetype2
  (let ((revision "1")
(commit "5e4c9ff898f84c888f7e4bfb3402ee35abbf8ad9"))
(package
  (name "sbcl-cl-freetype2")
  (version (string-append "1.1-" revision "." (string-take commit
7))) (source
   (origin
 (method git-fetch)
 (uri
  (git-reference
   (url "https://github.com/rpav/cl-freetype2.git;)
   (commit commit)))
 (sha256
  (base32
"0xmpswm65g5qq85n9nl5blqij2hw4nd4nc143nxhc77w49nf613d")) (file-name
(string-append "cl-freetype2-next-" version "-checkout"
  (build-system asdf-build-system/sbcl)
  (inputs
   `(("freetype" ,freetype)
 ("sbcl-alexandria" ,sbcl-alexandria)
 ("sbcl-cffi" ,sbcl-cffi)
 ("sbcl-trivial-garbage" ,sbcl-trivial-garbage)))
  (native-inputs
   `(("tests:cl-fiveam" ,sbcl-fiveam)
 ("asdf:cl-cffi-grovel" ,sbcl-cffi-grovel)))
  (arguments
   '(#:phases
 (modify-phases %standard-phases
   (add-after 'unpack 'fix-paths
 (lambda* (#:key inputs #:allow-other-keys)
   (define freetype (assoc-ref inputs "freetype"))
   (substitute* "src/ffi/ft2-lib.lisp"
 (("libfreetype" all) (string-append
   freetype "/lib/" all)))
   (substitute* "src/ffi/grovel/grovel-freetype2.lisp"
 (("/usr/include") (string-append freety

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi,

On Wed, 03 Oct 2018 20:34:24 +0200
Pierre Neidhardt  wrote:

> Last (hopefully?) step before getting Next up and running: add
> support for CFFI.
> 
> I've re-used your CFFI package and they seem to work.  Now if I want
> to package cl-sqlite, it fails because sqlite.so cannot be found.
> Indeed, the patch to /gnu/store/...-sqlite.../lib must be added to the
> cffi:*foreign-library-directories* global variable before compiling.
> 
> If I do that from quicklisp, it works.  Now I guess we need to tweak
> asdf-build-system so that packages can specify which paths to add to
> that global variable.

I've been using a cffi consumer for a while now, and my approach for
that package was to update references to library and header files with
the full paths to their respective store items.

Adding to *foreign-library-directories* at compile time may allow a
package to compile, but I get the feeling that it may not have the
desired effect when you try to load the package later on.

I guess another approach we could take if replacement is undesirable
would be to modify the cffi package to honour some environment variable
for its default, and then add that variable to the search path for
cffi. Maybe such a variable already exists, even. I think this is the
approach that Nix takes.

I personally tend to favour replacement, but others could chime in here
as well since this problem isn't specific to lisp packaging.

> 
> Makes sense?
> 
> I've given it a quick shot (patch attached) but then every ASDF build
> fails with
> 
> --8<---cut here---start->8---
> ice-9/boot-9.scm:222:17: In procedure map1:
> Syntax error:
> unknown location: unexpected syntax in form ()
> --8<---cut here---end--->8---
> 

It's confusing, but you either need to double quote the default
argument (e.g. (cffi-foreign-library-directories ''())), or re-quote
the unquoted variable when you pass it along, depending on how you want
users to specify the argument in the package (quoted for the former,
unquoted for the latter).

Hoping that helps,

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi Pierre,

On Tue, 02 Oct 2018 12:24:29 +0200
Pierre Neidhardt  wrote:

> > It'd be nice to have an importer.  Maybe we can use Nix's work to
> > reduce the amount of investigation needed to get there.  
> 
> Absolutely.  ASDF is good enough that the vast majority of CL
> libraries can be packaged without an itch.
> 
> If we could use Quicklisp or
> 
>   http://quickdocs.org/
>   
> to write a recursive importer, we could get programs like Next
> browser packaged in one go but for a couple of tweaks for the 2-3 odd
> packages.
> 
> Let me know if you want to work on this, otherwise I'll give it a
> shot.
> 

I'd like to be involved as I have some ideas on things we could do
differently from Nix that I'd begun investigating.  I'll elaborate more
once I get the chance to organize my thoughts.

Thanks,

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi,

On Sun, 30 Sep 2018 23:46:08 +0200
Pierre Neidhardt  wrote:

> Also see
> 
>   https://github.com/quicklisp/quicklisp-projects/issues/1561
> 
> There are some interesting links, mostly about the Nix system.  See
> the
> 
>   
> https://github.com/NixOS/nixpkgs/blob/5048b0d1f9e908665a01c35f49b2d9816128e089/pkgs/development/lisp-modules/quicklisp-to-nix-output/swank.nix
> 

Having taken just a quick look at what's there, it seems that the
approach is fairly different from what we're doing.  They're using the
default asdf build target, and I think they must be relying on output
translations having been set up right to avoid re-compilation.

I'm trying to get a Nix OS VM set up to play around with what's there.

> file: I think it would have given us a clear hint with
> ~asdFilesToKeep = ["swank.asd"];~, had we looked at Nix before.
> 

It looks like they're doing that in all of the packages.  In general,
we shouldn't expect to have to bring definitions from upstream's asd
file into our own.  Asdf's best practices documentation warns against
it.  Also, they're using upstream slime, unlike your package, so I
don't think anything is being compiled at all.

The difference here between Nix's system and ours
is that they're using the upstream asd file to load the system, whereas
we generate our own just for the build's output.  This allows us to
load the compiled file (or files) directly, without having to rely on
mapping source files to compiled files.

> I haven't looked to closely into what else Nix is doing to package
> Common Lisp, but it seems rather complete.  Any good idea we could
> borrow, Andy?

It'd be nice to have an importer.  Maybe we can use Nix's work to
reduce the amount of investigation needed to get there.

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hi,

On Mon, 01 Oct 2018 15:53:50 +0200
Pierre Neidhardt  wrote:

> Another issue, Andy, is with the new `normalize-dependency' function
> that adds support for the dependency syntax as specified by the ASDF
> grammar.  I think your approach is good but it fails for `jpl-queues`
> because it produces the following .asd file in the store:
>
> [...]
> 
> Note that jpl-util is missing from the registry link list.
> 
> It turns out that it fails because the match-lambda you've used to
> implement the standard are case-sensitive, while the standard is
> case-insensitive.

Right, good catch.

> 
> Adn... jpl-queues uses ":VERSION" and not ":version" as you
> expected :(
> 
> I think the simple fix would be to make the two match-lambda
> case-insensitive (both in generate-dependency-links and in
> make-asd-file).

We're always retrieving that list from a lisp implementation, so I
think it's safe to assume that those symbols will be up-cased in the
output that it sends us.  I'll send a patch with that change.

Thanks,

--
Andy

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Andy Patterson]

Hey Pierre,

Sorry for taking so long to get back to you.

On Wed, 19 Sep 2018 09:19:46 +0200
Pierre Neidhardt  wrote:

> On the long road to packaging Next browser (bug #32729), I've hit a
> big obstacle: packaging the SLIME/SWANK dependency.
> 
> We currently have an emacs-slime package, but that cannot be used as a
> Common Lisp dependency.
> 

I've managed to figure out why that is.  With the branch you're using
for the package, the asd file defines the package and variables that
get used - but in guix that asd file gets discarded.  I think the right
way is to have those definitions defined in a separate file, and
actually they are defined in one as well.  The following patch adds
that file to the asd and makes sure it compiles successfully.

I've noticed that the pull request that branch was made for is closed
though - I'll try to see if I can get things building with the other
one that's open and maybe co-ordinate with upstream to get that in.

For now though, maybe this will unblock you.  The patch was made after
rebasing your branch unto master.  I was also able to drop the commit
named "build-system/asdf: Fix normalize-string to support versioned
dependencies", since there's a more general version of it in master
now.

--
Andy

From a7b945bb58f22ac6c0bcee1bee62e40ffa9873a6 Mon Sep 17 00:00:00 2001
From: Andy Patterson 
Date: Sat, 29 Sep 2018 15:04:40 -0400
Subject: [PATCH] gnu: slime-swank: Make it loadable.

* gnu/packages/lisp.scm (sbcl-slime-swank)[origin]: Add
(guix build utils).
: Patch the asd file to load swank-loader-asdf.
---
 gnu/packages/lisp.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index aa146c9a5..a05d95f60 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -2223,12 +2223,18 @@ writing code that contains string literals that
contain code themselves.") (base32
  ;; "065bc4y6iskazdfwlhgcjlzg9bi2hyjbhmyjw3461506pgkj08vi"
  "0pkmg94wn4ii1zhlrncn44mdc5i6c5v0i9gbldx4dwl2yy7ibz5c"))
+   (modules '((guix build utils)))
(snippet
 '(begin
(substitute* "contrib/swank-listener-hooks.lisp"
  ((":compile-toplevel :load-toplevel ") ""))
(substitute* "contrib/swank-presentations.lisp"
  ((":compile-toplevel :load-toplevel ") ""))
+   (substitute* "swank.asd"
+ ((":file \"packages\".*" all)
+  (string-append all "(:file \"swank-loader-asdf\")\n")))
+   (substitute* "swank-loader-asdf.lisp"
+ ((":common-lisp" all) (string-append all " #:asdf")))
#t
 (build-system asdf-build-system/sbcl)
 (arguments
-- 
2.19.0

bug#32522: qtwebkit-5.212.0-alpha2.drv

[Andy Patterson]

Hi,

On Fri, 24 Aug 2018 21:57:52 +0200
Gnu Röoty  wrote:

> Hi ! From 2 weeks I want install the service CUPS with drivers HP, but
> qtwebkit failed for build.
> 
> [...]
> 
> My service CUPS to config.scm :
> 
> (services (cons* (gnome-desktop-service)
> 
>;;Service Cups avec pilotes imprimante hp
> (service cups-service-type
> (cups-configuration
> (web-interface? #t)
> (extensions
> (list cups-filters hplip

You might want to try hplip-minimal here, since it's the one that
doesn't depend on qtwebkit.  I don't have any answers for why it's
failing to build for you though.

>(xfce-desktop-service)
>    %desktop-services))

Hoping that helps,

--
Andy

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

[Andy Wingo]

On Thu 05 Jul 2018 14:27, l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Andy Wingo  skribis:
>
>> The signal thread is a possibility though in that case you'd get a
>> warning; the signal-handling thread appears in scm_all_threads.  Do you
>> see a warning?  If you do, that is a problem :)
>
> I don’t see a warning.
>
> But as a Guile user, I shouldn’t see a warning just because there’s a
> signal thread anyway; it’s not a thread I spawned myself.

I understand but it's how it works.  If we want to change this, probably
we need a similar interface as we have with finalization.

> The weird thing is that the signal thread always exists, and it’s
> surprising IMO that it shows up in ‘scm_all_threads’ because it’s not a
> “user thread”.  The other surprise is that the warning isn’t triggered:
>
> $ guile
> GNU Guile 2.2.4
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (all-threads)
> $1 = (# #)
> scheme@(guile-user)> (when (zero? (primitive-fork)) (primitive-_exit 0))
> ;; no warning

Are you certain that this is the signal-handling thread and not the
finalizer thread?  I suspect it is the finalizer thread, and that it
gets properly shut down before the fork.

Regarding seeing the warning: do you do make some other binding for the
default warning port in Guix?

Andy

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

[Andy Wingo]

Hi,

On Thu 05 Jul 2018 12:05, Mark H Weaver  writes:

> However, it's also the case that libgc uses 'pthread_atfork' (where
> available) to arrange to grab the GC allocation as well as the "mark
> locks" in the case where parallel marking is enabled.  See
> fork_prepare_proc, fork_parent_proc, and fork_child_proc in
> pthread_support.c.

I don't think this is enabled by default.  You have to configure your
libgc this way.  When investigating similar bugs, I proposed enabling it
by default a while ago:

  http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2012-February/004958.html

I ended up realizing that pthread_atfork was just a bogus interface.
For one, it turns out that POSIX clearly says that if a multithreaded
program forks, the behavior of the child after the fork is undefined if
it calls any non-async-signal-safe function before calling exec():

  https://lists.gnu.org/archive/html/guile-devel/2012-02/msg00157.html

But practically, the only reasonable thing to do with atfork is to grab
all of the locks, then release them after forking, in both child and
parent.  However you can't do this without deadlocking from a library,
as the total lock order is a property of the program and not something a
library can decide.

There are thus two solutions: either ensure that there are no other
threads when you fork, or only call async-signal-safe functions before
you exec().  open-process does the latter.  fork will warn if the former
is not the case.  When last I looked into this, I concluded that
pthread_atfork doesn't buy us anything, though I could be wrong!

>> Here's the body of primitive-fork fwiw:
>>
>> {
>>   int pid;
>>   scm_i_finalizer_pre_fork ();
>>   if (scm_ilength (scm_all_threads ()) != 1)
>
> I think there's a race here.  I think it's possible for the finalizer
> thread to be respawned after 'scm_i_finalizer_pre_fork' in two different
> ways:
>
> (1) 'scm_all_threads' performs allocation, which could trigger GC.
>
> (2) another thread could perform heap allocation and trigger GC after
> 'scm_i_finalizer_pre_fork' joins the thread.  it might then shut
> down before 'scm_all_thread' is called.
>
> However, these are highly unlikely scenarios, and most likely not the
> problem we're seeing here.
>
> Still, I think the 'scm_i_finalizer_pre_fork' should be moved after the
> 'if', to avoid this race.

Good point!  Probably we should use some non-allocating
 scm_i_is_multi_threaded() or something.  We can't move the pre-fork
thing though because one of the effects we are looking for is to reduce
the thread count!

Cheers,

Andy

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

[Andy Wingo]

Hi!

On Thu 05 Jul 2018 05:33, Mark H Weaver  writes:

>> One problem I’ve noticed is that the child process that
>> ‘call-with-decompressed-port’ spawns would be stuck trying to get the
>> allocation lock:
>>
>> So it seems quite clear that the thing has the alloc lock taken.  I
>> suppose this can happen if one of the libgc threads runs right when we
>> call fork and takes the alloc lock, right?
>
> Does libgc spawn threads that run concurrently with user threads?  If
> so, that would be news to me.  My understanding was that incremental
> marking occurs within GC allocation calls, and marking threads are only
> spawned after all user threads have been stopped, but I could be wrong.

I think Mark is correct.

> The first idea that comes to my mind is that perhaps the finalization
> thread is holding the GC allocation lock when 'fork' is called.

So of course we agree you're only supposed to "fork" when there are no
other threads running, I think.

As far as the finalizer thread goes, "primitive-fork" calls
"scm_i_finalizer_pre_fork" which should join the finalizer thread,
before the fork.  There could be a bug obviously but the intention is
for Guile to shut down its internal threads.  Here's the body of
primitive-fork fwiw:

{
  int pid;
  scm_i_finalizer_pre_fork ();
  if (scm_ilength (scm_all_threads ()) != 1)
/* Other threads may be holding on to resources that Guile needs --
   it is not safe to permit one thread to fork while others are
   running.

   In addition, POSIX clearly specifies that if a multi-threaded
   program forks, the child must only call functions that are
   async-signal-safe.  We can't guarantee that in general.  The best
   we can do is to allow forking only very early, before any call to
   sigaction spawns the signal-handling thread.  */
scm_display
  (scm_from_latin1_string
   ("warning: call to primitive-fork while multiple threads are 
running;\n"
" further behavior unspecified.  See \"Processes\" in the\n"
" manual, for more information.\n"),
   scm_current_warning_port ());
  pid = fork ();
  if (pid == -1)
SCM_SYSERROR;
  return scm_from_int (pid);
}

> Another possibility: both the finalization thread and the signal
> delivery thread call 'scm_without_guile', which calls 'GC_do_blocking',
> which also temporarily grabs the GC allocation lock before calling the
> specified function.  See 'GC_do_blocking_inner' in pthread_support.c in
> libgc.  You spawn the signal delivery thread by calling 'sigaction' and
> you make work for it to do every second when the SIGALRM is delivered.

The signal thread is a possibility though in that case you'd get a
warning; the signal-handling thread appears in scm_all_threads.  Do you
see a warning?  If you do, that is a problem :)

>> If that is correct, the fix would be to call fork within
>> ‘GC_call_with_alloc_lock’.
>>
>> How does that sound?
>
> Sure, sounds good to me.

I don't think this is necessary.  I think the problem is that other
threads are running.  If we solve that, then we solve this issue; if we
don't solve that, we don't know what else those threads are doing, so we
don't know what mutexes and other state they might have.

Andy

bug#28211: Stack marking issue in multi-threaded code

[Andy Wingo]

Hi!

First of all, I said on IRC but: ___nice___ debugging, Ludo!  An
impressive show of persistence.  Thanks Mark also for insightful
comments!

On Sat 30 Jun 2018 23:49, Mark H Weaver  writes:

>>> I should say that I'm not confident that _either_ of these proposed
>>> solutions will adequately address all of the possible problems that
>>> could occur when GC is performed on VM threads stopped at arbitrary
>>> points in their execution.
>>
>> Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
>> that each stack is marked by the thread it belongs to, in terms of data
>> locality, and thus also in terms of being sure that vp->fp is up-to-date
>> when the marker reads it.  It’s not something we can change now, though.
>
> I'm not sure it matters what thread the marking is done in, because when
> the actual collection happens, all threads are first stopped in their
> signal handlers, and presumably the appropriate memory barriers are
> performed so that all threads are synchronized before the full
> collection.

I think you are right here.  Still, it would be nice from a locality
POV if threads could mark themselves.  In some future I think it would
be nice if threads cooperatively reached safepoints, instead of using
the signal mechanism.  In that case we could precisely mark the most
recent stack frame as well.

>> Anyway, I don’t think we’ll have the final word on all this before
>> 2.2.4.  The way I see it we should keep working on improving it, but
>> there are difficult choices to make, so it will probably take a bit of
>> time.
>
> Sounds good.

Yeah!  Really great that this is fixed, and apologies for introducing it
in the first place!!

A

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Andy Wingo]

On Wed 09 May 2018 11:23, l...@gnu.org (Ludovic Courtès) writes:

>> Is the memoization you are referring to the "set!" in the "lazy" form in
>> ice-9/eval.scm ?  Or something else?  FWIW I would not think the "set!"
>> could be the issue, at least on x86, but who knows.
>
> Actually I’m not sure exactly.  ‘memoize-expression’ itself is
> side-effect-free, right?

As far as I know (and I had a look this morning), yes.  It takes a
Tree-IL input and returns a memoized output.  The internal mutation that
exists in the evaluator is just the lazy "compilation" (see the
invocations of the "lazy" form).

Of course the function being evaluated could mutate shared state as
well!

Andy

bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2

[Andy Wingo]

On Wed 09 May 2018 02:32, Mark H Weaver <m...@netris.org> writes:

> However, I think it's _far_ more likely that the NULL argument on the
> stack was copied from memory shared by multiple threads without proper
> thread synchronization.

I think this is unlikely on x86 given its total-store-ordering memory
model.  I agree with you about the value of barriers, but I don't think
they are part of this bug that Ludo is seeing.

>> I commented out the MADV_DONTNEED call to be sure, but I can still
>> reproduce the bug.
>
> I strongly doubt that the MADV_DONTNEED is relevant to this issue.

It could be.  It would zero out VM stack frames, and if GC is called
when/if vp->sp is out of date, then that would be possible.  However I
think vp->sp is never out of date, so that's probably not it.  The
things that can be out of date are the on-heap copy of the IP (vp->ip)
and the local register copy of the sp (sp).  It's more likely for the
local "sp" cache to be out of date -- if we recursed through Scheme in a
call out from the VM, eventualy causing stack expansion and relocation,
then on the return forgot to re-cache the sp value, that could be it.

Similarly, forgetting to set vp->ip before calling out to something that
could GC could likewise cause a problem because the stack map wouldn't
be right and the precise stack marker could clear a value by mistake.
This only happens for non-innermost frames though; the innermost frame
is marked conservatively.

The rules are: update vp->ip before something that can allocate, and
update local "sp" after returning from a C function that could have
recursively called Scheme.

I did find a couple places in the VM where we forgot to do one of these,
e.g. 07b7490f73fb4a6cb0c9577d082d37c8d9cee7b0 and just now
9a72e212622fa3bd118d7c02c4386601285b3224.  These two patches aren't
shipped yet fwiw.

Andy

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Andy Wingo]

Hi,

On Mon 30 Apr 2018 23:39, l...@gnu.org (Ludovic Courtès) writes:

> So the problem, AIUI, is that psyntax evaluates syntax parameters using
> ‘primitive-eval’ (via ‘eval-local-transformer’), but memoization in
> (ice-9 eval) is not thread-safe, hence the random crashes.

Sorry I've been a bit AWOL here... if this diagnosis is correct, then
the problem is ultimately the memoization that needs to be thread-safe,
right?

Is the memoization you are referring to the "set!" in the "lazy" form in
ice-9/eval.scm ?  Or something else?  FWIW I would not think the "set!"
could be the issue, at least on x86, but who knows.

A

bug#27476: guix pull fails on powerful server

[Andy Wingo]

On Fri 22 Sep 2017 16:10, l...@gnu.org (Ludovic Courtès) writes:

> Hi Ricardo,
>
> Ricardo Wurmus <rek...@elephly.net> skribis:
>
>> The following derivation will be built:
>>/gnu/store/yvyfkns3w3vm7ynwbr7mvxcmin4gd2a0-guix-latest.drv
>> copying and compiling to 
>> '/gnu/store/7m52dkr98nhwgpsx20mmpwyw2yzj58d3-guix-latest' with Guile 2.2.2...
>> loading...   25.4% of 629 filesrandom seed for tests: 1506066913
>> loading...   99.8% of 629 files
>> compiling... 69.2% of 629 filesice-9/threads.scm:289:22: In procedure 
>> loop:
>> ice-9/threads.scm:289:22: Syntax error:
>> guix/scripts.scm:130:2: >>=: >>= (bind) used outside of 'with-monad' in form 
>> (>>= (apply set-build-options* #:use-substitutes
>> ptions)) (lambda (unused-value) (mbegin %store-monad (mlet %store-monad 
>> ((derivation (origin->derivation (package-source pack
>> tutes? use-substitutes? #:dry-run? dry-run?) (return 
>> (show-derivation-outputs derivation)))
>
> This was reported at <https://bugs.gnu.org/27476>, and I suspect a
> thread-safety issue.  However, syntax parameters are purely functional
> AFAICS, so I fail to see why multithreading could be a problem.
>
> Andy, any idea what could be causing this?

I have heard of but not seen a number of similar bugs: errors that
"can't happen" but which appear under multiple threads.  I don't know
what underlying pattern is.  Has anyone found a test case that reliably
reproduces?

Andy

bug#26594: guix pull --bootstrap does not work

[Andy Wingo]

I did a "guix pull" and it carped that there was a 404 for the bash-4.4A
NAR, and suggested --fallback.  But there is no --fallback argument to
guix pull for some reason.  OK.  There's a --bootstrap argument but
although it can install the deps, it can't pull, because:

  In unknown file:
 ?: 0 [dynamic-func "strverscmp" #]

  ERROR: In procedure dynamic-func:
  ERROR: In procedure dynamic-pointer: Symbol not found: strverscmp
  builder for `/gnu/store/jagbm4f9npc7n7l9y4b1ncc25vigylky-guix-latest.drv' 
failed with exit code 1
  guix pull: error: build failed: build of 
`/gnu/store/jagbm4f9npc7n7l9y4b1ncc25vigylky-guix-latest.drv' failed

I would guess this is because the bootstrap Guile is statically linked.

Andy

bug#25775: Attempts to fix bootstrap Guile bug

[Andy Wingo]

Hi,

It seems that this bug is related to the introduction of
url-fetch/reset-patch-level.  It takes a #:guile kwarg but defaults to
#f; if not given #:guile, that #f propagates through instead of a
package object.

So one fix is here:

  diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
  index c8d94c8..d070cca 100644
  --- a/gnu/packages/bootstrap.scm
  +++ b/gnu/packages/bootstrap.scm
  @@ -76,8 +76,10 @@
   
 (let ((orig-method (origin-method source)))
   (origin (inherit source)
  -  (method (cond ((eq? orig-method url-fetch)
  - (boot url-fetch))
  +  (method (cond ((or (eq? orig-method url-fetch)
  + (eq? orig-method
  +  (@@ (gnu packages bash) 
url-fetch/reset-patch-level)))
  + (boot orig-method))
   (else orig-method)))
 (patch-guile %bootstrap-guile)
 (patch-inputs %bootstrap-patch-inputs)

I think anyway.  If you look at this code, the "boot" helper decorates
the url-fetch call with a #:guile.  But I don't think this function is
called for bash because I still see an error.

Another fix is here I think:

  diff --git a/gnu/packages/bash.scm b/gnu/packages/bash.scm
  index c121fd8..fdb3aa8 100644
  --- a/gnu/packages/bash.scm
  +++ b/gnu/packages/bash.scm
  @@ -250,7 +250,8 @@ can apply to a patch-level 0 Bash."
  (patch (url-fetch url hash-algo hash
(string-append name ".orig")
#:system system
  - #:guile guile)))
  + #:guile guile))
  +   (guile (package->derivation guile system)))
   (gexp->derivation name
 (with-imported-modules '((guix build utils))
   #~(begin

Here this "guile" propagates below to #:guile-for-build, which AFAIU
should be a derivation, not a package.

But even with this, I still get an error.  Add (unless guile (error
"what")) to the top of url-fetch/reset-patch-level, and I get:

  [6h8mzf08ld7r69yy9gdbxw9vba0l9sr2-profile] wingo@clucks:~/src/guix$ guix 
build guile-next
  Backtrace:
  In srfi/srfi-1.scm:
   575: 19 [map # 
(#)]
  In guix/scripts/build.scm:
   634: 18 [# #]
  In guix/packages.scm:
   786: 17 [cache! # # # ...]
  1095: 16 [thunk]
   982: 15 [bag-grafts # #]
   966: 14 [fold-bag-dependencies # ...]
   983: 13 [# # 
#]
   786: 12 [cache! # # "x86_64-linux" ...]
   910: 11 [thunk]
   786: 10 [cache! # # # ...]
  1092: 9 [thunk]
  1024: 8 [bag->derivation # # #]
  In srfi/srfi-1.scm:
   575: 7 [map # #]
  In guix/packages.scm:
   846: 6 [expand-input # # # ...]
  In guix/store.scm:
  1249: 5 [run-with-store # ...]
  In guix/packages.scm:
  1200: 4 [# #]
   486: 3 [patch-and-repack # # # ...]
  In srfi/srfi-1.scm:
   575: 2 [map # (#)]
  In gnu/packages/bash.scm:
   249: 1 [url-fetch/reset-patch-level 
"mirror://gnu/bash/bash-4.4-patches/bash44-007" ...]
  In unknown file:
 ?: 0 [scm-error misc-error #f "~A" ("what") #f]

  ERROR: In procedure scm-error:
  ERROR: what

That indicates to me that somehow the origin for this bash (or is it
bash/fixed?) isn't getting its url-fetch call appropriately decorated.

I think in the meantime it would be acceptable to insert an

  (unless guile
(error "update your guix daemon from git and restart it (#25775)"))

to url-fetch/reset-patch-level, or something like that.  WDYT?

Andy

bug#25101: [PATCH 2/3] gnu: Add and use sane-backends-minimal.

[Andy Patterson]

* gnu/packages/scanner.scm (sane-backends): Rename to...
(sane-backends-minimal): this. Adjust name, source, synopsis and
description accordingly.
* gnu/packages/cups.scm (hplip): Use 'sane-backends-minimal' instead of
'sane-backends'.
* gnu/packages/gnome.scm (colord, simple-scan): Likewise.
* gnu/packages/libreoffice.scm (libreoffice): Likewise.
* gnu/packages/wine.scm (wine): Likewise.
---
 gnu/packages/cups.scm|  2 +-
 gnu/packages/gnome.scm   |  4 ++--
 gnu/packages/libreoffice.scm |  2 +-
 gnu/packages/scanner.scm | 11 ++-
 gnu/packages/wine.scm|  2 +-
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index 0a8a10ecb..baa77f7aa 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -416,7 +416,7 @@ device-specific programs to convert and print many types of 
files.")
 (inputs `(("libjpeg" ,libjpeg)
   ("cups-minimal" ,cups-minimal)
   ("libusb" ,libusb)
-  ("sane-backends" ,sane-backends)
+  ("sane-backends" ,sane-backends-minimal)
   ("dbus" ,dbus)
   ("python-wrapper" ,python-wrapper)
   ("python" ,python)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 1762381cf..7ffe0bc2d 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2433,7 +2433,7 @@ keyboard shortcuts.")
("libusb" ,libusb)
("sqlite" ,sqlite)
("polkit" ,polkit)
-   ("sane-backends" ,sane-backends)))
+   ("sane-backends" ,sane-backends-minimal)))
 (home-page "http://www.freedesktop.org/software/colord/;)
 (synopsis "Color management service")
 (description "Colord is a system service that makes it easy to manage,
@@ -3571,7 +3571,7 @@ USB transfers with your high-level application or system 
daemon.")
("cairo" ,cairo)
("gdk-pixbuf" ,gdk-pixbuf)
("gusb" ,gusb)
-   ("libsane" ,sane-backends)))
+   ("libsane" ,sane-backends-minimal)))
 (native-inputs
  `(("gettext" ,gettext-minimal)
("itstool" ,itstool)
diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm
index 279e8e2d2..307a54496 100644
--- a/gnu/packages/libreoffice.scm
+++ b/gnu/packages/libreoffice.scm
@@ -784,7 +784,7 @@ and to return information on pronunciations, meanings and 
synonyms.")
("postgresql" ,postgresql)
("python" ,python)
("redland" ,redland)
-   ("sane-backends" ,sane-backends)
+   ("sane-backends" ,sane-backends-minimal)
("unixodbc" ,unixodbc)
("unzip" ,unzip)
("vigra" ,vigra)
diff --git a/gnu/packages/scanner.scm b/gnu/packages/scanner.scm
index 01db5ee21..e913858f5 100644
--- a/gnu/packages/scanner.scm
+++ b/gnu/packages/scanner.scm
@@ -26,15 +26,15 @@
   #:use-module ((guix licenses)
 #:prefix licence:))
 
-(define-public sane-backends
+(define-public sane-backends-minimal
   (package
-(name "sane-backends")
+(name "sane-backends-minimal")
 (version "1.0.25")
 (source (origin
  (method url-fetch)
  (uri (string-append
"https://alioth.debian.org/frs/download.php/file/4146/;
-   name "-" version ".tar.gz"))
+   "sane-backends-" version ".tar.gz"))
  (sha256
   (base32
"0b3fvhrxl4l82bf3v0j47ypjv6a0k5lqbgknrq1agpmjca6vmmx4"
@@ -71,9 +71,10 @@
 ;;  File generated for html-backends-split mode is different from 
reference
 ;; Makefile:501: recipe for target 'check.local' failed
 (home-page "http://www.sane-project.org;)
-(synopsis "Raster image scanner library and drivers")
+(synopsis
+ "Raster image scanner library and drivers, without scanner support")
 (description "SANE stands for \"Scanner Access Now Easy\" and is an API
 proving access to any raster image scanner hardware (flatbed scanner,
 hand-held scanner, video- and still-cameras, frame-grabbers, etc.).  The
-package contains the library and drivers.")
+package contains the library, but no drivers.")
 (license licence:gpl2+))) ; plus linking exception
diff --git a/gnu/packages/wine.scm b/gnu/packages/wine.scm
index 367f27af5..83b6297f0 100644
--- a/gnu/packages/wine.scm
+++ b/gnu/packages/wine.scm
@@ -83,7 +83,7 @@
("libmpg123" ,mpg123)
("libldap" ,openldap)
("libnetapi" ,samba)
-   ("libsane" ,sane-backends)
+   ("libsane" ,sane-backends-minimal)
("libpng" ,libpng)
("libjpeg" ,libjpeg)
("libtiff" ,libtiff)
-- 
2.11.0

bug#25101: [PATCH 1/2] gnu: Add hpaio-enabled sane-backends variant.

[Andy Patterson]

Hi,

Here's some patches implementing what you've suggested. I decided to use the
full "sane-backends" for the other dependents, since I guessed that they need
some backend support. If anyone knows that that's not required, it can be
changed.

Thanks,

--
Andy

bug#25101: [PATCH 1/2] gnu: Add hpaio-enabled sane-backends variant.

[Andy Patterson]

Hi, and sorry for the late reply.

On Tue, 06 Dec 2016 10:10:57 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Andy Patterson <ajpat...@uwaterloo.ca> skribis:
> 
> > On Mon, 05 Dec 2016 21:48:36 +0100
> > l...@gnu.org (Ludovic Courtès) wrote:
> >  
> >> > +(define-public sane-backends+hpaio
> >> 
> >> Could you add a comment and a synopsis explaining what’s this is?
> >>   
> >
> > Sure, is the following patch ok?  
> 
> Yup!
> 
> >> > +  (package
> >> > +(inherit sane-backends)
> >> > +(name "sane-backends+hpaio")
> >> > +(inputs
> >> > + `(("hplip" ,(@ (gnu packages cups) hplip))
> >> > +   ,@(package-inputs sane-backends)))
> >> 
> >> The closure size of this is 290 MiB whereas it’s 87 MiB for
> >> ‘sane-backends’.  I suppose that’s the reason to keep’em separated?
> >>  
> >
> > Yeah, and there's also the fact that hplip depends on sane-backends.
> > But this is the reason I didn't change sane-backends into a private
> > variable, and then make this the new sane-backends.  
> 
> Oh right.
> 
> One last thing: should we renaming “sane-backends” to
> “sane-backends-minimal”, and “sane-backends+hpaio” to “sane-backends”?

The current "sane-backends" isn't really minimal, as it includes most
backends. I'm not sure how it's applied elsewhere in Guix though, so
I'll leave it up to you.

> 
> That way all scanners would work out of the box, at the expense of
> extra disk usage, but that is roughly what patch 2/2 does anyway.

One more patch is required in either case, as hplip would need to use
sane-backends-minimal. Let me know if you'd like me to make this change.

--
Andy

bug#25101: simple-scan can't use hpaio

[Andy Patterson]

On Sat,  3 Dec 2016 23:00:35 -0500
Andy Patterson <ajpat...@uwaterloo.ca> wrote:

> Hi Danny,
> 
> I also noticed this problem a couple days ago, and I really needed to
> scan something, so I've had these patches in my tree. It basically
> implements your second suggestion. I think it's the right way to go
> about it.
> 
> I realise you might also have patches you're working on, but maybe
> this is helpful anyway.
> 
> Suggestions welcome, especially concerning how I handled the
> recursive module dependencies.
> 
> Thanks,
> 
> --
> Andy
> 

Just adding Danny; didn't realise that a CC also needs to be added to
the compose window for "git send-email".

bug#25101: simple-scan can't use hpaio

[Andy Patterson]

Hi Danny,

I also noticed this problem a couple days ago, and I really needed to scan
something, so I've had these patches in my tree. It basically implements your
second suggestion. I think it's the right way to go about it.

I realise you might also have patches you're working on, but maybe this is
helpful anyway.

Suggestions welcome, especially concerning how I handled the recursive module
dependencies.

Thanks,

--
Andy

bug#25101: [PATCH 2/2] gnu: simple-scan: Enable hpaio support.

[Andy Patterson]

* gnu/packages/gnome.scm (simple-scan)[inputs]: Use
'sane-backends+hpaio'.
---
 gnu/packages/gnome.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 3aa0f56..531da43 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -3572,7 +3572,7 @@ USB transfers with your high-level application or system 
daemon.")
("cairo" ,cairo)
("gdk-pixbuf" ,gdk-pixbuf)
("gusb" ,gusb)
-   ("libsane" ,sane-backends)))
+   ("libsane" ,sane-backends+hpaio)))
 (native-inputs
  `(("gettext" ,gettext-minimal)
("itstool" ,itstool)
-- 
2.10.2

bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

[Andy Wingo]

On Wed 16 Dec 2015 20:18, Efraim Flashner <efr...@flashner.co.il> writes:

>> We should be using C_INCLUDE_PATH instead of CPATH, to mark system
>> headers as system headers.  Except that C_INCLUDE_PATH only works for
>> C, so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.
>> And that's the proposal of this bug :)
>
> Are there other ones that could be set? Every time I compile it I see options
> for java and go.

No, the only ones mentioned in the manual are the ones I mention above.
To me this makes sense, as ObjC and C++ can include C, but that is not
the case for Java and Go.

Andy

bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

[Andy Wingo]

'-I' but before the standard system directories.  Mark it as a
 system directory, so that it gets the same special treatment as is
 applied to the standard system directories.  If DIR begins with
 '=', then the '=' will be replaced by the sysroot prefix; see
 '--sysroot' and '-isysroot'.

What is a system directory?  Well, it's searched for after all -I
includes, but also header files in it are marked as system headers.
Many warnings are not issued for system headers; search the manual for
the phrase "system headers".  For example:

'-Wsystem-headers'
 Issue warnings for code in system headers.  These are normally
 unhelpful in finding bugs in your own code, therefore suppressed.
 If you are responsible for the system library, you may want to see
 them.

So.  We should be using C_INCLUDE_PATH instead of CPATH, to mark system
headers as system headers.  Except that C_INCLUDE_PATH only works for C,
so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.  And
that's the proposal of this bug :)

Andy

bug#15193: OStree

[Andy Tai]

This may be of interest here
https://lwn.net/Articles/564793/

-- 
Andy Tai, a...@atai.org, Skype: licheng.tai
Year 2013 民國102年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

goal of Guix

[Andy Tai]

Hi, just curious is Guix eventually becoming a GNU/Linux distribution in
the manner of Debian, Fedora, etc. (with its unique package frameworks and
other infrastructures, of course)

-- 
Andy Tai, a...@atai.org, Skype: licheng.tai
Year 2013 民國102年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能