bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread chris
On  1月15日 月, chris wrote:
> On  1月16日 火, Sergey Trofimov wrote:
> > 
> > Here you go:
> > ```sh
> > qtw=$(guix build qtwayland@6)/lib/qt6/plugins
> > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser 
> > -s qt.force_platform wayland
> > ```
> >

I think it needed the extra slash after at the end of $qtw... the shell output 
looks problematic, but otherwise the browser has started. Thank you

```
$ qtw=$(guix build qtwayland@6)/lib/qt6/plugins; QT_PLUGIN_PATH=$qtw/; 
QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms; qutebrowser -s qt.force_platform 
wayland
23:47:07 ERROR: Failed to copy webengine resources, not applying quirk
Traceback (most recent call last):
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py",
 line 253, in patch_webengine
webengine_resources_path = copy_webengine_resources()
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py",
 line 197, in copy_webengine_resources
shutil.rmtree(work_dir)
  File 
"/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py",
 line 724, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File 
"/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py",
 line 680, in _rmtree_safe_fd
onerror(os.unlink, fullname, sys.exc_info())
  File 
"/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py",
 line 678, in _rmtree_safe_fd
os.unlink(entry.name, dir_fd=topfd)
PermissionError: [Errno 13] 許可がありません: 'qtwebengine_devtools_resources.pak'
23:47:08 INFO: Showing changelog after upgrade to qutebrowser v3.1.0.
```





bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread chris
On  1月15日 月, chris wrote:
> On  1月16日 火, Sergey Trofimov wrote:
> > 
> > Here you go:
> > ```sh
> > qtw=$(guix build qtwayland@6)/lib/qt6/plugins
> > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser 
> > -s qt.force_platform wayland
> > ```

I tried this command again just now and succeeded this time. I must have done 
something wrong the first time.

Thank you Sergey!





bug#68478: Issue fixed

2024-01-15 Thread Daniel Khodabakhsh
Was able to fix this package as well as apparently other packages
which had the same issue by running:

sudo guix gc --verify=contents,repair





bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread chris
On  1月16日 火, Sergey Trofimov wrote:
> 
> Here you go:
> ```sh
> qtw=$(guix build qtwayland@6)/lib/qt6/plugins
> QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser -s 
> qt.force_platform wayland
> ```
> 
> Maybe a qutebrowser-wayland package variant should be defined to do the
> required wrapping. Otherwise you can just install qtwayland@6 to your
> profile and use ~/.guix-home/profile/lib/qt6/plugins in paths.

Neither approach succeeded for me. What am I doing wrong...
```sh
$ ls $qtw
platforms/  wayland-graphics-integration-client/  
wayland-shell-integration/
wayland-decoration-client/  wayland-graphics-integration-server/

$ ls $qtw/platforms
libqwayland-egl.so  libqwayland-generic.so

$ qtw=/home/bumble/.guix-home/profile/lib/qt6/plugins; QT_PLUGIN_PATH=$qtw; 
QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms; qutebrowser -s qt.force_platform 
wayland
23:00:47 WARNING: Could not find the Qt platform plugin "wayland" in ""
23:00:47 CRITICAL: This application failed to start because no Qt platform 
plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: offscreen, vnc, minimal, xcb, vkkhrdisplay, 
linuxfb, minimalegl, eglfs.

Fatal Python error: Aborted

Current thread 0x7f7b99434740 (most recent call first):
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py",
 line 545 in __init__
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py",
 line 80 in run
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/qutebrowser.py",
 line 231 in main
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/bin/.qutebrowser-real",
 line 33 in 

Extension modules: PyQt6.QtCore, PyQt6.QtGui, PyQt6.QtWidgets, 
markupsafe._speedups, yaml._yaml, PyQt6.QtNetwork, PyQt6.QtQml, PyQt6.QtOpenGL, 
PyQt6.QtDBus, PyQt6.QtPrintSupport, PyQt6.QtWebChannel, PyQt6.QtWebEngineCore, 
PyQt6.QtWebEngineWidgets, PyQt6.QtSql (total: 14)
```





