bug#54297: Acknowledgement (Qutebrowser failed to render local fonts.)

[Zhu Zihao]

Tweaks the qt.args in Qutebrowser by adding "no-sandbox" it now renders
text properly, I guess the sandbox of qtwebengine is broken.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#29644: gcc-objc is unusable without its 'gcc' executable.

[Zhu Zihao]

I'm planning to package some GNUStep packages to Guix, but the gcc-objc
is broken.

Any one interested in fixing GCC? or I' ll plan to make gnustep-make use
clang instead of GCC.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#29644: gcc-objc is unusable without its 'gcc' executable.

[Zhu Zihao]

You can try with (on d05fcc21cb9509084a0424e6808b84b58dc52d62, but I
guess the commit doesn't matters.)

```
guix shell gcc@10 gcc-objc@10 clang@13

cat > hello.m << "EOF"
#include 

int main(int argc, const char * argv[]) {
  printf ("Hello, world!\n");
return 0;
}
EOF
```

`LANG=C gcc hello.m -o hello` complains that Objective-C compiler is not
installed.

`LANG=C clang hello.m -o hello` can compile to hello binary.

Even I try set environment variable GCC_EXEC_PREFIX (described in
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html)

GCC_EXEC_PREFIX=$GUIX_ENVIRONMENT/libexec/gcc/x86_64-unknown-linux-gnu/10.3.0 
gcc hello.m -o hello
 
or pass option
`-B$GUIX_ENVIRONMENT/libexec/gcc/x86_64-unknown-linux-gnu/10.3.0`. It
still says no Objective-C compiler.


Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Zhu Zihao schreef op za 26-03-2022 om 13:49 [+0800]:
>> I'm planning to package some GNUStep packages to Guix, but the gcc-
>> objc is broken.
>> 
>> Any one interested in fixing GCC? [...]
>
> How is it broken?  Is there some error message or something?
>
> Greetings,
> Maxime.
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#29644: gcc-objc is unusable without its 'gcc' executable.

[Zhu Zihao]

Maxime Devos  writes:

> Or maybe some plugin architecture is used, I don't know..

I think the problem is pointed out by Ricardo Wurmus in this reply 
https://issues.guix.gnu.org/29644#1
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#54784: Flatpak GTK apps cannot show pictures.

[Zhu Zihao]

# Main issue

Solanum in flatpak failed to render its logo.

# Reproduce step

Run

```
guix shell flatpak
flatpak install org.gnome.Solanum
flatpak run org.gnome.Solanum
```

# Investigation

The issue maybe caused by missing gdk pixbuf loaders. Try `flatpak run
--command=sh --devel org.gnome.Solanum` enter the debug shell of flatpak
and run `strace -o s.log solanum`. Found something like

```
openat(AT_FDCWD, 
"/run/current-system/profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache",
O_RDONLY) = -1 ENOENT (没有那个文件或目录)
...

access("/run/current-system/profile/share/themes/Adwaita/gtk-4.6/gtk.css", 
F_OK) = -1 ENOENT (没有那个文件或目录)
access("/run/current-system/profile/share/themes/Adwaita/gtk-4.4/gtk.css", 
F_OK) = -1 ENOENT (没有那个文件或目录)
access("/run/current-system/profile/share/themes/Adwaita/gtk-4.2/gtk.css", 
F_OK) = -1 ENOENT (没有那个文件或目录)
access("/run/current-system/profile/share/themes/Adwaita/gtk-4.0/gtk.css", 
F_OK) = -1 ENOENT (没有那个文件或目录)

...

openat(AT_FDCWD, "/run/current-system/profile/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (没有那个文件或目录)
```

It shows that flatpak is trying to load GTK related resource from
/run/current-system/profile. And use

```
flatpak run --filesystem=/gnu/store:ro --filesystem=/run/current-system:ro 
org.gnome.Solanum
```

It works well.

# Related links

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/flatpak/bubblewrap-paths.patch

The solution of Nixpkgs is add these path and store to the flatpak
sandbox. I'm not sure whether it's good or not. Because user may want to
setup its own GUIX{2,3,4}_GTK_PATH and GDK_PIXBUF_LOADER_FILES.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#54784: Flatpak GTK apps cannot show pictures.

[Zhu Zihao]

Ludovic Courtès  writes:

> Hi,
>
> Zhu Zihao  skribis:
>
>> It shows that flatpak is trying to load GTK related resource from
>> /run/current-system/profile. And use
>>
>> ```
>> flatpak run --filesystem=/gnu/store:ro --filesystem=/run/current-system:ro 
>> org.gnome.Solanum
>> ```
>>
>> It works well.
>>
>> # Related links
>>
>> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/flatpak/bubblewrap-paths.patch
>
> A patch like this one looks reasonable; it’s a transcription of what’s
> done on FHS systems, so why not.

Guix users often use declarative configuartion. So my concern is
mounting the whole store into flatpak sandbox will leak unneccesary
user secrets.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#54784: Flatpak GTK apps cannot show pictures.

[Zhu Zihao]

Ludovic Courtès  writes:

> Hi,
>
> Zhu Zihao  skribis:
>
>> It shows that flatpak is trying to load GTK related resource from
>> /run/current-system/profile. And use
>>
>> ```
>> flatpak run --filesystem=/gnu/store:ro --filesystem=/run/current-system:ro 
>> org.gnome.Solanum
>> ```
>>
>> It works well.
>>
>> # Related links
>>
>> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/flatpak/bubblewrap-paths.patch
>
> A patch like this one looks reasonable; it’s a transcription of what’s
> done on FHS systems, so why not.
>
> Would you like to give it a try?
>
> Thanks,
> Ludo’.

See https://issues.guix.gnu.org/55072

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#54297: Qutebrowser failed to render local fonts.

[Zhu Zihao]

Yes, this issue should be a duplicate of
https://issues.guix.gnu.org/53011

But I'm not sure whether we can update qtwebengine without touching other Qt 
components.

Lars-Dominik Braun  writes:

> Hi,
>
> I’ve been experiencing the same issue with RStudio (which uses
> qtwebengine under the hood)[1]. The workaround is the same, but it seems
> qtwebengine 5.15.7 has a fix for this issue[2] caused by an upgrade to
> glibc 2.33. So the solution would be to upgrade our qtwebengine package.
>
> Cheers,
> Lars
>
> [1] https://github.com/guix-science/guix-science/issues/12
> [2] https://bugreports.qt.io/browse/QTBUG-92969


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55427: emacs-libgit tests are broken

[Zhu Zihao]

Issue submitted to upstream with my guess and explanation.

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

This issue is not trivial and there's no way to workaround it IMO. 
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55427: emacs-libgit tests are broken

[Zhu Zihao]

Due to the inactive status of upstream. I'm planning to remove the
emacs-libgit input of emacs-magit.

magit will still work with the git executable if there's no
emacs-libgit.

Any thoughts?


Zhu Zihao  writes:

> [[PGP Signed Part:Undecided]]
> Issue submitted to upstream with my guess and explanation.
>
> https://github.com/magit/libegit2/issues/121
>
> This issue is not trivial and there's no way to workaround it IMO. 


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55427: emacs-libgit tests are broken

[Zhu Zihao]

magit doesn't use libgit for remote directory.

Maybe there're other reasons that make your magit work on remote file :P. 

https://github.com/magit/magit/blob/master/lisp/magit-git.el#L93

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Zhu Zihao schreef op di 17-05-2022 om 23:14 [+0800]:
>> magit will still work with the git executable if there's no
>> emacs-libgit.
>> 
>> Any thoughts?
>
> Due to issues with TRAMP, magit currently cannot always find the git
> executable, while AFAICT there are no problems with emacs-libgit.
>
> Greetings,
> Maxime.
>
> [[End of PGP Signed Part]]


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55427: emacs-libgit tests are broken

[Zhu Zihao]

Liliana Marie Prikler  writes:

>> magit will still work with the git executable if there's no
>> emacs-libgit.
>> 
>> Any thoughts?
> I don't see any benefits in this approach, do you?
>
> [1] http://ci.guix.gnu.org/build/859957/details

I don't see any benefits on libgit implementation.
The only method supported by libgit backend is `magit-bare-repo-p`[1],
magit use git executable to do 99.9% works.

The libgit backend should be a separated package. There's
https://github.com/magit/magit/blob/master/lisp/magit-libgit-pkg.el for
it. Its quaility is poor because it's currently in POC status and the
development status has been put on hold indefinitely.[2]

[1] https://github.com/magit/magit/blob/master/lisp/magit-libgit.el#L79

[2] https://github.com/magit/magit/issues/2959#issuecomment-1112185169
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55427: emacs-libgit tests are broken

[Zhu Zihao]

Maxime Devos  writes:

>> My concern is about not breaking the local use case.

As I said here: https://issues.guix.gnu.org/55427#15

Magit use git executable for 99.9% work. Guix user should install git
(or we patch the git absolute path for it) for almost all functionality.

libgit doesn't save you from missing git executable. 

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#55026: 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

bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication.

[Zhu Zihao]

I'm working with my private channel, And I update my gpg key using
NIPT-P384 algorithm. But `guix time-machine` complains that:

Updating channel 'cireguix' from Git repository at 
'/home/citreu/gitrepos/cireguix'...
Authenticating channel 'cireguix', commits 9b37ac0 to 6601a6a (1 new commits)...
[###]Backtrace:
In guix/store.scm:
   659:37 19 (thunk)
In guix/status.scm:
815:4 18 (call-with-status-report _ _)
In guix/store.scm:
   1298:8 17 (call-with-build-handler # …)
In guix/inferior.scm:
   904:34 16 (cached-channel-instance # …)
In guix/channels.scm:
523:7 15 (loop _ _)
In guix/combinators.scm:
48:26 14 (fold2 # …)
In guix/channels.scm:
   533:29 13 (_ #< name: cireguix url: "/home/citreu/gitre…> …)
   421:12 12 (latest-channel-instance # …)
In guix/git.scm:
290:7 11 (call-with-repository _ #)
In guix/git-authenticate.scm:
   442:22 10 (authenticate-repository # _ _ # …)
In guix/progress.scm:
71:36  9 (call-with-progress-reporter _ _)
In srfi/srfi-1.scm:
   460:18  8 (fold # …)
In guix/git-authenticate.scm:
   290:24  7 (_ # …)
226:4  6 (authenticate-commit # # …)
   129:23  5 (commit-signing-key _ # …)
In guix/openpgp.scm:
   562:26  4 (verify-openpgp-signature _ _ _)
In gcrypt/pk-crypto.scm:
250:8  3 (key-type (unsupported-algorithm 19 #vu8(5 43 129 4 …)))
   202:27  2 (_ (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 …)) 0)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 3 4 53 239 158 105 
250 133 46 247 192 56 245 48 43 60 70 47 46 85 221 226 213 94 248 254 218 85 
176 252 233 119 26 85 65 191 47 159 193 86 129 155 186 183 151 233 81 178 42 30 
81 234 192 184 140 230 226 26 72 186 82 18 213 187 6 28 34 39 197 75 37 138 226 
98 216 187 185 223 222 126 181 122 255 104 171 201 51 254 7 235 245 151 247 168 
215 165 73 181))

Does Guix support NIPT-P384 key?
-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao


signature.asc
Description: PGP signature

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Zhu Zihao]

My opinion: Maybe NSA recommend NIST family because they know how to get
around it. But they also have to believe foreign government can't break
it easily.

-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao

bug#57543: emacs-telega is broken.

[Zhu Zihao]

What about update emacs-telega to
0.8.44(https://github.com/zevlg/telega.el/commit/2d77c131856c9387a28dd6e4a15cef87029c3055)
?

I know the guidelines of Guix is package the stable release of software.
But I found that the telega in current Guix is partially broken(e.g.
messages with reactions is displayed as "TODO: messageUnsupported")

But the author of telega doesn't tag a release frequently. If we only
use the official release, it will be outdated.
-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

bug#58090: Missing bin/ffplay in ffmpeg@4

[Zhu Zihao]

citreu@asus-laptop:~$ guix describe
Generation 114  9月 26 2022 13:24:04 (当前)
  guix 754ce58
repository URL: https://mirror.guix.org.cn/git/guix
branch: master
commit: 754ce586e013582b0f6d28337fdc46db35395997
citreu@asus-laptop:~$ guix shell ffmpeg@4 --pure -- ffplay
guix shell: error: ffplay: command not found

-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

bug#63270: d-feet: Fails to build (Function does not take positional arguments)

[Zhu Zihao]

I fix this in https://issues.guix.gnu.org/63270 and it's pending to be
merged.

You can also try d-spy which IMO it's very good alternate.
-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

bug#63546: nix-channel error: opening pseudoterminal master: No such device

[Zhu Zihao]

You can have a look at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63893

which solves the problem.
-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

bug#43810: ripgrep and fd create .crates.toml which reference to build dir.

[Zhu Zihao]

In Guix commit 7cb4440951fa3a91d48c63ac5be123636abfcf82. I found that ripgrep 
and fd will emit a `.crates.toml` file outside of FHS structure(at the root of 
profile).


For example, the .crates.toml file from fd looks like.



```

[v1]
"fd-find 8.1.1 (path+file:///tmp/guix-build-fd-8.1.1.drv-0/fd-find-8.1.1)" = 
["fd"]
```


This file records the build directory, I think we'd better to exclude this to 
improve the determinisitc(If this file doesn't affect the functionality).


If we can't exclude it, it's better to place it in a proper place, if we leave 
it in the root of profile, .crates.toml from different rust apps will override 
each other.

bug#44139: Consider remove package emacs-cl-generic

[Zhu Zihao]

According to the description of emacs-cl-generic, it exists to provide
some backward compatibility for old Emacsen(< 25)

However, the Guix already package Emacs 27(even 28 on master branch).
IMO, emacs-cl-generic have done its job and we no longer need it.

Package emacs-finalize depends on emacs-cl-generic, it should still work
after we remove this dependency. If user install this package
accidentally, it may shadow the real cl-generic.el bundled with Emacs itself. 


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

Zihao


signature.asc
Description: PGP signature

bug#44327: `guix install` doesn't warn about collison in profile

[Zhu Zihao]

In commit ba60bbd4370570ff03a16c63af051be06f22658e. Try command

  guix install emacs && guix install emacs-xwidgets

These two packages are conflict with each other, but I can't see any
warning message emitted(It should emit some because profile-derivation
use union-build).

I also suggest to raise an error when conflict detected during building
profile to force user to resolve it.


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

Zihao


signature.asc
Description: PGP signature

bug#44327: `guix install` doesn't warn about collison in profile

[Zhu Zihao]

> > I also suggest to raise an error when conflict detected during building
> > profile to force user to resolve it.

> It should be already the case. :-)

IIRC the deafult collision handler of union-build is
warn-about-collision which doesn't terminate the build when collision
occured.

BTW, There's something called "priority" in Nix. The package with higher
priority in manifest will be able to override the package with lower one. 


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

Zihao


signature.asc
Description: PGP signature

bug#44863: Warning about importing a MELPA package

[Zhu Zihao]

ELPA importer supports MELPA[1] currently. But MELPA is a rolling
archive, which does not persist any old version tarball of
package, and harmful for reproducible build.

It's still useful for Guix packager to import package from MELPA to
draft a sketch of Emacs package, but it's not a reliable download
service. We may better warn user don't submit package which download url
belongs to MELPA. Maybe emit warning while executing `guix import elpa -a
melpa XXX`, or writing this rule to manual.

[1]: the stable archive is "MELPA stable", I use term "MELPA" to refer
to the unstable one.

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

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Reproduce steps:

   guix environment --ad-hoc qbittorrent && cat 
$GUIX_ENVIRONMENT/bin/qbittorrent


We can see the wrapper generated in qt-build-system doesn't extend
existing environment variable. Instead, it overrides them.

It was discussed in
https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00117.html one
year ago. This's not a trivial issue because using input method in Qt
program requires an qt plugin(XIM doesn't work here) which is managed by
QT_PLUGIN_PATH.

We should change following functions:

1. guix/build/qt-build-system.scm(wrap-all-programs)
2. guix/build/qt-utils.scm(wrap-qt-program)

It's ideal to make wrap-all-programs use wrap-qt-program internally and
we don't need to maintain two copy of wrap code.



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

Zihao


signature.asc
Description: PGP signature

bug#45193: Acknowledgement (Wrapper of Qt programs doesn't extend existing environment variable)

[Zhu Zihao]

In guix/build/qt-utils.scm:24:11

(define (wrap-qt-program out program)
  (define (suffix env-var path)
   ^
   I can't understand this, if you want to do a suffix wrap, you
   should do it in "wrap-program"(e.g. `("XDG_DATA_DIRS" suffix
   (,vars))), it will generate bash codes to do the job. If you
   use Guile code here, it'll capture build time environment
   variable values.

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

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Mark H Weaver writes:

> I agree with your analysis.  Would you like to propose a patch and test
> it as thoroughly as you can?

I just saw a patch posted by somebody on debbugs.

https://issues.guix.gnu.org/45221

Maybe we can go there to improve his patch and we don't have to write it
from scratch.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

I try to read and understand how wrap-qt-program in qt-utils.scm works.
When building QT program, Guix builder populates qt related environment
variable, and wrap-qt-program just record it into wrapper.

However, the wrap behaviour in qt-build-system is quite different, it
search all inputs and mark them should be included in envvar definition
if correspond directory exists.

Another difference is, wrap-qt-program will include the directory of
output in envvar but qt-build-system won't do.

I'm not sure whether we need to include output, and don't know recording
build time environment follows reproducible build rule or not. Maybe we
need an expert on Qt programming/packaging to give us some hints? :(

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Hartmut Goebel writes:

> I agree that leaking the environments variables from the build environment to
> the package is not a good idea. Also we might want to add some filters to 
> avoid
> all imports (including cmake) are going into the wrapping variables - which is
> much easier when dealing with inputs nor strings.

I just check how Nixpkgs do Qt wrapping, it use same strategy like 
wrap-qt-program.
Since our environment variable only contains the path to inputs, capture
the build-time environment can be forgiven (compare with patch-shebang).

I think the main problem is include unwanted directory accidentally and
increase the closure size. But it looks like an impossible job to do it
automatically. My idea is provide a keyword argument
#:qt-wrap-exclude-inputs to prevent qt-build-system to search unwanted inputs.

BTW, would you like to use prefix wrap for wrap-qt-program in qt-utils.scm?

> If I understand the code correctly,  line 103 of qt-build-system also handle 
> the
> output directories
>
>  (append (list directory)
>  input-directories
>
> and the qt-build-system should even handle different outputs (while qt-tuils
> does not):
>
>   (for-each handle-output outputs)
>
> (I may be wrong on this, please double check.

Yes you're right, output was handled. I misunderstood the code before. 

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Any progress in this patch? It's painful for CJK users that can't use
input method for Qt programs :(

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#46265: Hash mismatch in the source of package cunit

[Zhu Zihao]

building /gnu/store/qgri8w2rw585wc9npnbb2nd9qvj6szzs-CUnit-2.1-3.tar.bz2.drv...

Starting download of 
/gnu/store/vzq31539zql9s23708sbcrwb51lpwjf7-CUnit-2.1-3.tar.bz2
From 
http://downloads.sourceforge.net/project/cunit/CUnit/2.1-3/CUnit-2.1-3.tar.bz2...
following redirection to 
`https://downloads.sourceforge.net/#!/project/cunit/CUnit/2.1-3/CUnit-2.1-3.tar.bz2'...
downloading from 
http://downloads.sourceforge.net/project/cunit/CUnit/2.1-3/CUnit-2.1-3.tar.bz2 
...
 CUnit-2.1-3.tar.bz2  746B2.4MiB/s 00:00 [##] 100.0%
sha256 hash mismatch for 
/gnu/store/vzq31539zql9s23708sbcrwb51lpwjf7-CUnit-2.1-3.tar.bz2:
  expected hash: 057j82da9vv4li4z5ri3227ybd18nzyq81f6gsvhifs5z0vr3cpm
  actual hash:   1vc97w0kvchxzlf0v7nn1fzx7pi0ih29cdqd6r7rg1y6parqa6i5
hash mismatch for store item 
'/gnu/store/vzq31539zql9s23708sbcrwb51lpwjf7-CUnit-2.1-3.tar.bz2'
build of /gnu/store/qgri8w2rw585wc9npnbb2nd9qvj6szzs-CUnit-2.1-3.tar.bz2.drv 
failed
View build log at 
'/var/log/guix/drvs/qg/ri8w2rw585wc9npnbb2nd9qvj6szzs-CUnit-2.1-3.tar.bz2.drv.bz2'.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#46265: Hash mismatch in the source of package cunit

[Zhu Zihao]

Oh, it's probably my network issue, sorry for disturbing you.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#46314: materialdecoration failed to build with Qt 5.15.2.

[Zhu Zihao]

In c852d897551f514de95c224fa79e748f48808068, try `guix build
materialdecoration` and failed.

In file included from 
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylandwindow_p.h:66:0,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.h:44,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/build/src/plugins/decorations/material/materialdecoration_autogen/EWIEGA46WW/moc_materialdecoration.cpp:10,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/build/src/plugins/decorations/material/materialdecoration_autogen/mocs_compilation.cpp:2:
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylanddisplay_p.h:71:10:
 fatal error: QtXkbCommonSupport/private/qxkbcommon_p.h: No such file or 
directory
 #include 
  ^~~
compilation terminated.
make[2]: *** 
[src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/build.make:66:
 
src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/materialdecoration_autogen/mocs_compilation.cpp.o]
 Error 1
make[2]: *** Waiting for unfinished jobs
In file included from 
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylandwindow_p.h:66:0,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.h:44,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/plugin.cpp:24:
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylanddisplay_p.h:71:10:
 fatal error: QtXkbCommonSupport/private/qxkbcommon_p.h: No such file or 
directory
 #include 
  ^~~
compilation terminated.
make[2]: *** 
[src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/build.make:92:
 
src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/plugin.cpp.o]
 Error 1
In file included from 
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylandwindow_p.h:66:0,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.h:44,
 from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.cpp:35:
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylanddisplay_p.h:71:10:
 fatal error: QtXkbCommonSupport/private/qxkbcommon_p.h: No such file or 
directory
 #include 
  ^~~
compilation terminated.


A related issue is: https://github.com/lirios/materialdecoration/issues/11

Update materialdecoration to
https://github.com/lirios/materialdecoration/commit/d4208780606333499bbf5737af1a6a8ac83bd29e
may fix this issue, but it requires cmake-shared newer than currently we
have.

Full build log:



signature.asc
Description: PGP signature
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/3dsl2jalrcyldkrsqab1hc6sv8pyag9z-cmake-minimal-3.16.5/bin:/gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin:/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32/bin:/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10/bin:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/bin:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/bin:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/bin:/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7/bin:/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6/bin:/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0/bin:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/bin:/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8/bin:/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4/bin:/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/bin:/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin:/gnu/store/mpa04aq8lblbcviyxywxcsb1zbi0mf39-ld-wrapper-0/bin:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/bin:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/sbin:/gnu/store/vpvnd6593mjncvyir2rbgp3k83cr7w0a-qtbase-5.15.2/bin:/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/bin:/gnu/store/qwxfy2jyhq2744s4ljcqk3hwcpsf93aq-wayland-1.18.0/bin:/gnu/store/k30

bug#46362: got unexpected path `Backtrace:' from substituter

[Zhu Zihao]

This issue is similar with https://issues.guix.gnu.org/45828. But it
still not fixed in 127a88d390417d5d7b1b4a18c1b69c7169dcaf34.

When you have multiple substituters, Guix will try to fetch narinfo from
the second or even third substituters, and it dies.

```
chino@asus-laptop:~$ guix build opencv 
--substitute-urls="https://mirror.sjtu.edu.cn/guix https://mirror.guix.org.cn 
https://mirror.c1r3u.xyz https://ci.guix.gnu.org";
substitute: updating substitutes from 'https://mirror.sjtu.edu.cn/guix'... 
100.0%
substitute: 
guix build: error: got unexpected path `Backtrace:' from substituter
```

If there's one substituter, it will work and do the substitution.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#47559: GNU ELPA doesn't provide unzipped tarball for old version of package

[Zhu Zihao]

I found emacs-pyim failed to build because guix builder cannot download
source from GNU ELPA.

I check the page of pyim https://elpa.gnu.org/packages/pyim.html, and
found that GNU ELPA only provides .tar.lz format source for old version
of package.

If GNU ELPA no longer provides stable url for packages, we may need to
adjust elpa importer to use Git repo if possible. And we also need to
fix packages depend on GNU ELPA url because they may be broken in future.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#42173: Nix on Guix System: can't update channels

[Zhu Zihao via web]

I found that if I put "sandbox = false" to /etc/nix/nix.conf. Nix can update 
channel. Maybe nix's sandbox forget to import some guix binary path?

bug#42173: Nix on Guix System: can't update channels

[Zhu Zihao via web]

We can add the path to bash to build-sandbox-path in /etc/nix.conf, described 
in https://nixos.wiki/wiki/FAQ.