bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Ricardo Wurmus]

Hi Mark,

> However, in both EWW and Lynx, the embedded patches are rendered
> double-spaced, i.e. there are empty lines inserted between every two
> adjacent lines of every patch.  I guess that's because Mumi wraps each
> individual line within its own 'pre' and 'div' elements, instead of
> putting the entire patch within a single 'pre' element.

It does indeed wrap each line, because otherwise we can’t style the
lines e.g. to highlight additions with green and deletions with red.

People who use Emacs anyway will have Emacs apply its own fontification,
so that’s of no use to them.  But people who use Emacs would probably
want to use the Emacs interface to Debbugs anyway.

The extra spacing between lines as seen in EWW is not intentional, and I
did not see this in my local tests.  (Perhaps different patches render
differently in EWW?)  I’ll add this to my TODO list.

> As a result, for users of EWW or Lynx, Mumi is still far inferior to the
> web interface of Debian's bug tracking system (used by bugs.gnu.org).

Note that you can also view the raw messages.  Every message part has
its own link; following that link you can see the unstyled plain text
rendering.

There’s nothing wrong with the sample HTML you posted.  Yes, mumi’s is
more verbose than just wrapping text in … because we need
more markup to tell browsers how to style the patch.

-- 
Ricardo

bug#52139: jupyter trying to modify /gnu/store

[Lars-Dominik Braun]

Hi Ludo,

> But precisely: as Alexander wrote, when JUPYTER_CONFIG_DIR points to the
> store, jupyterlab cannot drop a config file there.  Or am I missing
> something?
sorry, my message was unclear here. The config file is written at
build time.

> BTW, if JUPYTER_CONFIG_DIR is meant to contain a directory name, as
> opposed to a colon-separated search path, we should make this change:
Looking at the documentation[1] again this is correct, but I feel we
should use JUPYTER_CONFIG_PATH instead, because it supports
colon-delimited entries, see attached patch. However that does not get
rid of error messages like these, when trying to use Settings→JupyterLab
Theme for example:

[W 08:10:14.476 LabApp] 500 PUT /lab/api/workspaces/lab?1639383014500 
(127.0.0.1): [Errno 30] Read-only file system: 
'/gnu/store/8q7wdpdddfqh46plbbsa3rwci5092n5y-profile/etc/jupyter/lab'

So it seems that JUPYTER_CONFIG_PATH overrides the default
JUPYTER_CONFIG_DIR, when the latter is not set. Or maybe guix-science’s
jupyterlab is simply too old – not sure right now.

Cheers,
Lars