bug#68415: User's shepherd services defined in guix home config can not start after guix pull.

2024-01-15 Thread Sergey Trofimov

Feng Shu  writes:

After I guix pull, services defined in guix home config can no 
start:


-
服务 root 已启动。
WARNING: Use of `load' in declarative module (#{ g117}#).  Add 
#:declarative? #f to your define-module invocation.

unbound-variable(#f "Unbound variable: ~S" (service) #f)

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
Creating XDG user directories... done
Comparing 
/gnu/store/bfkgfz1sm9q75jyn56pav2kmwl48i7w8-home/profile/share/fonts 
and
  /gnu/store/bfkgfz1sm9q75jyn56pav2kmwl48i7w8-home/profile/share/fonts... 
  done (same)

Evaluating on-change gexps.

---

When I run command: herd status, show error:

feng@Guix ~$ herd status
error: connect: /run/user/1000/shepherd/socket: No such file or 
directory


Have you tried debugging it? Is your home shepherd running? Do you 
see shepherd mentions in ~/.guix-home/on-first-login?

Have you tried restarting your system?





bug#68476: Shepherd stops responding if you set the time less than the current one

2024-01-15 Thread Sergey Trofimov

Aleksandr Vityazev  writes:


Hi,

I have running shepherd version 0.10.3 for the system and the 
user.  My
current time is Mon Jan 15 06:30:52 PM MSK 2024, if I set the 
time

less than the current one, both shepherds stop responding.

I set the time like this:
sudo date --set='20240115 18:00'


It's a known problem, see https://issues.guix.gnu.org/66684





bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread Sergey Trofimov
chris  writes:

> On  1月15日 月, Josselin Poiret wrote:
>> Hi chris,
>>
>> chris  writes:
>>
>> > Related to https://issues.guix.gnu.org/67289#7
>> >
>> > Here is the qutebrowser 3 process shell output. Would anyone recommend a 
>> > solution?
>> > ```
>> > $ qutebrowser
>> > 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""
>>
>> Have you installed qt-wayland?  Are you setting QT_QPA_PLATFORM
>> anywhere?
>
> Hey Josselin,
>
> I've tried installing qtwayland through guix home by specifying "qtwayland" in
> my home config file. QT_QPA_PLATFORM is specified in my home config this way
>

Here you go:
```sh
qtw=$(guix build qtwayland@6)/lib/qt6/plugins
QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser -s 
qt.force_platform wayland
```

Maybe a qutebrowser-wayland package variant should be defined to do the
required wrapping. Otherwise you can just install qtwayland@6 to your
profile and use ~/.guix-home/profile/lib/qt6/plugins in paths.





bug#67475: Close issue

2024-01-15 Thread Daniel K
Trying to close this issue.


bug#68476: Shepherd stops responding if you set the time less than the current one

2024-01-15 Thread Aleksandr Vityazev via Bug reports for GNU Guix


Hi,

I have running shepherd version 0.10.3 for the system and the user.  My
current time is Mon Jan 15 06:30:52 PM MSK 2024, if I set the time
less than the current one, both shepherds stop responding.

I set the time like this:
sudo date --set='20240115 18:00'

-- 
Best regards,
Aleksandr Vityazev





bug#68478: Guix System: pcaudiolib-1.1 expected string `Derive(['

