bug#63797: [PATCH 0/2] fix python-matrix-nio build

2023-06-30 Thread Andrew Tropin
On 2023-06-11 22:54, Arjan Adriaanse wrote:

> This updates python-matrix-nio which fixes the python-h11 dependency
> problem.  It also requires updating python-aiofiles.  Tested by
> successfully building dependent packages.
>
> Arjan Adriaanse (2):
>   gnu: python-aiofiles: Update to 23.1.0.
>   gnu: python-matrix-nio: Update to 0.20.2.
>
>  gnu/packages/matrix.scm | 16 
>  gnu/packages/python-xyz.scm |  4 ++--
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
>
> base-commit: 74443c30f3e20655a046c0d3ea236822ef130968

Hi Arjan,

Thank you for the patches, applied, pushed as
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=356c0009d4

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature


bug#64297: [Cuirass] Remote server not picking up job, losing workers

2023-06-30 Thread Ludovic Courtès
Ludovic Courtès  skribis:

> The problem is most likely with the connection-to-port caching in
> squee’s ‘connection-socket-port’, as can be seen in this other trace
> where I added ‘pk’ calls in ‘connection-socket-port’:

Confirmed, with a fix!

  https://notabug.org/cwebber/guile-squee/pulls/8

Ludo’.





bug#64389: java: stripping timestamps breaks jmods.

2023-06-30 Thread Ricardo Wurmus
The 'strip-archive-timestamps phase in our openjdk packages breaks the
jmod feature because it invalidates the content hashes.

Here I try to extend the JDK with modules from openjfx:

--8<---cut here---start->8---
jlink --add-modules 
java.desktop,javafx.swing,javafx.controls,jdk.unsupported.desktop --output 
myjdk --module-path openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/
Error: Hash of java.xml 
(da39a79e291a7cc5b8e240390a4386a7d2323017871d6c2d635301826d0159f9) differs to 
expected hash 
(e3ee7150f05504485371ab9bac2d724a553f975eca5d529dca786599cc5f98a3) recorded in 
java.base
java.lang.module.FindException: Hash of java.xml 
(da39a79e291a7cc5b8e240390a4386a7d2323017871d6c2d635301826d0159f9) differs to 
expected hash 
(e3ee7150f05504485371ab9bac2d724a553f975eca5d529dca786599cc5f98a3) recorded in 
java.base
at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
at java.base/java.lang.module.Resolver.checkHashes(Resolver.java:480)
at java.base/java.lang.module.Resolver.finish(Resolver.java:378)
at 
java.base/java.lang.module.Configuration.(Configuration.java:139)
at 
java.base/java.lang.module.Configuration.resolve(Configuration.java:422)
at 
java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
at 
jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
at 
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:536)
at 
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:424)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:276)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
--8<---cut here---end--->8---

When I remove the 'strip-archive-timestamps phase and try using jlink
from this variant of the openjdk package things work fine:

--8<---cut here---start->8---
java.base 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.base.jmod
java.datatransfer 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.datatransfer.jmod
java.desktop 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.desktop.jmod
java.prefs 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.prefs.jmod
java.xml 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.xml.jmod
javafx.base 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.base.jmod
javafx.controls 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.controls.jmod
javafx.graphics 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.graphics.jmod
javafx.swing 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.swing.jmod
jdk.unsupported 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/jdk.unsupported.jmod
jdk.unsupported.desktop 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/jdk.unsupported.desktop.jmod

Providers:
  java.desktop provides java.net.ContentHandlerFactory used by java.base
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
  java.desktop provides javax.print.PrintServiceLookup used by java.desktop
  java.desktop provides javax.print.StreamPrintServiceFactory used by 
java.desktop
  java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by 
java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileReader used by java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileWriter used by java.desktop
  java.desktop provides javax.sound.midi.spi.SoundbankReader used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileReader used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileWriter used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.FormatConversionProvider used 
by java.desktop
  java.desktop provides javax.sound.sampled.spi.MixerProvider used by 
java.desktop
  java.desktop provides sun.datatransfer.DesktopDatatransferService used by 
java.datatransfer
  jdk.unsupported.desktop provides sun.swing.InteropProvider used by 
java.desktop
--8<---cut here---end--->8---

