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
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
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
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
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
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
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
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
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
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
# 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.
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
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
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))
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
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:
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
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
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
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
> 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
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.
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?
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
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
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
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),
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:
>
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
> 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)?
--
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 p
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
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:
```
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
>> > simultanuo
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
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,
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.
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
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
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'",
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
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
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
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
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
"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
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."
>>
@@ -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")
-
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 everyb
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
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?
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
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:
>
> > T
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 |
rom 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(+)
d
55 matches
Mail list logo