2024-01-15 Thread Daniel Khodabakhsh
Have a Guix System with minimal modifications (just added the
spice-vdagent service because I'm using this in QEMU).
In the latest `guix pull` + `sudo guix system reconfigure
~/configuration.scm`. I get the following error:

guix system: error: error parsing derivation
`/gnu/store/4xz1998qw8niax3pi0lsbwxfl7dfrpil-pcaudiolib-1.1-checkout.drv':
expected string `Derive(['

Tried running `guix gc` but this didn't fix it.
Is this an issue with my system? Or an issue with the package itself?





bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread chris
On  1月15日 月, Josselin Poiret wrote:
> Hi chris, 
> 
> chris  writes:
> 
> > Related to https://issues.guix.gnu.org/67289#7
> >
> > Here is the qutebrowser 3 process shell output. Would anyone recommend a 
> > solution?
> > ```
> > $ qutebrowser
> > 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""
> 
> Have you installed qt-wayland?  Are you setting QT_QPA_PLATFORM
> anywhere?

Hey Josselin,

I've tried installing qtwayland through guix home by specifying "qtwayland" in 
my home config file. QT_QPA_PLATFORM is specified in my home config this way
```
(simple-service 'env-vars home-environment-variables-service-type
   '(("EDITOR" . "emacs")
 ("OPENER" . "sh.opener.sh")
 ("BROWSER" . "qutebrowser")
 ("GTK_IM_MODULE" . "fcitx")
 ("QT_IM_MODULE" . "fcitx")
 ("XMODIFIERS" . "@im=fcitx")
 ("QT_QPA_PLATFORM" . "wayland")
 ("QT_SCALE_FACTOR" . "1")
 ("XDG_SESSION_TYPE" . "wayland")
 ("XDG_SESSION_DESKTOP" . "sway")
 ("XDG_CURRENT_DESKTOP" . "sway")
 ("DESKTOP_SESSION" . "sway")
 ("LIBSEAT_BACKEND" . "seatd")))
```

QT_QPA_PLATFORM prints at the shell this way
```
$ echo $QT_QPA_PLATFORM
wayland
```

I tried changing "qtwayland" to "qtwayland@6.5" in my home config and 
reconfiguring home. I've also tried installing qtwayland without guix home 
using "guix install qtwayland" but those did not resolve the issue.

I can try any suggestion and if it doesn't work, revert back using guix home 
switch-generation





bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

2024-01-15 Thread Collin J. Doering
Excellent! Confirmed latest version 1.2.0-2.7bcd3d0 solves the issue. Also, 
fwiw I was not on a foreign distro.

Also, thanks for noting that cuirass also is a channel, so in the future I 
could simply use it directly for upstream changes.

Best wishes!

On 15 Jan 2024 at 10:40, Ludovic Courtès  wrote:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and
>> b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when
>> building in local build mode that most likely explain what you were
>> observing.
>
> If you run ‘guix pull’ now, you’ll get version 1.2.0-2.7bcd3d0 of the
> ‘cuirass’ package, which includes the fixes above.
>
> I’m tentatively closing this issue but please do let me know if you
> notice any problems.
>
> Thanks,
> Ludo’.


-- 
Collin J. Doering

http://rekahsoft.ca
http://blog.rekahsoft.ca
http://git.rekahsoft.ca


signature.asc
Description: PGP signature


bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread Josselin Poiret via Bug reports for GNU Guix
Hi chris, 

chris  writes:

> Related to https://issues.guix.gnu.org/67289#7
>
> Here is the qutebrowser 3 process shell output. Would anyone recommend a 
> solution?
> ```
> $ qutebrowser
> 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""

Have you installed qt-wayland?  Are you setting QT_QPA_PLATFORM
anywhere?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature


bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

2024-01-15 Thread Haugen, Kjetil
[AMD Official Use Only - General]

Thanks, Ludovic:

After upgrading, builds are now executing for me ...

> From: Ludovic Courtès 

> If you run ‘guix pull’ now, you’ll get version 1.2.0-2.7bcd3d0 of the 
> ‘cuirass’ package, which includes the fixes above.
> I’m tentatively closing this issue but please do let me know if you notice 
> any problems.



bug#68483: Qutebrowser QT platform plugin could not be initialized

2024-01-15 Thread chris
Related to https://issues.guix.gnu.org/67289#7

Here is the qutebrowser 3 process shell output. Would anyone recommend a 
solution?
```
$ qutebrowser
20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""
20:40:33 CRITICAL: This application failed to start because no Qt platform 
plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: offscreen, vnc, minimal, xcb, vkkhrdisplay, 
linuxfb, minimalegl, eglfs.

Fatal Python error: Aborted

Current thread 0x7f36c07e6740 (most recent call first):
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py",
 line 545 in __init__
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py",
 line 80 in run
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/qutebrowser.py",
 line 231 in main
  File 
"/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/bin/.qutebrowser-real",
 line 33 in 

Extension modules: PyQt6.QtCore, PyQt6.QtGui, PyQt6.QtWidgets, 
markupsafe._speedups, yaml._yaml, PyQt6.QtNetwork, PyQt6.QtQml, PyQt6.QtOpenGL, 
PyQt6.QtDBus, PyQt6.QtPrintSupport, PyQt6.QtWebChannel, PyQt6.QtWebEngineCore, 
PyQt6.QtWebEngineWidgets, PyQt6.QtSql (total: 14)
```





bug#68413: Ungexp doesn't work on deep lists

2024-01-15 Thread Josselin Poiret via Bug reports for GNU Guix
Hi Ludo,

Ludovic Courtès  writes:

> Actually, what bug are we talking about?  It seems to work for me with
> this example:
>
> --8<---cut here---start->8---
> scheme@(guile-user)> (define packages `(("coreutils" ,coreutils) ("make" 
> ,gnu-make)))
> scheme@(guile-user)> ,build (scheme-file "foo" #~(begin '#$packages))
> building /gnu/store/lq9gvbilv0y2nph00zxk6bn3lvcgdxqq-foo.drv...
> $7 = "/gnu/store/9ryh6v80jvjv3kwx0q782h26h9gbaclj-foo"
> scheme@(guile-user)> (call-with-input-file $7 get-string-all)
> $8 = "(begin (quote ((\"coreutils\" 
> \"/gnu/store/mppp9hwxizx9g9pikwcvvshb2ffxyq7p-coreutils-9.1\") (\"make\" 
> \"/gnu/store/9fadhs5qmwl5x7f669a0v39b3ryrmmf1-make-4.3\""
> --8<---cut here---end--->8---
>
> One of the design decisions for gexps was to ensure that substituting a
> file-like object by its file name would be O(1) in most cases.
>
> Substitution in lists as in the example above is supported, but
> primarily for backward compatibility.  It should be avoided when
> possible because it’s inefficient: ‘gexp->sexp’ needs to traverse the
> whole list/tree in search of potential candidates.

Notice that OP's example uses `(("thing" . ,package)), ie. lists of
pairs and not lists of lists, as in your case!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature


bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests

2024-01-15 Thread Jean-Pierre De Jesus Diaz via Bug reports for GNU Guix
The package at the guix-past channel does not pass the tests at
`tests/cms-test.pl'
file.  It fails with the following error:

>From the build log:

...
CMS consistency test
/gnu/store/lj75fc25zx2y9pqvfp95la84rdhlj4f8-perl-5.36.0/bin/perl cms-test.pl
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: verify error
```

And the from the error file that the test writes:

$ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err
Verification failure
140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate
verify error:pk7_smime.c:335:Verify error:certificate has expired

My guix description is:

Generation 74Jan 15 2024 12:28:39(current)
  guix 162d6a2
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 162d6a2fdd6af13272967c77347a54934ecb45e6
  guix-past 0e8c1ea
repository URL: https://gitlab.inria.fr/guix-hpc/guix-past
branch: master
commit: 0e8c1eae3efd34ab291fc6a4b69b767683488bb9

--
Jean-Pierre De Jesus DIAZ
Foundation Devices, Inc.


spxpvzpamzndlggz8xd4d79vis312d-openssl-1.0.2u.drv.gz
Description: application/gzip


bug#68053: Docker 20.10.25 fails test on aarch64

2024-01-15 Thread Giovanni Biscuolo


Fixed in .

-- 
Giovanni Biscuolo

Xelera IT Infrastructures





bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

2024-01-15 Thread Tanguy LE CARROUR
Hi,

I've just experienced the problem first hand:
https://lists.gnu.org/archive/html/help-guix/2024-01/msg00091.html

Nils suggested to set the `PATH` environment variable, but 1) I have no
clue how to do that  and 2) it is not exactly the behaviour I would
expect from a home service.

Has anything been decided?

Regards,

-- 
Tanguy





bug#68413: Ungexp doesn't work on deep lists

2024-01-15 Thread Ludovic Courtès
Hi,

Josselin Poiret  skribis:

> Justin Veilleux  writes:
>
>>> (define packages
>>> (list
>>>  (cons "coreutils" coreutils)
>>>  (cons "make" gnu-make)
>>>  ...))
>>>
>>> #~(for-each
>>>(lambda (f)
>>>  ... do-something)
>>>'#$packages)
>>
>> If I send a patch to "fix" this, will it be usefull or is there a reason
>> for this behavior?
>
> I think IMO that it's a bug, but it's also quite tricky to properly
> traverse deep structures like this.  The bug comes from the fact that in
> gexp->sexp, we traverse lists by matching the reference with (refs ...),
> but that doesn't match if the reference is a pair instead.  Then, it
> tries to match with ($  (? self-quoting? x)), which does
> match since self-quoting? apparently returns #t on a pair, whether or
> not its constituents are also self-quoting.

Actually, what bug are we talking about?  It seems to work for me with
this example:

--8<---cut here---start->8---
scheme@(guile-user)> (define packages `(("coreutils" ,coreutils) ("make" 
,gnu-make)))
scheme@(guile-user)> ,build (scheme-file "foo" #~(begin '#$packages))
building /gnu/store/lq9gvbilv0y2nph00zxk6bn3lvcgdxqq-foo.drv...
$7 = "/gnu/store/9ryh6v80jvjv3kwx0q782h26h9gbaclj-foo"
scheme@(guile-user)> (call-with-input-file $7 get-string-all)
$8 = "(begin (quote ((\"coreutils\" 
\"/gnu/store/mppp9hwxizx9g9pikwcvvshb2ffxyq7p-coreutils-9.1\") (\"make\" 
\"/gnu/store/9fadhs5qmwl5x7f669a0v39b3ryrmmf1-make-4.3\""
--8<---cut here---end--->8---

One of the design decisions for gexps was to ensure that substituting a
file-like object by its file name would be O(1) in most cases.

Substitution in lists as in the example above is supported, but
primarily for backward compatibility.  It should be avoided when
possible because it’s inefficient: ‘gexp->sexp’ needs to traverse the
whole list/tree in search of potential candidates.

Thanks,
Ludo’.





bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

2024-01-15 Thread Ludovic Courtès
Hi,

Ludovic Courtès  skribis:

> Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and
> b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when
> building in local build mode that most likely explain what you were
> observing.

If you run ‘guix pull’ now, you’ll get version 1.2.0-2.7bcd3d0 of the
‘cuirass’ package, which includes the fixes above.

I’m tentatively closing this issue but please do let me know if you
notice any problems.

Thanks,
Ludo’.





bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

2024-01-15 Thread Ludovic Courtès
Hi,

Maxim Cournoyer  skribis:

> Simon Tournier  writes:
>
>> Hi Inria’s folks, :-)
>>
>> On Sat, 02 Dec 2023 at 18:13, Maxim Cournoyer  
>> wrote:
>>
>>> I'd rather we try it with a few more software such as 'dnf' to narrow it
>>> down to just 'yum', or some other issues in our Guix-generated RPM.
>>
>> have you tried with ’dnf’?  Is it similarly slow as ’yum’?
>
> I've tried it myself, and it was fast.  yum is an alias that invokes dnf
> even on an old obsolete Fedora 37 VM I had available.
>
> We could mention that other package managers than yum should be
> preferred in a "@quotation Note", due to a performance problem when
> handling modern RPMs as those made by Guix; or we could close this and
> wait for yum to have become completely irrelevant (which seems like in a
> year or so, last I checked the RHEL end-of-life dates).
>
> Is someone volunteering to add the note?  Or should we close this?

Yeah maybe let’s just a short note warning against old versions of ‘yum’
and close this issue.

Thanks for following up!

Ludo’.