Re: hello from a new commiter

[宋文武]

Zheng Junjie  writes:

> hello! 
>
> I have been granted commit access.
>
> You might know me, Past few years I fix some error on riscv64, fix some
> cross-compilation, Add plasma-desktop, etc. I'm using this access to
> better improve these.

That's great, thank you for the work and looking forward for future
improvements!

Re: (Lx)Qt team in Guix

[宋文武]

Maxim Cournoyer  writes:

> Hi Andreas,
>
> +guix-devel
>
> Andreas Enge  writes:
>
>> Hello,
>>
>> I am reaching out since I am receiving in cc patches for Qt, and realise
>> that I do not feel quite confident about them; I added myself because I
>> feel able to work on C code, but I think you are much more involved and
>> competent for Qt than I and also sufficiently numerous, so I could safely
>> remove myself.
>>
>> But when trying to do so, I realised that the situation is a bit convoluted:
>> In addition to a qt team, there is an lxqt team, and I was actually part
>> only of the latter; but the two overlap in claiming responsibility for
>> gnu/packages/qt.scm. Moreover Maxim is part of qt, and 宋文武 and I are
>> part of lxqt.
>
> I think the reason qt.scm is part of the lxqt team is historical; lxqt-team
> predates qt-team.  We should probably just remove qt.scm from
> lxqt-team's scope.  What do you think?
>
>> So I would suggest to sort this out somehow; maybe merge lxqt into qt?
>
> I'd keep both team separated; I'm interested in maintaining qt upgrades
> but not much lxqt.

Hello, I have just pushed 2 commits to remove qt.scm from the scope of
lxqt and add myself to the qt team.

Happy weekend!

Re: Proposal to turn off AOT in clojure-build-system

[宋文武]

Steve George  writes:

> Hi,
>
> Guix's clojure-build-system turns on AOT compilation by default. I would like 
> to advocate that 'as a distributor' we should *not* ship Clojure code AOT'd, 
> so we should change the default.
>
> This has been discussed previously. In #56604 r0man noted that AOT 
> compilation should not be on by default [0], Reilly makes the same point in 
> #53765 [1].

Hello, we have both source and binary packages for Common Lisp (eg:
cl-ppcre and sbcl-ppcre), the source packages are for development and
binary packages for build applications.  I think we can do the same for
Clojure, and yes package them in source package (without AOT) by
default, and add binary packages when needed by actual applications.

I'm not using clojure myself, but the use cases for development and
applications distributation are both important for Guix, and manage
development environments better is a big sell point.

Re: CI job for lisp-team branch

[宋文武]

Guillaume Le Vaillant  writes:

> Hi.
> I created a lisp-team branch to work one some updates for clisp and
> sbcl. Could someone with admin access to the CI things add a job for it?
> Thanks.

Hello, Curiass CI job created.

Thanks.

Re: GDB-multiarch

[宋文武]

Ekaitz Zarraga  writes:

> Hi all,
>
> As you might know I'm talking part on the RISC-V bootstrapping efforts in 
> Guix.
> This makes me need a multi-architecture GDB. So I made this simple package:
>
> ``` scheme
> (define-module (gdb)
>   #:use-module (gnu packages)
>   #:use-module (gnu packages gdb)
>   #:use-module ((guix licenses) #:select (gpl3+))
>   #:use-module (guix packages)
>   #:use-module (guix utils))
>
> (define-public gdb-multiarch-12
>   (package
> (inherit gdb/pinned)
> (name "gdb-multiarch")
> (version "12.1")
> (arguments
>  `(#:configure-flags
>(list "--enable-targets=all")
>,@(package-arguments gdb-12)))
> (properties '(
>
> (define-public gdb-multiarch gdb-multiarch-12)
> ```
>
> We could think about upstreaming it, probably replacing the output `gdb` 
> binary
> with `gdb-multiarch` as I think Debian does.
>
> I think this might be interesting for many others.
>
> WDYT?
>
>
> ElenQ Technology
> Ethical Innovation

Hello, I have pushed one 'gdb-multiarch' into master as commit ceff14b7cd4.

It have different arguments, which I copied from other places..

+(define-public gdb-multiarch
+  (package/inherit gdb-12
+(name "gdb-multiarch")
+(arguments
+ `(#:configure-flags
+   (list "--enable-targets=all"
+ "--enable-multilib"
+ "--enable-interwork"
+ "--enable-languages=c,c++"
+ "--disable-nls")
+   ,@(package-arguments gdb-12)))
+(synopsis "The GNU debugger (with all architectures enabled)")))


Does it works for you?  Thanks.

Re: How can we decrease the cognitive overhead for contributors?

[宋文武]

Maxim Cournoyer  writes:

> Perhaps you'd like to invest 1 hour (30 minutes?) into learning to use
> 'patman'.  It allows attaching metadata to a feature branch by means of
> Git message tags, e.g. the associated email address with 'Series-to:',
> or the current revision with 'Series-version:', etc.  Then submitting
> the series is a matter of invoking just 'patman', and following the
> indications.
>
> For more information, try: 'guix shell info-reader u-boot -- info
> "(u-boot) Patman patch manager"'

Oh, patman look interesting for long series, will learn it later..

>> I wrote some elisp to one-key apply patches from GNUS, but I guess my
>> point is: not everyone can do that. How are we to expect more
>> contributors if that, or something similar, is the barrier to entry?
>
> Using an Emacs-based workflow:
>
> 1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
> 2. M-x cd RET ~/src/guix or wherever is your guix checkout
> 3. Select series you want to apply
> 4. Sort by subject

Also can first read on issues (mumi), find a issue ID,
then M-x gnus-read-ephemeral-emacs-bug-group ID.

> 5. Press '|' (pipe) on any message, and pipe this to the command 'git am
> -3'.  To apply multiple patches at once, you can specify an argument
> prefix, e.g. 'C-u 10 |' to apply 10 patches at once.
>
> I hope that helps someone.

Don't know the 'C-u 10 |' one, cool, thank you!

Re: bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[宋文武]

Maxime Devos  writes:

> For example, naev used to work just fine, yet apparently it doesn't
> anymore: https://issues.guix.gnu.org/65390.
>
> Given that Guix has ci.guix.gnu.org, I would expect such new problems
> to be detected and resolved early, and it was detected by
> ci.guix.gnu.org, yet going by issues.guix.gnu.org it was never even
> investigated.

Yes, honestly I only look for build failures from bug reports, not from
CI if i'm not doing a "request for merge" from another branch.

>
> (Yes, there is a delay, but that doesn't matter at all, as there's
> this dashboard .)

I found the dashboard inconvenient to use, it show failures for both
builds and dependencies in the same red color, and can't be searched.
What I usually do is:

1. download the job status json with:
  wget -O jobs.json 
'https://ci.guix.gnu.org/api/jobs?evaluation=692229=x86_64-linux'

2. use jq to show package names with build failures:
  cat jobs.json  | jq '. | map(select(.status == 1)) | .[].name' -r

3. select interested one to investigate (if doing merge, diff the failures from
working branch with master).