We will need to find a way to remove timestamps without leaving invalid
hashes behind.  Can we recompute the file hashes or avoid embedding
timestamps in the first place?

-- 
Ricardo





bug#64271: libasr is unmaintained upstream

2023-06-30 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道:

OpenSMTPd temporarily(…) builds with openssl with commit
023ff651462f70004c7a92b19fd072ee3138e5a2, so the comment is 
gone.


Heh.  I see you released -p1 literally while I was typing that :-)

Thanks!

T G-R


signature.asc
Description: PGP signature


bug#64271: libasr is unmaintained upstream

2023-06-30 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Omar Polo 写道:
I'm not a guix user so can't send patches, hope this is the 
correct

way to report issues however.


Yep.

The upstream libasr-portable repository was archived, as the 
project
was unmaintained (and unmaintenable in some sense) for some 
time:


https://github.com/OpenSMTPD/libasr/

OpenSMTPD (its only consumer I guess) doesn't depend on it 
anymore, it

should be built with the bundled version that was updated.


Removed libasr in commit 902a48e0d3ce4a1983a6d3f71472639a8e59c48f.


P.S.: looking at the recipe for OpenSMTPD I noticed the comment
  "reccomended, and supports e.g. ECDSA".  While it's true 
  that
  it's reccomended to build with LibreSSL, ec keys should 
  work
  just as fine with OpenSSL.  The only issue is the combo 
  OpenSSL
  3.x + LibreTLS 3.7.0 due to a known regression that will 
  be
  fixed in a upcoming release (I hope) since LibreSSL' tls 
  did it:

  https://github.com/libressl/openbsd/commit/318ad8e73e


OpenSMTPd temporarily(…) builds with openssl with commit 
023ff651462f70004c7a92b19fd072ee3138e5a2, so the comment is gone.


Thanks!

T G-R


signature.asc
Description: PGP signature


bug#64369: Request for merging "mesa-updates" branch

2023-06-30 Thread John Kehayias via Bug reports for GNU Guix
Hello all,

This is a request to merge the recently created "mesa-updates" branch. 
Currently there are just 2 patches on there, fixing/updating mesa only. The 
main thing to see is how substitute building goes in case anything breaks, but 
I'm hoping there isn't anything caused by this update.

I believe the "ruby-team" and "tex-team-next" [1] are ahead in the queue, not 
sure the timing of where those are. In addition/alternatively, would it make 
sense to have this branch as a separate build job on Cuirass directly as the 
"kernel-updates" branch? This would need a build roughly every month or so when 
mesa puts out a new update, we check for breakages, and then merge to master 
with substitutes available already.

I wasn't sure if this needs formal blockers in debbugs for the other branch 
merge requests, let me know!

Thanks,
John

[0] 

[1] 






bug#64297: [Cuirass] Remote server not picking up job, losing workers

2023-06-30 Thread Ludovic Courtès
Ludovic Courtès  skribis:

> As of cuirass@1.1.0-16.b825967, ‘cuirass remote-server’ appears to not
> pick jobs as quickly as it should and to lose sight of workers (you can
> see them come and go on ).
>
> /var/log/cuirass-remote-worker.log shows that it does build things, but
> only sporadically.  Then there are things like:
>
>   2023-06-26 10:07:58 warning: Poll loop busy during 3404 seconds.
>
> This is presumably related to Cuirass commit
> c4743b54720e86b0e0b0295fb6d33977e4293644 (previously ‘remote-worker’
> would have a database worker thread; now it opens a new connection every
> time—a stopgap before it’s fiberized, but apparently not a good one).

Apparently this has to do with squee calling ‘current-read-waiter’
(i.e., poll(2)) while waiting for its response and passing checking the
wrong FD for some reason, as in this case:

--8<---cut here---start->8---
18484 15:01:00 connect(55, {sa_family=AF_UNIX, 
sun_path="/tmp/ephemeralpg.58xnKh/.s.PGSQL.5432"}, 110) = 0 <0.19>
18484 15:01:00 getsockopt(55, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 <0.14>
18484 15:01:00 getsockname(55, {sa_family=AF_UNIX}, [128 => 2]) = 0 <0.10>
18484 15:01:00 poll([{fd=55, events=POLLOUT|POLLERR}], 1, -1) = 1 ([{fd=55, 
revents=POLLOUT}]) <0.11>
18484 15:01:00 sendto(55, "\0\0\0!\0\3\0\0user\0ludo\0database\0test\0\0", 33, 
MSG_NOSIGNAL, NULL, 0) = 33 <0.14>
18484 15:01:00 poll([{fd=55, events=POLLIN|POLLERR}], 1, -1 
18484 15:01:00 <... poll resumed>)  = 1 ([{fd=55, revents=POLLIN}]) 
<0.001786>
18484 15:01:00 recvfrom(55, 
"R\0\0\0\10\0\0\0\0S\0\0\0\26application_name\0\0S\0\0\0\31client_encoding\0UTF8\0S\0\0\0\27DateStyle\0ISO,
 MD"..., 16384, 0, NULL, NULL) = 376 <0.16>
18484 15:01:00 sendto(55, "P\0\0\0\366\0\nUPDATE Builds SET status = -2, worker 
= null FROM\n(SELECT id FROM Workers"..., 291, MSG_NOSIGNAL, NULL, 0 

18484 15:01:00 <... sendto resumed>)= 291 <0.000589>
18484 15:01:00 poll([{fd=54, events=POLLIN}], 1, -1 
18484 15:03:14 <... poll resumed>)  = 1 ([{fd=54, revents=POLLIN}]) 
<134.319198>
18484 15:03:14 recvfrom(55,  
18484 15:03:14 <... recvfrom 
resumed>"1\0\0\0\0042\0\0\0\4n\0\0\0\4C\0\0\0\rUPDATE 0\0Z\0\0\0\5I", 16384, 0, 
NULL, NULL) = 35 <0.26>
18484 15:03:14 sendto(55, "P\0\0\0V\0DELETE FROM Workers WHERE\n(extract(epoch 
from now())::int - last_seen) >  "..., 131, MSG_NOSIGNAL, NULL, 0 
18484 15:03:14 <... sendto resumed>)= 131 <0.84>
18484 15:03:14 poll([{fd=54, events=POLLIN}], 1, -1) = 1 ([{fd=54, 
revents=POLLNVAL}]) <0.13>
18484 15:03:14 recvfrom(55, "1\0\0\0\0042\0\0\0\4n\0\0\0\4C\0\0\0\rDELETE 
4\0Z\0\0\0\5I", 16384, 0, NULL, NULL) = 35 <0.16>
18484 15:03:14 sendto(55, "X\0\0\0\4", 5, MSG_NOSIGNAL, NULL, 0) = 5 <0.25>
18484 15:03:14 close(55)= 0 <0.18>
18484 15:03:14 openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory) <0.19>
18484 15:03:14 write(2, "2023-06-30T15:03:14 warning: Poll loop busy during 134 
seconds.\n", 64) = 64 <0.24>
--8<---cut here---end--->8---

In this case FD 54 is a connection with a worker process; terminating
that process led poll(2) to return, thus unblocking the “poll loop”.

The problem is most likely with the connection-to-port caching in
squee’s ‘connection-socket-port’, as can be seen in this other trace
where I added ‘pk’ calls in ‘connection-socket-port’:

--8<---cut here---start->8---
19468 15:37:43 connect(55, {sa_family=AF_UNIX, 
sun_path="/tmp/ephemeralpg.58xnKh/.s.PGSQL.5432"}, 110) = 0 <0.18>
19468 15:37:43 getsockopt(55, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 <0.10>
19468 15:37:43 getsockname(55, {sa_family=AF_UNIX}, [128 => 2]) = 0 <0.09>
19468 15:37:43 poll([{fd=55, events=POLLOUT|POLLERR}], 1, -1) = 1 ([{fd=55, 
revents=POLLOUT}]) <0.09>
19468 15:37:43 sendto(55, "\0\0\0!\0\3\0\0user\0ludo\0database\0test\0\0", 33, 
MSG_NOSIGNAL, NULL, 0) = 33 <0.12>
19468 15:37:43 poll([{fd=55, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=55, 
revents=POLLIN}]) <0.002109>
19468 15:37:43 recvfrom(55, 
"R\0\0\0\10\0\0\0\0S\0\0\0\26application_name\0\0S\0\0\0\31client_encoding\0UTF8\0S\0\0\0\27DateStyle\0ISO,
 MD"..., 16384, 0, NULL, NULL) = 376 <0.09>
19468 15:37:43 sendto(55, "P\0\0\0\366\0\nUPDATE Builds SET status = -2, worker 
= null FROM\n(SELECT id FROM Workers"..., 291, MSG_NOSIGNAL, NULL, 0) = 291 
<0.12>
19468 15:37:43 write(1, "\n", 1)= 1 <0.15>
19468 15:37:43 ioctl(54, TCGETS, 0x7ffd8fde6660) = -1 ENOTTY (Inappropriate 
ioctl for device) <0.12>
19468 15:37:43 write(1, ";;; (cached # 
#)\n", 68) = 68 <0.12>
--8<---cut here---end--->8---

Above we open a fresh connection on FD 55, but ‘connection-socket-port’
determines that the connection object is cached and associated with a
port for FD 54.

To be continued…


bug#64350: python-wand-0.6.11 fails in check phase

2023-06-30 Thread Csepp


Thorsten Wilms  writes:

> Hi, python-wand 0.6.11 fails to install. I found this in the log:
>
> phase `add-install-to-path' succeeded after 0.0 seconds
> starting phase `wrap'
> find-files: 
> /gnu/store/8y1vnzs66bnfgiaxdxhmc7wd9ggkcpy6-python-wand-0.6.11/bin: No such 
> file or directory
> find-files: 
> /gnu/store/8y1vnzs66bnfgiaxdxhmc7wd9ggkcpy6-python-wand-0.6.11/sbin: No such 
> file or directory
> phase `wrap' succeeded after 0.0 seconds
> starting phase `check'
> error: in phase 'check': uncaught exception:
> unbound-variable #f "Unbound variable: ~S" (tests?) #f 
> phase `check' failed after 0.0 seconds
> Backtrace:
>   10 (primitive-load "/gnu/store/m7pmcj4czzw4pc40s6sfyahq8q9…")
> In guix/build/gnu-build-system.scm:
> 908:2  9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
>   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
> 634:9  7 (for-each # …)
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/build/gnu-build-system.scm:
>929:23  5 (_)
> In ice-9/eval.scm:
>279:15  4 (_ #(#(#) (# # …)))
>223:20  3 (proc #(#(#) (# …)))
> In unknown file:
>2 (%resolve-variable (7 . tests?) #)
> 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:
> Unbound variable: tests?

Sorry, don't have the time for a proper patch.
Replace this:
lambda _
with this
lambda* (#:keys tests? #:allow-other-keys)

Feel free to send it as a patch.





bug#63608: UTF-8 support absent within guix shell --pure less

2023-06-30 Thread Bruno Victal
On 2023-05-22 15:25, Maxim Cournoyer wrote:> So GUIX_LOCPATH is *not* set, 
right?  Could you try adding 'glibc' to
> the environment as well?  It's the one providing the GUIX_LOCPATH search
> path.

The issue still remains (with and without glibc-locales):

--8<---cut here---start->8---
~/src/guix$ guix shell --pure less glibc glibc-locales
~/src/guix [env]$ less gnu/packages/java-xml.scm
"gnu/packages/java-xml.scm" may be a binary file.  See it anyway? 
…

~/src/guix [env]$ echo $GUIX_LOCPATH
/gnu/store/654wv1gyw1r2gpcwggmn8spbcrq5b9vq-profile/lib/locale
--8<---cut here---end--->8---


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.





bug#64014: guix pack regression

2023-06-30 Thread André A . Gomes
Ludovic Courtès  writes:

> Yes, that’d be great.  If you still have that older pack that didn’t
> have the problem, you could also run it under ‘strace -f -o
> /tmp/log.strace’ to see what happens before the failure.

Ludovic, I didn't reach any meaningful conclusion.  Please close this
issue.  Thanks.


-- 
André A. Gomes
"You cannot even find the ruins..."





bug#64365: [Shepherd] Export deregister-service.

2023-06-30 Thread Bruno Victal
Although 'register-services' is exported its counterpart
'deregister-service' is not.

Some notes:
* 'register-services' is in its plural form while its counterpart
is not, maybe one of them should be renamed for consistency sake?

* From the docstring and code the interface of 'deregister-service'
seems to differ from 'register-services' though I haven't
confirmed it. Perhaps add some documented examples for reference?


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.