bug#51696: Request: Adopt the unofficial GUIX community on Matrix

[Mark H Weaver]

Hi Jacob,

Jacob Hrbek  writes:

> There is an unofficial GNU Guix community on matrix (#guix:matrix.org)
> with 375 members and an unofficial matrix space that i've created
> (https://matrix.to/#/#gnu-guix:tchncs.de) which consist of
> IRC<->Matrix bridged channels.
>
> Proposing for GNU Guix to adopt this community, it's moderators and my
> space to configure IRC<->Matrix bridge (less then 4000 CPU cycles per
> day last time i checked) to connect those two communities and users
> who prefer either of those protocols to increase the reach of GNU Guix
> to new users.

I appreciate this initiative, and from my preliminary investigations it
seems to me that Matrix would be a good protocol to support.  I would be
glad if GNU Guix gained an official Matrix channel.

I have one concern: I'm concerned about control.

You propose that GNU Guix should adopt "this community, it's moderators
and my space".  Who are these moderators?  Who controls the "space"?
Who gets to decide who is given moderation privileges over the "space"?

If, in the future, you disagreed with the GNU Guix project leadership
over how the "space" was being managed, who would have the technical
and/or legal ability to override the others' wishes?

In short, would we need to trust you?

I hope that you will not read these concerns as suggesting that you have
ill intent.  On the contrary, although I don't know you, I think it's
highly likely that your intent is benign, and I appreciate your efforts
to improve our communications infrastructure.

I would have these concerns regardless of who held the keys, even if it
were a long-time Guix project participant who I had come to deeply
respect and trust.

What do you think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#51645: (No Subject)

[Jacob Hrbek]

Note: conversation was moved on guix-devel mailing list.

publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#51696: Request: Adopt the unofficial GUIX community on Matrix

[Jacob Hrbek]

There is an unofficial GNU Guix community on matrix (#guix:matrix.org) with 375 
members and an unofficial matrix space that i've created 
(https://matrix.to/#/#gnu-guix:tchncs.de) which consist of IRC<->Matrix bridged 
channels.

Proposing for GNU Guix to adopt this community, it's moderators and my space to 
configure IRC<->Matrix bridge (less then 4000 CPU cycles per day last time i 
checked) to connect those two communities and users who prefer either of those 
protocols to increase the reach of GNU Guix to new users.

-- Jacob "Kreyren" Hrbek

Sent with ProtonMail Secure Email.

publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#51435: unison does not build on core-updates-frozen

[Ludovic Courtès]

Hi,

Vivien Kraus  skribis:

>>From 093b913147b8f7e9aab66887ed1484e6aaeeb102 Mon Sep 17 00:00:00 2001
> From: Vivien Kraus 
> Date: Thu, 4 Nov 2021 10:59:18 +0100
> Subject: [PATCH 1/2] gnu: Add texlive-dvips-l3backend.
>
> * gnu/packages/tex.scm (texlive-dvips-l3backend): New variable.

[...]

>>From a7568441319c4e42ec2e51dfddf62eacb0a054e2 Mon Sep 17 00:00:00 2001
> From: Vivien Kraus 
> Date: Thu, 4 Nov 2021 01:02:39 +0100
> Subject: [PATCH 2/2] gnu: unison: Fix building the manual.
>
> * gnu/packages/ocaml.scm (unison)[native-inputs]: Add the missing texlive 
> inputs.

Pushed as 648b81211fa1d14048a39fff59397ae90a5fef91.

Thanks!

Ludo’.

bug#51693: [patch] Add Java 17

[Dr. Arne Babenhauserheide]

Hi,

the attached patch adds openjdk@17

Take care with updating packages depending on this, because the changes
to the module system can cause runtime failures.

From 23d8220c78a9ac6aa84dff96fd0c0a1d8214a699 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide 
Date: Mon, 8 Nov 2021 21:21:41 +0100
Subject: [PATCH] gnu: openjdk17: add Java 17.0.1.

* gnu/packages/java.scm (openjdk17): 17.0.1
---
 gnu/packages/java.scm | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index da72dbb38c..34abdcc418 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2581,6 +2581,52 @@ (define-public openjdk16
#t))
 (home-page "https://openjdk.java.net/projects/jdk/16;)))

+(define-public openjdk17
+  (package
+(inherit openjdk16)
+(name "openjdk")
+(version "17.0.1")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/openjdk/jdk17u;)
+(commit (string-append "jdk-" version "-ga"
+  (file-name (git-file-name name version))
+  (sha256
+   (base32
+"1l1jgbz8q7zq66npfg88r0l5xga427vrz35iys09j44b6qllrldd"
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("openjdk16:jdk" ,openjdk16 "jdk")
+   ("pkg-config" ,pkg-config)
+   ("unzip" ,unzip)
+   ("which" ,which)
+   ("zip" ,zip)))
+(arguments
+ (substitute-keyword-arguments (package-arguments openjdk15)
+   ((#:phases phases)
+`(modify-phases ,phases
+   (add-after 'unpack 'make-templates-writable
+ (lambda _
+   ;; The build system copies a few .template files from the
+   ;; source directory into the build directory and then modifies
+   ;; them in-place.  So these files have to be writable.
+   (for-each
+(lambda (file)
+  (invoke "chmod" "u+w" file))
+(find-files "src/java.base/share/classes/jdk/internal/misc/"
+"\\.template$"))
+   #t))
+   (replace 'fix-java-shebangs
+ (lambda _
+   ;; This file was "fixed" by patch-source-shebangs, but it requires
+   ;; this exact first line.
+   (substitute* "make/data/blockedcertsconverter/blocked.certs.pem"
+ (("^#!.*") "#! java BlockedCertsConverter SHA-256\n"))
+   #t))
+   
+(home-page "https://openjdk.java.net/projects/jdk/17;)))
+
 (define-public icedtea icedtea-8)

 
--
2.33.1



Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#51642: Package wishlist location

[zimoun]

Hi,

On Sun, 07 Nov 2021 at 00:57, "bdju"  wrote:

>   which I think is where package
> requests are intended to go. At least, that's where I always add things
> I wish were packaged. I know Nixpkgs takes package requests on their
> issue tracker, but I don't typically see such things on the guix mailing
> lists.
>
> https://libreplanet.org/wiki/Group:Guix/Wishlist

Well, first Debbugs has the tag ’wishlist’ [1] and second I am not
convinced that people package software based on wishlist (wherever the
list is).  Personally, I package what I use or need.

>From my point of view, I would prefer this wishlist about packages
outside the Bug Tracker.  I am fine with wishlist for missing features
because they are somehow kind of bug but not for packages – without
looking far, I can think to more than 50 Scientific packages missing,
and I do not see the need to list such packages or how it helps the
project to get them listed – for what my opinion is worth here – and if
such wishlist is useful, then it appears to me simpler to have the
complete list at one unique location (for instance [2]), instead of
filtering first the Bug Tracker to get such wishlist.

1: 
2: 

Cheers,
simon

bug#47474: fossil: hash mismatch

[zimoun]

Hi,

On Thu, 04 Nov 2021 at 21:46, phodina via Bug reports for GNU Guix 
 wrote:

> the checksum was corrected by Tobias Geerinckx-Rice in commit
> 20771f4043990632b73187b10d1851a1244df4e6 as well as the pkg was
> updated from 2.10 -> 2.11.

Indeed, when looking forward. :-)

However, in the context of Disarchive and long-term, it is seems
relevant to keep it still open; as example to test “guix time-machine”
and various fallbacks, IMHO.


Cheers,
simon

bug#51463: Lack of error message in several guix subcommands

[zimoun]

Hi Ludo,

On Sun, 07 Nov 2021 at 23:14, Ludovic Courtès  wrote:

> I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the
> issue affected ‘read-error’ exceptions for reasons other than missing
> closing parentheses).

With your fix, I am questioning the ’if’ test.  Introduced before
524c9800afb433cc474132185d8e37f72004adb3.


For instance, it reads,

--8<---cut here---start->8---
/tmp/pkgs/foo.scm:26:1: missing closing parenthesis
--8<---cut here---end--->8---

when Guile reports,

--8<---cut here---start->8---
/tmp/foo.scm:25:1: unexpected end of input while searching for: )
--8<---cut here---end--->8---

and this message is parsed to catch and report the first message,
instead.

Well, I agree that on one hand, Guile error messages seem badly worded
for newcomers.  On the other hand, post
4d59596a1c5f6b20870e619cbf67068ac7dd64ff, the message for extra
parenthesis,

--8<---cut here---start->8---
guix repl: error: read error while loading '/tmp/pkgs/foo.scm': 
/tmp/pkgs/foo.scm:25:23: unexpected ")"
--8<---cut here---end--->8---

is inconsistent from the one for missing parenthesis. Other said, the
then-branch uses ’format’ and the else-branch uses ’report-error’.


Some Guile errors are sometimes cryptic (the reason of “missing closing
parenthesis” I guess), therefore, the question is: do we add ’cond’
branches for each cases? Using “report-error” for all? Or do we only
rely on Guile error messages?  Dropping ’if’ test.


Last, checking and playing with all that, I note that this catch is done
when using ’load*’ and nothing is done for option ’load-path’.


Cheers,
simon

bug#50945: Guix home: No such file or directory: "/run/user/1003/on-first-login-executed"

[Andrew Tropin]

On 2021-11-05 17:58, Xinglu Chen wrote:

> Hi,
>
> On Thu, Oct 07 2021, Andrew Tropin wrote:
>
>> On 2021-10-01 17:46, Jan Nieuwenhuizen wrote:
>>
>>> Hi,
>>>
>>> When using su or sudo to enter an account managed by guix home, I get
>>> this error
>>>
>>> --8<---cut here---start->8---
>>> Backtrace:
>>>2 (primitive-load "/home/guix/.guix-home/on-first-login")
>>> In ice-9/ports.scm:
>>>461:11  1 (call-with-output-file "/run/user/1003/on-first-login-…" …)
>>> In unknown file:
>>>0 (open-file "/run/user/1003/on-first-login-executed" "w" …)
>>>
>>> ERROR: In procedure open-file:
>>> In procedure open-file: No such file or directory: 
>>> "/run/user/1003/on-first-login-executed"
>>> --8<---cut here---end--->8---
>>>
>>> [...]
>>
>> Thank you for a very detailed report.
>>
>> pam_elogind doesn't create a session, when the login shell spawned by
>> sudo or su => XDG_RUNTIME_DIR not get created => this message appears.
>>
>> I think we can omit execution of any processes by on-first-login script
>> in case session wasn't created.  Added the check:
>>
>> From aab6df0298963fe91a6ebfd1dadbc1530eceeff7 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Thu, 7 Oct 2021 08:12:04 +0300
>> Subject: [PATCH] home-services: on-first-login: Check if XDG_RUNTIME_DIR
>>  exists.
>>
>> * gnu/home-services.scm (on-first-login): on-first-login won't execute
>> anything if XDG_RUNTIME_DIR doesn't exists.
>> ---
>>  gnu/home-services.scm | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/gnu/home-services.scm b/gnu/home-services.scm
>> index 9f1e986616..0b77a1321d 100644
>> --- a/gnu/home-services.scm
>> +++ b/gnu/home-services.scm
>> @@ -286,8 +286,11 @@ will be put in @file{~/.guix-home/files}.")))
>> ;; XDG_RUNTIME_DIR dissapears on logout, that means such trick
>> ;; allows to launch on-first-login script on first login only
>> ;; after complete logout/reboot.
>> -   (when (not (file-exists? flag-file-path))
>> - (begin #$@gexps (touch flag-file-path))
>> +   (if (file-exists? xdg-runtime-dir)
>> +   (when (not (file-exists? flag-file-path))
>
> Use (unless …) instead of (when (not …)…).
>
>> + (begin #$@gexps (touch flag-file-path)))
>> +   (display "XDG_RUNTIME_DIR doesn't exists, the session wasn't
>> +created, on-first-login script won't execute anything.")
>
> It would be good to tell the user how they could manually run the
> script, that way they could manually set/create $XDG_RUNTIME_DIR and run
> the script.
>
>   "XDG_RUNTIME_DIR doesn't exist; the 'on-first-login' script won't
>   execute anything.  You can manually execute the script by running
>   '$HOME/.guix-home/on-first-login'
>
> WDYT?

Addressed suggestions, attaching updated patch.

From 8b924b02ab917632047d6653f19d9b16175989bf Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Thu, 7 Oct 2021 08:12:04 +0300
Subject: [PATCH] home-services: on-first-login: Check if XDG_RUNTIME_DIR
 exists.

* gnu/home-services.scm (on-first-login): on-first-login won't execute
anything if XDG_RUNTIME_DIR doesn't exists.
---
 gnu/home/services.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index 5c9b743f7b..1e295b6afe 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -286,8 +286,13 @@ (define (compute-on-first-login-script _ gexps)
;; XDG_RUNTIME_DIR dissapears on logout, that means such trick
;; allows to launch on-first-login script on first login only
;; after complete logout/reboot.
-   (when (not (file-exists? flag-file-path))
- (begin #$@gexps (touch flag-file-path))
+   (if (file-exists? xdg-runtime-dir)
+   (unless (file-exists? flag-file-path)
+ (begin #$@gexps (touch flag-file-path)))
+   (display "XDG_RUNTIME_DIR doesn't exists, on-first-login script
+won't execute anything.  You can check if xdg runtime directory exists,
+XDG_RUNTIME_DIR variable is set to apropriate value and manually execute the
+script by running '$HOME/.guix-home/on-first-login'")
 
 (define (on-first-login-script-entry m-on-first-login)
   "Return, as a monadic value, an entry for the on-first-login script
-- 
2.33.0


Also, added a note about elogind/XDG_RUNTIME_DIR to manual.

From f5d35fd4f542a11226c0159ee32498e374ff40a2 Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Mon, 8 Nov 2021 12:22:04 +0300
Subject: [PATCH] doc: Add a note about elogind and XDG_RUNTIME_DIR for Guix
 Home.

* doc/guix.texi (Declaring the Home Environment): Add a note about elogind and
XDG_RUNTIME_DIR.
---
 doc/guix.texi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 3355a535ad..36437cf161 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -35916,6 +35916,13 @@ guix home reconfigure 

bug#50773: ungoogled-chromium fails to use webcam

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> As of commit c582be4c38596a6a31a39c6799723dcd8b6eb909 (Sept. 23),
> ungoogled-chromium fails to grab images from my webcam (for instance in
> BigBlueButton instances), printing this message repeatedly:
>
>   [4685:3:0924/102919.814053:ERROR:video_stream_encoder.cc(1762)] Failed to 
> encode frame. Error code: -7

For the record, this is still the case with:

--8<---cut here---start->8---
$ guix describe
Generacio 194   Nov 07 2021 23:40:30(nuna)
  guix bd41e59
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bd41e590dd24e54797fb8b6854c244efd4d12df5
$ guix package -A ungoogled
ungoogled-chromium  95.0.4638.69-1  out gnu/packages/chromium.scm:489:2
ungoogled-chromium-wayland  95.0.4638.69-1  out 
gnu/packages/chromium.scm:957:2
--8<---cut here---end--->8---

> I found that an older generation (Aug. 30) works for me:
>
>   guix time-machine --commit=f91ae9425bb385b60396a544afe27933896b8fa3 -- \
> environment --ad-hoc ungoogled-chromium -- chromium

Still my preferred workaround.  :-)

Efraim Flashner  skribis:

> I'm fighting ungoogled chromium for something unrelated, but I noticed I
> needed to add thirdparty/libusb to %preserved-third-party-files to get
> it to build headless for me. Perhaps it tries to reach out directly to
> the webcam through usb itself?

I don’t know, not sure how to debug this.

Marius, do you have ideas of things to look at?

Thanks,
Ludo’.