[1] https://jupyter.readthedocs.io/en/latest/use/jupyter-directories.html
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index db2ab8e5f0..450d17208f 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -8478,7 +8478,7 @@ (define-public python-jupyter-core
 ;; search paths.
 (native-search-paths
  (list (search-path-specification
-(variable "JUPYTER_CONFIG_DIR")
+(variable "JUPYTER_CONFIG_PATH")
 (files '("etc/jupyter")))
(search-path-specification
 (variable "JUPYTER_PATH")
@@ -12145,8 +12145,6 @@ (define-public python-nbconvert
  (when tests?
;; Some tests invoke the installed nbconvert binary.
(add-installed-pythonpath inputs outputs)
-   ;; Tries to write to this path.
-   (unsetenv "JUPYTER_CONFIG_DIR")
;; Tests depend on templates installed to output.
(setenv "JUPYTER_PATH"
(string-append
@@ -12254,6 +12252,8 @@ (define-public python-notebook
;; Some tests do not expect all files to be installed in the
;; same directory, but JUPYTER_PATH contains multiple entries.
(unsetenv "JUPYTER_PATH")
+   ;; Interferes with tests that check paths.
+   (unsetenv "JUPYTER_CONFIG_PATH")
;; Some tests need HOME
(setenv "HOME" "/tmp")
(with-directory-excursion "/tmp"

bug#52462: track ocaml support on different architectures

[Efraim Flashner]

It seems worth it to open a bug to track the current support of camlboot
on different architectures.

x86_64-linuxsupported (with substitutes)
i686-linux  supported (with substitutes)
aarch64-linux   unknown
armhf-linux unknown
powerpc64le-linux   unknown

I test built camlboot on my aarch64-linux board, it stopped compilation
at ~55 hours with Signal 9 (OOM). 2GB RAM, 2GB swap.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#52269: [core-updates-frozen] sitecustomize.py does not honor .pth files

[Ludovic Courtès]

Hello Maxim,

Maxim Cournoyer  skribis:

>>From 762357609270ab016236d22999ae5cfc3fe4ff28 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Fri, 3 Dec 2021 22:36:26 -0500
> Subject: [PATCH] sitecustomize.py: Honor .pth files.
>
> Fixes .
>
> * gnu/packages/aux-files/python/sitecustomize.py: Use site.addsitedirs to add
> the site directories; this takes care of the .pth files.  Make sure the added
> items still appear before Python's own 'site-packages' directory.

I had completely overlooked this patch.

Lars had useful comments about it.

Do we need to address this before we merge ‘core-updates-frozen’ into
‘master’?

If so, what changes need to be made to the patch before it can be
applied?

TIA!

Ludo’.

bug#52464: Backtrace during substitution

[Lars-Dominik Braun]

Hi,

I saw the following backtrace on core-updates-frozen, commit
869d69ad3248288ffe30264f5e5bd760792ca758, while fetching substitutes:

---snip---
substituting 
/gnu/store/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-image-0.18.1.tar.gz...
downloading from 
https://ci.guix.gnu.org/nar/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-image-0.18.1.tar.gz
 ...
 scikit-image-0.18.1.tar.gz  28.3MiB 8.42GiB/s 00:00 [  ]  
89.9%Backtrace:
  19 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 18 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 17 (_ #(#(#)))
In guix/ui.scm:
   2206:7 16 (run-guix . _)
  2169:10 15 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
802:4 13 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   658:37 11 (thunk)
   1320:8 10 (call-with-build-handler _ _)
   1320:8  9 (call-with-build-handler # …)
In guix/scripts/build.scm:
   699:26  8 (_)
In guix/store.scm:
  1421:15  7 (_ # _ _)
   759:13  6 (process-stderr _ _)
In unknown file:
   5 (display "@ substituter-succeeded /gnu/store/xbxrx9yqg…" …)
In guix/status.scm:
   725:16  4 (write! _ _ _)
639:6  3 (_ (download-progress "/gnu/store/xbxrx9yqgqbv6949g…" …) …)
In guix/progress.scm:
   223:17  2 (display-download-progress "scikit-image-0.18.1.tar.g@" …)
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 =: Wrong type argument in position 1: #f
---snap---

However I cannot reproduce it. My guix-daemon is at
efd4d36a283acf5441159d4babf25d2054776579 (master).

Cheers,
Lars

bug#52269: [core-updates-frozen] sitecustomize.py does not honor .pth files

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hello Maxim,
>
> Maxim Cournoyer  skribis:
>
>>>From 762357609270ab016236d22999ae5cfc3fe4ff28 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer 
>> Date: Fri, 3 Dec 2021 22:36:26 -0500
>> Subject: [PATCH] sitecustomize.py: Honor .pth files.
>>
>> Fixes .
>>
>> * gnu/packages/aux-files/python/sitecustomize.py: Use site.addsitedirs to add
>> the site directories; this takes care of the .pth files.  Make sure the added
>> items still appear before Python's own 'site-packages' directory.
>
> I had completely overlooked this patch.
>
> Lars had useful comments about it.
>
> Do we need to address this before we merge ‘core-updates-frozen’ into
> ‘master’?

The only reason I'm on the fence about it is that it causes a big
rebuild.  But rebuilding aside, I believe it'd be nice to have it in.
I've only spotted one package affected so far (python-pdbpp), but there
may be others.

> If so, what changes need to be made to the patch before it can be
> applied?

I'll try having a look today.

Thanks,

Maxim

bug#52464: Backtrace during substitution

[Maxime Devos]

Hi,

Lars-Dominik Braun schreef op ma 13-12-2021 om 13:31 [+0100]:
> substituting /gnu/store/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-
> image-0.18.1.tar.gz...
> downloading from 
> https://ci.guix.gnu.org/nar/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-image-0.18.1.tar.gz
>  ...
>  scikit-image-0.18.1.tar.gz  28.3MiB 8.42GiB/s 00:00
> [  ]  89.9%Backtrace:
>  [...]
> In guix/progress.scm:
>    223:17  2 (display-download-progress "scikit-image-0.18.1.tar.g@"
> …)
> 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 =: Wrong type argument in position 1: #f

I guess that means 'transferred' is #false somehow.
Looking at guix/status.scm, maybe the following is important:

>(('download-progress item uri
> (= string->number size)
> (= string->number transferred))

string->number returns #f if the input is malformed, so I guess that
is what happens. I don't know _how_ that happens though.

Detecting #f somewhere and emitting a warning or error like
‘warning: ‘the malformed string’, representing the number of
transferred bytes, is malformed’ would be better. Fixing the underlying
error would be ideal.

I think I've seen this reported before, though I cannot find it again.

Greetings,
Maxime.

bug#52375: Both pages load fine for me

[Vivien Kraus via Bug reports for GNU Guix]

Dear guix,

As a guix home user on a GNOME guix system, both pages work in epiphany
(private mode) for me.

My graphics card is reported as "llvmpipe (LLVM 11.0.0, 256 bits)" by
GNOME.

Vivien


signature.asc
Description: This is a digitally signed message part

bug#52269: [core-updates-frozen] sitecustomize.py does not honor .pth files

[Maxim Cournoyer]

Hello,

Lars-Dominik Braun  writes:

> Hi Maxim,
>
>> +if not matching_sites:
>> +exit(0)
> are you sure about using `exit()` here? sitecustomize.py is imported
> during startup and this would simply quit the Python interpreter if
> GUIX_PYTHONPATH is not set, wouldn’t it? (Can’t test the change
> unfortunately, because it’s a massive rebuild.)

You can test it by placing the new sitecustomize.py file in the current
directory, and then:

$ guix shell python-wrapper python-pdbpp

[env]$ $ PYTHONPATH=. GUIX_PYTHONPATH= python sample.py

where sample.py contains something like:

--8<---cut here---start->8---
__import__("pdb").set_trace()

print('hello')
--8<---cut here---end--->8---

Indeed, when GUIX_PYTHONPATH is unset or matching_sites is empty, it
exit with 0 as you expected:

--8<---cut here---start->8---
$ PYTHONPATH=. GUIX_PYTHONPATH= python sample.py
Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File 
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/site.py",
 line 589, in 
main()
  File 
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/site.py",
 line 582, in main
execsitecustomize()
  File 
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/site.py",
 line 521, in execsitecustomize
import sitecustomize
  File "/home/maxim/proj/kinova/kts_robot/sitecustomize.py", line 52, in 

exit(0)
  File 
"/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/lib/python3.9/_sitebuiltins.py",
 line 26, in __call__
raise SystemExit(code)
SystemExit: 0
--8<---cut here---end--->8---

After the proposed change:

--8<---cut here---start->8---
[env]$ PYTHONPATH=. GUIX_PYTHONPATH= python sample.py
> /home/maxim/proj/kinova/kts_robot/sample.py(5)()
-> print('hello')
--8<---cut here---end--->8---

There's no longer pdbpp because of clearing GUIX_PYTHONPATH but at least
it doesn't crash :-).

>> +# Move the entries that were appended to sys.path in front of Python's own
>> +# site-packages directory.  This enables Guix packages to override Python's
>> +# bundled packages, such as 'pip'.
>> +python_site_index = sys.path.index(python_site)
>> +new_site_start_index = sys.path.index(matching_sites[0])
>> +if python_site_index < new_site_start_index:
>> +sys.path = (sys.path[:python_site_index]
>> ++ sys.path[new_site_start_index:]
>> ++ sys.path[python_site_index:new_site_start_index])
> This is unrelated to the pdb issue, right? I see that it’s necessary
> right now, but as suggested in #46848 I’d prefer unbundling
> setuptools/pip from python. (I’ll send a v3 of the patchset at some
> point.)

Previously the Guix-provided paths were directly spliced at the right
location; now using 'site.addsitedir' simply appends them, which
requires manual fiddling afterward.

I agree that after it's un-bundled it shouldn't be necessary anymore, but
let's keep this change for core-updates along work on the 517
python-build-system (I'll try having a look to it after the next release
it out -- ping me otherwise).

Thank you,

Maxim
>From 49f0d2a493b868b9414ea10c7a676cf8404e1bca Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Fri, 3 Dec 2021 22:36:26 -0500
Subject: [PATCH] sitecustomize.py: Honor .pth files.

Fixes .

* gnu/packages/aux-files/python/sitecustomize.py: Use site.addsitedirs to add
the site directories; this takes care of the .pth files.  Make sure the added
items still appear before Python's own 'site-packages' directory.
---
 .../aux-files/python/sitecustomize.py | 22 ++-
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/aux-files/python/sitecustomize.py b/gnu/packages/aux-files/python/sitecustomize.py
index 71e328b9ac..e2348e0356 100644
--- a/gnu/packages/aux-files/python/sitecustomize.py
+++ b/gnu/packages/aux-files/python/sitecustomize.py
@@ -18,6 +18,7 @@
 # along with GNU Guix.  If not, see .
 
 import os
+import site
 import sys
 
 # Commentary:
@@ -47,9 +48,18 @@ all_sites_norm = [os.path.normpath(p) for p in all_sites_raw]
 matching_sites = [p for p in all_sites_norm
   if p.endswith(site_packages_prefix)]
 
-# Insert sites matching the current version into sys.path, right before
-# Python's own site.  This way, the user can override the libraries provided
-# by Python itself.
-sys_path_absolute = [os.path.realpath(p) for p in sys.path]
-index = sys_path_absolute.index(python_site)
-sys.path[index:index] = matching_sites
+if matching_sites:
+# Deduplicate the entries, append them to sys.path, and handle any
+# .pth files they contain.
+for 

bug#51787: GC takes more than 9 hours on berlin

[Christian Thäter]

On 2021-12-12 18:09, Mathieu Othacehe wrote:

>Hey,
>
>> OK, thanks. Looks it just finished removing the trash directory
>> content. I started a GC process from my session to monitor it
>> closely.  
>
>Daily GC recap:
>
>* The GC process I started yesterday, did collect 5.5TiB in
>  approximately 24 hours, that are now in the /gnu/store/trash
>  directory.
>  
>* The /gnu/store/trash directory contains 288910 entries. If those
>items
>  are removed at the same rate than on the previous days, it will take
>  days/months to delete them all.
>
>* I noticed that the upstream Nix GC process can now operate without
>  locking. I think it shouldn't be too hard to port it to our fork or
>  maybe rewrite the process in Guile while we are at it.
>
>  That will not fix the slow hard-drives issues though.

While discussing this issue on IRC I came up with some idea:

'rmrfd' a system daemon that deletes huge trees in the background where
'-rf' stands for --really --fast :)

Actually this is an use case that happens for on my backup system too.
With that idea I just started coding and ran some experiments. For me
this looks quite feasible now and I will continue next days on this
small project. Any feedback or help would be welcomed!

The initial ideas and experiments are at https://github.com/cehteh/rmrfd

Note that the important part is that it will put some efforts into
freeing as much space as possible at begin of the freeing process,
Unlike just 'rm -rf' where space may only freed really late when the
last link count of the data goes to zero.

Cheers
Christian

bug#51787: GC takes more than 9 hours on berlin

[Christian Thäter]

On 2021-12-12 18:09, Mathieu Othacehe wrote:

>Hey,
>
>> OK, thanks. Looks it just finished removing the trash directory
>> content. I started a GC process from my session to monitor it
>> closely.  
>
>Daily GC recap:
>
>* The GC process I started yesterday, did collect 5.5TiB in
>  approximately 24 hours, that are now in the /gnu/store/trash
>  directory.
>  
>* The /gnu/store/trash directory contains 288910 entries. If those
>items
>  are removed at the same rate than on the previous days, it will take
>  days/months to delete them all.

On another note: when 'guix gc' determines that objects are dead, are
they really dead then or can it be that they are 'locally' dead but in
case the store serves as substitutes/offload server some external
clients may still request dead objects?

In the either case would make sense to run the GC more frequently, but
for the later case a --min-age option to preserve objects that just
died recently could be helping. Further it may consider the atime of
objects for removal.

And finally while I had this Idea: You mount the
guix store with 'relatime' or 'nodiratme', if not that could explain
the slow deletion process as well!

Christian



>
>* I noticed that the upstream Nix GC process can now operate without
>  locking. I think it shouldn't be too hard to port it to our fork or
>  maybe rewrite the process in Guile while we are at it.
>
>  That will not fix the slow hard-drives issues though.
>
>Thanks,
>
>Mathieu
>
>
>

bug#47030: blueman fails to find a dbus service file

[Grigory Shepelev]

Installed guix a few weeks ago on my desktop PC and just yesterday on my
laptop (thinkpad L13). Having the same problem on both of them.

Gnome's default bluetooth "app" doesn't work.

After having the same config as in your example I can launch
blueman-manager and connect to my bluetooth sound system. It makes a sound
as if it's connected and displays itself as connected but I can't pick it
as an output device in gnome's setting "sound" tab.

How have you dealt with this?

(nonnative in english, sorry for possible mistakes)

bug#47030: blueman fails to find a dbus service file

[Grigory Shepelev]

Bluetoothctl also works. So the problem is not bluetooth itself but it's
"connection" with audio in gnome's default way.

вс, 12 дек. 2021 г. в 10:18, Grigory Shepelev :

> Installed guix a few weeks ago on my desktop PC and just yesterday on my
> laptop (thinkpad L13). Having the same problem on both of them.
>
> Gnome's default bluetooth "app" doesn't work.
>
> After having the same config as in your example I can launch
> blueman-manager and connect to my bluetooth sound system. It makes a sound
> as if it's connected and displays itself as connected but I can't pick it
> as an output device in gnome's setting "sound" tab.
>
> How have you dealt with this?
>
> (nonnative in english, sorry for possible mistakes)
>