>
> Do people really need to report 33% of all jobs
> (https://ci.guix.gnu.org/eval/668365/dashboard) before those failures
> are taken seriously, instead of the ‘there don't seem to be that much
> more build failures from the core-updates/... merge, let's solve them
> later (i.e., never)’ that seems to be  status quo?

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?

As for now, x86_64 master (eval 668365) has 696 build failures, 604
dependencies failures, 30 unknown (canceld?) failures, total 1330
failures according to the jobs.json data.

Should we open a bug report for each of those 696 build failures?
aarch64-linux-gnu.gcc
abjad-ext-ipython
adms
aegis
anubis
aoflagger
apache-commons-parent-pom
apricots
arachne-pnr
arcan-sdl
arcan
archivebox
arm-linux-gnueabihf.gcc
arpack-ng-openmpi
asignify
asmjit
avro-cpp
azimuth
balsa
barectf
beignet
blacksmith
boinc-server
bonnie++
boost-signals2
btar
burp
cc65
cedille
chaiscript
chezmoi
clang
combinatorial-blas
commoncpp
confusion-mdl
coq-ide
coturn
cpplint
cssc
ctl
cube
darkice
dbus-cxx
ddcci-driver-linux
debops
deluge
dolphin-emu
dosbox-staging
dovecot-trees
d-tools
duc
dvdstyler
dxvk
ecl-april
ecl-binding-arrows
ecl-canonicalized-initargs
ecl-cl-form-types
ecl-cl-gserver
ecl-closure-template
ecl-cl-prevalence
ecl-cmd
ecl-coalton
ecl-coleslaw
ecl-conium
ecl-hdf5-cffi
ecl-lispbuilder-sdl
ecl-mito
ecl-nodgui
ecl-prometheus
ecl-radiance-contribs
ecl-schemeish
ecl-supertrace
ecl-trivial-octet-streams
ecl-trucler
ecl-typo
ecl-yxorp
edi
efilinux
elemental
elpa-openmpi
elpa
emacs-next-pgtk
emacspeak
emacsy
emilua
emulation-station
enblend-enfuse
eog-plugins
epic5
epour
eternalterminal
evdi
fanc
fasthenry
fenics
fiano-fmap
flowee
freedink-engine
freeorion
frotz-dumb-terminal
fulcrum
ganeti
gash-utils
gcc-objc++
gcc-objc
gcc-stripped-tarball
gcc-toolchain
gcc
gcc
ghc-ncurses
ghc-next
ghmm
gimagereader
gitile
gitless
glibc
glibc
glusterfs
gmime
gnash
gnaural
gnome-dictionary
gnucap
go-github-com-charmbracelet-glamour
gourmet
goxel
guile2.0-commonmark
guile2.0-gcrypt
guile2.0-redis
guile2.2-fibers
guile2.2-ics
guile2.2-pfds
guile2.2-xapian
guile-emacs
guile-gnunet
guile-goblins
guile-irc
guile-sparql
guile-static-stripped
guix-minimal
gx-saturator-lv2
gx-slow-gear-lv2
gx-vbass-preamp-lv2
h5check
harminv
hash-extender
hdf5-parallel-openmpi
hdf-eos2
hdf-eos5
hdf-java
hikari
hosts
ht
hydrus-network
hyperledger-iroha
hypre-openmpi.skylake-avx512
i3lock-blur
i586-pc-gnu.gcc-stripped-tarball
i586-pc-gnu.gcc
i586-pc-gnu.gcc
i586-pc-gnu.glibc
i686-linux-gnu.gcc-stripped-tarball
i686-linux-gnu.gcc
i686-linux-gnu.gcc
i686-w64-mingw32.coreutils
i686-w64-mingw32.diffutils
i686-w64-mingw32.findutils
i686-w64-mingw32.gawk
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gdb-minimal
i686-w64-mingw32.gettext
i686-w64-mingw32.glibc
i686-w64-mingw32.grep
i686-w64-mingw32.guile
i686-w64-mingw32.guix
i686-w64-mingw32.gzip
i686-w64-mingw32.patch
i686-w64-mingw32.sed
i686-w64-mingw32.xz
insight-toolkit
insight-toolkit.haswell
insight-toolkit.ivybridge
insight-toolkit.skylake
insight-toolkit.skylake-avx512
insight-toolkit.westmere
irram
itk-snap
java-asm-tree
java-commons-compress
java-eclipse-jetty-util-ajax
java-eclipse-lsp4j-common
java-fasterxml-jackson-databind
java-geronimo-xbean-asm-util
java-geronimo-xbean-bundleutils
java-janino
java-jgit
java-jsch-agentproxy-jsch
java-objenesis
java-sonatype-aether-api
java-sonatype-spice-parent-pom
java-surefire-logger-api
java-xom
java-xsdlib
js-context-menu
jucipp
julia-calculus
julia-deepdiffs
julia-genericschur
julia-infinity
julia-wcs
kalendar
kbd-neo
khmer
launchmon
leptonica
libfreenect-examples
libiax2
libnfsidmap
libpsyc
libsigrokdecode
libstdc++
libtcod
libtmcg
libtorrent-rasterbar

Don't add propagated-inputs for all outputs

[宋文武]

Hello, we have a TODO for "extend `propagated-inputs` with support for
multiple outputs".  I try to do it for a while, but unable to find a
clear way, since add a new syntax for specify output in
propagated-inputs require changes in too many places..

Think about the intention, what we want is to avoid unwanted
propagated-inputs for building a package or user profiles, and
propagated-inputs is mostly used for development packages which
requiring headers/libraries from its inputs.  It seems I can hardcode
the choice here to the "dev" output (if a package have both "dev" and
"out", its "out" should considered be an application) or the "out"
output (a library/development package).


Then the change is straight:

>From 98a8666a0cbf33e24efff615243b98144a92c950 Mon Sep 17 00:00:00 2001
Message-ID: <98a8666a0cbf33e24efff615243b98144a92c950.1693047369.git.iyzs...@member.fsf.org>
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 26 Aug 2023 18:27:09 +0800
Subject: [PATCH] packages: Don't propagate inputs for non-development package
 outputs.

* guix/packages.scm (transitive-inputs): Only include propagated inputs from a
package for its "dev" output, or its "out" output if the package doesn't have
a "dev" one.
---
 guix/packages.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index ba98bb0fb4..435d55de71 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1143,7 +1143,13 @@ (define (transitive-inputs inputs)
(loop rest result propagated first? seen)
(loop rest
  (cons input result)
- (cons (package-propagated-inputs package) propagated)
+ ;; Only add propagated inputs for PACKAGE:dev, or PACKAGE:out
+ ;; when PACKAGE doesn't have a "dev" output.
+ (if (if (member "dev" (package-outputs package))
+ (member "dev" outputs)
+ (or (null? outputs) (member "out" outputs)))
+ (cons (package-propagated-inputs package) propagated)
+ propagated)
  first?
  (vhash-consq package outputs seen
   ((input rest ...)

base-commit: eeb71d778f149834015858467fbeeb1276d96d1d
-- 
2.41.0



Not much benifits now, but i think it will helps when we have more
mulitple outputs packages.  Also how about add a slimming team aiming to
reduce the closure size of packages and system, anyone interested?

Thanks. 拾

Re: A certain new commiter

[宋文武]

Hilton Chain  writes:

> Hello Guix,
>
> With the commit [1] made hours ago, I have been granted commit access
> to Guix repository.
>
> Currently, I'm maintaining packages I may use and those I've touched,
> and for now I have no specific plan to move on.  This means I can have
> more time to go through the review process, and I'm glad to do so.
>
> I'm also hako on libera.chat, please contact me if there's anything I
> can help with.
>

Welcome, and happy hacking! 拾

Thanks.

Re: bug#64798: [PATCH 000/209] update kde package and add plasme desktop

[宋文武]

宋文武  writes:

> 宋文武  writes:
>
>> Zheng Junjie <873216...@qq.com> writes:
>>
>>> hello!
>>>
>>> I updated some kde package, and add plasma desktop.
>>
>> Hello, I had pick those patches from your Github repo, and modify
>> some commit messages (mostly from 'use ...' to 'Use ...', 'add ...' to
>> 'Add ...') to hopefully align better with our style.
>>
>> And put it here https://codeberg.org/iyzsong/guix with my wip (building
>> qtwebengine now...), I plan to update all KDE packages (games, internet,
>> multimedia, etc.), and will push to a kde-updates branch on
>> git.savannah.gnu.org once it's in good shape.
>
> I have push a kde-updates branch to savannah, with plasma update to
> 5.27.7.  Applications are all build fine but some have runtime issues.
> I haven't got Plasma built due to substitute issues, will try later in
> next days...
>
> In addition to version updates, there have some changes:
>
> 2b9e2e65cf gnu: Remove kwayland-server.
> 08846c7ebf gnu: qgpgme: Propagate gpgme.
> b9e192ad9a gnu: Add qcoro-qt5.
> ab3eba1447 gnu: Add kpipewire.
>
> Review is welcome, Thanks!

Plasma build and works fine.
Also fixed 3 mahjongg games with:

>From 1e4085670a149df7e9858ef6c52995415cf27037 Mon Sep 17 00:00:00 2001
Message-ID: <1e4085670a149df7e9858ef6c52995415cf27037.1691235884.git.iyzs...@member.fsf.org>
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 5 Aug 2023 15:37:57 +0800
Subject: [PATCH 1/2] gnu: kajongg: Hardcode paths to 'ogg123' and 'python3'.

* gnu/packages/kde-games.scm (kajongg)[inputs]: Add vorbis-tools.
[arguments]<#:phases>: Hardcode paths to 'ogg123' and 'python3'.
---
 gnu/packages/kde-games.scm | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/kde-games.scm b/gnu/packages/kde-games.scm
index a47deb6c68..9e2b885c2b 100644
--- a/gnu/packages/kde-games.scm
+++ b/gnu/packages/kde-games.scm
@@ -37,7 +37,8 @@ (define-module (gnu packages kde-games)
   #:use-module (gnu packages python)
   #:use-module (gnu packages python-web)
   #:use-module (gnu packages python-xyz)
-  #:use-module (gnu packages qt))
+  #:use-module (gnu packages qt)
+  #:use-module (gnu packages xiph))
 
 (define-public ktuberling
   (package
@@ -300,7 +301,15 @@ (define-public kajongg
  (substitute* "src/mjresource.py"
(("'share', 'kmahjongglib'" all)
 (string-append "'" (assoc-ref inputs "libkmahjongg")
-   "/share', 'kmahjongglib'")
+   "/share', 'kmahjongglib'")))
+ (substitute* "src/sound.py"
+   (("oggBinary = 'ogg123'")
+(format #f "oggBinary = '~a'"
+(search-input-file inputs "bin/ogg123"
+ (substitute* "src/common.py"
+   (("interpreterName = 'python3'")
+(format #f "interpreterName = '~a'"
+(search-input-file inputs "bin/python3"))
  (add-after 'qt-wrap 'wrap
(lambda* (#:key outputs #:allow-other-keys)
  (let ((out (assoc-ref outputs "out")))
@@ -327,7 +336,8 @@ (define-public kajongg
python-qtpy
python-zope-interface
qtbase-5
-   qtsvg-5))
+   qtsvg-5
+   vorbis-tools))
 (home-page "https://apps.kde.org/kajongg/;)
 (synopsis "Classical Mah Jongg game for 4 players")
 (description "Kajongg is the ancient Chinese board game for 4 players.

base-commit: 0a4490e4fd77a0dd50262d080bd024a2f41cdc4a
-- 
2.41.0

>From 4c0a6635d81970da2f461757ff891f2528a57b5c Mon Sep 17 00:00:00 2001
Message-ID: <4c0a6635d81970da2f461757ff891f2528a57b5c.1691235884.git.iyzs...@member.fsf.org>
In-Reply-To: <1e4085670a149df7e9858ef6c52995415cf27037.1691235884.git.iyzs...@member.fsf.org>
References: <1e4085670a149df7e9858ef6c52995415cf27037.1691235884.git.iyzs...@member.fsf.org>
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 5 Aug 2023 19:36:49 +0800
Subject: [PATCH 2/2] gnu: libkmahjongg: Make its tilset available to games.

* gnu/packages/kde-games.scm (libkmahjongg)[arguments]: Add a phase
to add its "$out/share" to XDG_DATA_DIRS.
---
 gnu/packages/kde-games.scm | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gnu/packages/kde-games.scm b/gnu/packages/kde-games.scm
index 9e2b885c2b..8ed530d83e 100644
--- a/gnu/packages/kde-games.scm
+++ b/gnu/packages/kde-games.scm
@@ -27,6 +27,7 @@ (define-module (gnu packages kde-games)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system qt)
+  #:use-module (guix gexp)
  

Re: A Forum for Guix Users

[宋文武]

Sarthak Shah  writes:

> The reason why I'm suggesting a move away from mailing lists is that it is a 
> lot easier to follow threads on forums. 
> You have all the replies on the same page, compared to clicking on the link 
> of each reply, realizing it doesn't have the answer, clicking
> another link and so on...

Well, I could not image we'd move away from mailing lists (for patches,
issues)...  For QA forum we have the help-guix list, it has an
unofficial public-inbox instance at https://yhetil.org/guix-user/ ,
which show replies in one page, and can be clicked to reply by email...
Maybe we can write a more polished web interface for public-inbox.


Also today I learned there exist fediverse reddit like sites using
lemmy/kbin, where you can get a modern forum experience. eg:
https://kbin.social/m/g...@lemmy.ml (not much people there though...)


If we can bridge mailing lists with those fediverse sites, that will be
cool!  樂

Re: Guix's python has pip's user dir in its loadpath

[宋文武]

e...@beaver-labs.com writes:

> Dear Guix devs,
>
> While working around this bug:
>
> https://issues.guix.gnu.org/63912
>
> I found that guix's Python will load anything in
> .local/lib/python3.10/site-packages/ over any installed package in the
> current profile. This makes pip-installed package overshadow guix's.
>
> I'm not sure this is desirable behavior. What I was expecting was for
> the host system's python packages to be completely ignored.

Hello, I think this is a well-known issue according to PEP 668:
https://peps.python.org/pep-0668/

The suggested solution is to introduce a `EXTERNALLY-MANAGED` file to
disable the useage of `pip install`, and advice `guix shell` or `venv`.

Similiar to ArchLinux: 
https://gitlab.archlinux.org/archlinux/packaging/packages/python/-/commit/547eee4deb54fda2a3892997145b57de37301c5d

Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors

[宋文武]

Christopher Baines  writes:

> While I did stop running a mirror in Singapore, it's now back and from
> the discussion on IRC today [3] there was some anecdotal evidence that
> this helps with fetching substitutes from China.

Yes, only the Singapore IPv4 mirror is usable for me in China.


[berdeaux]
wget 
'https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0'
Connecting to bordeaux.guix.gnu.org 
(bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected.
.. 159.69K  8.27KB/seta 6h 50m 

wget -4 
'https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0'
Connecting to bordeaux.guix.gnu.org 
(bordeaux.guix.gnu.org)|185.233.100.56|:443... connected.
.. 31.69K  5.60KB/seta 10h 6m ^C

[us-east-mirror]
wget 
'https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0'
Connecting to bordeaux-us-east-mirror.cbaines.net 
(bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected.
Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.2’
..  639.69K  26.8KB/seta 1h 57m ^C

[singapore-mirror]
wget 
'https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0'
Connecting to bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)|2401:c080:1400:71df:5400:4ff:fe73:757d|:443...
 connected.
.. 415.69K  22.1KB/seta 2h 9m  ^C

wget -4 
'https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0'
Connecting to bordeaux-singapore-mirror.cbaines.net 
(bordeaux-singapore-mirror.cbaines.net)|64.176.80.78|:443... connected.
..  14.59M   199KB/seta 11m 22s

Re: bug#20255: 'search-paths' should respect both user and system profile.

[宋文武]

Maxim Cournoyer  writes:

> Hi,
>
> 宋文武  writes:
>
>> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
>> search-paths from multiple profiles by `guix package --search-paths`, in
>> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
>> update).  
>>
>>
>> Close now!

Well, I reopen this since the changes is not totaly (duplicates in
/etc/profile, guix home changes) done, sorry...

>
> Cool, thanks for the update.  Perhaps a NEWS entry would be useful to
> keep Guix System existing users in the loop?  Until we have a better
> mechanism/approach to these stateful files that don't change past the
> original installation.

Now, I send more patches with NEWS entry.


Add guix-devel to CC for more reviews, TIA!

Re: Commit Access: jgart

[宋文武]

"jgart"  writes:

> Hi Guixers,
>
> Thanks for granting me commit access. I'm looking forward to helping out with 
> patch review, with a
> particular focus on moving patches along for the Python team.
>
> I also intend to continue contributing more packages, updates, and 
> improvements.
>
> Thanks again for granting me the privilege of commit access and I am looking 
> forward to continuing our collaborations.
>
> all best,

Hi jgart, congrats and thank you for joining the party!  
Always a pleasure working with you :)

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

宋文武  writes:

> I got 'guix-build-coordinator-agent-only' built now, running it (with
> --help) will segfault though..
>
>
> How to run it to connect to the coordinator?
>

Update, now it running fine with:
```
guix-build-coordinator-agent  \
  --uuid= \
  --password= \
  --coordinator=https://rack.z572.online \
  --substitute-urls='https://data.guix.gnu.org https://cache.z572.online 
https://mirrors.sjtug.sjtu.edu.cn/guix/'
```

So, Z572 (his email seems to be blocked the mailing lists..) has setup a
guix-build-coordinator with
guix-build-coordinator-queue-builds-service-type, derivations fetched
from data.guix.gnu.org.  Then next we'd like to make our riscv64
machines to join the offical build farm.  Does the agent machine have to
belong to guix committer?

Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)

[宋文武]

Simon Tournier  writes:

> Since it is computing, we could ask about the bootstrap of such
> generated data.  I think it is a slippery slope because it is totally
> not affordable to re-train for many cases: (1) we would not have the
> hardware resources from a practical point of view,, (2) it is almost
> impossible to tackle the source of indeterminism (the optimization is
> too entailed with randomness).  From my point of view, pre-trained
> weights should be considered as the output of a (numerical) experiment,
> similarly as we include other experimental data (from genome to
> astronomy dataset).
>
> 1: https://salsa.debian.org/deeplearning-team/ml-policy
> 2: https://people.debian.org/~lumin/debian-dl.html
>

Hello, zamfofex submited a package 'lc0', Leela Chess Zero” (a chess
engine) with ML model, also it turn out that we already had 'stockfish'
a similiar one with pre-trained model packaged.  Does we reached a
conclusion (so lc0 can also be accepted)?  Or should we remove 'stockfish'?

Thanks!

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

宋文武  writes:

> A friend (Z572 from #guixcn) of mime had setup a coordinator /
> substitute server of riscv64 (running guix system) at
> https://cache.z572.online.

Well, he has a vps virtual machine (x86_64) running guix system, but
offload to a riscv64 licheepi 4a for building now...

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

宋文武  writes:

> Christopher Baines  writes:

>> The first hurdle to overcome is just getting the build coordinator agent
>> available on the system. For the board I have, I cross compiled the
>> guix-build-coordinator-agent-only package.
>
> Okay, now I installed guix from debian on my visionfive2, and start
> compiling for it.

I got 'guix-build-coordinator-agent-only' built now, running it (with
--help) will segfault though..


How to run it to connect to the coordinator?

Also my net speed to ci/bordeaux is unuseable, i guess this will prevent
use my sbc as a build agent for the official build farm?

A friend (Z572 from #guixcn) of mime had setup a coordinator /
substitute server of riscv64 (running guix system) at
https://cache.z572.online.  I tried connect to it with:

```
guix-build-coordinator-agent  \
  --uuid= \
  --password= \
  --coordinator=https://cache.z572.online/agent \
  --substitute-urls='https://cache.z572.online'
```

but got:
```
locale is C.UTF-8
(gnutls version: 3.7.7, guix version: 1.4.0-6.dc5430c)
skipping writing metrics as /var/lib/prometheus/node-exporter does not exist
2023-05-13 11:27:16 (INFO ): starting agent 07949cb9-27e0-4cab-a1be-4a6468767835
2023-05-13 11:27:16 (INFO ): connecting to coordinator 
https://cache.z572.online/agent
Backtrace:
   2 (primitive-load 
"/gnu/store/5ijyqpfl667585pjyh8izvwkipfaaw4b-guix-build-coordinator-agent-only-0-81.3f6473c/bin/.guix-build-coordinator-agent-real")
In guix-build-coordinator/agent.scm:
499:7  1 (run-agent _ #< 3f7d38d0a0> 
("riscv64-linux") _ #f _ _ _ _ _)
In srfi/srfi-43.scm:
Exception thrown while printing backtrace:
In procedure vector-ref: Argument 2 out of range: 14

srfi/srfi-43.scm:968:7: vector->list: expected vector, got #f
```

Maybe my arguments or his endpoint is wrong.


Help need, thank you!

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

Christopher Baines  writes:

> The NAT is no problem, the build coordinator (intentionally) has very
> few requirements.

That's great.

> The first hurdle to overcome is just getting the build coordinator agent
> available on the system. For the board I have, I cross compiled the
> guix-build-coordinator-agent-only package.

Okay, now I installed guix from debian on my visionfive2, and start
compiling for it.

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

Christopher Baines  writes:

> This is a start, but more hardware will be needed to keep up with the
> master branch, plus testing patches and other branches, so if you have
> hardware to hand, or know of hardware available for purchase that might
> be suitable, that would be really useful to know about.

Hello I have a visionfive2 4GiB memory model with a nvme disk, does it
suitable to join the guix build farm?  My home network is behind NAT.

Thank you!

Re: Call for members to join the Xfce, LXQt and Localization teams

[宋文武]

宋文武  writes:

> Zhu Zihao  writes:
>
>> count me in :)
>
> Good, all three?  Thank you!

As we talked in #guixcn, join you to the xfce and localization team,
thanks!

Re: Call for members to join the Xfce, LXQt and Localization teams

[宋文武]

Zhu Zihao  writes:

> count me in :)

Good, all three?  Thank you!

Call for members to join the Xfce, LXQt and Localization teams

[宋文武]

Hello, I recently joined/created teams for xfce, lxqt, and localization,
in which I am the only member so far, so I'd like to call for more
members.

I think Team members mostly do (in the scope and area of expertise by team):
- Review patches from guix-patches.
- Handle issues or usages support from guix-help and bug-guix.

And the goals of said 3 teams are:
- xfce: Maintain the Xfce desktop environment in Guix, timely
  updates/releases.

- lxqt: Maintain the LXQt desktop environment in Guix, timely
  updates/releases.

- localization: Help your friends which doesn't use English as the main
  system language to use the Guix System, by setup the required fonts
  and input methods etc.  Also maintain the required packages.

If this interests you, please reply or send a patch for
'etc/teams.scm.in', thank you!

I have CCed a list of people which I think might be interested (by looked
at git shortlog or asked on IRC) :)

Re: bug#61894: [PATCH RFC] Team approval for patches

[宋文武]

Ludovic Courtès  writes:

> Hi Chris,
>
> Christopher Baines  skribis:
>
>> Regarding this change specifically though, I'm unclear how it would
>> impact the things I push for others. I pushed some patches today, would
>> this mean that I'd have to look at what team/teams are involved
>> (according to /etc/teams.scm.in) for each commit/series, and then either
>> continue if I'm a member of that team, or skip it if I'm not?
>>
>> If I'm going to not be pushing stuff I would have previously pushed
>> because I'm not in the relevant teams, maybe I should just add myself to
>> every team? I guess this is not a serious question, but I'm more making
>> the point that if teams become a formal part of patch review, then some
>> formalities over membership of a team is probably a prerequsite.
>>
> [...]
>
> Good questions.
>
> For teams like ‘core’ or ‘home’, there should be no overlap, so it’s
> quite easy to see who’s in charge.
> [...]
> For “random packages”, I’m fine with the status quo.

Hello, I'd like to know if I'm working fine according to the status
quo..

I usually push patches for others who don't have commit access, while
most packages don't have a team at all, and some with me as the only
team member.

Should I wait for another commiter's approvol under this new policy or
can I push "random packages" (eg: jwm) solo under the status quo?  For
packages I as the only team member (eg: fcitx), should I looking for
another commiter for other's patches and my patches?

Thank you!

Re: bug#61894: [PATCH RFC] Team approval for patches

[宋文武]

Andreas Enge  writes:

> Hello,
>
> in the current situation I think the suggestion is putting the horse before
> the cart. In a first step before adding policy, we should make the teams
> functional.

I find debian have various teams, and each team has a page for packages
status: https://tracker.debian.org/teams/debian-multimedia/

If we want more functional/formol teams, I think we need more tools like
this.

How to run mumi locally?

[宋文武]

Hello, I try to run mumi locally on guix system with:
--8<---cut here---start->8---
(service mumi-service-type
 (mumi-configuration
   (mailer? #f)))
--8<---cut here---end--->8---

But then curl localhost:1234 return a empty reply.


In /var/log/mumi.worker.log there are errors:
--8<---cut here---start->8---
2023-02-01 13:10:26 Starting full indexing.
2023-02-01 13:10:26 worker error: (system-error open-file ~A: ~S (No such file 
or directory /var/mumi/data/spool/index.db.realtime) (2))
2023-02-01 13:10:26 worker error: (system-error open-file ~A: ~S (No such file 
or directory /var/mumi/data/spool/index.db.realtime) (2))
--8<---cut here---end--->8---

I think this means I have to get debbugs data (index, log, or maildir?)
files somehow.  How to do it?  Thank you!

Re: Mumi Feature Request: Easier way to apply patches from web interface

[宋文武]

Arun Isaac  writes:

>> Maybe add a guix command for issues/patches?
>>
>> guix issues new
>> guix issues open nnn
>> guix issues reply nnn 
>> guix issues apply nnn
>> guix issues close nnn
>
> Indeed, we should have something like this. But, probably better to put
> it in mumi so that other projects that use debbugs (I have skribilo in
> mind) can also benefit.

Yes, put it in mumi make senses, find a previous thread:

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[宋文武]

Christopher Baines  writes:

> guix-comm...@gnu.org writes:
>
>> This is an automated email from the git hooks/post-receive script.
>>
>> iyzsong pushed a commit to branch master
>> in repository guix.
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new a3b57e57e6 gnu: w3m: Update to 0.5.3+git20230121.
>> a3b57e57e6 is described below
>>
>> commit a3b57e57e68a1f4848bf8bacd797c5d989f56de2
>> Author: André Batista 
>> AuthorDate: Fri Jan 27 09:37:02 2023 -0300
>>
>> gnu: w3m: Update to 0.5.3+git20230121.
>> 
>> * gnu/packages/w3m.scm (w3m): Update to 0.5.3+git20230121.
>> 
>> Signed-off-by: 宋文武 
>> ---
>>  gnu/packages/w3m.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Given the +1800 dependent packages, the contributing guidance suggests
> this change should go to the core-updates branch.
>
> → guix refresh -l w3m
> Building the following 984 packages would ensure 1859 dependent packages
> are rebuilt: ranger@1.9.3 ...

oops, I forget to check its dependent, think the only one is
emacs-w3m...  Sorry for the troubles!

Re: Mumi Feature Request: Easier way to apply patches from web interface

[宋文武]

"jgart"  writes:

> Note that I realize that this is possible:
>
> https://man.sr.ht/~whereiseveryone/wiki/tipsandtricks.md#applying-patches-from-issuesguixgnuorg
>
> or
>
> wget -O- https://issues.guix.gnu.org/issue/48364/patch-set/2 | git am
>
> What this feature is is to generate the appropriate command for the 
> respective patch series that you'd like to apply from 
> https://issues.guix.gnu.org

Maybe add a guix command for issues/patches?

guix issues new
guix issues open nnn
guix issues reply nnn 
guix issues apply nnn
guix issues close nnn

Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[宋文武]

"("  writes:

> On Wed Jan 4, 2023 at 12:00 PM GMT, Ludovic Courtès wrote:
>> Finally pushed!  It should show up online soon.  Looking forward to
>> part 2.  :-)
>
> \o/
>
> Next part will be about monads and G-expressions :)
>

Great, I enjoy read Part 1, and waiting for next...  Thank you!

Re: ️ Install every Guix package ️

[宋文武]

"jgart"  writes:

> Hi Guixers,
>
> How would you approach writing a script that installs every Guix package 
> exhaustively for your current revision?
>
> I'm thinking of something similar to `all-packages` on PyPi but for every 
> Guix package (the whole wide ️).
>
> https://pypi.org/project/all-packages/


Maybe guix package -m manifest.scm:

--8<---cut here---start->8---
(use-modules
 (srfi srfi-1)
 (ice-9 match)
 (gnu packages)
 (guix packages))

;;; copied from guix/scripts/weather.scm.
(define (all-packages)
  "Return the list of public packages we are going to query."
  (delete-duplicates
   (fold-packages (lambda (package result)
(match (package-replacement package)
  ((? package? replacement)
   (cons* replacement package result))
  (#f
   (cons package result
  '()

  ;; Dismiss deprecated packages but keep hidden packages.
  #:select? (negate package-superseded))
   eq?))

(packages->manifest (all-packages))
--8<---cut here---end--->8---

No idea how long it will be :)

Re: Dissecting Guix -- blog post series

[宋文武]

"("  writes:

> Heya!
>
> Some of you may have seen on IRC that I've been writing a post for the Guix
> blog that I hope will form the first part of a series.  This series aims to
> dissect the internals of Guix, from bottom to top.  Perhaps they could go in
> the cookbook once the series is done?  My aim is to write the following posts
> (complete with cheesy titles :P), hopefully one per week:
>
> * Dissecting Guix, Part 1: Derivations
>
> Discusses derivations, the bottom layer of the Guix compilation tower, and
> dissects some example derivations.
>
> A draft of this post may be found below. Please feel free to critique! :)

Great, thank you!

I think it's missing what "build-derivations" do, or "Part 0: Store".

Re: Clarify the license field of the package

[宋文武]

Maxime Devos  writes:

> On 22-08-2022 11:02, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>>  The license of the package; a value from ‘(guix licenses)’, or a
>>  list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>> files?
>
> (If 'built binary files', I would include generated or copied
> documentation in the list. And icons, .desktop files, ..., I'm not
> restricting myself to _executable_ binaries here and also not to
> binaries that aren't sources as well.)

Sure, it should be clear what license any file has.  Below, I'd refer
them as sources and outputs.
>
> Rarely, there is some weirdness where the source code is free
> (VSCodium?) but the official build has a non-free license
> (VSCode?). At least for that example, it doesn't apply to Guix though
> (because VSCodium is not packaged, and because with some rare
> exceptions we build from source).
>
> However, in my experience, in free software they almost always have
> the same license, so the distinction appears meaningless to me with
> the possible exception of build scripts and test files (including, but
> not limited to, test code).

There are 2 main cases which the licenses of sources and outputs of a
package can be different:

  1. statically linked binaries (eg: golang, rust), leading outputs has
  more licenses than the package's sources (should be all sources), see:
  
https://artemis.sh/2022/08/21/this-program-is-illegally-packaged-in-14-distributions.html

  2. not used sources or when licenses not propagated to outputs during
  build (eg: tests, build tools, sources generator), leading outputs has
  less licenses than sources.

I think this distinction will be important when we audit the license
compatibility issues for outputs, since we also distribute outputs via
substitutes.
>
> I think it should include the source files, as the license of the
> source is important for people doing 'guix build --source'.

I agree too.
>
>> 2. When its value is a list of multiple licenses, it's files under
>> different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
>> or files under one license select from choices?
>>
>> My guess is that the license field is for source files since we can
>> disable binary substitutes, and list is used for files under different
>> licenses.
>>
>> Does my guess is correct?  Thank you!
>
> As answered in a reply to a patch, myself I go for 'files under
> different licenses' -- to me it seems hard to go wrong with 'just
> include all participating licenses' instead of trying to make a
> selection.
>
> However, keep in mind that sometimes a file is part licensed as, say,
> BSD(*), part as Expat, with modifications under the GPL -- to me it
> appears that for practical purposes you could consider such a thing to
> be 'effectively GPL', but that's not 100% accurate, as it appears
> required to preserve the BSD and Expat license text. (Such things can
> happen when incorporating code from other, differently-licensed,
> projects).
>
> (*) let's say without the advertising clause or whatever it was (IIRC
> and IIUC the original BSD was incompatible with the GPL?).
>
> If there's some consensus, I think it would be nice to clarify this
> matter in the manual.

Yes, after read
<https://www.gnu.org/licenses/license-compatibility.html> (Combining code),
I think we should list all licenses of sources files in the package's
license field.  

And for license choices, write in comments, since we lacking "OR", our
list of multiple license is same as "AND" in SPDX license expressions.

https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
https://wiki.spdx.org/view/FileNoticeExamples

Later, I think we can introduce a "OR" form for license field or use SPDX 
license
expressions directly.


In summary, I think our next steps are:

1. Clarify the license field is for sources and the list is for files
under multiple license (required to simultaneously comply with two or
more licenses) in our manual.

2. Consider extend the license field with "OR" form or use SPDX license
expressions.

3. Introduce some ways to show and check licenses for package's outputs.


What do you think?  Thanks for help!

Re: Clarify the license field of the package

[宋文武]

John Kehayias  writes:

> Hello 宋文武,
>
> On Mon, Aug 22, 2022 at 05:02 PM, 宋文武 wrote:
>
>> Hello list, I have some questions about the 'license' of a package,
>> currently defined as:
>>
>> The license of the package; a value from ‘(guix licenses)’, or a
>> list of such values.
>>
>> 1. It's the license of source files (guix build -S) or built binary
>>files?
>>
>
> Not a lawyer by any means, so I'm not sure how it works. For sure it
> applies to the source, but after building the binary output will
> contain a LICENSE or COPYING file (always? I would assume). Other than
> that, I don't know :)

Yes, guix distribute both sources and binaries (via substitute).  As a
packager, I'm afraid to get that 'license' field wrong...

> [...]
> Those are my guesses/experiences above, hope that is helpful.

Thank you for join discussion!

Clarify the license field of the package

[宋文武]

Hello list, I have some questions about the 'license' of a package,
currently defined as:

The license of the package; a value from ‘(guix licenses)’, or a
list of such values.

1. It's the license of source files (guix build -S) or built binary
   files?

2. When its value is a list of multiple licenses, it's files under
   different licenses (eg: lib/*.so under LGPL, while bin/* under GPL),
   or files under one license select from choices?

My guess is that the license field is for source files since we can
disable binary substitutes, and list is used for files under different
licenses.

Does my guess is correct?  Thank you!

Re: 100k commits!

[宋文武]

Marius Bakke  writes:

> Guix,
>
> We just passed 100 000 commits!
>
> The lucky winner is ...
>
>   commit 9fe9856ebef515927900e56686a1071936bdafcc
>   Author: Ricardo Wurmus 
>   Date:   Wed Aug 10 12:19:55 2022 +0200
>
>   gnu: r-fontawesome: Update to 0.3.0.
>
>   * gnu/packages/cran.scm (r-fontawesome): Update to 0.3.0.
>
> An appropriate package name for such a big milestone.  :-)
>
> Congratulations for making it this far, and a big thank you to the 700+
> contributors who made this possible.  You are truly awesome.
>
> Happy hacking!

Awesome, happy hacking!

Re: bug#57104: Python-symengine fails to build

[宋文武]

Andreas Enge  writes:

> Since it replaces a broken package by a more modern broken package, I still
> took the liberty to push, but it would be nice if someone with knowledge of
> python and/or symengine could have a look. Disabling the tests makes the
> compilation succeed, but it would be nice to find a better solution...
>

Fixed it by using 'nosetests' to run the tests.

Close now, thanks!

Re: [bug]: xfce4: xfpm-power-backlight-helper alway let me input password.

[宋文武]

tumashu   writes:

>>At 2022-02-22 15:04:22, "宋文武"  wrote:
>>
>>>tumashu  writes:
>>>
>>>> Hello:
>>>>
>>>>   When I update my guix system today, I have found that run xfce4: 
>>>> xfpm-power-backlight-helper alway let me input password,  how to avoid 
>>>> input password?
>>>
>>>No answer yet, my understand is that:
>>>
>>>1. xfpm-power-backlight-helper need to run with 'pkexec'.
>>>2. 'pkexec' will always ask for password unless some polkit rules allow
>>>   the action.
>>>3. '/etc/polkit-1/actions/org.xfce.power.policy' allows the action, but its
>>>   executable is something like
>>>   
>>> '/gnu/store/vsnzjhjm37cd42w7vv7mxgy8hi8w6zi0-xfce4-power-manager-4.16.0/sbin/xfpm-power-backlight-helper'.
>>>   
>>>So run 'pkexec xfpm-power-backlight-helper' will ask for password while 
>>>'pkexec /gnu/store/.../xfpm-power-backlight-helper' will not.
>>
>>no,  need input password when run "pkexec 
>>/gnu/store/.../xfpm-power-backlight-helper"
>>
>>I do not run this command by hand, when I start xfce4 with slim,  a window 
>>pop and let me input password many time,
>>when I press Fkey,  ask password again.
>
> When I test gnome and mate, have no this problem.
>

The policykit rule only allow "active" session, I guess slim may lack
'elogind-service' support to be an "active" session.

I have 'elogind-service' and use 'sx' to start xfce, no problem here...

My ~/.config/sx/sxrc:

#!/bin/sh
setxkbmap dvorak
xsetroot -solid sienna -cursor_name cross

exec dbus-run-session -- startxfce4



Hope this helps!

Re: [bug]: xfce4: xfpm-power-backlight-helper alway let me input password.

[宋文武]

tumashu  writes:

> Hello:
>
>   When I update my guix system today, I have found that run xfce4: 
> xfpm-power-backlight-helper alway let me input password,  how to avoid input 
> password?

No answer yet, my understand is that:

1. xfpm-power-backlight-helper need to run with 'pkexec'.
2. 'pkexec' will always ask for password unless some polkit rules allow
   the action.
3. '/etc/polkit-1/actions/org.xfce.power.policy' allows the action, but its
   executable is something like
   
'/gnu/store/vsnzjhjm37cd42w7vv7mxgy8hi8w6zi0-xfce4-power-manager-4.16.0/sbin/xfpm-power-backlight-helper'.
   
So run 'pkexec xfpm-power-backlight-helper' will ask for password while 'pkexec 
/gnu/store/.../xfpm-power-backlight-helper' will not.

Re: Rethinking propagated inputs?

[宋文武]

Hello, good plan!


Liliana Marie Prikler  writes:

> At this point the question then becomes what to name this "build"
> output and what to put into it besides pkg-config stuff.
In Debian, it's a "dev" package, includes .h (C headers), .pc, .a
(static libraries).


> Particularly in the land of glib, there also exist typelibs, which can
> be used as "build" inputs in the case of Vala or as runtime inputs in
> the case of pygobject and other language bindings.
It's "gir1.2-glib-2.0" in debian, we can add a "gir" output.


> Perhaps this is
> early bikeshedding when we'd actually need to code up #:by, but what
> would be the better approach here?  Separate "build" into
> "pkg-config", "cmake" (for CMake-based package discovery), "typelib"
> etc. or have one more or less anonymous blob called "build"?
I think we should have "build" (or "dev") and "typelib" (or "gir"), but
not "pkg-config" and "cmake" in most cases.

With a "dev" output, we don't need 'propagated-inputs' in other outputs
most cases, so reduce the mess for profiles.

With a "typelib" output, we can reduce the runtime closure size for
packages which don't depends on them.

The build time clojure size reduced by "pkg-config" and "cmake" outputs is
small.

Re: GNU Guix 1.3.0 released

[宋文武]

Maxim Cournoyer  writes:

> We are pleased to announce the release of GNU Guix 1.3.0!
>
> This release corresponds to 8,300 commits over almost 6 months by 212
> people.  Support for the POWER9 platform is now offered as technological
> preview.  This release adds new features, refines the user experience
> and improves performance.  It also includes many new packages and
> services along bug fixes--see below for a list of changes.
>
> Read more about today’s announcement at:
>
>   https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released
>

Cheers!  Thank you, to everyone who make it possible!

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[宋文武]

Leo Famulari  writes:

> [...]
> To clarify, Leo Prikler is not the same person that was involved in
> removing the Cairo bug fixes. That was a different person, also named
> Leo.
>
> Not me, either :)

Um, my bad, thank you!

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[宋文武]

宋文武  writes:

> Leo Prikler  writes:
>
>> Hi Mark,
>>
>> Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
>>> Hi Leo,
>>> 
>>> Leo Prikler  writes:
>>> 
>>> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>>> > > I also spent some time re-reading messages that Mark sent in this
>>> > > thread and, like him, I really don't understand what Mark did
>>> > > wrong.
>>> > > 
>>> > > For sure Mark /insisted/ that Raghav and Léo did something wrong
>>> > > with
>>> > > some commits, we can say Mark did it being /direct/ and
>>> > > /accusatory/
>>> > > but we cannot really say Mark assumed bad faith from them.
>>> > He did wrong insofar as his accusatory message read as though he
>>> > was
>>> > assuming bad faith
>
> Hello Leo, I see nothing wrong for assuming bad faith when security
> fixes of packages are removed, in the end the truth matter, which I
> believe is: You thought the patches for cario is not needed now on
> core-updates, so you remove them.

Sorry, I'm not a native English speaker, what I mean is "for assuming
bad intent", or more clearly: "for assuming that you remove thoese
security patches to introduce backdoors on purpose".  I don't think Mark
try to prove you're lying from his messages, if that's what "assumed bad
faith" means...

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[宋文武]

Leo Prikler  writes:

> Hi Mark,
>
> Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
>> Hi Leo,
>> 
>> Leo Prikler  writes:
>> 
>> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>> > > I also spent some time re-reading messages that Mark sent in this
>> > > thread and, like him, I really don't understand what Mark did
>> > > wrong.
>> > > 
>> > > For sure Mark /insisted/ that Raghav and Léo did something wrong
>> > > with
>> > > some commits, we can say Mark did it being /direct/ and
>> > > /accusatory/
>> > > but we cannot really say Mark assumed bad faith from them.
>> > He did wrong insofar as his accusatory message read as though he
>> > was
>> > assuming bad faith

Hello Leo, I see nothing wrong for assuming bad faith when security
fixes of packages are removed, in the end the truth matter, which I
believe is: You thought the patches for cario is not needed now on
core-updates, so you remove them.


> [...]
> Well, you did fumble on those facts a little, because the true history
> of the misleading commits was only discovered later.  So did I in the
> same thread.  Either way, "just pointing out facts" is not an accurate
> assessment in my opinion; facts are nothing without interpretation,
> which see.

Yes, you have to take actions based on interpretation to get more clues
from existed facts to reach the truth.

> [...]
> Let it be said, that I don't condemn you for starting this thread.  Not
> only did it highlight an issue, that would otherwise have gone
> unnoticed, I think most of the participants are now more acutely aware
> of what might go wrong if they evade review.  It is sad, that things
> turned out the way they did, but despite what others might claim you
> don't bear sole responsibility for that.

Sure, I think we just lack some trust.  With the trust, you'll know that
Mark only want to confirm the truth with you and avoid this kind of
issues in the future.

Re: A "cosmetic changes" commit that removes security fixes

[宋文武]

Mark H Weaver  writes:

> Hi Raghav,
>
> Raghav Gururajan  writes:
>
>>> Those commits on 'core-updates' were digitally signed by Léo Le Bouter
>>>  and have the same problems: they remove security
>>> fixes, and yet the summary lines indicate that only "cosmetic changes"
>>> were made.
>>
>> Yeah, the commit title didn't mention the change but the commit message did.
>
> I'm sorry, but that won't do.  There are at least three things wrong
> with these commits:
>
> (1) The summary lines were misleading, because they implied that no
> functional changes were made.

Yes, if the title can't summary the change, then the change should be
splited into multiple commits.
>
> (2) The commit messages were misleading, because they failed to mention
> that security holes which had previously been fixed were now being
> re-introduced.  That wasn't at all obvious.
>
> Commits like these, which remove patches that had fixed security
> flaws, are fairly common: someone casually looking over the commit
> log might assume that the patches could be safely removed because a
> version update was done at the same time, rendering those patches
> obsolete.

Agree, I think we should mention explicitly that those patches are now
not needed after some code audit.
>
> (3) Although your 'glib' commit was immediately followed by a 'glib'
> update, rendering it harmless, your misleading 'cairo' commit left
> 'cairo' vulnerable to CVE-2018-19876 and CVE-2020-35492 on our
> 'core-updates' and 'wip-gnome' branches.  Those will need to be
> fixed now.

This patch is for core-updates:
>From 15e28e84eaea8f68b6247ab53052f0dd50a544b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Thu, 22 Apr 2021 19:21:51 +0800
Subject: [PATCH] gnu: cairo: Reintroduce security patches [security fixes].

Two patches were accidentally removed in commit
f94cdc86f644984ca83164d40b17e7eed6e22091.

* gnu/packages/patches/cairo-CVE-2018-19876.patch,
gnu/packages/patches/cairo-CVE-2020-35492.patch: New files.
* gnu/local.mk (dist_patch_DATA): Add them.
* gnu/packages/gtk.scm (cairo)[patches]: Apply them.
---
 gnu/local.mk  |  2 +
 gnu/packages/gtk.scm  |  5 +-
 .../patches/cairo-CVE-2018-19876.patch| 37 ++
 .../patches/cairo-CVE-2020-35492.patch| 49 +++
 4 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/cairo-CVE-2018-19876.patch
 create mode 100644 gnu/packages/patches/cairo-CVE-2020-35492.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index a8dd66f34a..39b2b72a42 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -880,6 +880,8 @@ dist_patch_DATA =		\
   %D%/packages/patches/bpftrace-disable-bfd-disasm.patch	\
   %D%/packages/patches/busybox-CVE-2021-28831.patch		\
   %D%/packages/patches/byobu-writable-status.patch		\
+  %D%/packages/patches/cairo-CVE-2018-19876.patch		\
+  %D%/packages/patches/cairo-CVE-2020-35492.patch		\
   %D%/packages/patches/calibre-no-updates-dialog.patch		\
   %D%/packages/patches/calibre-remove-test-sqlite.patch		\
   %D%/packages/patches/calibre-remove-test-unrar.patch		\
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 9f3aea4aca..f70e667115 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -142,7 +142,10 @@ tools have full access to view and control running applications.")
 (string-append "https://cairographics.org/releases/cairo-;
version ".tar.xz"))
(sha256
-(base32 "0c930mk5xr2bshbdljv005j3j8zr47gqmkry3q6qgvqky6rjjysy"
+(base32 "0c930mk5xr2bshbdljv005j3j8zr47gqmkry3q6qgvqky6rjjysy"))
+   (patches (search-patches
+		 "cairo-CVE-2018-19876.patch"
+		 "cairo-CVE-2020-35492.patch"
 (build-system glib-or-gtk-build-system)
 (outputs '("out" "doc"))
 (arguments
diff --git a/gnu/packages/patches/cairo-CVE-2018-19876.patch b/gnu/packages/patches/cairo-CVE-2018-19876.patch
new file mode 100644
index 00..c0fba2ecaa
--- /dev/null
+++ b/gnu/packages/patches/cairo-CVE-2018-19876.patch
@@ -0,0 +1,37 @@
+Copied from Debian.
+
+From: Carlos Garcia Campos 
+Date: Mon, 19 Nov 2018 12:33:07 +0100
+Subject: ft: Use FT_Done_MM_Var instead of free when available in
+ cairo_ft_apply_variations
+
+Fixes a crash when using freetype >= 2.9
+
+[This is considered to be security-sensitive because WebKitGTK+ sets its
+own memory allocator, which is not compatible with system free(), making
+this a remotely triggerable denial of service or memory corruption.]
+
+Origin: upstream, commit:90e85c2493fdfa3551f202ff10282463f1e36645
+Bug: https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5
+Bug-Debian: https://bugs.debian.org/916389
+Bug-CVE: CVE-2018-19876
+---
+ src/cairo-ft-font.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/cairo-ft-font.c b/src/cairo-ft-font.c
+index 325dd61..981973f 100644
+--- 

Re: GNOME 40

[宋文武]

Hello!

Last week I tried to package GTK4, haven't done it yet.


Raghav Gururajan  writes:

> Let us do this,
> [1] Create wip-gnome branch on savannah
I think Leo created it already, thanks.

> [2] Create guix-patches thread for wip-gnome.
> [3] Leo, me or anyone else can contribute by sending patches to that thread.
> [4] Leo and I (hopefully after getting commit access) can review and
> push the patches to wip-gnome.
> [5] From wip-gnome, any existing committers can double-check and merge
> commits to core-updates.
>
> Sounds good for everyone?

Yes!
>
> Let us all work together and make Guix's GNOME awesome, comrades! :-)
>
> Regards,
> RG.

Sure, thank you!

Re: GNOME 40

[宋文武]

> If anyone is curious of the work or wants to participate, we are
> working there: 
> https://git.guix-patches.cbaines.net/guix-patches/log/?h=wip-gnome-40
>
Hello, looks great!  I'd like to do some work for GNOME4 too, mostly at
weekends though.

> If anyone wants to participate, please reach to cbaines about access.
>
Um, not sure yet, I'll ask later if I need it...


Léo Le Bouter  writes:

> On Sun, 2021-03-28 at 16:48 -0400, Mark H Weaver wrote:
>> How is it more flexible than a "wip-*" branch on Savannah?
>> 
>>  Thanks,
>>Mark
>
> Because as the GNU Guix project we have no control on the forge to
> catter it to our own needs, because there is bureaucracy involved with
> approving new committers so they can work on wip branches (shouldnt be
> necessary).

Does't our savannah repository need committers' gpg signatures for
'wip-*' branch too?

If it is, then I guess there could be some problems.  To push to
savannah, I have to git rebase the cbaines wip-gnome-40 branch to add my
signature to all the commits?  I haven't did this, any help?

If it is not, then I think there should be little difference for me to
use savannah or cbaines's repository.  I can merge cbaines/wip-gnome-40
into savannah/wip-gnome-40 many times, and when it's ready, send patches
to the list for pick, or do some works to get rid of the merge commits
if needed..

Eager to see GNOME4 on Guix!

Re: ZFS on Guix, again

[宋文武]

raid5atemyhomework  writes:

> Hi guix-devel,
>
> I had some questions on the big ZFS guix bugpatches a week ago, and
> did not find any response, so I am back here pestering everyone.

Hello, thank you for working on ZFS for guix!

>
> [...]
> There are two alternatives:
>
> * Go with what I already proposed which I think is more general-purpose and 
> cleaner (there is a separate service type that accepts symbols, and a 
> separate service type that accepts `` records, and the latter 
> just extends the former).
> * Don't make a separate service type, but now we need to add some kind of 
> `fstab?` field to `file-system` so that the ZFS shepherd service that mounts 
> ZFS file systems will not be included in the `/etc/fstab`.
>
> I think overall that having lots of tiny service types that are then
> combined together fits the functional design of Guix better.  So I
> would strongly propose my original design rather than hacks on top of
> `file-system-service-type`.

Well, I think the 'file-system-service-type' should handle all file
systems related configurations, but my opion is not strong.  Waiting
ludo to decide...

Re: SJTUG's Guix mirror is online now

[宋文武]

Peng Mei Yu  writes:

> Hello,
>
> After extensive cooperation with SJTUG's maintainers, we are happy to
> announce that SJTUG's Guix mirror is online now.
>
> The substitute URL is: https://mirrors.sjtug.sjtu.edu.cn/guix
>
> Asia residents, especially China residents, will greatly benefit from
> this mirror.  Average download speed is about 3MB/s within China, which
> is a 100 times increase compared to ci.guix.gnu.org.

Truely a life saver, thank you!

Re: Phases and snippets no longer returning a Boolean

[宋文武]

Ludovic Courtès  writes:


> With these changes, the return value of origin snippets and build phases
> is now ignored.
> ...
>
> That’s it!  Thoughts?  Comments?

Indeed better!  Return ‘#t’ feel perlish, perl requires return ‘1’ at
the end of each module.

Make mutiple packages from outputs (Was: A plan for parameterized packages)

[宋文武]

zimoun  writes:

> Dear,
>
> On Sun, 15 Nov 2020 at 21:46, Danny Milosavljevic  
> wrote:
>
>> * Enable/disable building the documentation.  I really don't need a 40 MiB
>> manual stored onto a 16 MiB firmware flash chip.  If that's better done as an
>> extra output, fair enough.
>
> Related (I hope) is: build packages with several outputs.  For instance,
> ’git’ has several 'outputs' ("send-email", "svn", etc.), so the list of
> "inputs" provides e.g., "subversion" even if I am only interested by
> e.g., "git:send-email".  This matters about closure.
>
> And it is maybe an occasion to revisit the museum, i.e., the TODO file:
>
> ** extend ‘propagated-build-inputs’ with support for multiple outputs
>
> #+BEGIN_SRC scheme
>   (outputs '("out" "include"))
>   (propagated-build-inputs
> `"i1" ,p1 "o1")
> ("i2" ,p2))
>=> "include")
>   ("i3" ,p3)))
> #+END_SRC
>
> For one reference:
>
>   
>
>
> All the best,
> simon

I'd like to suggest another plan: Make every ‘output’ become a 
object, so ‘propagated-build-inputs’ doesn’t need to change.  Then we’ll
have something like debian’s source/binary packages [1] and archlinux’s
base/split packages [2].

Example:
--8<---cut here---start->8---
(define-public %gtk+
  (source-package
(name "gtk+")
(version "3.24.20")
(source ...)
(inputs ...)
(native-inputs ...)
(outputs
  `(("out" .
 (binary-package
   (name "gtk+")  ; version inherit from source
   (propagated ...)  ; per output propagated-inputs here
   (native-search-paths ...)
   (synopsis ...) ; can override package metadata
   (description ...)))
("gtk-update-icon-cache" .
 (binary-package
   (name "gtk-update-icon-cache")
   ...
(arguments ...)
(home-page ...)
(synopsis ...)
(descirption ...)
(license ...)))

(define-public gtk+
  (source-package->binary-package %gtk+ "out"))

(define-public gtk-update-icon-cache
  (source-package->binary-package %gtk+ "gtk-update-icon-cache"))
--8<---cut here---end--->8---

[1] https://sources.debian.org/src/gtk+3.0/3.24.23-2/debian/control/
[2] 
https://github.com/archlinux/svntogit-packages/blob/packages/gtk3/trunk/PKGBUILD


We'll have to build some compatibility layer with existing ‘package’ and
adjust UI though.  I think this is possible and will bring various
benefits!

Re: Japanese Input wont't without manually adding environmental variables?

[宋文武]

yasu  writes:

> I see..., thank you anyway!
>
> I wonder if we can collect of this kind of usability tips in wiki-like
> systems somewhere so we don't have to keep digging google for
> information. 

Well, I don't know if a guix wiki existed, but we have Guix Cookbook:
, it's a info manual build from the guix
git repository, need to work on it more...

>
> I am very excited about Guix - I switched from Nix and I am not going
> back!

Me too, thank you!

Re: Japanese Input wont't without manually adding environmental variables?

[宋文武]

yasu  writes:

> Hi!
>
> After installing packages ibus and ibus-anthy , I thought I would be able to 
> type Japanese - but I had to follow the tip below and manually add these 
> variables to make it work.
> Would this be considered a bug? 

Yes, guix lack supports for input methods.

>
> https://www.mail-archive.com/help-guix@gnu.org/msg08282.html
>
> export 
> GUIX_GTK2_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-2.0/2.10.0/immodules-gtk2.cache"
>  
> export 
> GUIX_GTK3_IM_MODULE_FILE="$HOME/.guix-profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
>  
>

For these kind of environment variables, we usually set them in
'.guix-profile/etc/profile' via 'native-search-paths' of a package.

But adding 'GUIX_GTK3_IM_MODULE_FILE' to the 'native-search-paths' of
'gtk+' is not good enough or won't solve this issue as we usually don't
install 'gtk+' into the profile.  I'd like to find another way set them,
could be add some code to '(guix profiles)' with the 'gtk-im-modules'
profile hook.  Need more thinking... 


In the meantime, we have to set those environment variables manually..

Re: Critical opensmtpd vulnerability

[宋文武]

Tobias Geerinckx-Rice  writes:

> Fellow Guix running opensmtpd mail servers,
>
> As you probably know by now, a serious remote code execution bug was
> recently found and fixed in OpenSMTPd[0].
>
> TL;DR: You should probably stop your opensmtpd daemon until you've
> checked that our regular opensmtpd package (6.0.3p1) is not
> vulnerable.  If possible, switch to opensmtpd-next and adapt your
> configuration syntax:
>
>(service opensmtpd-service-type
> (opensmtpd-configuration
>  (package opensmtpd-next)
>  (config-file (plain-file "smtpd.conf"
>   "include
> "/etc/guix/mail/my-new-smtpd.conf"\n"
>

I just upgrade my vulnerable opensmtpd 6.6.1p1 to 6.6.2p2, thank you
very much!

Re: [bug#39028] [PATCH 5/7] gnu: python-cryptography: Update to 2.8

[宋文武]

Hello Braun, I have pushed the previous 4 patches into master, thank you!

Lars-Dominik Braun  writes:

> * gnu/packages/python-crypto.scm (python-cryptography): Update to 2.8
> (python-cryptography-vectors): Update to 2.8

This is not a small change for me, as 'guix refresh -l python-cryptography' 
says:
  Building the following 167 packages would ensure 367 dependent packages are 
rebuilt...

And I'm not sure about disable tests in python-pyopenssl (in the next
patch), maybe we should update it to 19.1.0.

So I leave this and remain patches for others to pick up, TIA!

shepherd services have unwanted environment variables

[宋文武]

Hello, when fixing an issue for our libvirtd service, I found that most
our shepherd services inherit the default environment variables of the
pid 1 'shepherd', which is:

--8<---cut here---start->8---
$ cat /proc/1/environ  | tr '\0' '\n'
HOME=/
TERM=linux
BOOT_IMAGE=/gnu/store/xwp07fcvwj9dpjsr9z4x9l03z9jj7fgx-linux-5.2.8/bzImage
--root=system
--system=/gnu/store/58gir4yk5xj2lqzvlja8ml57z54k54n0-system
--load=/gnu/store/58gir4yk5xj2lqzvlja8ml57z54k54n0-system/boot
PATH=/gnu/store/q8bcf3cl33mq31y9k1wnwc895ng3qdq8-e2fsck-static-1.45.2/sbin
GUIX_LOCPATH=/gnu/store/94k5w17z54w25lgp90czdqfv9m4hwzhq-glibc-utf8-locales-2.28/lib/locale
--8<---cut here---end--->8---

Obviously, we don't want BOOT_IMAGE, --root, --system, --load here, and
this PATH is not good.

I think a resonable default could be:

  LANG=
  GUIX_LOCPATH=/run/current-system/locale
  LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
  
PATH=/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin

So we can have shepherd services running under the same locale
configured by user and finding runtime binaries (eg: for libvirtd to
find qemu) in standard places.

What do you think?

Re: [PATCH] download: Support 'https_proxy'.

[宋文武]

Ludovic Courtès  writes:

> Hi!
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> Hello, this patch add 'https_proxy' to 'guix download' (and guix-daemon
>> if we update guix?):
>
> Neat!

Pushed, thank you for the review!

>
>> From 424da6e43ba9c928403e3fd9b42e75d0fe90fc23 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Fri, 10 May 2019 21:27:40 +0800
>> Subject: [PATCH] download: Support 'https_proxy'.
>>
>> * guix/build/download.scm (setup-http-tunnel): New procedure.
>> (open-connection-for-uri): Honor the 'https_proxy' environment variable.
>
> [...]
>
>> +(define (setup-http-tunnel port uri)
>> +  "Establish a tunnel to the destination server of URI."
>
> Maybe “Establish over PORT an HTTP tunnel to the destination server of
> URI.”?

Sure.

>
> Otherwise LGTM!
>
>> Some problems and questions:
>> 
>> - It assumes ‘https_proxy’ is ‘http://PROXY-SERVER:PORT’, if the scheme
>>   part is missing, it fail.
>
> That’s already the case with ‘http_proxy’.
>
> It seems that other tools can happily deal with the lack of a URI
> scheme, so perhaps in a subsequent patch we should add code to
> automatically add a URI scheme when it’s missing?

Yes, I think the URI scheme can be ‘http’, ‘https’ or ‘socks5’, etc. and
default to ‘http’.  We only have ‘http’ now, other are good exercise :)

>
>> - It fails some servers (eg: www.google.com) for me while curl works...
>
> For www.google.com it fails even without ‘https_proxy’, so that’s OK.
> :-)
>
>> - I think this should go into guile’s ‘(web client)’ module?
>
> Yes!  Once we’ve committed it Guix, it’d be great if you could a similar
> patch to bug-gu...@gnu.org.
>
> Thank you!
>
> Ludo’.

Okay, get it!

[PATCH] download: Support 'https_proxy'.

[宋文武]

Hello, this patch add 'https_proxy' to 'guix download' (and guix-daemon
if we update guix?):

>From 424da6e43ba9c928403e3fd9b42e75d0fe90fc23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 10 May 2019 21:27:40 +0800
Subject: [PATCH] download: Support 'https_proxy'.

* guix/build/download.scm (setup-http-tunnel): New procedure.
(open-connection-for-uri): Honor the 'https_proxy' environment variable.
---
 guix/build/download.scm | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index a64e0f0bd3..92cef76dff 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -380,6 +380,20 @@ ETIMEDOUT error is raised."
   (apply throw args)
   (loop (cdr addresses
 
+(define (setup-http-tunnel port uri)
+  "Establish a tunnel to the destination server of URI."
+  (define target
+(string-append (uri-host uri) ":"
+   (number->string
+(or (uri-port uri)
+(match (uri-scheme uri)
+  ('http 80)
+  ('https 443))
+  (format port "CONNECT ~a HTTP/1.1\r\n" target)
+  (format port "Host: ~a\r\n\r\n" target)
+  (force-output port)
+  (read-response port))
+
 (define* (open-connection-for-uri uri
   #:key
   timeout
@@ -393,21 +407,20 @@ VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
   (define https?
 (eq? 'https (uri-scheme uri)))
 
+  (define https-proxy (let ((proxy (getenv "https_proxy")))
+(and (not (equal? proxy ""))
+ proxy)))
+
   (let-syntax ((with-https-proxy
 (syntax-rules ()
   ((_ exp)
;; For HTTPS URIs, honor 'https_proxy', not 'http_proxy'.
-   ;; FIXME: Proxying is not supported for https.
(let ((thunk (lambda () exp)))
  (if (and https?
   (module-variable
(resolve-interface '(web client))
'current-http-proxy))
- (parameterize ((current-http-proxy #f))
-   (when (and=> (getenv "https_proxy")
-(negate string-null?))
- (format (current-error-port)
- "warning: 'https_proxy' is ignored~%"))
+ (parameterize ((current-http-proxy https-proxy))
(thunk))
  (thunk)))
 (with-https-proxy
@@ -415,6 +428,9 @@ VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
;; Buffer input and output on this port.
(setvbuf s 'block %http-receive-buffer-size)
 
+   (when https-proxy
+ (setup-http-tunnel s uri))
+
(if https?
(tls-wrap s (uri-host uri)
  #:verify-certificate? verify-certificate?)
-- 
2.19.2



Some problems and questions:

- It assumes ‘https_proxy’ is ‘http://PROXY-SERVER:PORT’, if the scheme
  part is missing, it fail.

- It fails some servers (eg: www.google.com) for me while curl works...

- I think this should go into guile’s ‘(web client)’ module?

Re: "Guix Pull" Fails

[宋文武]

"Raghav Gururajan"  writes:

> Hello Guix!
>
> I just did "guix pull" but it failed multiple times. Please find the 
> following:
>
> root@secondary ~# guix pull
>
> downloading from 
> https://ci.guix.info/nar/gzip/zh3s89l1kri7r5ya0bmhil65lm0my691-module-import...
>
> module-import 187B 52KiB/s 00:00 [##] 100.0%
>
> building /gnu/store/1gnvnkaw5wg51c55wxywmwl80bgkpv9k-isrgrootx1.pem.drv...
>
> downloading from https://letsencrypt.org/certs/isrgrootx1.pem...
>
> |sha256 hash mismatch for 
> /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
>
> expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>
> actual hash: 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
>
> hash mismatch for store item 
> '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem'
>
> build of /gnu/store/1gnvnkaw5wg51c55wxywmwl80bgkpv9k-isrgrootx1.pem.drv failed
>
> View build log at 
> '/var/log/guix/drvs/1g/nvnkaw5wg51c55wxywmwl80bgkpv9k-isrgrootx1.pem.drv.bz2'.
>
> cannot build derivation 
> `/gnu/store/paq8cw9f06lxw34aakk0vg1b9nx21cqf-le-certs-0.drv': 1 dependencies 
> couldn't be built
>
> guix pull: error: build of 
> `/gnu/store/paq8cw9f06lxw34aakk0vg1b9nx21cqf-le-certs-0.drv' failed
>
> root@secondary ~# 
> /var/log/guix/drvs/1g/nvnkaw5wg51c55wxywmwl80bgkpv9k-isrgrootx1.pem.drv.bz2
>
> bash: 
> /var/log/guix/drvs/1g/nvnkaw5wg51c55wxywmwl80bgkpv9k-isrgrootx1.pem.drv.bz2: 
> Permission denied


Hello, thank for the report, it seems that Let's Encrypt had added the 3
missing '^M' to each its pem cert file.

I had pushed a fix, please try again, thank you!

Re: GNU Guix 1.0.0 released

[宋文武]

Ludovic Courtès  writes:

> We are thrilled to announce the release of GNU Guix 1.0.0!
>
> This 1.0 release is a major milestone for Guix.  It represents 7 years
> of hard work with more than 40,000 commits by 260 people, 19 releases,
> and an equally amazing amount of work on documentation, translation,
> artwork, web design, mentoring, outreach, and many other activities that
> together have made it a thriving project.
>
> Read more about today’s announcement at:
>
>   https://gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released
>
> Whether you’re a software developer, a user, or a free software
> enthusiast, we hope GNU Guix will provide you with the tools to deploy
> and manage software with confidence and ease, qualities that are not
> usually associated with software deployment.  We’d love to hear from you!
>

Congratulations for the great 1.0.0 release, and thank you very much!!

And for all ones that sending/reviewing/applying patches, packaging
softwares, making system services, writing and translating
documentations, helping each other, hacking for the good, so anyone
involved, thank you!

GNU Guix is such an excellent project and community, I learned a lot and
gain much satisfactions with it, and will continue to.

See you here in the next 7 years!

Re: Reverted: gnu: font-awesome: Update to 5.7.2.

[宋文武]

Leo Famulari  writes:

> On Sat, Feb 23, 2019 at 09:03:10PM -0500, guix-comm...@gnu.org wrote:
>> iyzsong pushed a commit to branch master
>> in repository guix.
>> 
>> commit 590b989c95f5b72dfe4b9928d1426fb7d35d1428
>> Author: Pkill -9 
>> Date:   Sat Feb 23 10:12:32 2019 +
>> 
>> gnu: font-awesome: Update to 5.7.2.
>> 
>> * gnu/packages/fonts.scm (font-awesome): Update to 5.7.2.
>> [home-page]: Use HTTPS.
>> 
>> Signed-off-by: 宋文武 
>
> If I understand correctly, Font Awesome 5 is incompatible with the Free
> System Distribution Guidelines, specifically this section [0]:
>
> --
> “Information for practical use” includes software, documentation, fonts,
> and other data that has direct functional applications. It does not
> include artistic works that have an aesthetic (rather than functional)
> purpose, or statements of opinion or judgment.
>
> All information for practical use in a free distribution must be
> available in source form. (“Source” means the form of the information
> that is preferred for making changes to it.)
> --
>
> The problem is that, in version 5, upstream stopped distributing the
> build scripts and so the icons can no longer be built from source even
> though the sources are distributed freely.

Okay, a unfortunate situation.

>
> We discussed this previously in bug #32916 [1] but unfortunately forgot
> to add a comment in the package definition warning of this issue.
>
> I've reverted this commit and added a comment about the issues in
> version 5.
>
> [0]
> https://www.gnu.org/distros/free-system-distribution-guidelines.en.html
> [1]
> https://bugs.gnu.org/32916

Thanks for the explanation!

Re: [PATCH] shepherd: Delete the socket file upon exit.

[宋文武]

Danny Milosavljevic  writes:

> On Sun, 17 Feb 2019 11:38:16 +0800
> iyzs...@member.fsf.org (宋文武) wrote:
>
>> Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
>> script too...
>> 
>> According to 'man 2 bind', the socket pathname should be deleted when no
>> longer required, so a patch to fix this bug:
>
> Hmm, I guess you can do that.
>
> But /run is supposed to be a tmpfs and elogind is supposed to rm -rf 
> /run/user/1000
> after all sessions of that user terminated in any case, so how is it left over
> in the first place?
>

Well, maybe the elogind version I used didn't have this feature, or I
had another user session running...

> If the deletion in the case above doesn't work, please report a bug.

Thanks, good to know, and it indeed works.

>
> If that patch is only in order to enable users to restart user's shepherd
> without exiting all their sessions, then I guess that's ok--although unusual.
>
> Does your patch do the right thing if the user's shepherd is already
> running? (i.e. keep the socket file)

Yes, it deletes the socket file at exit (not at startup).

[PATCH] shepherd: Delete the socket file upon exit.

[宋文武]

Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
script too...

According to 'man 2 bind', the socket pathname should be deleted when no
longer required, so a patch to fix this bug:

>From f171f6adb2fc6ee3bf4d25378c2e7bba109b43d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 17 Feb 2019 11:27:28 +0800
Subject: [PATCH] shepherd: Delete the socket file upon exit.

Fixes .

* modules/shepherd.scm (call-with-server-socket): New procedure.
(main): Use it instead of 'open-server-socket'.
---
 modules/shepherd.scm | 65 ++--
 1 file changed, 39 insertions(+), 26 deletions(-)

diff --git a/modules/shepherd.scm b/modules/shepherd.scm
index e241e7a..314b989 100644
--- a/modules/shepherd.scm
+++ b/modules/shepherd.scm
@@ -49,6 +49,17 @@
   (listen sock 10)
   sock)))
 
+(define (call-with-server-socket file-name proc)
+  "Call PROC, passing it a listening socket at FILE-NAME and deleting the
+socket file at FILE-NAME upon exit of PROC.  Return the values of PROC."
+  (let ((sock (open-server-socket file-name)))
+(dynamic-wind
+  noop
+  (lambda () (proc sock))
+  (lambda ()
+(close sock)
+(delete-file file-name)
+
 
 ;; Main program.
 (define (main . args)
@@ -256,32 +267,34 @@
   ;; Get commands from the standard input port.
   (process-textual-commands (current-input-port))
   ;; Process the data arriving at a socket.
-  (let ((sock   (open-server-socket socket-file)))
-
-;; Possibly write out our PID, which means we're ready to accept
-;; connections.  XXX: What if we daemonized already?
-(match pid-file
-  ((? string? file)
-   (with-atomic-file-output pid-file
- (cute display (getpid) <>)))
-  (#t (display (getpid)))
-  (_  #t))
-
-(let next-command ()
-  (define (read-from sock)
-(match (accept sock)
-  ((command-source . client-address)
-   (setvbuf command-source (buffering-mode block) 1024)
-   (process-connection command-source))
-  (_ #f)))
-  (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
-(((sock) _ _)
- (read-from sock))
-(_
- #f))
-  (when poll-services?
-(check-for-dead-services))
-  (next-command)))
+  (call-with-server-socket
+   socket-file
+   (lambda (sock)
+
+ ;; Possibly write out our PID, which means we're ready to accept
+ ;; connections.  XXX: What if we daemonized already?
+ (match pid-file
+   ((? string? file)
+(with-atomic-file-output pid-file
+  (cute display (getpid) <>)))
+   (#t (display (getpid)))
+   (_  #t))
+
+ (let next-command ()
+   (define (read-from sock)
+ (match (accept sock)
+   ((command-source . client-address)
+(setvbuf command-source (buffering-mode block) 1024)
+(process-connection command-source))
+   (_ #f)))
+   (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
+ (((sock) _ _)
+  (read-from sock))
+ (_
+  #f))
+   (when poll-services?
+ (check-for-dead-services))
+   (next-command
 
 ;; Start all of SERVICES, which is a list of canonical names (FIXME?),
 ;; but in a order where all dependencies are fulfilled before we
-- 
2.19.2

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello Song,
>
>> Hello, thank you again, I have push them!
>
> Thank you.
>
>> - Add comments about the missing translations (disable the
>>   PULL_TANSLATIONS), which are in the lxqt-l10n git repository.  I think
>>   we can prefetch it as a 'origin', add it to the input of the
>>   application, or add a 'lxqt-l10n' package.
>
> I didn't add lxqt-l10n because it is stated as deprecated on it's home
> page.

Okay, I see now the repositories (lxqt-about, etc) have their
translations checked in, so the next release will have translations
files in the tarballs.  In the meantime, we could add 'lxqt-l10n' as a
package to get translations for those LXQt applications.  I tried to
build lxqt-l10n, but its CMakeLists.txt can't be used as-is, I'd leave
it now...

>
>> - Correct some licenses, eg: obconf-qt, qps are under GPL2+.
>
> Sorry about this. I should have been more careful.
>
>> And a "lxqt-build-tools: Dedifen LXQT_*_DIR variables" patch is
>> unapplied:
>>
>>  (build-system cmake-build-system)
>>  (arguments
>> - `(#:tests? #f)); no tests
>> + `(#:tests? #f  ;; no tests
>> +   #:configure-flags
>> +   `("-DLXQT_DATA_DIR=/run/current-system/profile/share"
>> + "-DLXQT_ETC_XDG_DIR=/run/current-system/profile/etc/xdg")))
>>
>> What are thoses variables used for?  If I install the 'lxqt' package
>> into my user profile, should I set them to the directories under my
>> profile ($HOME/.guix-profile/share and $HOME/.guix-profile/etc/xdg)?
>
> These variables are used by all LXQt packages during build time. But
> there is no big issue if they are not defined here, I guess it is
> because XDG_*_DIRS environment variables are set correctly during
> runtime. They default to directories within
> /gnu/store/*-lxqt-build-tools-*/ like this:
> "/gnu/store/86wy8q4yplhalf3yvmzv673naarxn3na-lxqt-build-tools-0.5.0/share"
>
> I defined these variables here to serve an aesthetic purpose, so that
> the "Technical Info" tab within lxqt-about can show the values defined
> above rather than directories like this:
> "/gnu/store/86wy8q4yplhalf3yvmzv673naarxn3na-lxqt-build-tools-0.5.0/share".
>

Yeah, thanks for the explanation.

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello Song,
>
> On Fri, Oct 26, 2018 at 2:26 PM 宋文武  wrote:
>
>>   - Correct some licenses, eg: obconf-qt, qps are under GPL2+.
>
> I made a terrible mistake. I assumed that all LXQt apps are licensed
> under LGPL2.1+. But in fact only core LXQt apps are licensed under
> LGPL2.1+. Several apps are licensed under GPL2+.

Indeed.

>
> GPL2+ apps: pcmanfm-qt, lximage-qt, obconf-qt, pavucontrol-qt, qps,
> qtermwidget, qterminal, screengrab.

> [4. text/x-patch;
> 0001-gnu-lxqt-Correct-licenses-for-several-packages.patch]...

Good catch, applied, thanks!  (I thought I had checked all the licenses,
but forget...)

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello everyone,
>
> I made a series of packages for LXQt. The code is at:
> https://github.com/meiyopeng/guix/tree/lxqt

Hello, thank you again, I have push them!

With some minor edits:

- Add comments about the missing translations (disable the
  PULL_TANSLATIONS), which are in the lxqt-l10n git repository.  I think
  we can prefetch it as a 'origin', add it to the input of the
  application, or add a 'lxqt-l10n' package.

- Correct some licenses, eg: obconf-qt, qps are under GPL2+.


And a "lxqt-build-tools: Dedifen LXQT_*_DIR variables" patch is
unapplied:

 (build-system cmake-build-system)
 (arguments
- `(#:tests? #f)); no tests
+ `(#:tests? #f  ;; no tests
+   #:configure-flags
+   `("-DLXQT_DATA_DIR=/run/current-system/profile/share"
+ "-DLXQT_ETC_XDG_DIR=/run/current-system/profile/etc/xdg")))

What are thoses variables used for?  If I install the 'lxqt' package
into my user profile, should I set them to the directories under my
profile ($HOME/.guix-profile/share and $HOME/.guix-profile/etc/xdg)?

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello, Mr. Song.
>
> Thank you for your reply.
>
>> Some notes to you:
>> - Wrap lines under 80 characters if possible.
>
> My emacs automatically wrap lines at exactly 80 characters. Should I set
> it to less than 80?

Not needed (there is 'guix lint', which warn lines longer than 90
characters), no problem.

>
> #+BEGIN_SRC emacs-lisp
>   (setq-default fill-column 80)  ;; Change this to 70?
> #+END_SRC
>
> "宋文武" is a Chinese name. Are you a Chinese? I am a Chinese. My name
> is 彭美玉 (Peng Mei Yu in Pinyin).

是的，你好，很高兴认识你～

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello everyone,
>
> I made a series of packages for LXQt. The code is at:
> https://github.com/meiyopeng/guix/tree/lxqt

Hello, it looks great!

>
> I did this beacuse I want to run i3 window manager within lxqt
> session. Currently most things work great except lxqt-panel. I have two
> problems.
>
> 1. The $QT_PLUGIN_PATH environment variable points to
> /run/current-system/profile/lib/qt5/plugins. I don't know where it's
> set.

The QT_PLUGIN_PATH can be set by the 'native-search-paths' of qtbase, I
guess you have qtbase in your system profile.  If you install qtbase
into the user profile, the variable would contains
'~/.guix-profile/lib/qt5/plugins'.

> So qtsvg has to be installed into syetem profile, or all the lxqt
> applications can not properly display icons.

Yeah, instead the system profile you can also install qtsvg, etc. into
the user profile.

> Should I add qtsvg to lxqt applications' propagated-inputs? If so,
> should I add qtbase too, since qtbase also provides lib/qt5/plugins,
> although lxqt works without qtbase in system profile but I can never
> be sure.

Yes, we can make them 'propagated-inputs' so that the variables can be
set by the profile (via native-search-paths), or we can wrap the
binaries with all the environment variables (eg: krita).


>
> 2. lxqt-panel complains about "Warning: Could not find any platform
> plugin". (lxqt-runner also prints this message but it works.) I found
> out this message was printed by kwindowsystem.
>
> The related code in kwindowsystem:
> https://github.com/KDE/kwindowsystem/blob/9f88c9a5d25ff7909c25ce399572ca348b5706b1/src/pluginwrapper.cpp#L79
>
> Qt's document (https://doc.qt.io/qt-5/qcoreapplication.html#libraryPaths)
> says "entries of the QT_PLUGIN_PATH environment variable are always
> added to libraryPaths". So I install kwindowsystem into system profile,
> and add /run/current-system/profile/lib/plugins to QT_PLUGIN_PATH. Then
> this error message disappear. But lxqt-panel still does not work.

Okay, we can look into it later...

>
> I still have no idea how to fix lxqt-panel. This does not affect me
> because I use i3, so lxqt-panel is useless to me. But there may be other
> people interested in LXQt and I want to help them get this fixed. Can
> anybody help me?
>
> Will anybody help me review the code? I'd appreciate it.

Generally it look good to me, and I had cherry-pick 2 commits, and push
them (hope it doesn't break existing other lxqt things...), and will
look into others in next days.

Some notes to you:
- Wrap lines under 80 characters if possible.
- Keep comments for '#:tests #f', etc.

Thank you!

Re: GHC 8.4.3

[宋文武]

Ricardo Wurmus  writes:

> Ricardo Wurmus  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Timothy Sample  writes:
>>>
   • There are 21 failing packages.  They are agda, beast, corrode,
 git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test,
 ghc-hashable-bootstrap, ghc-indents, ghc-monadplus,
 ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc,
 ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib,
 raincat, rapicorn, and shellcheck.
>>>
>>> Raincat is now fixed on wip-haskell.
>>
>> git-annex is also fixed now.
>
> agda is also fixed now.
>
> ghc-regex has had its last release in 2017, so this is an upstream
> problem, I think.  ghc-regex-tdfa-rc probably fails just because
> ghc-regex cannot be built.
>
> ghc-monadplus was only needed for agda.  I found that version 1.3 builds
> fine, but 1.4.x does not.
>
> ghc-nats-bootstrap builds fine.
>
> ghc-hashable-bootstrap builds fine.
>
> ghc-indents now builds fine (after disabling the tests).
>
> ghc-haddock-test is deprecated and should be removed.
> ghc-packedstring is deprecated and should also be removed.
>
> This leaves ghc-aws, ghc-gnuplot, ghc-statistics, ghc-vector-builder,
> ghc-wave, ghc-xmonad-contrib, and shellcheck.
>
> Any takers?

Fixed 5, leaving ghc-aws and ghc-statistics (I got test fails for
ghc-happy).

Re: Help sending package.

[宋文武]

Fis Trivial  writes:

> Please help sending this package to guix-patches list. I got blocked due
> to various reasons (It's not something bad, it's just I can't send it
> myself with contained keywords). The patches is contained within
> package.tar.xz attached in this mail.
>
> Thanks in advance.

Sent, thanks for the patch :-)

Re: New ‘guix pull’ dosen’t update the guix manual in GuixSD

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

>> The last there are from the ‘export’ statement of ‘/etc/profile’, the
>> first two are added by ‘source’ the profiles.  Since there is a guix in
>> the system profile contains the old info manual, the current one won’t
>> be picked.
>
> Ooh!  I think the change below should be enough to ensure
> ~/.config/guix/current comes first:
>
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -602,7 +602,7 @@ directory."
>  # because they would require combining both profiles.
>  # FIXME: See .
>  export 
> MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
> -export 
> INFOPATH=$HOME/.config/guix/current/share/info:$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
> +export 
> INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
>  export 
> XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
>  export 
> XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
>  
> @@ -630,7 +630,7 @@ then
>export `cat /etc/environment | cut -d= -f1`
>  fi
>  
> -for profile in \"$HOME/.config/guix/current\" \"$HOME/.guix-profile\"
> +for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
>  do
>if [ -f \"$profile/etc/profile\" ]
>then
> @@ -644,6 +644,8 @@ do
>fi
>  done
>  
> +export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
> +
>  # Set the umask, notably for users logging in via 'lsh'.
>  # See .
>  umask 022
>
>
> How does that sound?

Yeah, that's fine.  Maybe add comments about why source ‘current’ after
user profile (prefer current guix) and why ‘export INFOPATH’ at the end
(prefer the current guix manual).  Thank you!

New ‘guix pull’ dosen’t update the guix manual in GuixSD

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> For those who haven’t been following along on
> , I have just
> pushed a new ‘guix pull’.
>
> To summarize, ~/.config/guix/latest no longer exists.  Instead
> ~/.config/guix/current is populated with a complete Guix (without
> ‘guix-daemon’ though), including an up-to-date manual and so on.
> ~/.config/guix/current is a regular profile, meaning that you can
> roll-back to a previously-pulled Guix and so on.

Great!


After run ‘guix pull’ twice, I have got ‘~/.config/guix/current’, then
use it to do a system reconfigure for ‘/etc/profile’.

But the guix manual doesn’t got updated, my ‘INFOPATH’ contains:

- /home/iyzsong/.guix-profile/share/info
- /run/current-system/profile/share/info
- /home/iyzsong/.config/guix/current/share/info
- /home/iyzsong/.guix-profile/share/info
- /run/current-system/profile/share/info

The last there are from the ‘export’ statement of ‘/etc/profile’, the
first two are added by ‘source’ the profiles.  Since there is a guix in
the system profile contains the old info manual, the current one won’t
be picked.

I think we should make ‘INFOPATH’ a search path of the ‘current’ guix
profile, so that it overrides previous ones.

Re: PYTHONPATH - let's systematically tame the baest

[宋文武]

Hartmut Goebel  writes:

> Hi,

Hello!

>
> let's pick up on this issue and systematically design the test-cases to
> benchmark the proposed solutions. I already prepared a test-script to
> simplify this and will provide a full description as later.
>
> **Please comment if any relevant case is missing or if any case can be
> skipped**
>
> 1) Test-cases
>
> For all environments (see below) these cases must give the expected
> output - which is defined by what a "foreign distribution's" python
> would do:
> - "installed" python
> - venv with and without --system-site-packages
> - stacked venv with and without --system-site-packages

We should consider both python2 and python3, and virtual environments
created by the 'virtualenv' package.

>
> 2) Environments to be tested.
>
> The proposed solution must pass the test-suite in all of these environments:
>
> 2.1 guix environment:
>
>  guix environment --ad-hoc python -- python3 testit
>   --> Expected outcome: site-packages from GUIX_ENVIRONEMENT
>
> 2.2 guix environment with container:
>
>  guix environment -C --ad-hoc python -- python3 testit
>   --> Expected outcome: site-packages from GUIX_ENVIRONEMENT
>
> 2.3 Installed package *without setting the environment variables!*
>
>  guix package -i python && ~/.guix-profile/bin/python3 testit
>     --> Expected outcome: site-packages from ~/.guix-profile/
>     --> Shall this work, too? Is it nice-to-have or useless?

Yeah, it's nice to have (to avoid introducing an environment variable),
but not necessary.

>
> 2.4 running from /gnu/store (directly)
>
>     $(readlink -f ~/.guix-profile/bin/python3) testit
>     --> Expected outcome: site-packages from /gnu/store
>     --> What is the expected outcome? What is the expected

I think if we use environment variable to specify all the site-packages,
it should be the same as running from profile.  It maybe different if we
resolve site-packages by the executable location...

>
> 2.5 running from /gnu/store (via link)
>
>     ln -s $(readlink -f ~/.guix-profile/bin/python3)
> /tmp/test-guix-pythonA.exe ;
>     /tmp/test-guix-pythonA.exe testit
>     --> Expected outcome: site-packages from /gnu/store

True when we're not use the environment variable.

>
> 2.6 Installed in GuixSD
>
>     --> Do we need to test this? Or is this already covered by one of
> the other cases?

For this, there is nothing special about GuixSD.


Had you review my 'GUIX_PYTHON_X_Y_SITE_PACKAGES' patch?  I think it's
enough to support both python2 and python3 in the same profile:

http://lists.gnu.org/archive/html/guix-devel/2018-03/msg00238.html


Thanks!

Re: PYTHONPATH issue explanation

[宋文武]

iyzs...@member.fsf.org (宋文武) writes:

> [...]
>
> I'd like do more tests with the GUIX_PYTHON_X_Y_SITE_PACKAGES option
> (patch sent), hope it works :-)

Hello, I have write a shell script to do some tests, it looks good to me!


Updated 'GUIX_PYTHON_X_Y_SITE_PACKAGES' patch, target 'core-updates' at
commit 171a117c (you also have to comment out the "manual-database"
profile hook in the "guix/profiles.scm", as it's broken in that commit):

>From d807306d02aab0a84de4fa3ff457a5b97ac15520 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
Date: Sat, 17 Mar 2018 18:46:55 +0800
Subject: [PATCH] gnu: python-2.7, python-3.6: Honor
 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

This replace the use of 'PYTHONPATH' as search path specification, as
suggested by Hartmut Goebel <h.goe...@crazy-compilers.com>.  See
<https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00178.html> for
details.

* gnu/packages/python.scm (python-guix-search-path-specification)
(python-guix-sitecustomize.py): New procedures.
(python-2.7, python-3.6):
[native-search-paths]: Use 'python-guix-search-path-specification'.
[arguments]: Add 'install-sitecustomize.py' phase.
---
 gnu/packages/python.scm | 65 +++--
 1 file changed, 57 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index f3a75c30e..45de8c527 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -136,6 +136,41 @@
   #:use-module (guix build-system trivial)
   #:use-module (srfi srfi-1))
 
+(define (python-guix-search-path-specification version)
+  "Return the search path specification for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES"))
+ (files   (list (string-append
+ "lib/python" major.minor "/site-packages"
+(search-path-specification
+ (variable variable)
+ (files files
+
+(define (python-guix-sitecustomize.py version)
+  "Return the content of @file{sitecustomize.py} for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES")))
+(format #f "# Append module search paths for guix packages to sys.path.
+import os
+import site
+
+SITE_PACKAGES = os.environ.get('~a')
+
+if SITE_PACKAGES is None:
+SITE_PACKAGES = []
+else:
+SITE_PACKAGES = SITE_PACKAGES.split(os.pathsep)
+
+for i in SITE_PACKAGES:
+site.addsitedir(i)
+" variable)))
+
 (define-public python-2.7
   (package
 (name "python2")
@@ -304,6 +339,16 @@
  "/site-packages")))
(install-file tkinter.so target)
(delete-file tkinter.so)
+#t)))
+  (add-after 'install 'install-sitecustomize.py
+(lambda* (#:key outputs #:allow-other-keys)
+  (let* ((out (assoc-ref outputs "out"))
+ (sitedir (car (find-files out "^site-packages$"
+   #:directories? #t
+(with-output-to-file
+(string-append sitedir "/sitecustomize.py")
+  (lambda ()
+(display ,(python-guix-sitecustomize.py version
 #t))
 (inputs
  `(("bzip2" ,bzip2)
@@ -318,9 +363,7 @@
 (native-inputs
  `(("pkg-config" ,pkg-config)))
 (native-search-paths
- (list (search-path-specification
-(variable "PYTHONPATH")
-(files '("lib/python2.7/site-packages")
+ (list (python-guix-search-path-specification version)))
 (home-page "https://www.python.org;)
 (synopsis "High-level, dynamically-typed programming language")
 (description
@@ -428,13 +471,19 @@ data types.")
  ,file)))
   (find-files out "\\.py$")))
   (list '() '("-O") '("-OO")))
+ #t)))
+   (replace 'install-sitecustomize.py
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (sitedir (car (find-files out "^site-packages$"
+#:directories? #t
+ (wit

guile-gdbm doesn't work with gdbm-1.14

[宋文武]

Hello, since version 1.14, gdbm doesn't export "gdbm_errno" anymore [1],
so the guile-gdbm ffi binding code [2] need updates now (I'm not
confident to do it myself...).

[1] 
http://git.gnu.org.ua/cgit/gdbm.git/commit/?id=c175231e2781abd17eabf412cfb597654a076c7b
[2] https://github.com/ijp/guile-gdbm/blob/master/gdbm.scm#L156

Re: PYTHONPATH issue explanation

[宋文武]

Hartmut Goebel <h.goe...@crazy-compilers.com> writes:

> Hi,
>
> I agree with Ricardo: We first should agree on what we want to
> implement.

Okay.

>
> I created a pad at [1] for collecting all test-cases and the expected
> results. Please add you test-cases there. Thanks!
>
> [1] https://semestriel.framapad.org/p/guix-python-site-packages-test-cases

I have append some text, it's available to all in realtime?
not sure how it works...

>
> Am 17.03.2018 um 02:41 schrieb 宋文武:
>
>> - "GUIX_PYTHON_X_Y_SITE_PACKAGES" […] is necessary for the "build" 
>> environment.
> For the build environment we could easily work around using PYTHONPATH.
> Since the build-system is clearly defined and does not interfere with
> any user-definitions, this is save to do.

Yes, but if "GUIX_PYTHON_X_Y_SITE_PACKAGES" does works (i hope so) in
the "profile" side, it's better to replace PYTHONPATH for consistent.

>
>> - Avoid any environment variable for the "profile" environment.
>>
>>   We have a union "profile" for all the python packages, so environment
>>   variables can be totally avoided with the help of "venv".
> […]
>>  We only need to make the "profile"
>>   a "venv" for python.  For python3, a simple "pyvenv.cfg" file is
>>   enough, for python2 I guess we have to make a union or copy files like
>>   what "virtualenv" does.
>
> This would be a very elegant solution. Unfortunately this does not work
> as shown in part 2 of my analysis, esp. point 4a.

A workaround for the broke case maybe tell the user to create a
"sitecustomize.py" in the created venv, and add the search paths of
profile himself.


I'd like do more tests with the GUIX_PYTHON_X_Y_SITE_PACKAGES option
(patch sent), hope it works :-)

Re: [PATCH] gnu: python: Honor 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

[宋文武]

iyzs...@member.fsf.org (宋文武) writes:

>> I plan to implement option 1 by adding a "sitecustomize.py" (better
>> than modify "site.py") into the python packages, and modify
>> "search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES".
>
> Patch coming:
>
> [patch with typo...]
>
>
> This targets 'core-updates' and will rebuild the world, I can't afford
> to test it...

Updated with typo fixed:

>From d9c273c0ee8c5e87b12b37a325c649f8df808af3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
Date: Sat, 17 Mar 2018 18:46:55 +0800
Subject: [PATCH] gnu: python-2.7, python-3.6: Honor
 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

This replace the use of 'PYTHONPATH' as search path specification, as
suggested by Hartmut Goebel <h.goe...@crazy-compilers.com>.  See
<https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00178.html> for
details.

* gnu/packages/python.scm (python-guix-search-path-specification)
(python-guix-sitecustomize.py): New procedures.
(python-2.7, python-3.6):
[native-search-paths]: Use 'python-guix-search-path-specification'.
[arguments]: Add 'install-sitecustomize.py' phase.
---
 gnu/packages/python.scm | 67 ++---
 1 file changed, 58 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6639e6c9e..2ce8db710 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -136,6 +136,41 @@
   #:use-module (guix build-system trivial)
   #:use-module (srfi srfi-1))
 
+(define (python-guix-search-path-specification version)
+  "Return the search path specification for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES"))
+ (files   (list (string-append
+ "lib/python" major.minor "/site-packages"
+(search-path-specification
+ (variable variable)
+ (files files
+
+(define (python-guix-sitecustomize.py version)
+  "Return the content of @file{sitecustomize.py} for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES")))
+(format #f "# Append module search paths for guix packages to sys.path.
+import os
+import site
+
+SITE_PACKAGES = os.environ.get('~a')
+
+if SITE_PACKAGES is None:
+SITE_PACKAGES = []
+else:
+SITE_PACKAGES = SITE_PACKAGES.split(os.pathsep)
+
+for i in SITE_PACKAGES:
+site.addsitedir(i)
+" variable)))
+
 (define-public python-2.7
   (package
 (name "python2")
@@ -304,6 +339,16 @@
  "/site-packages")))
(install-file tkinter.so target)
(delete-file tkinter.so)
+#t)))
+  (add-after 'install 'install-sitecustomize.py
+(lambda* (#:keys outputs #:allow-other-keys)
+  (let* ((out (assoc-ref outputs "out"))
+ (sitedir (car (find-files out "^site-packages$"
+   #:directories #t
+(with-output-to-file
+(string-append sitedir "/sitecustomize.py")
+  (lambda ()
+(display ,(python-guix-sitecustomize.py version
 #t))
 (inputs
  `(("bzip2" ,bzip2)
@@ -318,9 +363,7 @@
 (native-inputs
  `(("pkg-config" ,pkg-config)))
 (native-search-paths
- (list (search-path-specification
-(variable "PYTHONPATH")
-(files '("lib/python2.7/site-packages")
+ (list (python-guix-search-path-specification version)))
 (home-page "https://www.python.org;)
 (synopsis "High-level, dynamically-typed programming language")
 (description
@@ -427,13 +470,19 @@ data types.")
  "-x" "(lib2to3|test/bad.*)"
  ,file)))
   (find-files out "\\.py$")))
-  (list '() '("-O") '("-OO"))
+  (list '() '("-O") '("-OO"))
+   (replace 'install-sitecustomize.py
+ (lambda* (#:keys outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+ 

Re: [PATCH] gnu: python: Honor 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

[宋文武]

Hartmut Goebel <h.goe...@crazy-compilers.com> writes:

> Am 17.03.2018 um 12:18 schrieb 宋文武:
>
>  I plan to implement option 1 by adding a "sitecustomize.py" (better
> than modify "site.py") into the python packages, and modify
> "search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES".
>
> Sorry, do say, but does not work in a virtual environment, since 
> GUIX_PYTHON_X_Y_SITE_PACKAGES will be added unconditionally. Also I assume 
> this will execute site.main
> () twice.

Okay, and maybe it actually works?  :-)

It turns out that 'sitecustomize.py' will be imported (executed) at most
once, and won't be added unconditionally:

- with "include-system-site-packages = false", a python3 created venv
  will have a "sys.path" like:

  ['',
  '/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python36.zip',
  '/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6',
  
'/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6/lib-dynload',
  '/tmp/venv36/lib/python3.6/site-packages']

  Since "sitecustomize.py" is in
  
"/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6/site-packages",
  it's not executed at all.


- with "include-system-site-packages = true", the python3 created venv
  will have a "sys.path" like:

  ['',
  '/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python36.zip',
  '/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6',
  
'/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6/lib-dynload',
  '/tmp/lib/python3.6/site-packages',
  
'/gnu/store/pppycfhs5gc7dsx7g099l9p6ncw3m6d9-python-3.6.4/lib/python3.6/site-packages',
  .. (entries added by GUIX_PYTHON_3_6_SITE_PACKAGES)]

  I think this is the wanted result.

  I haven't try "virtualenv" and python2 (need time to build...), but
  I guess the results should be the same?
  

[PATCH] gnu: python: Honor 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

[宋文武]

> I plan to implement option 1 by adding a "sitecustomize.py" (better
> than modify "site.py") into the python packages, and modify
> "search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES".

Patch coming:

>From d9c273c0ee8c5e87b12b37a325c649f8df808af3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sat, 17 Mar 2018 18:46:55 +0800
Subject: [PATCH] gnu: python-2.7, python-3.6: Honor
 'GUIX_PYTHON_X_Y_SITE_PACKAGES'.

This replace the use of 'PYTHONPATH' as search path specification, as
suggested by Hartmut Goebel .  See
 for
details.

* gnu/packages/python.scm (python-guix-search-path-specification)
(python-guix-sitecustomize.py): New procedures.
(python-2.7, python-3.6):
[native-search-paths]: Use 'python-guix-search-path-specification'.
[arguments]: Add 'install-sitecustomize.py' phase.
---
 gnu/packages/python.scm | 67 ++---
 1 file changed, 58 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6639e6c9e..2ce8db710 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -136,6 +136,41 @@
   #:use-module (guix build-system trivial)
   #:use-module (srfi srfi-1))
 
+(define (python-guix-search-path-specification version)
+  "Return the search path specification for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES"))
+ (files   (list (string-append
+ "lib/python" major.minor "/site-packages"
+(search-path-specification
+ (variable variable)
+ (files files
+
+(define (python-guix-sitecustomize.py version)
+  "Return the content of @file{sitecustomize.py} for python VERSION."
+  (let* ((major.minor (version-major+minor version))
+ (variable(string-append
+   "GUIX_PYTHON_"
+   (string-replace-substring major.minor "." "_")
+   "_SITE_PACKAGES")))
+(format #f "# Append module search paths for guix packages to sys.path.
+import os
+import site
+
+SITE_PACKAGES = os.environ.get('~a')
+
+if SITE_PACKAGES is None:
+SITE_PACKAGES = []
+else:
+SITE_PACKAGES = SITE_PACKAGES.split(os.pathsep)
+
+for i in SITE_PACKAGES:
+site.addsitedir(i)
+" variable)))
+
 (define-public python-2.7
   (package
 (name "python2")
@@ -304,6 +339,16 @@
  "/site-packages")))
(install-file tkinter.so target)
(delete-file tkinter.so)
+#t)))
+  (add-after 'install 'install-sitecustomize.py
+(lambda* (#:keys outputs #:allow-other-keys)
+  (let* ((out (assoc-ref outputs "out"))
+ (sitedir (car (find-files out "^site-packages$"
+   #:directories #t
+(with-output-to-file
+(string-append sitedir "/sitecustomize.py")
+  (lambda ()
+(display ,(python-guix-sitecustomize.py version
 #t))
 (inputs
  `(("bzip2" ,bzip2)
@@ -318,9 +363,7 @@
 (native-inputs
  `(("pkg-config" ,pkg-config)))
 (native-search-paths
- (list (search-path-specification
-(variable "PYTHONPATH")
-(files '("lib/python2.7/site-packages")
+ (list (python-guix-search-path-specification version)))
 (home-page "https://www.python.org;)
 (synopsis "High-level, dynamically-typed programming language")
 (description
@@ -427,13 +470,19 @@ data types.")
  "-x" "(lib2to3|test/bad.*)"
  ,file)))
   (find-files out "\\.py$")))
-  (list '() '("-O") '("-OO"))
+  (list '() '("-O") '("-OO"))
+   (replace 'install-sitecustomize.py
+ (lambda* (#:keys outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (sitedir (car (find-files out "^site-packages$"
+#:directories #t
+ (with-output-to-file
+ (string-append sitedir "/sitecustomize.py")
+   (lambda ()
+ (display ,(python-guix-sitecustomize.py version
+ #t)))
 (native-search-paths
- (list (search-path-specification
-(variable "PYTHONPATH")
-(files (list (string-append "lib/python"
-(version-major+minor version)
-  

Re: PYTHONPATH issue explanation

[宋文武]

Hartmut Goebel  writes:

Hello,

> Hi,
>
> given the ongoing discussion around Python show that my explanation was
> not good enough. I'll try to summarize and give more background.

Thanks for the explanations and this one!

So I have more understanding of it and ideas...

>
> With regard to Python, guix currently has a major issue, which my
> proposals are addressing. There are other issues (like naming the
> executables, the "wrapper" script", etc.) which are not addressed
> here.
> [...]

Okay, the "major issue" is that we're using "PYTHONPATH", which will add
entries into "sys.path" before builtin ones.  It's semantically wrong
and may (or had?) cause issues.


> Part 3 of my analysis lists three solutions for this, where only number
> 2 and 3 are "good choices".

Option 2, "GUIX_PYTHONHOME_X_Y" can not be used in the build-system
unless we make a union of python inputs, so I think we should go for 1
and optional (later) add 3 too:

- "GUIX_PYTHON_X_Y_SITE_PACKAGES" (X.Y is not a valid env identifier
  in bash) is necessary for the "build" environment.

  We don't make a union of all the inputs in the "build" environment, so
  a PATH (contains multiples directories) like env have to be used to
  let python find all its "site-packages" from inputs.

  > Drawbacks: This might break Python appications expecting
  > site-packages to be below sys.prefix.

  We have a patch named "python-2.7-site-prefixes.patch" seems to handle
  this, maybe we should do it for python3 too?


- Avoid any environment variable for the "profile" environment.

  We have a union "profile" for all the python packages, so environment
  variables can be totally avoided with the help of "venv".

  > We could avoid GUIX-PYTHONHOME[23] if we stop resolving the symlinks
  > at the correct point in iteration.

  This is exactly what "venv" does!  We only need to make the "profile"
  a "venv" for python.  For python3, a simple "pyvenv.cfg" file is
  enough, for python2 I guess we have to make a union or copy files like
  what "virtualenv" does.


I plan to implement option 1 by adding a "sitecustomize.py" (better
than modify "site.py") into the python packages, and modify
"search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES".

How's that sound?

Re: [RFC] A simple draft for channels

[宋文武]

Ricardo Wurmus  writes:

> Hi Guix,
>
> I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
> packages, because we can’t really keep track of packages that were added
> or redefined in this way.  I want to replace it with slightly more
> formal “channels”.

Hello, as a way to get and manage third-party guix repositories, it
sounds more like “overlays” (in Gentoo world) rather than “channels” (in
Nix world, to ensure binaries availability and updates stability) to me.

https://wiki.gentoo.org/wiki/Overlay
https://nixos.org/nix/manual/index.html#sec-channels

How about call it as “overlay”?

Re: Change defaults of 'define-record-type*' need invalidate auto-compilation caches

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> [...]
>>
>> Only with '--fresh-auto-compile' or delete the cache of x.scm, I will
>> get the output "y".
>>
>> Is this a bug?
>
> It’s a feature.  :-)
>
> Namely, default value resolution happens at macro-expansion time:
>
> scheme@(guile-user)> ,use(guix records)
> scheme@(guile-user)> (define-record-type* 
>   foo make-foo foo?
>   (x foo-x (default "x")))
>
> scheme@(guile-user)> ,expand (foo)
> $2 = (let* ((x "x")
>(s ((@@ (srfi srfi-9) allocate-struct)  1)))
>   ((@@ (srfi srfi-9) struct-set!) s 0 x)
>   s)
>
> That way, we can check at macro-expansion time that all the required
> fields are present, which is nice.
>
> The downside is what you write: that everything that uses the record
> type must be recompiled when it is changed (IOW, the record type is part
> of the ABI).
>
> HTH!

Get it, thanks for the explanation!

Re: Change defaults of 'define-record-type*' need invalidate auto-compilation caches

[宋文武]

> Hello,

Send it by mistake...


For example, in the current directory, I have 'foo.scm':
--8<---cut here---start->8---
(define-module (foo)
  #:use-module (guix records)
  #:export (foo foo-x))

(define-record-type* 
  foo make-foo foo?
  (x foo-x (default "x")))
--8<---cut here---end--->8---


And 'x.scm':
--8<---cut here---start->8---
(use-modules (foo))
(display (foo-x (foo)))
--8<---cut here---end--->8---


Run 'guile -L . x.scm', will output "x".

Then I change the '(default "x")' to '(default "y")' in foo.scm, and
re-run 'guile -L x.scm', it still output "x", I would expect it to
change to "y".

Only with '--fresh-auto-compile' or delete the cache of x.scm, I will
get the output "y".

Is this a bug?

Change defaults of 'define-record-type*' need invalidate auto-compilation caches

[宋文武]

Hello,

Re: [WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> Currently we run profile hooks for all manifest inputs, so if you
>> install a new package to your profile, all profile hooks will be run
>> again, even if the new package doesn't provide info manuals, man pages,
>> etc.  Ideally only interested hooks need to be run, eg: if the new
>> package has info manuals, then the 'info-dir-file' hook will run.
>>
>> I get it works somehow, but breaks the '--dry-run' functionality which I
>> have no idea how to preserve...
>
> Indeed.  I had the idea of adding a notion of “build rounds”, which
> would also be useful for grafts: you’d register (client-side) an extra
> build round to be run after the current one.  For grafts, the first
> round would return the ungrafted derivations.  For profile hooks, the
> first round would return the profile without any hooks.  “-n” would
> display what would be built/downloaded as part of the first round,
> ignoring subsequent rounds.
>

Hello, happy new year!  So I have just disable profile hooks for the
'dry-run' now and send patches to guix-patches.

Re: [WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[宋文武]

Martin Castillo <casti...@uni-bremen.de> writes:

> Hi,
>
> in the second patch file:
>> +  ;; We only need to build the 'dir' file for inputs that does
> containing info
>> +  ;; manuals.
> s/containing/contain
>

Okay, thanks!

> On 15.12.2017 16:12, 宋文武 wrote:> Hello!
>>
>> Currently we run profile hooks for all manifest inputs, so if you
>> install a new package to your profile, all profile hooks will be run
>> again, even if the new package doesn't provide info manuals, man pages,
>> etc.  Ideally only interested hooks need to be run, eg: if the new
>> package has info manuals, then the 'info-dir-file' hook will run.
>
> One would need to filter man-pages too, right?

Yes, that need be done in the 'manual-database' hook.

Re: [bug#29708] Update s-shell

[宋文武]

ng0  writes:

> Ludovic Courtès transcribed 0.4K bytes:
>> ng0  skribis:
>> 
>> > From cf2cbe9e9e525aa9dd697fcedb255a0fbc194ac9 Mon Sep 17 00:00:00 2001
>> > From: ng0 
>> > Date: Thu, 14 Dec 2017 13:22:58 +
>> > Subject: [PATCH] s-shell: Update to commit
>> >  da2e5c20c0c5f477ec3426dc2584889a789b1659.
>> >
>> > * gnu/packages/shells.scm (s-shell): Update to commit 
>> > da2e5c20c0c5f477ec3426dc2584889a789b1659.
>> > (version): Use 'git-version'.
>> 
>> I adjusted the commit log and pushed.
>
> Why is it [version]? Shouldn't it be (version)?
> Even though [version] now makes sense, I've seen
> mostly [] when it followed a () - and that's why
> I've been using ()[] and never(?) [] on its own.

Here the top level is the same as previous line, so it can be ommited:

  * ... (s-shell): ...
  [version]: ...

is same as:

  * ... (s-shell): ...
  (s-shell)[version]: ...

[WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[宋文武]

Hello!

Currently we run profile hooks for all manifest inputs, so if you
install a new package to your profile, all profile hooks will be run
again, even if the new package doesn't provide info manuals, man pages,
etc.  Ideally only interested hooks need to be run, eg: if the new
package has info manuals, then the 'info-dir-file' hook will run.

I get it works somehow, but breaks the '--dry-run' functionality which I
have no idea how to preserve...

>From 3fd19f5f59c28689e55b3a7dede942014f9b7fb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 15 Dec 2017 22:20:38 +0800
Subject: [PATCH 1/2] gexp: Add 'eval-gexp'.

* guix/gexp.scm (eval-gexp): New procedure.
---
 guix/gexp.scm | 16 
 1 file changed, 16 insertions(+)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 1929947d9..678e0c1e6 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -76,6 +76,7 @@
 gexp->derivation
 gexp->file
 gexp->script
+eval-gexp
 text-file*
 mixed-text-file
 file-union
@@ -1161,6 +1162,21 @@ and '%load-compiled-path' to honor EXP's imported modules."
  #:local-build? #t
  #:substitutable? #f)
 
+(define* (eval-gexp exp #:optional (name "value"))
+  "Return as a monadic value the EXP (a gexp) evaluate to.  This is
+implemented by building a store file NAME that contains the textual
+representation of EXP's value, and then @code{read} from it."
+  (mlet* %store-monad
+  ((drv (gexp->derivation
+ name
+ (gexp (with-output-to-file (ungexp output)
+ (lambda ()
+   (write (eval (quote (ungexp exp)) (current-module))
+ #:local-build? #t
+ #:substitutable? #t))
+   (_   (built-derivations (list drv
+(return (call-with-input-file (derivation->output-path drv) read
+
 (define* (text-file* name #:rest text)
   "Return as a monadic value a derivation that builds a text file containing
 all of TEXT.  TEXT may list, in addition to strings, objects of any type that
-- 
2.13.3

>From ca6aecb94455c6e009d94bf6a0780a8f876bc85d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 15 Dec 2017 22:38:41 +0800
Subject: [PATCH 2/2] profiles: info-dir-file: Don't consider unwanted manifest
 entries.

* guix/profiles.scm (info-dir-file): Use 'eval-gexp' to filter out those
manifest inputs that doesn't have info manuals.
---
 guix/profiles.scm | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index cedf9faa8..14b6c4253 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -683,7 +683,22 @@ MANIFEST."
   (define gzip;lazy reference
 (module-ref (resolve-interface '(gnu packages compression)) 'gzip))
 
-  (define build
+  ;; We only need to build the 'dir' file for inputs that does containing info
+  ;; manuals.
+  ;;
+  ;; XXX: This breaks '--dry-run', all manifest inputs will be built before
+  ;; returning the profile derivation...
+  (define interested
+(eval-gexp
+ #~(filter
+(lambda (input)
+  (file-exists? (string-append input "/share/info")))
+'#$(manifest-inputs manifest
+
+  ;; XXX: We have to pass paths of inputs instead of paths of info files,
+  ;; because 'gexp-inputs' only adds inputs for strings which satisfies
+  ;; 'direct-store-path?'.
+  (define (build inputs)
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils)
@@ -707,12 +722,12 @@ MANIFEST."
 
   (mkdir-p (string-append #$output "/share/info"))
   (exit (every install-info
-   (append-map info-files
-   '#$(manifest-inputs manifest)))
+   (append-map info-files '#$inputs))
 
-  (gexp->derivation "info-dir" build
-#:local-build? #t
-#:substitutable? #f))
+  (mlet* %store-monad ((inputs interested))
+(gexp->derivation "info-dir" (build inputs)
+  #:local-build? #t
+  #:substitutable? #f)))
 
 (define (ghc-package-cache-file manifest)
   "Return a derivation that builds the GHC 'package.cache' file for all the
-- 
2.13.3



Needing help and directions, thanks!

Re: qttools missing CMake version info

[宋文武]

Thomas Danckaert  writes:

> Hi,
>
> qttools no long has a file Qt5LinguistToolsConfigVersion.cmake in
> /gnu/store/.../ /lib/cmake/Qt5LinguistTools, which breaks the build
> for (among others?) keepassxc.  During the build of qttools, I see a
> warning
>
> WARNING: Cannot open substitute for input
> '/gnu/store/...-qttools-5.9.2/lib/qt5/mkspecs/features/data/cmake/Qt5ConfigVersion.cmake.in'
>
> Does this ring a bell for any of the local qt experts?

Fixed in b000294ef75f89bcaa6afc0c61e492c13f24376b, thanks for the
report!

Re: [WIP][PATCH] download: Don't report the progress too fast

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> iyzs...@member.fsf.org (宋文武) skribis:
>
>> From d0c49ac1341c21d0efb069afb1521f61541e3eb4 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
>> Date: Sat, 16 Sep 2017 14:10:18 -0600
>> Subject: [PATCH] download: Don't report the progress too fast.
>>
>> * guix/utils.scm (): New record type.
>> (call-with-progress-reporter): New procedure.
>> * guix/build/download.scm (dump-port*, rate-limited, progress-reporter/file):
>> New procedures.
>> (ftp-fetch, http-fetch): Use 'dump-port*'.
>> (progress-proc): Remove procedure.
>> * guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of
>> .
>> (process-substitution): Adjust accordingly.
>
> LGTM.  If you’ve confirmed that it works as intended, please push.
>

Done, thanks for the review!

Re: [PATCH] substitute: Close the download port after substitution finished.

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hi 宋文武,
>
> 宋文武 <iyzs...@member.fsf.org> skribis:
>
>> * guix/scripts/substitute.scm (progress-substitution): Call 'close-port'
>> after 'restore-file'.
>
> Good catch, please push!
>
> How did you notice?

I meet it when test my progress reporter patch at
<https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00190.html>,
which will write the last report to console after close
'progress-report-port'.


Pushed, thanks for the review!

[PATCH] substitute: Close the download port after substitution finished.

[宋文武]

* guix/scripts/substitute.scm (progress-substitution): Call 'close-port'
after 'restore-file'.
---
 guix/scripts/substitute.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 19212d749..3dcf42d0d 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -961,6 +961,7 @@ DESTINATION as a nar file.  Verify the substitute against 
ACL."
   progress)))
   ;; Unpack the Nar at INPUT into DESTINATION.
   (restore-file input destination)
+  (close-port input)
 
   ;; Skip a line after what 'progress-reporter/file' printed, and another
   ;; one to visually separate substitutions.
-- 
2.13.3

Re: [WIP][PATCH] download: Don't report the progress too fast

[宋文武]

iyzs...@member.fsf.org (宋文武) writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> [...]
>> Thoughts?
>
> How about replace the use of thread from ‘progress-reporter/file’ by a
> ‘rate-limited’ render procedure, and then change the elapsed time to
> ETA, which is okay without updating in seconds?

So I end up it with:

>From d0c49ac1341c21d0efb069afb1521f61541e3eb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
Date: Sat, 16 Sep 2017 14:10:18 -0600
Subject: [PATCH] download: Don't report the progress too fast.

* guix/utils.scm (): New record type.
(call-with-progress-reporter): New procedure.
* guix/build/download.scm (dump-port*, rate-limited, progress-reporter/file):
New procedures.
(ftp-fetch, http-fetch): Use 'dump-port*'.
(progress-proc): Remove procedure.
* guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of
.
(process-substitution): Adjust accordingly.
---
 guix/build/download.scm | 174 ++--
 guix/scripts/substitute.scm |  54 +++---
 guix/utils.scm  |  32 +++-
 3 files changed, 161 insertions(+), 99 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index bcf22663b..9490f4805 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -27,6 +27,7 @@
   #:use-module (guix base64)
   #:use-module (guix ftp-client)
   #:use-module (guix build utils)
+  #:use-module (guix utils)
   #:use-module (rnrs io ports)
   #:use-module (rnrs bytevectors)
   #:use-module (srfi srfi-1)
@@ -45,7 +46,7 @@
 url-fetch
 byte-count->string
 current-terminal-columns
-progress-proc
+progress-reporter/file
 uri-abbreviation
 nar-uri-abbreviation
 store-path-abbreviation))
@@ -148,65 +149,97 @@ Otherwise return STORE-PATH."
(define time-monotonic time-tai))
   (else #t))
 
-(define* (progress-proc file size
-#:optional (log-port (current-output-port))
-#:key (abbreviation basename))
-  "Return a procedure to show the progress of FILE's download, which is SIZE
-bytes long.  The returned procedure is suitable for use as an argument to
-`dump-port'.  The progress report is written to LOG-PORT, with ABBREVIATION
-used to shorten FILE for display."
-  ;; XXX: Because of <http://bugs.gnu.org/19939> this procedure is often not
-  ;; called as frequently as we'd like too; this is especially bad with Nginx
-  ;; on hydra.gnu.org, which returns whole nars as a single chunk.
-  (let ((start-time #f))
-(let-syntax ((with-elapsed-time
- (syntax-rules ()
-   ((_ elapsed body ...)
-(let* ((now (current-time time-monotonic))
-   (elapsed (and start-time
- (duration->seconds
-  (time-difference now
-   start-time)
-  (unless start-time
-(set! start-time now))
-  body ...)
+
+;; TODO: replace '(@ (guix build utils) dump-port))'.
+(define* (dump-port* in out
+ #:key (buffer-size 16384)
+ (reporter (make-progress-reporter noop noop noop)))
+  "Read as much data as possible from IN and write it to OUT, using chunks of
+BUFFER-SIZE bytes.  After each successful transfer of BUFFER-SIZE bytes or
+less, report the total number of bytes transferred to the REPORTER, which
+should be a  object."
+  (define buffer
+(make-bytevector buffer-size))
+
+  (call-with-progress-reporter reporter
+(lambda (report)
+  (let loop ((total 0)
+ (bytes (get-bytevector-n! in buffer 0 buffer-size)))
+(or (eof-object? bytes)
+(let ((total (+ total bytes)))
+  (put-bytevector out buffer 0 bytes)
+  (report total)
+  (loop total (get-bytevector-n! in buffer 0 buffer-size
+
+(define (rate-limited proc interval)
+  "Return a procedure that will forward the invocation to PROC when the time
+elapsed since the previous forwarded invocation is greater or equal to
+INTERVAL (a time-duration object), otherwise does nothing and returns #f."
+  (let ((previous-at #f))
+(lambda args
+  (let* ((now (current-time time-monotonic))
+ (forward-invocation (lambda ()
+   (set! previous-at now)
+   (apply proc args
+(if previous-at
+(let ((elapsed (time-difference now previous-at)))
+  (if (time>=? elapsed interval)
+  (forward-invocation)
+  

Re: [WIP][PATCH] download: Don't report the progress too fast

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> [...]
>> Date: Fri, 8 Sep 2017 22:49:03 +0800
>> Subject: [PATCH] download: Report the progress asynchronously in another
>>  thread.
>>
>> * guix/utils.scm (): New record type.
>> (call-with-progress-reporter): New procedure.
>> * guix/build/download.scm (dump-port*, progress-reporter/file): New
>> procedures.
>> (ftp-fetch, http-fetch): Use them.
>> (progress-proc): Remove procedure.
>> * guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of
>> .
>> (process-substitution): Adjust accordingly.
>
> Impressive!
>
> I have a couple of concerns though:
>
>   1. Using a thread “just” for progress reporting seems quite
>  heavyweight, though maybe that’s OK.

Yes..
>
>   2. As per POSIX, we cannot mix ‘fork’ and threads, so programs that
>  use ‘primitive-fork’ should not also use threads.  One such program
>  is (guix scripts substitute), via ‘decompressed-port’.  Guile
>  rightfully emits a warning when a multithreaded program calls
>  ‘primitive-fork’:
>
>https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c#n1224

Oh, thanks for pointing it out!
>
>3. “Atomic boxes” are a Guile 2.2 feature, but we still support 2.0.
>
> To address these, I would use ‘abort-to-prompt’ & co., possibly with
> “suspendable ports”, but this is a 2.2 feature.  (It may be that we
> should use Fibers directly.)

Sure, I’d like to try fibers.  When we can drop the support of Guile
2.0?  (I guess one sign is that 2.2 is in the debian stable.)

>
> Tricky!  Not sure what to do here.
>
> Thoughts?

How about replace the use of thread from ‘progress-reporter/file’ by a
‘rate-limited’ render procedure, and then change the elapsed time to
ETA, which is okay without updating in seconds?

Re: [WIP][PATCH] download: Don't report the progress too fast

[宋文武]

Hi, sorry for my late response.

l...@gnu.org (Ludovic Courtès) writes:

> Hello 宋文武,
>
> iyzs...@member.fsf.org (宋文武) skribis:
>
>> Hello, our progress report of 'guix download' can refresh too fast.  For
>> example, it blinks much with this script:
>
> Indeed, that’s always annoyed me.  I’m glad you’re looking at it!
>
>> [...]
>
> [...]
> (Also, longer-term, we’d want to do that other way around, which is to
> update the report every N milliseconds, as opposed to just printing
> something when a chunk has been transferred.)
>

Yes, so the elapsed time won't be freezed, and here is my try using
thread:

>From 4036ce5de7bf3b98327010bbfbf75029f3d0b572 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
Date: Fri, 8 Sep 2017 22:49:03 +0800
Subject: [PATCH] download: Report the progress asynchronously in another
 thread.

* guix/utils.scm (): New record type.
(call-with-progress-reporter): New procedure.
* guix/build/download.scm (dump-port*, progress-reporter/file): New
procedures.
(ftp-fetch, http-fetch): Use them.
(progress-proc): Remove procedure.
* guix/scripts/substitute.scm (progress-report-port): Rewrite in terms of
.
(process-substitution): Adjust accordingly.
---
 guix/build/download.scm | 169 ++--
 guix/scripts/substitute.scm |  54 +++---
 guix/utils.scm  |  32 -
 3 files changed, 159 insertions(+), 96 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index bcf22663b..7c712ca94 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -27,6 +27,7 @@
   #:use-module (guix base64)
   #:use-module (guix ftp-client)
   #:use-module (guix build utils)
+  #:use-module (guix utils)
   #:use-module (rnrs io ports)
   #:use-module (rnrs bytevectors)
   #:use-module (srfi srfi-1)
@@ -36,6 +37,8 @@
   #:autoload   (ice-9 ftw) (scandir)
   #:use-module (ice-9 match)
   #:use-module (ice-9 format)
+  #:use-module (ice-9 atomic)
+  #:use-module (ice-9 threads)
   #:export (open-socket-for-uri
 open-connection-for-uri
 %x509-certificate-directory
@@ -45,7 +48,7 @@
 url-fetch
 byte-count->string
 current-terminal-columns
-progress-proc
+progress-reporter/file
 uri-abbreviation
 nar-uri-abbreviation
 store-path-abbreviation))
@@ -148,65 +151,92 @@ Otherwise return STORE-PATH."
(define time-monotonic time-tai))
   (else #t))
 
-(define* (progress-proc file size
-#:optional (log-port (current-output-port))
-#:key (abbreviation basename))
-  "Return a procedure to show the progress of FILE's download, which is SIZE
-bytes long.  The returned procedure is suitable for use as an argument to
-`dump-port'.  The progress report is written to LOG-PORT, with ABBREVIATION
-used to shorten FILE for display."
-  ;; XXX: Because of <http://bugs.gnu.org/19939> this procedure is often not
-  ;; called as frequently as we'd like too; this is especially bad with Nginx
-  ;; on hydra.gnu.org, which returns whole nars as a single chunk.
-  (let ((start-time #f))
-(let-syntax ((with-elapsed-time
- (syntax-rules ()
-   ((_ elapsed body ...)
-(let* ((now (current-time time-monotonic))
-   (elapsed (and start-time
- (duration->seconds
-  (time-difference now
-   start-time)
-  (unless start-time
-(set! start-time now))
-  body ...)
-  (if (number? size)
-  (lambda (transferred cont)
-(with-elapsed-time elapsed
-  (let* ((%  (* 100.0 (/ transferred size)))
- (throughput (if elapsed
- (/ transferred elapsed)
- 0))
- (left   (format #f " ~a  ~a"
- (abbreviation file)
- (byte-count->string size)))
- (right  (format #f "~a/s ~a ~a~6,1f%"
- (byte-count->string throughput)
- (seconds->string elapsed)
- (progress-bar %) %)))
-(display "\r\x1b[K" log-port)
-(display (string-pad-middle left right
-(current-terminal-columns))
- log-port)
-(flush-output-port log-port)
- 

Re: QT install and search paths

[宋文武]

Hartmut Goebel <h.goe...@crazy-compilers.com> writes:

> Am 04.09.2017 um 09:44 schrieb Thomas Danckaert:
>> Just to make sure, the idea is to:
>>
>>  1. apply 宋文武's qtbase patch adjusting the paths of various qt components
>>
>>  2. apply your 2 patches for qtscintilla and qtwebkit
>>
>>  3. adjust kde.scm so packages in there build correctly?
>
> ACK from my side.

Yes, and here are my updates on the paths issue of pkg-config files and
qwt:

>From e8a252f5037b77f44a1516c715bbd437a6e23cb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@member.fsf.org>
Date: Sun, 3 Sep 2017 17:38:57 +0800
Subject: [PATCH 2/3] gnu: qt: Fix install paths in submodules.

Before this, the paths in pkg-config (.pc) and libtool (.la) files of
submodules are all pointing to qtbase.

* gnu/packages/qt.scm (qtbase)[native-inputs]: Move 'which' to
'propagated-inputs'.
[arguments]: Rename 'patch-mkspecs' phase to 'patch-mkspecs' and patch
more qmake spec files there.
(qtsvg)[arguments]: Add 'configure-qmake' phase.
---
 gnu/packages/qt.scm | 86 +++--
 1 file changed, 63 insertions(+), 23 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 80508f058..a41aa4fbb 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -375,7 +375,8 @@ developers using C++ or QML, a CSS & JavaScript like language.")
 #t
 (build-system gnu-build-system)
 (propagated-inputs
- `(("mesa" ,mesa)))
+ `(("mesa" ,mesa)
+   ("which" ,(@ (gnu packages base) which
 (inputs
  `(("alsa-lib" ,alsa-lib)
("cups" ,cups)
@@ -426,8 +427,7 @@ developers using C++ or QML, a CSS & JavaScript like language.")
("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-2)
-   ("ruby" ,ruby)
-   ("which" ,(@ (gnu packages base) which
+   ("ruby" ,ruby)))
 (arguments
  `(#:phases
(modify-phases %standard-phases
@@ -491,10 +491,11 @@ developers using C++ or QML, a CSS & JavaScript like language.")
  '("-no-sse2"))
"-no-mips_dsp"
"-no-mips_dspr2")
- (add-after 'install 'patch-qt_config.prf
+ (add-after 'install 'patch-mkspecs
(lambda* (#:key outputs #:allow-other-keys)
  (let* ((out (assoc-ref outputs "out"))
-(mkspecs (string-append out "/lib/qt5/mkspecs"))
+(archdata (string-append out "/lib/qt5"))
+(mkspecs (string-append archdata "/mkspecs"))
 (qt_config.prf (string-append
 mkspecs "/features/qt_config.prf")))
;; For each Qt module, let `qmake' uses search paths in the
@@ -508,6 +509,20 @@ developers using C++ or QML, a CSS & JavaScript like language.")
   "$$clean_path($$replace(dir, mkspecs/modules, ../../lib))")
  (("\\$\\$\\[QT_INSTALL_BINS\\]")
   "$$clean_path($$replace(dir, mkspecs/modules, ../../bin))"))
+
+   ;; Searches Qt tools in the current PATH instead of QT_HOST_BINS.
+   (substitute* (string-append mkspecs "/features/qt_functions.prf")
+ (("cmd = \\$\\$\\[QT_HOST_BINS\\]/\\$\\$2")
+  "cmd = $$system(which $${2}.pl 2>/dev/null || which $${2})"))
+
+   ;; Resolve qmake spec files within qtbase by absolute paths.
+   (substitute*
+   (map (lambda (file)
+  (string-append mkspecs "/features/" file))
+'("device_config.prf" "moc.prf" "qt_build_config.prf"
+  "qt_config.prf" "winrt/package_manifest.prf"))
+ (("\\$\\$\\[QT_HOST_DATA/get\\]") archdata)
+ (("\\$\\$\\[QT_HOST_DATA/src\\]") archdata))
#t))
 (native-search-paths
  (list (search-path-specification
@@ -553,26 +568,51 @@ developers using C++ or QML, a CSS & JavaScript like language.")
 (arguments
  `(#:phases
(modify-phases %standard-phases
- (replace 'configure
-   (lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
-   ;; Valid QT_BUILD_PARTS variables are:
-   ;; libs tools tests examples demos docs translations
-   (zero? (system* "qmake" "QT_BUILD_PARTS = libs tools te

Re: QT install and search paths

[宋文武]

Hartmut Goebel <h.goe...@crazy-compilers.com> writes:

> Am 03.09.2017 um 13:46 schrieb 宋文武:
>
>  0002-gnu-qt-Fix-install-paths-in-submodules.patch
>
> I'm afraid this breaks some packages, e.g. qwt (qt.scm) and sonnet
> (kde-frameworks.scm). Can you have a look at what is going wrong here?
> Thanks

Yeah, this patch need more works.  I also find that 'qttools' ends up
with broken 'imported_location' in Qt5LinguistToolsConfig.cmake and
Qt5HelpConfigExtras.cmake, will look into it later...

Re: QT install and search paths

[宋文武]

> [...]
> And vlc fails to build due to can't find headers of Qt5X11Extras.
> Indeed, the pkg-config output of Qt5X11Extras seems wrong:

> $ pkg-config --cflags --libs Qt5X11Extras
> -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtGui 
> -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
> -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtCore 
> -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
> -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtX11Extras
>  -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
> -L/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/lib -lQt5X11Extras 
> -lQt5Gui -lQt5Core

> I can try fix this pkg-config issue.

Here is it:

>From b2f4822b3a1c8f76d2c6dcf39590d3810d3510bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 3 Sep 2017 17:38:57 +0800
Subject: [PATCH 2/2] gnu: qt: Fix install paths in submodules.

Before this, the paths in pkg-config (.pc) and libtool (.la) files of
submodules are all pointing to qtbase.

* gnu/packages/qt.scm (qtsvg)[arguments]: Use a customized qt.conf to
override install paths to $out.
---
 gnu/packages/qt.scm | 57 +
 1 file changed, 40 insertions(+), 17 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 80508f058..771a03bd5 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -554,25 +554,48 @@ developers using C++ or QML, a CSS & JavaScript like language.")
  `(#:phases
(modify-phases %standard-phases
  (replace 'configure
-   (lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(qtbase (assoc-ref inputs "qtbase"))
+(tmpdir (string-append (getenv "TMPDIR")))
+(qmake (string-append tmpdir "/qmake"))
+(qt.conf (string-append tmpdir "/qt.conf")))
+   ;; Use qmake with a customized qt.conf to override install
+   ;; paths to $out.
+   (symlink (which "qmake") qmake)
+   (with-output-to-file qt.conf
+ (lambda ()
+   ;; Thoese must be kept in sync with qtbase.
+   (format #t "[Paths]
+Prefix=~a
+ArchData=lib/qt5
+Data=share/qt5
+Documentation=share/doc/qt5
+Headers=include/qt5
+Libraries=lib
+LibraryExecutables=lib/qt5/libexec
+Binaries=bin
+Tests=tests
+Plugins=lib/qt5/plugins
+Imports=lib/qt5/imports
+Qml2Imports=lib/qt5/qml
+Translations=share/qt5/translations
+Settings=etc/xdg
+Examples=share/doc/qt5/examples
+HostPrefix=~a
+HostData=lib/qt5
+HostBinaries=bin
+HostLibrariesPath=lib
+" out qtbase)))
+
;; Valid QT_BUILD_PARTS variables are:
;; libs tools tests examples demos docs translations
-   (zero? (system* "qmake" "QT_BUILD_PARTS = libs tools tests"
-   (string-append "PREFIX=" out))
- (add-before 'install 'fix-Makefiles
-   (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out(assoc-ref outputs "out"))
-   (qtbase (assoc-ref inputs "qtbase")))
-   (substitute* (find-files "." "Makefile")
-(((string-append "INSTALL_ROOT)" qtbase))
- (string-append "INSTALL_ROOT)" out)))
-   #t)))
-(add-before 'check 'set-display
-  (lambda _
-;; make Qt render "offscreen", required for tests
-(setenv "QT_QPA_PLATFORM" "offscreen")
-#t)))
+   (zero? (system* qmake "QT_BUILD_PARTS = libs tools tests")
+ (add-before 'check 'set-display
+   (lambda _
+ ;; make Qt render "offscreen", required for tests
+ (setenv "QT_QPA_PLATFORM" "offscreen")
+ #t)))
 
 (define-public qtimageformats
   (package (inherit qtsvg)
-- 
2.13.3


This fixes the pkg-config files of various qt submodules, and gets vlc
built.


I think remaining non-KDE things to fix are qt-utils.scm, sddm,
greenisland and cool-retro-term.

Re: QT install and search paths

[宋文武]

NS\\]")
-  "$$replace(dir, mkspecs/modules, bin)")
- (("\\$\\$\\[QT_INSTALL_IMPORTS\\]")
-  "$$replace(dir, mkspecs/modules, imports)")
- (("\\$\\$\\[QT_INSTALL_QML\\]")
-  "$$replace(dir, mkspecs/modules, qml)"))
+  "$$clean_path($$replace(dir, mkspecs/modules, ../../bin))"))
#t))
 (native-search-paths
  (list (search-path-specification
 (variable "QMAKEPATH")
-(files '("")))
+(files '("lib/qt5")))
(search-path-specification
 (variable "QML2_IMPORT_PATH")
-(files '("qml")))
+(files '("lib/qt5/qml")))
(search-path-specification
 (variable "QT_PLUGIN_PATH")
-(files '("plugins")))
+(files '("lib/qt5/plugins")))
(search-path-specification
 (variable "XDG_DATA_DIRS")
 (files '("share")))
@@ -805,6 +804,18 @@ developers using C++ or QML, a CSS & JavaScript like language.")
  (snippet
;; The examples try to build and cause the build to fail
   '(delete-file-recursively "examples"
+(arguments
+ (substitute-keyword-arguments (package-arguments qtsvg)
+   ((#:phases phases)
+`(modify-phases ,phases
+   (add-before 'check 'set-ld-library-path
+ ;; <https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00019.html>
+ ;;
+ ;; Make the uninstalled libQt5WaylandClient.so.5 available to the
+ ;; wayland platform plugin.
+ (lambda _
+   (setenv "LD_LIBRARY_PATH" (string-append (getcwd) "/lib"))
+   #t))
 (native-inputs
  `(("glib" ,glib)
("perl" ,perl)
-- 
2.13.3



> 3. tests of other packages may fail for the same reason.

Yes, I have got tiled running, and find that 'cool-retro-term' need to
be adjusted.

And vlc fails to build due to can't find headers of Qt5X11Extras.
Indeed, the pkg-config output of Qt5X11Extras seems wrong:
--8<---cut here---start->8---
$ pkg-config --cflags --libs Qt5X11Extras
-I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtGui 
-I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
-I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtCore 
-I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
-I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5/QtX11Extras
 -I/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/include/qt5 
-L/gnu/store/l8xp2i57plmdd3pprhznc8r03ha3sv2s-qtbase-5.9.1/lib -lQt5X11Extras 
-lQt5Gui -lQt5Core
--8<---cut here---end--->8---

I can try fix this pkg-config issue.

>
> I'll take care of the packages in kde-frameworks.scm, I assume/hope
> Thomas will take care of the ones in kde.scm.

Yeah, I build 'kiarchive', and find it puts 'mkspecs' under $out, which
needs change to $out/lib/qt5/mkspecs.

>
> 宋文武, how can we coordinate the required changes? Should they go into one 
> patch? Or into a series?

I think we could make a series patches, and can squash them later if
suitable.