Re: Welcome to Zheng (z572) as a new committer!

[Zhu Zihao]

Congratulations!

Maxim Cournoyer  writes:

> Hi comrades,
>
> Zheng has joined the committers to help improving cross-compilation,
> riscv64, and KDE, among others.
>
> Let's wish them a warm welcome!
>
> Happy hacking!


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: Why does Guix duplicate dependency versions from Cargo.toml?

[Zhu Zihao]

Jonas Møller  writes:

> Hi Guix! Why does cargo-build-system need #:cargo-inputs specified in the 
> package definition? This seems like a big
> mistake for a couple of reasons.

Just like the nice people in mail list explained, when building a
package, Guix builders are not allowed to connect to network, so the
crates should be prefetched.

and AFIAK, Maxime Devos is working on new build system called
"Antioxidant", which can build rust application without cargo (Yes,
invoke rustc directly!), The new build system will cache the rlib
intermediate result of crate and share between different builds. 

> 1 It is completely redundant, it should match what is in Cargo.toml. I know 
> `guix import crate` exists to automate
>  this process, but I don't understand the rationale for duplicating
>  this information.

Not only Guix do this, Debian also package Rust crates [1]. 

> 2 It is bad practice for Guix to override Cargo.lock if it exists, this means 
> that Guix is building a different binary to the
>  one the developers of the packaged Rust application are seeing on their end, 
> this is a much bigger problem.  

OK, IMO almost all software packaged by Linux distro are "different"
from upstream at binary level. A notable example is, software developer
may prefeer to add bundled 3rd party dependencies to ease the build of
package. But distro maintainers want to ensure every software use the
library provided by distro[2]. And there maybe distro specific patches
(Redhat backports security fixes to the old version of package for their
RHEL)

>  This can and will cause spurious build failures, or bugs that are unknown to 
> the developers of the Rust programs that
>  Guix packages.

The Rust crate in Guix is used to package rust application, if user have
problem with the rust application on Guix (e.g. ripgrep, fd, xxd, bat
...) They should report to Guix first, so it's Guix developer's
responsibility to smooth out those differences. 

If user want to develop a Rust crate/application, they can still use
"cargo" command and fetch crates from crates.io registry.

 

[1]: https://packages.debian.org/sid/librust-bytecount-dev
[2]: https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: A certain new commiter

[Zhu Zihao]

That's awesome, Congratulations!

Hilton Chain  writes:

> [[PGP Signed Part:Undecided]]
> 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.
>
> Thanks,
> Hilton Chain
>
> ---
> This mail is signed by the key with the following fingerprint, I'll
> use it for commit signing:
> F4C2 D1DF 3FDE EA63 D1D3  0776 ACC6 6D09 CA52 8292
>
> The signing key is a subkey of
> 220F 98D9 5E86 204C 0036  DA7B 6DEC 4360 408B 4185
>
> , which is attached.  And it can be found in [2] as well.
>
> [1]:
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=85dbe6d13f20b884f343032e5d1829cc0ef9000d
>
> [2]:
> https://savannah.gnu.org/users/hako
> https://keys.openpgp.org/vks/v1/by-fingerprint/220F98D95E86204C0036DA7B6DEC4360408B4185
>
> [2. application/pgp-keys]...
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

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

[Zhu Zihao]

count me in :)

宋文武  writes:

> 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) :)


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: What's missing from qutebrowser for text rendering?

[Zhu Zihao]

This is a known bug of qtwebengine, it's not related to your font
settings. It's about glibc and the sandbox of qtwebengine.

See here for more detail:
https://bugs.chromium.org/p/chromium/issues/detail?id=1164975

It's not fixed because the open source support of Qt 5 series is end. Only
commercial support can get the patch(Qt 5.15.8).

If we want to fix this, we may give the KDE's Qt branch a look. AFAIK,
Archlinux use it.

A simple workaround for your problem is: Disable the sandbox.

"jgart"  writes:

> hi guixers,
>
> what am I missing from qutebrowser to render text from sites like wikipedia 
> and g-golf documentation site?
>
> See this screenshot (will expire in a week):
>
> https://up.nixnet.services/j80xqgx7.png
>
> has anyone else run into this issue?
>
> I'm on guix system and I installed qutebrowser via my guix home profile
>
> Does qutebrowser on guix system require me to explicitly install fonts for it?
>
> all best


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: Congrats on KDE Plasma

[Zhu Zihao]

Thanks for your great works!

BTW, Can Guix run a complete KDE desktop now? Do you have plan to make a
KDE desktop service like `xfce-desktop-service-type`?

Raghav Gururajan  writes:

> [[PGP Signed Part:Undecided]]
> Hello Guix!
>
> I'd like to congratulate and thank Petr Hodina, Brendan Tildesley, Marius 
> Bakke,
> et al; for their tremendous effort in bringing KDE Plasma to Guix.
>
> :-)
>
> Regards,
> RG.
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: foreign-distro?

[Zhu Zihao]

If you want to left the choice to user. You can just don't patch it. Or
you can always patch it because user can still use package transformer
to specify a custom ffmpeg.


jgart  writes:

> Does Guix have a declarative Guix API way of knowing if it is installing
> a package into foreign distro versus Guix System?
>
> I'm thinking of a function like `foreign-distro?`:
>
> ```
> (define-public peek
>   (package
>(name "peek")
>...
> (inputs 
>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
>
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
>
> WDYT


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: How do I reference the src checkout in a package?

[Zhu Zihao]

Try `#$(package-source this-package)` in the builder gexp.

Or you can try `(assoc-ref inputs "source")`, but be careful, this is
undocumented behaviour and it may change without notice and break your
recipes.

OT: it's better to ask for help in help-g...@gnu.org :)

jgart  writes:

> On Sat, 29 Oct 2022 23:05:50 -0500 jgart  wrote:
>
> For example, nix allows you to reference the source checkout with the $src 
> variable:
>
> https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/compilers/carp/default.nix#L38


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: How Do We Fish If It Loads?

[Zhu Zihao]

It seems that there's no carp-lang packaged in Guix. So we have to
package it first.

And we should find out how the build system of Carp work.

OT: People will happier if you can elaborate the software you want to
package, e.g. describe what is Carp.

jgart  writes:

> hi,
>
> how do we package carp libraries for guix if it does this?
>
> `(load "g...@github.com:carpentry-org/time.carp@0.1.0")`
>
> * https://github.com/carpentry-org/time#installation


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: [PATCH 1/2] gnu: ddcutil: Update to 1.3.2.

[Zhu Zihao]

Hello, kiasoc5. Thanks for contributing to Guix!

However, patches should be sent to guix-patc...@gnu.org, so the debbugs
can track the status of your patch :)
-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

[RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS

[Zhu Zihao]

# Background

Now in Guix. LLVM is built with configure flag
"-DBUILD_SHARED_LIBS:BOOL=TRUE". According to
https://llvm.org/docs/CMake.html. Build LLVM with `BUILD_SHARED_LIBS` is
not recommended for non LLVM developing usage. LLVM says that packager
should use `LLVM_BUILD_LLVM_DYLIB` instead.

The main difference between `LLVM_BUILD_LLVM_DYLIB` and
`BUILD_SHARED_LIBS` is the former one will generate a monolith shared
library called `libLLVM.so` and the latter will generate individual
libLLVMCore.so libLLVMXXX.so ...

# Issue

`BUILD_SHARED_LIBS` works for us now. But this configure flags will
violates some setup of the cmake script of LLVM.

LLVM components provides an cmake option called `LLVM_LINK_LLVM_DYLIB`
to let user to choose whether dynamically linked or not. Our build
breaks this option.

In lib/cmake/llvm/AddOCaml.cmake:69

```
  if(LLVM_LINK_LLVM_DYLIB)
list(APPEND ocaml_flags "-lLLVM")
  else()
```

If the add_ocaml_library function is used and `LLVM_LINK_LLVM_DYLIB` is
set to true, it'll tries to link the libLLVM.so which is not provided by
us.

This issue also exists for add_llvm_library.


Though this looks like the issue of LLVM, because `llvm-config`
executable works well for us: if you pass `--link-static` to
llvm-config, it will complain that static archive files is not found.
And if pass `--link-shared`, it can generate the command args that link
to individual shared library.

# Solution

I suggest to replace `-DBUILD_SHARED_LIBS:BOOL=TRUE` with
`-DLLVM_BUILD_LLVM_DYLIB:BOOL=TRUE`.

# Cons

We may introduce following problems if we apply this solution.

1. Increase the closure size of LLVM.

By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to
build the static archive. This may increase the closure size of LLVM.
And some package linking with LLVM may use the static archive instead of
linking to the dynamic library.

My opinion: If we're OK with the bigger closure size, that's not a
problem. If not, we may consider disable the static archive generation.
For LLVM components, we can use `LLVM_LINK_LLVM_DYLIB` to ask these
packages to link with the shared version. For package use `llvm-config`
directly or indirectly, we can pass `--link-shared` to it.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

Re:Re: bug#55026: potential prebuilt binaries in the Mono package

[Zhu Zihao]

Agree.


Actually, there's more prebuilt binaries in Mono 6 (current version)


And it's impossible to remove these binaries (see 
https://github.com/dotnet/source-build/issues/1930)






At 2022-08-13 04:03:43, "Maxim Cournoyer"  wrote:
>Hi,
>
>zamfofex  writes:
>
>> It seems the package for Mono in Guix uses a tarball that contains a
>> lot of prebuilt DLLs. This doesn’t seem to have been mentioned when
>> the package was introduced. Could it have been a mistake? Some related
>> discussion:  and also
>> 
>
>If nobody volunteers to do the work necessary to get our mono package to
>build without prebuilt binaries in the next 2 weeks, I suggest we remove
>it from our collection.  Only a handful package depend on it, most of
>them optionally it seems, and the mono we carry is severely outdated
>(2016).
>
>What do you think?
>
>Maxim

Re: “Building a Secure Software Supply Chain with GNU Guix”

[Zhu Zihao]

Ludovic Courtès  writes:

>> We have PGP sign and git commit chain to make sure the commits are
>> committed by trusted people. But it's still possible for the channel
>> owner to inject malicious code into the channel in a future commit. Like
>> what Marak Squires did in faker.js project :( or the committer of Guix
>> was attacked by an evil maid.
>
> I’m not aware of the faker.js story, do you have a link?

https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

Here's a detailed report about Marak and faker.js.

>> In Nix flakes, there's pure evaluation to make sure no side-effectful
>> code is allowed. But Guix channel is less restricted than a Nix flake.
>> It's a important problem to make sure the evaluation is safe for the user.
>
> Yes, I understand.  I don’t think that makes a practical difference
> though: when you pull from a Guix channel or fetch a Nix flake, that’s
> because you want to install software according to what that
> channel/flake provides.  So whether evil code is in the channel/flake
> (as Scheme/Nix code) or in the package(s) themselves makes little
> difference.
>
> Does that make sense?

My two cents: When depolying a manifest, we use `guix package -p
 -m `, This command consists two
parts. Guix will first evaluate the packages specified in the manifest,
and build the profile. And then populate the profile to given
destination. The first part can be done in a sandboxed environment, or a
non-privileged account like "nobody".

-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao


signature.asc
Description: PGP signature

Re: “Building a Secure Software Supply Chain with GNU Guix”

[Zhu Zihao]

Good article!

There's still some questions to ask. I'm concerned about the safety of
the evaluation of channel code. IIRC, there's no sandbox for the
evaluation of package in channel. So, it's possible to inject some
side-effect code into a channel like

```
(define-module (my channel code))

(display "I'm planning to do evil things here!")

(define-public some-package ...)
(define-public another-package ...)
```

We have PGP sign and git commit chain to make sure the commits are
committed by trusted people. But it's still possible for the channel
owner to inject malicious code into the channel in a future commit. Like
what Marak Squires did in faker.js project :( or the committer of Guix
was attacked by an evil maid.

In Nix flakes, there's pure evaluation to make sure no side-effectful
code is allowed. But Guix channel is less restricted than a Nix flake.
It's a important problem to make sure the evaluation is safe for the user.


Ludovic Courtès  writes:

> [[PGP Signed Part:Undecided]]
> Hello Guix!
>
> I’m happy to announce the publication of a refereed paper in the
> Programming journal:
>
>   https://doi.org/10.22152/programming-journal.org/2023/7/1
>
> It talks about the “secure update” mechanism used for channels and how
> it fits together with functional deployment, reproducible builds, and
> bootstrapping.  Comments from reviewers showed that explaining the whole
> context was important to allow people not familiar with Guix or Nix to
> understand why The Update Framework (TUF) isn’t a good match, why
> Git{Hub,Lab} “verified” badges aren’t any good, and so on.
>
> What’s presented there is not new if you’ve been following along, but
> hopefully it puts things in perspective for outsiders.
>
> I also think that one battle here is to insist on verifiability when a
> lot of work about supply chain security goes into “attestation” (with
> in-toto, sigstore, Google’s SLSA, and the likes.)
>
> Enjoy!
>
> Ludo’.
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao


signature.asc
Description: PGP signature

Re: Building, packaging and updating Guix with confidence

[Zhu Zihao]

Josselin Poiret  writes:

> In the second case, I am in the process of adding a very simple Guile C
> extension to Guix that only requires to wrap a simple libc function.
> The C code itself took approx. 5% of my time on it, while adding the
> magical invocations for the Autotools took 35%, and now testing the
> changes is taking 60%,

If your foreign function use case is very trivial? Why not give Guile
dynamic FFI a try?

> because I need to test that `guix pull` works,
> that the local development setup works, and that the guix package works,
> all with a local change that cannot be authenticated and that also
> cannot be referred to with a git-reference [more on that later] since
> it's entirely local.  This is causing me many headaches, and I don't
> think that even after manually testing this with handwritten hacks so
> that these changes actually do appear everywhere, I will be confident
> enough for them to be merged.

It's possible to use guix channel to test a local guix repo. A short
example here.

```
cat > local-channel.scm << "EOF"
(list (channel
   (inherit %default-guix-channel)
   (url "/home/foo/bar/path/to/local/guix/repo")
   (branch "test-branch")))
EOF   

guix time-machine -C local-channels.scm --disable-authentication -- build hello
```

> c) The `guix pull` way.  This is a bit of an hybrid.  Internally, it
> amounts to eval'ing build-aux/build-self.scm inside of the currently
> running guix, which returns a procedure which, given a source code
> checkout of Guix, returns a derivation that builds the new Guix.  This
> itself relies on (guix self) where most of the building code is.  The
> scheme modules are compiled in an ad-hoc manner (not following
> Makefile.am), and files are included without consulting the Makefile.
> This is why `guix pull` users are not affected by [1].  But then, there
> still is an issue with the guix daemon (and in the future the C
> extensions), which is C code.  Since we're not pretending to know how to
> universally configure C packages, we rely on the guix-daemon package
> defined in gnu/packages/package-management.scm of the future Guix, which
> inherits from the guix package itself, and then builds itself roughly
> following b), meaning the daemon is still out-of-date.

This is somewhat "the bootstrap problem". It's very ideal if we can
describe the build graph in Guix with derivations. But we still need a
daemon first to process derivations. So we need to build daemon without
Guix.

This issue may be solved by rewriting daemon in Guile. If daemon is
written in Guile. We can run it without compilation.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Time namespace for build sandbox (was Re: Set FORCE_SOURCE_DATE=1 by default)

[Zhu Zihao]

Can we make some experiments on the Linux time namespace for build
sandbox?

This can mock the real system with our desired value, maybe a good
solution for the reproduciblity on Linux machine.

Ref: https://man7.org/linux/man-pages/man7/time_namespaces.7.html
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Problem with emacs-libgit

[Zhu Zihao]

You may interest in https://issues.guix.gnu.org/55427.

And also https://github.com/magit/libegit2/issues/121.


Zelphir Kaltstahl  writes:

> Hello Guix developers!
>
> Today I am experiencing a problem with installing Emacs via Guix on foreign 
> distro.
>
> Here is what I do:
>
> shell command
> guix time-machine \
>  --channels="${DIR}/channels.scm" -- \
>  shell \
>  --manifest="${DIR}/manifest.scm" -- \
>  emacs
> 
>
> My channels.scm was updated today, using `guix pull && guix package -u` and 
> then `guix describe --format=channels > channels.scm`, so I guess it should 
> be very up to date:
>
> channels.scm
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "76cc5b9e806635cfb94a2c1101ffe6500eab6976")
> (introduction
>   (make-channel-introduction
> "9edb3f66fd807b096b48283debdcddccfea34bad"
> (openpgp-fingerprint
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
> 
>
> manifest.scm
> (specifications->manifest
>  '("emacs"
>"emacs-auto-complete"
>"emacs-company"
>"emacs-dockerfile-mode"
>"emacs-editorconfig"
>"emacs-erlang"
>"emacs-exec-path-from-shell"
>"emacs-flycheck"
>"emacs-geiser"
>"emacs-geiser-guile"
>"emacs-geiser-racket"
>"emacs-goto-chg"
>"emacs-jinja2-mode"
>"emacs-json-mode"
>"emacs-magit"
>"emacs-markdown-mode"
>"emacs-moe-theme-el"
>"emacs-monokai-theme"
>"emacs-multiple-cursors"
>"emacs-neotree"
>"emacs-ob-async"
>"emacs-org"
>"emacs-ox-gfm"
>"emacs-pkg-info"
>"emacs-project"
>;; "emacs-python-environment"
>"emacs-racket-mode"
>"emacs-sml-mode"
>"emacs-toml-mode"
>;; "emacs-typescript-mode"
>"emacs-undo-tree"
>"emacs-web-mode"
>"emacs-yaml-mode"
>"emacs-yasnippet"
>"guile"
>"guile-colorized"
>"guile-fslib"
>"guile-json"
>"guile-readline"
>"racket"))
> 
>
> My manifest seems long, but the actual error that happens is the following:
>
> 
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> The following derivations will be built:
>   
> /gnu/store/yqc31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv
>   /gnu/store/f9iy2d8ixx93xm9x32qvbcyva24pcb1k-emacs-magit-3.3.0.drv
>
> building 
> /gnu/store/yqc31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv...
> | 'check' phasebuilder for 
> `/gnu/store/yqc31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv'
>  failed with exit code 1
> build of 
> /gnu/store/yqc31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv
>  failed
> View build log at 
> '/var/log/guix/drvs/yq/c31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv.gz'.
> guix shell: error: build of 
> `/gnu/store/yqc31b08dxahwpghlp872976ba3ilg2m-emacs-libgit-20200515-1.0ef8b13.drv'
>  failed
> 
>
> And that log file contains the following at the end (it is over 400 lines):
>
> 
> 29/29 Test #29: libegit2_tree    Passed0.09 sec
>
> 97% tests passed, 1 tests failed out of 29
>
> Total Test time (real) =   7.87 sec
>
> The following tests FAILED:
>   3 - libegit2_blob (Failed)
> Errors while running CTest
> make: *** [Makefile:94: test] Error 8
>
> Test suite failed, dumping logs.
> error: in phase 'check': uncaught exception:
> %exception #< program: "make" arguments: ("test" "-j" "16") 
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `check' failed after 7.9 seconds
> command "make" "test" "-j" "16" failed with status 2
> 
>
> So it seems some test is failing and that prevents the whole build.
>
> Is there anything else, that I should be providing as info? I attach the 
> whole log file to this message.
>
> Best regards,
> Zelphir


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Build failure of extra-cmake-modules 5.91.0 (was: Status of KDE Plasma)

[Zhu Zihao]

Hi.

I'm creating a patch that updates ECM to 5.91.0 but it failed the check.

The build log reports the KDEFetchTranslations test failed, with
following log

```
 3/86 Test  #3: KDEFetchTranslations 
.***Failed0.34 sec
Internal cmake changing into directory: 
/tmp/guix-build-extra-cmake-modules-5.91.0.drv-0/build/tests/KDEFetchTranslations
Error: cmake execution failed
The C compiler identification is GNU 10.3.0
The CXX compiler identification is GNU 10.3.0
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working C compiler: 
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/gcc - skipped
Detecting C compile features
Detecting C compile features - done
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Check for working CXX compiler: 
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++ - skipped
Detecting CXX compile features
Detecting CXX compile features - done
module: KDEInstallDirs
Installing in . Run 
/tmp/guix-build-extra-cmake-modules-5.91.0.drv-0/build/tests/KDEFetchTranslations/prefix.sh
 to set the environment for extra-cmake-modules.
module: KDECMakeSettings
Could not set up the appstream test. appstreamcli is missing.
module: ECMMarkNonGuiExecutable
CMake Error at CMakeLists.txt:22 (message):
  Wrong repository name: extra-cmake-modules, should be
  'frameworks/extra-cmake-modules'


Configuring incomplete, errors occurred!
See also 
"/tmp/guix-build-extra-cmake-modules-5.91.0.drv-0/build/tests/KDEFetchTranslations/CMakeFiles/CMakeOutput.log".
```

It says that the name of project should equal to
`frameworks/extra-cmake-modules`. But I don't see they set the project
name to `frameworks/extra-cmake-modules`.

I checked the package recipe of Archlinux and Nixpkgs, looks that they
don't have this issue.

WDYT?



signature.asc
Description: PGP signature
diff --git a/gnu/packages/kde-frameworks.scm b/gnu/packages/kde-frameworks.scm
index e914499541..e57e9e1d0a 100644
--- a/gnu/packages/kde-frameworks.scm
+++ b/gnu/packages/kde-frameworks.scm
@@ -85,48 +85,64 @@ (define-module (gnu packages kde-frameworks)
   #:use-module (srfi srfi-1))
 
 (define-public extra-cmake-modules
-  (package
-(name "extra-cmake-modules")
-(version "5.70.0")
-(source (origin
-  (method url-fetch)
-  (uri (string-append
-"mirror://kde/stable/frameworks/"
-(version-major+minor version) "/"
-name "-" version ".tar.xz"))
-  (sha256
-   (base32
-"10c5xs5shk0dcshpdxg564ay5y8hgmvfvmlhmhjf0dy79kcah3c3"
-(build-system cmake-build-system)
-(native-inputs
- ;; Add test dependency, except on armhf where building it is too
- ;; expensive.
- (if (and (not (%current-target-system))
-  (string=? (%current-system) "armhf-linux"))
- '()
- `(("qtbase" ,qtbase-5;for tests (needs qmake)
-(arguments
- `(#:tests? ,(and (not (%current-target-system))
-  (not (null? (package-native-inputs this-package
-   #:phases
-   (modify-phases %standard-phases
+ (package
+   (name "extra-cmake-modules")
+   (version "5.91.0")
+   (source (origin
+ (method url-fetch)
+ (uri (string-append
+   "mirror://kde/stable/frameworks/"
+   (version-major+minor version) "/"
+   name "-" version ".tar.xz"))
+ (sha256
+  (base32
+   "0k65rvxh926ya6qahzk2ns7g1fya1429648mlx7iipxa61g8h5wp"
+   (build-system cmake-build-system)
+   (native-inputs
+;; Add test dependency, except on armhf where building it is too
+;; expensive.
+(if (and (not (%current-target-system))
+ (string=? (%current-system) "armhf-linux"))
+'()
+(list qtbase-5)))   ;for tests (needs qmake)
+   (arguments
+(list
+ #:tests? (and (not (%current-target-system))
+   (not (null? (package-native-inputs this-package
+ #:phases
+ #~(modify-phases %standard-phases
  (add-after 'unpack 'fix-lib-path
(lambda _
  ;; Always install into /lib and not into /lib64.
- (substitute* "kde-modules/KDEInstallDirs.cmake"
-   (("\"lib64\"") "\"lib\"")
-   ;; TODO: Base the following on values taken from Qt
-   ;; Install plugins into lib/qt5/plugins
-   ;; TODO: Check if this is okay for Android, too
-   ;; (see comment in KDEInstallDirs.cmake)
-   (("_define_relative\\(QTPLUGINDIR \"\\$\\{_pluginsDirParent}\" \"plugins\"")
-"_define_relative(QTPLUGINDIR \"${_pluginsDirParent}\" \"qt5/plugins\"")
-   ;; Install imports into lib/qt5/imports
-   (("_define_relative\\(QTQUICKIMPORTSDIR QTPLUGINDIR \"imports\"")

Re: Status of KDE Plasma

[Zhu Zihao]

Hi! I'm glad to see there's somebody interested in KDE packaging.

Z572 have done some work here, and make kwin available on Guix.
https://github.com/Z572/guix/tree/kwin

Currently I'm planning to upgrade Extra cmake modules from 2.70 to 2.91
in upcoming staging branch. This will help us to package a more recent
version of KDE packages.

Can you figure out a minimal set of packages needed to run Plasma
desktop? We can add a milestone and checklist about it.

Anthony Wang  writes:

> [[PGP Signed Part:Undecided]]
> Hello!
>
> I'm a KDE contributor and free software enthusiast, and I recently started
> switching over some of my systems to GNU Guix. However, as an avid KDE Plasma
> user, I'm a bit disappointed that Plasma doesn't seem to be packaged for 
> Guix. I
> did a bit of searching and found that there has been some progress towards
> packaging Plasma:
> - https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/kde-plasma.scm
> - https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00426.html
>
> I have a few questions: What is the current status of KDE Plasma on Guix? And 
> also, how can I help or contribute?
>
> -Anthony Wang
>
> [2. application/pgp-keys; publickey - ta1...@protonmail.com - 
> 0x8EE27F78.asc]...
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: gnu: shepherd: patch, snippet or phase

[Zhu Zihao]

IMO, It's cumbersome to add patches in build phase, you have to add a
new phase, and write something like:

```
(invoke "patch" "-p1" ...)
```

So packager will prefer to add it in the `patches` slot of 
struct. I'd like to see if we have some build procedure like
`apply-patches` to help packager reduce the misnomer of `patches` slot.

Or we can add a new keyword argument #:patches-for-build to
gnu-build-system. For example

```
(package
  (name "XXX")
  (source
   (origin
...
(patches (search-patches ""
  (arguments
   (list
   ;; This patch only used when building the package 
   #:patches-for-build (search-patches ".")
   ...
   )))
```  


zimoun  writes:

> Hi Maxime,
>
> On Sat, 05 Mar 2022 at 22:49, Maxime Devos  wrote:
>> (as implied per zimoun's previous mail (‘FWIW, it would be unfair for
>> the patch to have the discussion here’), moved to guix-devel)
>
> Thanks. :-)
>
>> Leo Famulari schreef op za 05-03-2022 om 16:13 [-0500]:
>>> On Thu, Mar 03, 2022 at 07:25:22AM +0100, Maxime Devos wrote:
>>> > Leo Famulari schreef op wo 02-03-2022 om 18:50 [-0500]:
>>> > > Origin snippets should only be used to remove nonfree things
>>> > > from the upstream source code. All other changes should use
>>> > > patch files or a build phase.
>>> > 
>>> > Why?  If it's a source code change and it fits an origin snippet,
>>> > why not an origin snippet?  Why would the source in Guix need to
>>> match
>>> > the source upstream?
>>> 
>>> `guix build --source` is a tool to provide freely licensed source
>>> code
>>> to be used for any purpose, including building on systems besides
>>> Guix.
>>> 
>>> Using the Guix tools, there is no way to access the upstream source
>>> code
>>> without applying the snippets. The reason for that is that the origin
>>> snippet mechanism was introduced specifically to remove non-free
>>> components without making it easy to reverse the transformation.
>>
>> It might be introduced for removing non-free components, that doesn't
>> mean it cannot be used for more.  Also, I don't see the point of ease
>> of reversing here. It's trivial to reverse the transformation induced
>> by the snippet: just delete the snippet in a git checkout.
>
> Well, the point is the FSDG [1] frame, I guess.  From my understanding,
> when --source had been introduced, it was a countermeasure to be able to
> use hybrid source and still be compliant with an interpretation of: «A
> free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so.»
>
> Therefore, using Guix tools, e.g., guix build --source, it is not easy
> to reverse what ’snippet’ does.
>
> I would not say it is trivial to reverse the transformation because the
> user needs to run “guix edit”, then reassemble the URL, then fetch.
> Otherwise, yes the user could go to the Guix repo, remove the snippet,
> then run “guix shell -D guix”, do somehow “./pre-inst-env guix …”.
>
> Well, I do not consider these steps “trivial”.  And if one user does
> that, somehow they really want to obtain nonfree information. :-)
>
>
>
> 1: 
>
>>> Compare that to patch files, which are easily reversed,
>>
>> Removing a patch file by removing it from the 'patches' field is easy,
>> as easy as removing a snippet.  I assume you meant the additional
>> condition ‘... using only CLI tools’?
>
> Yes, somehow.
>
>
>> I am aware of the guideline of keeping the source usable outside Guix
>> systems.  AFAICT, in this case, the snippet modifying
>> Makefile.am/Makefile.in keeps the source usable on non-Guix systems.
>> In fact, it makes the source _more_ usable, both on Guix and non-Guix,
>> by working-around a Guile 3.0.5 compiler bug.  So I don't see any
>> problems here.
>
> Well, the question without consensus is what “guix build --source”
> should return?
>
>   a) The source of what “guix build” concretely builds?
>   b) The source of upstream (modulo the removal of nonfree part)?
>
> The aim is to be as close as possible as b), IMHO.  The exception of
> patches could be discussed. :-)
>
>
> Back to Shepherd, because the question is originally from patch#54216
> [2], the initial snippet was turning a flag:
>
> + (snippet
> +  '(begin
> + ;; Build with -O1 to work around .
> + (substitute* "Makefile.am"
> +   (("compile --target")
> +"compile -O1 --target"))
>
> Somehow, the snippet could be considered as a “patch“.  And, in the same
> time, the upstream source will not compile without this ’-O1’, IIUC.
>
> However, since “we“ are in the same time upstream and downstream, we
> could fix that without introducing this kind of snippet.
>
> Last, because the package is for building with Guix, then it seems more
> appropriate to have the substitution in the ’arguments’, as v3 [3] is
> doing.
>
>
> 2: 

Re: Hardened toolchain

[Zhu Zihao]

> I like this idea.  I propose we make harden? default to #t.  That way 
> practically most packages will be built with
> hardened features. Let's face it, I am a bit lazy, if I submit a package to
> guix, I am usually going to be it the easy way. If the easy way is harden? #f,
> then that's is how I will submit it. :)

I suggest a build transform flag like `--hardened` for people who wants
a hardened software, just like `--tune` for SIMD instructions.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re:

[Zhu Zihao]

Joshua Branson  writes:

> +The vision of the GNU Guix project is to replace proprietary software with
> +freedom respecting software.  We hope to create a general purpose and
> +extensible operating system that works well accross embedded environments to
> +extremely powerful server setups.  When this vision is complete (it may never
> +be complete, that's why it is a vision!) all software will be free software.

IMO, replacing proprietary software with libre software should be the
vision of the whole GNU project. 

Maybe we can change it to "The vision of the GNU Guix project is
providing a reliable and convenient way for people to use, distribute,
develop libre software."

Other parts LGTM :)
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: GNU Shepherd 0.9.0 released

[Zhu Zihao]

Ludovic Courtès  writes:

> [[PGP Signed Part:Undecided]]
> We are pleased to announce the GNU Shepherd version 0.8.1.  This release
> represents 49 commits by 3 people, bringing a new concurrent,
> event-driven core, improved logging, and on-demand service startup.

"version 0.8.1"

A bug here? :)

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Support for glibc 2.35

[Zhu Zihao]

Olivier Dion via "Development of GNU Guix and the GNU System distribution." 
 writes:

> Hello,
>
> I would like to know if there's plan to add glibc@2.35 soon to the guix
> channel?

I'm afraid not. Bumping the version of glibc is not a trivial package
update in Guix, it means almost all packages need to rebuild (rebuild
the world).

If you really need it, you may inherit from a existing glibc package,
update to 2.35 and use it. But you may need extra patches to make it
work well.

I'd suggest you use docker and run some distro with glibc 2.35(FWIK Archlinux).
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Zhu Zihao]

We can make GNU build system tries autoreconf or autogen.sh first if we
encounter some build issues. But I don't think it's a good idea to
remove configure script in the snippet of origin. Because you can't
track all files that generated by Autotools. It is also burden for
packager to pick the build-time dependencies like libtool,
autoconf-archive, gnulib etc. if we force all autotools baseed packages
use autoreconf

For software developer, they prefer to bundle a generated configure
script because it will be a bootstrap problem sometimes.

A simple examples,the m4 macro GUILE_PKG defined in guile.m4 helps
autotools to check guile installation. If there's no generated configure
script. Software user should have guile.m4 to generate configure script.
A macro that detects guile installation requires a guile installation to
work. Catch 22 :)


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: The Shepherd on Fibers

[Zhu Zihao]

Philip McGrath  writes:

> Would it be feasible for shepherd *not* to fork? Or only to fork in a way that
> cooperates with fibers?

IMO the problem is not fork, you can't do anything useful to create
subprocess without fork on *NIX systems.

fork is allowed to execute in multi-thread environment. It just don't
care about other threads, it's safe and recommended if you only call
execv after fork.

The problem is, Shepherd is too flexible and people can do so many
things other than fork+exec in the startup of Shepherd service (unlike
systemd, only create subprocess is allowed). So Shepherd has to be
conservative.

> Second, I'm a little uneasy about `unwind-protect`:
>
> ```
> +(define-syntax-rule (unwind-protect body ... conclude)
> +  "Evaluate BODY... and return its result(s), but always evaluate CONCLUDE
> +before leaving, even if an exception is raised.
> +
> +This is *not* implemented with 'dynamic-wind' in order to play well with
> +delimited continuations and fibers."
> +  (let ((conclusion (lambda () conclude)))
> +(catch #t
> +  (lambda ()
> +(call-with-values
> +(lambda ()
> +  body ...)
> +  (lambda results
> +(conclusion)
> +(apply values results
> +  (lambda args
> +(conclusion)
> +(apply throw args)
> ```
>
> though maybe it's used only internally and doesn't have to deal with the 
> general
> case: I'm not an expert by any means, but my understanding (from a Racket
> mailing list thread at [5], continued at [6]) is that dealing with the general
> case may be something of an open research question.
>
> As an example of the sort of problem, what if the `body`s evaluate normally, 
> but
> an exception is raised in the dynamic extent of `(conclusion)`, causing
> `(conclusion)` to run again? One possible mitigation would be to `set!` a 
> local
> variable before the normal `(conclusion)` and check it in the exception 
> handler.
>
> More generally, of course, `body ...` could escape by some mechanism other 
> than
> a raising an exception.
>
> If you were writing Racket, I would recommend `(call-with-continuation-barrier
> (λ () body ...))`—logically, `body ...` isn't re-entrant anyway—but I see from
> [7] that Guile's continuation barriers are barriers to the fibers' context
> switches.

> The key difference between Guile and Racket is that Guile's Fibers are just a
> library, without any special privileges, and use the same control operators 
> that
> are available to user code. I think that may be unique among the Concurrent ML
> implementations I'm aware of.
>
> Why is that a problem? Well, in many ways I think it's quite cool! But a
> problematic aspect is that (from the discussion at [5]):
>
>
>> On 11/30/19 10:23, Matthew Flatt wrote:
>>> You're trying to implement `amb` where a client can mix `amb` and
>>> `dynamic-wind` and get sensible behavior, right?
>>> The `dynamic-wind` operation certainly interferes with building new
>>> control forms. Racket threads and other control forms that need to
>>> interact a certain way with `dynamic-wind` end up being built in at the
>>> same level as `dynamic-wind`.
>>> At Sat, 30 Nov 2019 06:15:16 -0600, Alexis King wrote:
 Is there any way to do that with Racket’s continuation machinery,
>>> There's not a safe way. In many cases, Racket lets you write new things
>>> that have the power of built-in through unsafe APIs --- and it turns
>>> out that there are unadvertised procedures (provided by the primitive
>>> `#%unsafe` module) for this particular case:
>>> [...]
>>> At Sat, 30 Nov 2019 06:15:16 -0600, Alexis King wrote:
 Also, is this kind of thing discussed anywhere in the literature?
>>> I don't know of any published work on this topic (so let me know if you
>>> find something!). As you probably have seen already, our ICFP'07 paper
>>> just points out that `dynamic-wind` causes problems, but doesn't try to
>>> hold `dynamic-wind` itself responsible for those problems.
>>> An opinion and some pointers to newsgroup discussions:
>>>http://okmij.org/ftp/continuations/against-callcc.html#dynamic_wind
>>>

The reentrant feature of call/cc costs many but worth nothing. And people
have to create dynamic-wind to fix this ugly issue.

Schemers now create a new proposal, SRFI-226. In this proposal, call/cc
is reimplemented in delimited control operator.

> Maybe it would be enough for this case for Fibers to provide variants of
> `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate 
> with the Fibers implementation. I don't know if that would be possible of 
> not—in
> addition to my limited familiarity with Fibers, I have not read all of the
> related literature that Alexis, Matthew, and Matthias Felleisen discuss in [5]
> and [6]—again, I am not an expert!
>
> I'm not sure how useful any of that is, but take it for whatever it's worth. 
> My
> overall impression is that the Shepherd on Fibers is a big step in the right
> 

Re: Semantics of circular imports

[Zhu Zihao]

Philip McGrath  writes:

> Oh, wow. I definitely had not realized that, *even inside a declarative 
> module*, a reference to a variable with no statically visible definition 
> would semantically be a dynamic lookup in a mutable environment at 
> runtime (rather than a compile-time error), though I do see now that 
> `info guile declarative` does indeed say that marking a module as 
> declarative "applies only to the subset of top-level definitions that 
> are themselves declarative: those that are defined within the 
> compilation unit, and not assigned (‘set!’) or redefined within the 
> compilation unit."

It depends on how you reference to it. If a variable is referenced in
the same module, it'll be inlined if it's small enough.

If you reference it from another module, it'll do something like
module-ref instead (works like non-declarative binding)

> This seems like a big barrier to cross-module inlining, though IIUC Guile
> currently doesn't do much of that by default (maybe for this reason).

Guile 3.0.8 comes to rescue. It works by rewrite the `define-module`
call and attach the tree-il of some bindings on it.

For details, read the blog post authored by Andy Wingo

https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile

TIPS: If you're interested in the implementation detail of Guile. You
should not miss the Andy Wingo's blog post!  

> The use of "top-level" to refer to definitions within a module is 
> somewhat confusing to me. I usually understand "top-level" to refer to 
> the kind of interactive REPL environment for which R6RS leaves the 
> semantics unspecified. Racket uses "module-level variable"  and "module 
> context" in contrast to "top-level variable" and "top-level context" to
> make this distinction.[1][2][3] (There are also R6RS "top-level 
> programs", but I wouldn't think of those unless made very clear from 
> context.)

Top-level is the set of outermost brackets in a file :)

The optimization pass related to the top-level in Guile is called
letrectify. It rewrites the top-level bindings into a big letrec block.
You can check the comment of (language tree-il letrectify) and it has
a good example.

Because top-levels can reference each other, so the evaluation order
will not the same as the code order.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: The Shepherd on Fibers

[Zhu Zihao]

IIUC, After fork and execute the program, shepherd will wait for the pid
file to appear. This is a block operation.

Shepherd on Fiber make this operation non-blocking (because the pid file
is created by Linux kernel, Shepherd just need to wait for it), every
service activation runs on its own fiber. after fork+exec, shepherd
suspend current fiber, andspawn another fiber to start another service
immediately.

But finally all fibers are co-operatively scheduled on 1 thread.

"pelzflorian (Florian Pelz)"  writes:

> On Sat, Mar 26, 2022 at 07:09:12PM +0800, Zhu Zihao wrote:
>> > So shepherd service authors still cannot write blocking code but need
>> > to yield?
>> 
>> IMO, service should not block service, if they have something important
>> to do before running a program, why not fork first and do it in the
>> child-process (maybe wrap the actual startup program in Guile script)?
>
> In other words, all stays the same as without fibers?
>
> Regards,
> Florian


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: The Shepherd on Fibers

[Zhu Zihao]

Zhu Zihao  writes:

> [[PGP Signed Part:Undecided]]
>> So shepherd service authors still cannot write blocking code but need
>> to yield?
>
> IMO, service should not block service, if they have something important
> to do before running a program, why not fork first and do it in the
> child-process (maybe wrap the actual startup program in Guile script)?

service should not block service
 ^^^ daemon
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: The Shepherd on Fibers

[Zhu Zihao]

> So shepherd service authors still cannot write blocking code but need
> to yield?

IMO, service should not block service, if they have something important
to do before running a program, why not fork first and do it in the
child-process (maybe wrap the actual startup program in Guile script)?
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Improve the output of `guix refresh -l`

[Zhu Zihao]

Couldn't agree more :)

Ludovic Courtès  writes:

> Maxime Devos  skribis:
>
>> Zhu Zihao schreef op do 17-03-2022 om 18:22 [+0800]:
>>> for example, run `guix refresh -l pango`, The terminal prints:
>>> 
>>> ```
>>> Building the following 2945 packages would ensure 7521 dependent
>>> packages are rebuilt: ..
>>> ```
>>> 
>>> The package list is too long to read, flood my terminal with package
>>> names. It will hide the actual rebuilt count, I have to pipe the
>>> output
>>> to less command to make sure I can see it.
>>> 
>>> What about add an option like `--detail` for `guix refresh -l`?
>>
>> The short option '-l' is a shorthand for the long option
>> '--list-dependents'.  It seems to me that '--list-dependents' should
>> actually list the dependents, so I would not do that, otherwise the
>> option name would (by itself) not correspond to its behaviour anymore.
>
> Maybe it could use ‘fill-paragraph’ and
> ‘call-with-paginated-output-port’ so that it’s less annoying?
>
>> Maybe something like a '--count-dependents' option would be nice
>> though.
>
> That too, and/or ‘--direct-dependents’ (sometimes it’s good enough).
>
> Another option would be a ‘guix refresh’ mode that automatically
> rebuilds the updated package and its direct dependents.
>
> Thoughts?
>
> Ludo’.


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

[Zhu Zihao]

Make Guix available on Windows platform will be a painful job.

1. Windows doesn't allow user to create symbolic link without admin
permission, which guix use intensely.

2. There's no RUNPATH for Windows DLL, so all dynamic library
dependencies should in the same directory to allow Windows find it.

3. Many developers on Guix, but less developer on Guile. I post some thread on 
guile-devel,
but there's few people will reply me. And the Windows support of Guile 3
is still missing.


Ryan Prior  writes:

> One side-thread in "Building a software toolchain that works" notes that Guix 
> faces challenges for adoption because it's
> not readily available to users of proprietary operating systems like macOS 
> and Windows.
>
> I've witnessed over the past decade that GNU/Linux development on other 
> platforms has become widespread, in large
> part due to the availability of the Docker for Desktop application which 
> packages a lightweight, automagically managed
> GNU/Linux virtual machine running the Docker daemon with Docker client 
> software built for the target platform.
>
> A user of Docker for Desktop on a proprietary OS can run "docker" commands 
> which transparently execute commands
> inside a GNU/Linux container, making building and testing software quite 
> convenient and reproducible without needing
> to set up cross-compile toolchains or spend time managing VM software.
>
> It makes absolute sense to me that Guix is not interested in building a 
> native distribution for the Windows or macOS
> toolchains. One of Guix System's unique strengths is its adherence to the GNU 
> FSDG and I don't think that's
> incompatible with making the Guix tools more generally available to end-user 
> devs hacking on software using a
> proprietary OS.
>
> Technically, I think we could use a similar approach to the Docker for 
> Desktop system: a "Guix for Desktop" installs
> software to create and manage a minimal Guix System virtual machine which 
> automatically updates and reconfigures
> itself, requiring no manual administration by the end-user. And it would 
> install a Guix client that connects to the Guix
> daemon running in the VM using a shared socket, enabling users to incorporate 
> Guix transparently into their workflows.
>
> I think this would be a compromise for certain, the same way it is for Emacs 
> and other GNU flagship projects that run on
> non-free systems. On the one hand, it serves to make those systems more 
> valuable, which undermines our cause. But on
> the other hand it provides a major on-ramp to free software and superior 
> build tooling, positively impacting the
> practical freedoms available to the end-users who adopt Guix.
>
> wdyt?


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Improve the output of `guix refresh -l`

[Zhu Zihao]

Hello, Guix!

Inspired by
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=209a3274f8702acd32fa2a489667048ca4ad304b.
I found that the output of `guix refresh -l` for package have many
dependants is not convenient to read.

for example, run `guix refresh -l pango`, The terminal prints:

```
Building the following 2945 packages would ensure 7521 dependent
packages are rebuilt: ..
```

The package list is too long to read, flood my terminal with package
names. It will hide the actual rebuilt count, I have to pipe the output
to less command to make sure I can see it.

What about add an option like `--detail` for `guix refresh -l`?
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

[Zhu Zihao]

This problem is not related to that patch so I would like to discuss here.

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Zhu Zihao schreef op za 12-03-2022 om 10:38 [+0800]:
>> > What if a program uses both 'pango' and gtk?  Then IIUC, it would
>> > simultanuously use pango and pango-next in the same process, which
>> can
>> > easily cause problems (see e.g. the bug report about segfaults
>> > involving multiple libcairos).

Can you show me the link of the libcairo conflict example you said?

I don't know what cause the segfaults in your example. C linker will
embed the full path of the library into the RUNPATH, unless
LD_LIBRARY_PATH is set, C library will use the dependencies they found in
link time.

>> 
>> i've asked in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44327 and
>> suggest to introduce priority mechanism like Nix. But Ludovic Courtès
>> doesn't accept my suggestion
>
> How could a priority mechanism solve the segfaults?

'priority' will let user to specify which package can override other
packages, if some of their contents overlapped with each other. Now Guix
will silently choose one. 


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

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

[Zhu Zihao]

tumashu  writes:

> i can not run gdm success, but have the problem too when run sddm.

Try put a fontconfig file under /var/lib/sddm/.config/fontconfig/fonts.conf

cat > /var/lib/sddm/.config/fontconfig/fonts.conf << "EOF"



   /run/current-system/profile/share/fonts/

EOF

And install the fonts in system wide package configuration.

This issue was introduced in the merge of 'core-updates-frozen'. But I
can't find a proper way to fix this. 

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: search-input-file vs (assoc-ref inputs)

[Zhu Zihao]

Some of my concern about label-less style inputs.

1. How can we refer to a non-package input? Some code might use
something like

(inputs
  `((".patch" ,(origin 

If I want to replace this patch, I can simply use list operations from
SRFI-1 to manipulate it. But in label-less style, there's no label for a
 object. Packagers may try to embed these objects into the build
expression using `ungexp`. But I think it violates the dependency
inversion principle(We don't rely on label, but rely on concrete
object).

2. libgcc, libgcc is a specific output of gcc. IIUC in build expression,
it shares label with gcc, gcc is an implicit input in many build
system. It's not so convenience for me to refer libgcc.

For example, I want to set up the `LD_LIBRARY_PATH` for testing. it's
better to use `(string-append (this-package-inputs "libgcc") "/lib")`.
But I can't do this, the label of libgcc is "hidden".
`search-input-directory` doesn't work here because "/lib" is a common
directory exists in many package. I have to write `(dirname
(search-input-file input "libstdc++.so.6"))`, so ugly...

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Status of Qt build system patches on 'staging' branch.

[Zhu Zihao]

Leo Prikler writes:

> It appears that back in the day they were reverted with
> 918a099e7422fe8ad3464dc5a1b4f60843297742 before a staging merge on
> February 1st.  If nothing else happened on staging since, someone will
> need to revert the revert or apply the patches themselves once more.

These patches were pushed to 'staging-next' branch because 'staging'
branch was forzen at that time. So maybe this is a mistake that we
forget to pick them back to the 'staging'? Should I open a issue to
cherrypick that patches?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Status of Qt build system patches on 'staging' branch.

[Zhu Zihao]

Hello Guix!

In January I'm following up a series of 
patches(https://issues.guix.gnu.org/45784) that fixes Qt build
system to honor user's environment variable. It has been six months now,
but these patches are still in 'staging' branch.

Tho these patches will trigger rebuild of almost all qt applications,
but I think six month is so long, and these patches can also help fix
some icon issues of qt application. Can someone tell me the status of
it?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Specify substitute url in GUI installer

[Zhu Zihao]

Hi, Guix users!

Thanks to the  (from SJTU). We finally set up
a Guix substitute mirror in SJTU LUG.

You can try with command line option
"--substitute-urls=https://mirrors.sjtug.sjtu.edu.cn/guix;

However, it's sad that there's no option for user to specify substitute
url in GUI installer of Guix ISO. It means that people new to Guix still
have to tolerate the slow connection during the installation.

Can we add such option for GUI installer?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Word order in Guix l10n

[Zhu Zihao]

Arun Isaac writes:

> Hi Zhu Zihao,
>
> I faced the same problem while working on the Tamil localization. I used
> the ~* argument jumping supported by (ice-9 format) to work around
> this. So, for the message "could not find bootstrap binary '~a' for
> system '~a'", you could do something like
>
> "无法找到用于引导 ~1@* 系统的二进制文件 ~0@*"
>
> ~0@* refers to the 0th argument, ~1@* refers to the 1th argument, and so
> on. Look for "argument jumping" in
> https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html
>
> Hope that helps!
>
> Regards,
> Arun

Thanks! Your code really help me a lot ;)

But there's a few mistakes, I should use

"无法找到用于引导 ~1@*~a 系统的二进制文件 ~0@*~a"

It still requires a "~a" to specify object output.


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Word order in Guix l10n

[Zhu Zihao]

Hi, Guix users!

Currently I'm putting my energy into Guix l10n(zh_CN). However, there's
a serious flaw in current implementation of l10n.

AFAFIK, Guix use format in (ice-9 format) to format the the template
string return by `G_`. The template string of (ice-9 format) looks
similar to the format template defined in ANSI CL, which only supports
format arguments **one by one**.

In CJK languages, word order usually different from English.

For example. consider message

  "could not find bootstrap binary '~a' for system '~a'"

We mark first ~a as %1 and mark second as %2. It should be translated
into Chinese like this

  "无法找到用于引导 %2 系统的二进制文件 %1"

But currently it looks to be impossible because we can't refer
to positional argument in format template.

My suggestions is we can create a new format function supports refer to
positional argument like

  (pos-format "~3 ~2 ~1" "foo" "bar" "baz") ;; => "baz bar foo"

And replace `format` in l10n with `pos-format` step by step. Maybe we
can create a function to combine `G_` and `format` so we can change its
implement detail without breaking existing code.

Please leave your comment on my opinion, thanks :)


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Help Wanted: Issues when packaging QT plugins.

[Zhu Zihao]

Hi, Guix users!

I'm planning to package https://github.com/fcitx/fcitx-qt5. A QT plugin
to support Fcitx input method. I found 2 issues during the packaging.

1. This is an old issue mentioned in
https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00117.html.
qt wrapper doesn't extend but override QT_PLUGIN_PATH and XDG_DATA_DIRS env 
vars. So
any environemnt setup in profile will be ignored. Personally, I don't
think is an expected behaviour.(GTK wrapper does extend)

2. Qt plugins require QT_PLUGIN_PATH to be properly set up. Currently,
qtbase and packages inherited from it have native-search-paths spec for
this environment variable. Should packager add this spec for new qt
plugins? Or just leave it to user?

Any answer or suggestion will be appreciated.
-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Add emacs-source-reference for C code discoverablity.

[Zhu Zihao]

GNU Emacs can navigate and reference the source code of C function. But
the variable source-directory should be setup properly.

Current Emacs package discard C source code during the build. There's
serveral solution to add it.

1. Modify the emacs package definition, this trigger the rebuild of
all emacs-xyz, and increase the closure for who doesn't want the source
reference.

2. Like 1. But put the source to another output in emacs package. Still
trigger rebuild but doesn't increase closure size. 

3. Create a new package named emacs-source-reference to hold it. I think
this is the better way.

BTW, if we add source reference, what about also generate etags file for
them?

Please leave your comments on these ideas. Thanks a lot.
-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Re: A public Lisp programming interface provide feature like `guix environment --container`

[Zhu Zihao]

Leo Prikler writes:

> For the record, what you do want is something à la
> (call-in-container-environment THUNK MANIFEST . KWARGS)
> where manifest is the Guix environment manifest, THUNK is a procedure
> to call with 0 arguments and KWARGS is a list of options for things you
> might want to set up, e.g. just the GUIX_ENVIRONMENT variable or more
> than that.
>
> Is that about right?
>
> Regards, Leo

Yes, that's what I want. KWARGS may accept something like user-mappings,
network?, namepsaces etc. like `launch-environment/container`. So I can
create container entry script for different executable in batch with
more confidence in code reuse. It's ugly to 
concatenate string argument (For example: `(string-append "--expose="
 "=" yyy)`) when I want to reuse some path variable.


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Re: A public Lisp programming interface provide feature like `guix environment --container`

[Zhu Zihao]

Leo Prikler writes:

> launch-environment/container still assumes the command to be a shell
> script, which I think is not quite what you want.  You probably want to
> take a look at call-with-container from (guix build linux-container) or
> child-hurds.

I just read the source code of call-with-container. IMO, it just run
code in container, without any settings. It's quite inconvenient for my
usage. For example: I have to setup mount binding of my package closure 
manually. 

> I currently don't know of any procedure, that "directly" invokes Scheme
> code through Guix environments, so you'd have to build that on your
> own.  However, given that your stated goal is to port container entry
> scripts [I read this as "the script called by the container at entry"]
> to Guile, would it not make sense to have
>
>   (guix-environment [ENVIRONMENT OPTIONS] "--" "guile" "entry.scm")
>
> WDYT?
>
> Regards, Leo

Hmmm, maybe this is the solution, tho it's not very very elegant.


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

A public Lisp programming interface provide feature like `guix environment --container`

[Zhu Zihao]

"guix environment --container" is a very useful feature for me to
isolate the untrusted software. But sadly it lacks a interface for user
to use it in Lisp programming.

In (guix scripts environment), only `guix-environment` is exported. but
it process unix style command line option.

I'm wondering it's good to expose some interface suitable for Lisp, just
like the internal function `launch-environment/container`. This can
encourage me to port more container entry script from shell to Guile.

-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao


signature.asc
Description: PGP signature

Re:Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

[Zhu Zihao]

Patches sent to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43663


Please review, thanks!








At 2020-09-28 04:15:42, "Mark H Weaver"  wrote:
>Hi,
>
>"Zhu Zihao"  writes:
>
>> @@ -1017,10 +1010,31 @@ from forcing GEXP-PROMISE."
>> (lambda _
>>   (use-modules (guix build cargo-utils))
>>   (let ((null-hash 
>> "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"))
>> -   (substitute* '("Cargo.lock" "gfx/wr/Cargo.lock")
>> - (("(\"checksum .* = )\".*\"" all name)
>> -  (string-append name "\"" null-hash "\"")))
>> -   (generate-all-checksums "third_party/rust"))
>> +   (for-each (lambda (file)
>> +   (format #t "patching checksums in ~a~%" file)
>> +   (substitute* (find-files "." "Cargo.lock$")
>> + (("^checksum = \".*\"")
>> +  (string-append "checksum = \"" null-hash 
>> "\""
>> + (find-files "." "Cargo.lock$"))
>[...]
>> Why we need another `find-files` in `substitute*`? The outer
>> `find-files` should find all locks file for you, maybe you can use the
>> arg of lambda instead.
>
>Indeed, that's clearly what I had intended to do, but then I apparently
>forgot a step.  Good catch, thanks!
>
>> @@ -756,8 +750,8 @@ from forcing GEXP-PROMISE."
>> ("libxt" ,libxt)
>> ("libffi" ,libffi)
>> ("ffmpeg" ,ffmpeg)
>> -   ("libvpx" ,libvpx)
>> -   ("icu4c" ,icu4c)
>> +   ;; UNBUNDLE-ME! ("libvpx" ,libvpx)
>> +   ;; UNBUNDLE-ME! ("icu4c" ,icu4c)
>> ("pixman" ,pixman)
>> ("pulseaudio" ,pulseaudio)
>> ("mesa" ,mesa)
>>
>> IceCat 78 may need icu4c v67, which variable name is `icu4c-67` in
>> guix channel.
>
>Good idea!  Would you like to propose a patch, test it, and report back?
>If not, I'll try it eventually.  I would certainly be very glad to
>reduce the number of bundled libraries in our IceCat package, which
>seems to be getting worse over time.  Any help on that effort would be
>much appreciated.
>
>   Best,
>Mark

Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

[Zhu Zihao]

@@ -1017,10 +1010,31 @@ from forcing GEXP-PROMISE."
(lambda _
  (use-modules (guix build cargo-utils))
  (let ((null-hash 
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"))
-   (substitute* '("Cargo.lock" "gfx/wr/Cargo.lock")
- (("(\"checksum .* = )\".*\"" all name)
-  (string-append name "\"" null-hash "\"")))
-   (generate-all-checksums "third_party/rust"))
+   (for-each (lambda (file)
+   (format #t "patching checksums in ~a~%" file)
+   (substitute* (find-files "." "Cargo.lock$")
+ (("^checksum = \".*\"")
+  (string-append "checksum = \"" null-hash "\""
+ (find-files "." "Cargo.lock$"))
+   (for-each generate-all-checksums
+ '("services"
+   "js"
+   "third_party/rust"
+   "dom/media"
+   "dom/webauthn"
+   "toolkit"
+   "gfx"
+   "storage"
+   "modules"
+   "xpcom/rust"
+   "media"
+   "mozglue/static/rust"
+   "netwerk"
+   "remote"
+   "intl"
+   "servo"
+   "security/manager/ssl"
+   "build")))




Why we need another `find-files` in `substitute*`? The outer `find-files` 
should find all locks file for you, maybe you can use the arg of lambda instead.


@@ -756,8 +750,8 @@ from forcing GEXP-PROMISE."
("libxt" ,libxt)
("libffi" ,libffi)
("ffmpeg" ,ffmpeg)
-   ("libvpx" ,libvpx)
-   ("icu4c" ,icu4c)
+   ;; UNBUNDLE-ME! ("libvpx" ,libvpx)
+   ;; UNBUNDLE-ME! ("icu4c" ,icu4c)
("pixman" ,pixman)
("pulseaudio" ,pulseaudio)
("mesa" ,mesa)



IceCat 78 may need icu4c v67, which variable name is `icu4c-67` in guix channel.

Re:Re: Packaging question: Backport patch or use newer commit?

[Zhu Zihao]

Thanks for your help! I back port that patch and build succesfully now. That 
patch is small enough so I sure it's suitable for backport.





















At 2020-09-13 00:35:10, "Leo Famulari"  wrote:
>On Sun, Sep 13, 2020 at 12:04:11AM +0800, Zhu Zihao wrote:
>> Hi everybody. I' m packaging digikam(https://digikam.org). A free photo 
>> management software from KDE project. There're 2 dependecies missing from 
>> current Guix(qtav & libksane)
>> 
>> 
>> I tried to package qtav(https://github.com/wang-bin/QtAV/) first, but it's 
>> latest release(v1.13.0) failed to build with Qt 5.14. And it was fixed in 
>> https://github.com/wang-bin/QtAV/commit/5abba7f0505e75fc. The question is: 
>> "Should I backport this fix to v1.13.0 or just use this commit to build 
>> qtav?"
>> 
>> 
>> If there're some guidelines on this, please tell me, thanks a lot!
>
>In general, we try to only package what upstream considers the "latest
>release".
>
>If the latest release doesn't work, we try to fix it in the smallest way
>that we can.
>
>So, in this case, that would mean trying to apply the patch you
>mentioned to the 1.13.0 release. If that works, great.
>
>Otherwise, we have to also consider the value of our own time, and it
>might be best to build the software based on the commit itself.
>
>Does that help?

Packaging question: Backport patch or use newer commit?

[Zhu Zihao]

Hi everybody. I' m packaging digikam(https://digikam.org). A free photo 
management software from KDE project. There're 2 dependecies missing from 
current Guix(qtav & libksane)


I tried to package qtav(https://github.com/wang-bin/QtAV/) first, but it's 
latest release(v1.13.0) failed to build with Qt 5.14. And it was fixed in 
https://github.com/wang-bin/QtAV/commit/5abba7f0505e75fc. The question is: 
"Should I backport this fix to v1.13.0 or just use this commit to build qtav?"


If there're some guidelines on this, please tell me, thanks a lot!


--


Zihao

Re:Re: Can Emacs packages define their own EMACSLOADPATH in their open script?

[Zhu Zihao]

I'm newbie to Guix and know little about Guix jargon. I'm sorry about that my 
words make you puzzled.


>? The source of what?

I mean the emacs package in guix source, the emacs-next package, precisely.




>> will record its modification of EMACSLOADPATH in profile,
>

>Where is it recorded?  Which modification?  What is "EMACSLOADPATH in profile"?


The package definition of emacs-next has native-search-path field, which add 
customized EMACSLOADPATH environment variable.
And I guess it modified ~/.guix-profile/etc/profile.

If you still doesn't understand, please ask me again, thanks!

Can Emacs packages define their own EMACSLOADPATH in their open script?

[Zhu Zihao]

I use guix to manage different version of Emacs in a foreign distro. However, 
the Emacs package in the source will record its modification of EMACSLOADPATH 
in profile, which will cause conflict in different version of Emacs, and also 
conflict with Emacs in foreign distro.


My idea is move the setting of EMACSLOADPATH into the wrapper script. What's 
you guys opinions? Thanks.

Re: [PATCH] gnu: Add font-sarasa-gothic

[Zhu Zihao]

You miss the right angle bracket in the copyright line

It should be

;;; Copyright © 2020 Zhu Zihao 
^

Others are OK.

On Sat, 30 May 2020 22:33:15 +0800,
Marius Bakke wrote:
>
> [1  ]
> [1.1  ]
> Zhu Zihao  writes:
>
> > This patch adds Sarasa Gothic. Sarasa Gothic is based on Iosevka and Source 
> > Han
> > Sans, intends to make a really monospaced(inclduing CJK characters) 
> > programming
> > fonts. In Sarasa Gothic, a normal CJK character is same height and double 
> > width
> > as an ASCII character.
>
> Thanks!  Applied with the following changes, hope the copyright line was
> okay:
>
> [1.2 diff ]
> diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
> index 3c7361f162..f60d4f80fb 100644
> --- a/gnu/packages/fonts.scm
> +++ b/gnu/packages/fonts.scm
> @@ -34,6 +34,7 @@
>  ;;; Copyright © 2020 John Soo 
>  ;;; Copyright © 2020 Raghav Gururajan 
>  ;;; Copyright © 2020 Julien Lepiller 
> +;;; Copyright © 2020 Zhu Zihao   ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1267,7 +1268,7 @@ programming.  Iosevka is completely generated from its 
> source code.")
>(mkdir "source")
>(chdir "source")
>(invoke "7z" "x" source))
> -(native-inputs `(("p7zip" ,(@ (gnu packages compression) p7zip
> +(native-inputs `(("p7zip" ,p7zip)))
>  (home-page "https://github.com/be5invis/Sarasa-Gothic;)
>  (license license:silofl1.1)
>  (synopsis "Sarasa Gothic / 更纱黑体 / 更紗黑體 / 更紗ゴシック / 사라사 고딕")
> [2 signature.asc ]
> No public key for A2A06DF2A33A54FA created at 2020-05-30T22:33:15+0800 using 
> RSA

Re: [PATCH] gnu: Add font-sarasa-gothic

[Zhu Zihao]

Modified description.

>From dac6806a5eb9e919cf32da6d909ba4dd71accf35 Mon Sep 17 00:00:00 2001
From: Zhu Zihao 
Date: Sat, 30 May 2020 00:40:05 +0800
Subject: [PATCH] gnu: Add font-sarasa-gothic

* gnu/packages/fonts.scm (font-sarasa-gothic): New variable
---
 gnu/packages/fonts.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 21423baefd..86bed09a95 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -1251,6 +1251,34 @@ programming.  Iosevka is completely generated from its 
source code.")
  (for-each make-file-writable (find-files "." ".*"))
  #t)))
 
+(define-public font-sarasa-gothic
+  (package
+(name "font-sarasa-gothic")
+(version "0.12.6")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/be5invis/Sarasa-Gothic;
+   "/releases/download/v" version
+   "/sarasa-gothic-ttc-" version ".7z"))
+   (sha256
+(base32 "1g6k9d5lajchbhsh3g12fk5cgilyy6yw09fals9vc1f9wsqvac86"
+(build-system font-build-system)
+(arguments
+ `(#:phases (modify-phases %standard-phases
+  (replace 'unpack
+(lambda* (#:key source #:allow-other-keys)
+  (mkdir "source")
+  (chdir "source")
+  (invoke "7z" "x" source))
+(native-inputs `(("p7zip" ,(@ (gnu packages compression) p7zip
+(home-page "https://github.com/be5invis/Sarasa-Gothic;)
+(license license:silofl1.1)
+(synopsis "Sarasa Gothic / 更纱黑体 / 更紗黑體 / 更紗ゴシック / 사라사 고딕")
+(description
+ "Sarasa Gothic is a programming font based on Iosevka and Source Han Sans,
+most CJK characters are same height, and double width as ASCII characters.")))
+
 (define-public font-go
   (let ((commit "f03a046406d4d7fbfd4ed29f554da8f6114049fc")
 (revision "1"))
-- 
2.26.2

[PATCH] gnu: Add font-sarasa-gothic

[Zhu Zihao]

This patch adds Sarasa Gothic. Sarasa Gothic is based on Iosevka and Source Han
Sans, intends to make a really monospaced(inclduing CJK characters) programming
fonts. In Sarasa Gothic, a normal CJK character is same height and double width
as an ASCII character.

>From cebd1e00a8bd29a555d5b109f4aae2adea7f977f Mon Sep 17 00:00:00 2001
From: Zhu Zihao 
Date: Sat, 30 May 2020 00:40:05 +0800
Subject: [PATCH] gnu: Add font-sarasa-gothic

* gnu/packages/fonts.scm (font-sarasa-gothic): New variable
---
 gnu/packages/fonts.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 21423ba..92f96b5 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -1251,6 +1251,34 @@ programming.  Iosevka is completely generated from its 
source code.")
  (for-each make-file-writable (find-files "." ".*"))
  #t)))
 
+(define-public font-sarasa-gothic
+  (package
+(name "font-sarasa-gothic")
+(version "0.12.6")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/be5invis/Sarasa-Gothic;
+   "/releases/download/v" version
+   "/sarasa-gothic-ttc-" version ".7z"))
+   (sha256
+(base32 "1g6k9d5lajchbhsh3g12fk5cgilyy6yw09fals9vc1f9wsqvac86"
+(build-system font-build-system)
+(arguments
+ `(#:phases (modify-phases %standard-phases
+  (replace 'unpack
+(lambda* (#:key source #:allow-other-keys)
+  (mkdir "source")
+  (chdir "source")
+  (invoke "7z" "x" source))
+(native-inputs `(("p7zip" ,(@ (gnu packages compression) p7zip
+(home-page "https://github.com/be5invis/Sarasa-Gothic;)
+(license license:silofl1.1)
+(synopsis "Sarasa Gothic / 更纱黑体 / 更紗黑體 / 更紗ゴシック / 사라사 고딕")
+(description
+ "Sarasa Gothic is based on Iosevka and Source Han Sans, most CJK 
characters
+are same height, and double width as ASCII characters.")))
+
 (define-public font-go
   (let ((commit "f03a046406d4d7fbfd4ed29f554da8f6114049fc")
 (revision "1"))
-- 
2.26.2