bug#61885: [PATCH] gnu: go-github-com-robfig-cron-1.2: Move to (gnu packages golang)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Winter,

Simon Tournier 写道：
Becaus (gnu packages golang) and (gnu packages check) use each 
other, this

  -^
   Typo

s/Becaus/Because I guess


Pushed as 997b93cc4a6deff54ebd854a716cca94095114bf with this fix. 
Thanks!


I'll close this bug now; the more general problem (and more 
work-arounds to it) are tracked in others.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61914: IceCat does not start with en_GB.utf8 locale

[Maxim Cournoyer]

Hello Timo,

(Please don't forget to keep the bug in CC so that our discussion
remains public so that anyone can jump in to help!)

Timo Wilken  writes:

> Hi Maxim,
>
> Thanks for your reply!
>
> What finally worked for me was the following:
>
> $ sed -i.bak
> 's|/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s|/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv|g'
> \
>   ~/.mozilla/icecat/vfc41hol.default/extensions.json \
>   ~/.mozilla/icecat/vfc41hol.default/addonStartup.json.lz4
>
> After running that, IceCat suddenly worked fine.
>
> No directory starting with /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s
> exists on my system.
>
> I guess that means the "guix gc" I did yesterday is to blame!

> There were lots of entries like the following in my extensions.json:
>
> "rootURI":"jar:file:///gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions/langpack...@icecat.mozilla.org.xpi!/",
>
> ...and then when guix gc deleted an old IceCat directory, these files
> were gone.

Interesting.  I would have expected that the language packs extensions,
which are shipped with icecat itself (they are in its application global
directory, under for example
/gnu/store/...-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions),
would have self-updated when the browser would have changed.

Perhaps it depends on the version string of icecat changing, or their
date stamp, which is purposefully set to 1970 for reproducibility.

Browsing about:config, I see:

--8<---cut here---start->8---
extensions.systemAddon.update.enabled   false
--8<---cut here---end--->8---

I wonder if this could make a different to be set to true instead.  It's
set to false by the makeicecat.sh script we run to transform the Firefox
source into GNU IceCat.  I guess we'll have to look at the source for
more clues as to how language pack updates are handled exactly.

-- 
Thanks,
Maxim

bug#61698: Incorrect Native *_PATH's when linux source is not a tarball.

[Maxim Cournoyer]

Hello Mitchell,

Mitchell Schmeisser  writes:

> This is a bit of a convoluted bug but here it goes. The title may not be
> entirely correct.
>
> When ~set-paths~ is called it adds all of the inputs to ~C_INCLUDE_PATH~
> and friends /except/ the source input.
>
> #+BEGIN_SRC scheme
> (define-public linux-zynq
>   (customize-linux #:name "linux-zynq"
>  #:linux linux-libre-5.15
>  #:source (package-source linux-xlnx-5.15.0)
>  #:defconfig "xilinx_zynq_defconfig"))
> #+END_SRC
>
> However, below is a snippet from the `set-paths` phase targeting 
> arm-linux-gnueabihf

[...]


> This only happens when source is a git repository, and only when
> building the kernel.
> When a tarball is used this does not happen because it is not a directory in 
> the store.

This has already been fixed on the core-updates branch [0], which is
scheduled for a merge in a not too distant future.  See commit
6454208222 ("build: gnu-build-system: Remove source from native
inputs.").

Closing.

-- 
Thanks,
Maxim

bug#61742: icecat.desktop show ??????????

[Maxim Cournoyer]

Hi Akib,

[...]

>> Interestingly, this older icecat in my store, at version 102.7.0 didn't
>> have that problem:
>>
>> cat 
>> /gnu/store/8x8pqbdykw9wpkc2ankxg6ccnqv82ca2-icecat-102.7.0-guix0-preview1/\
>>  share/applications/icecat.desktop
>>
>> [Desktop Entry]
>> Version=1.0
>> Name=GNU IceCat Web Browser
>> Name[ar]=متصفح الويب فَيَرفُكْس
>> Name[ast]=Restolador web GNU IceCat
>> Name[bn]=ফায়ারফক্স ওয়েব ব্রাউজার
>> Name[ca]=Navegador web GNU IceCat
>> Name[cs]=GNU IceCat Webový prohlížeč
>> Name[da]=GNU IceCat - internetbrowser
>> [...]
>
> The "Name[bn]" key is wrong, it contains "Firefox Web Browser" in
> Bengali, while it should be "GNU IceCat" (or something like that).

Thank you.  This problem exists upstream; the only transformations we do
in the desktop file definition are:

--8<---cut here---start->8---
  (add-after 'wrap-program 'install-desktop-entry
(lambda _
  ;; Install the '.desktop' file.
  (let* ((desktop-file 
"taskcluster/docker/icecat-snap/icecat.desktop")
 (applications (string-append #$output 
"/share/applications")))
(substitute* desktop-file
  (("^Exec=icecat") (string-append "Exec=" #$output 
"/bin/icecat"))
  (("IceCat")   "GNU IceCat")
  (("Icon=.*")  "Icon=icecat\n")
  (("NewWindow")"new-window")
  (("NewPrivateWindow") "new-private-window")
  (("StartupNotify=true")
   "StartupNotify=true\nStartupWMClass=Navigator"))
(install-file desktop-file applications
--8<---cut here---end--->8---

-- 
Thanks,
Maxim

bug#61742: icecat.desktop show ??????????

[Maxim Cournoyer]

Hi,

Christopher Baines  writes:

> Maxim Cournoyer  writes:
>
>> Interestingly, this older icecat in my store, at version 102.7.0 didn't
>> have that problem:
>
> You can bisect this by using
> https://data.guix.gnu.org/repository/1/branch/master/package/icecat/output-history
>
> I see this problem start to happen with
> /gnu/store/2a67f3c5lv14bq11vyyb6k2z2aw457nk-icecat-102.8.0-guix0-preview1
>
> So it's probably these changes here
> https://data.guix.gnu.org/compare?base_commit=636b771536b95d15a2fd68b468deeebac97d6bee&target_commit=d318ccc36308171a74b4863ea25a3dded05a2851
>

Thanks!  I investigated a bit, and found that the problem was caused by
the use of the trivial-build-system in the make-mozilla-with-l10n
procedure of (gnu packages gnuzilla), which doesn't install a UTF-8
locale.

It should be fixed with 89e5f3f3847b3bfd507ea9f0874a73f99a53cbf9 ("gnu:
make-mozilla-with-l10n: Use the copy-build-system.").

Thanks to everyone!

-- 
Maxim

bug#61343: bug#61574: bug#61343: bug#61574: [PATCH v2] scripts: repl: Extend REPL %load-path with all channels.

[Simon Tournier]

Hi,

I reopen the bug.

On jeu., 02 mars 2023 at 17:44, Andrew Tropin  wrote:

> Thank you for the patch, I also faced this problem and it seems this
> change doesn't fix it.

Indeed.  I have no clue what I messed up.  Since I removed the Git
worktree, I am not able to investigate the root of my mistake.  I
remember running with ’guix repl -q’ for avoiding spurious ~/.guile
configuration and I remember running “./pre-inst-env guix pull -p
/tmp/new” and checking.  Hum?!  Anyway!

My apologies.

Back to the issue:

   1. The patch does not tweak ’guix repl script.scm’ but only the
  interactive part – which also has the issue, I guess.

   2. The culprit seems (current-profile) which does not correctly load
  %package-module-path as the comment is suggesting,

;;   This in turn ensures that
;; (%package-module-path) will contain entries for the channels
;; available in the current profile.


Adding (gnu packages) as Josselin suggested but commenting
(current-profile) make channels available both for scripts and
interactive.  For instance this patch works, which means something is
buggy somewhere.

--8<---cut here---start->8---
1 file changed, 5 insertions(+), 2 deletions(-)
guix/scripts/repl.scm | 7 +--

modified   guix/scripts/repl.scm
@@ -22,6 +22,7 @@ (define-module (guix scripts repl)
   #:use-module (guix ui)
   #:use-module (guix scripts)
   #:use-module (guix repl)
+  #:use-module (gnu packages)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-37)
@@ -193,7 +194,8 @@ (define script
  ;; 'set-program-arguments'.  This in turn ensures that
  ;; (%package-module-path) will contain entries for the channels
  ;; available in the current profile.
- (current-profile)
+ (pk 'script)
+;(current-profile)
 
  (set-program-arguments script)
  (set-user-module)
@@ -211,7 +213,8 @@ (define script
   ((guile)
(save-module-excursion
 (lambda ()
-  (current-profile) ;Run (%package-module-path) as explained 
above.
+  (pk 'no-script)
+;(current-profile) ;Run 
(%package-module-path) as explained above.
   (set-user-module)
   ;; Do not exit repl on SIGINT.
   ((@@ (ice-9 top-repl) call-with-sigint)
--8<---cut here---end--->8---


Well, I have tried to debug by adding ’pk’ around but I often get error
when “Computing Guix derivation”.  Well, the test-error is a long
process here. :-)

As discussed in #42688 [1], instead of
1b179d7876f19f04009a2f9e248ac10711f4c660, the plain call to
(%package-module-path) – instead of (current-profile) – fixes the issue.

This patch works and avoids the full load of (gnu packages), I guess
twice. :-)

--8<---cut here---start->8---
1 file changed, 3 insertions(+), 3 deletions(-)
guix/scripts/repl.scm | 6 +++---

modified   guix/scripts/repl.scm
@@ -27,7 +27,7 @@ (define-module (guix scripts repl)
   #:use-module (srfi srfi-37)
   #:use-module (ice-9 match)
   #:use-module (rnrs bytevectors)
-  #:autoload   (guix describe) (current-profile)
+  #:autoload   (gnu packages) (%package-module-path)
   #:autoload   (system repl repl) (start-repl)
   #:autoload   (system repl server)
   (make-tcp-server-socket make-unix-domain-server-socket)
@@ -193,7 +193,7 @@ (define script
  ;; 'set-program-arguments'.  This in turn ensures that
  ;; (%package-module-path) will contain entries for the channels
  ;; available in the current profile.
- (current-profile)
+ (%package-module-path)
 
  (set-program-arguments script)
  (set-user-module)
@@ -211,7 +211,7 @@ (define script
   ((guile)
(save-module-excursion
 (lambda ()
-  (current-profile) ;Run (%package-module-path) as explained 
above.
+  (%package-module-path)
   (set-user-module)
   ;; Do not exit repl on SIGINT.
   ((@@ (ice-9 top-repl) call-with-sigint)
--8<---cut here---end--->8---


1: 


Cheers,
simon

bug#61742: icecat.desktop show ??????????

[Akib Azmain Turja via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hello,
>
> Maxim Cournoyer  writes:
>
>> Hi Feng,
>>
>> Maxim Cournoyer  writes:
>>
>>> Hi Feng,
>>>
>>> Feng Shu  writes:
>>>
 /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/share/applications/icecat.desktop

 [Desktop Entry]
 Version=1.0
 Name=GNU IceCat Web Browser
 Name[ar]=?? ?? 
 Name[ast]=Restolador web GNU IceCat
 Name[bn]=?? ??? 
 
 Name[ca]=Navegador web GNU IceCat
 Name[cs]=GNU IceCat Webov?? prohle??
 Name[da]=GNU IceCat - internetbrowser
 Name[el]= GNU IceCat
>>>
>>> [...]
>>>
>>> Sorry, what is the issue?  I don't understand.
>>
>> OK, these are actual '?' question marks characters; that's a problem!
>> Sorry for failing to understand the issue earlier.
>>
>> Perhaps the build environment of icecat would need locale support to
>> generate these correctly?
>
> Interestingly, this older icecat in my store, at version 102.7.0 didn't
> have that problem:
>
> cat 
> /gnu/store/8x8pqbdykw9wpkc2ankxg6ccnqv82ca2-icecat-102.7.0-guix0-preview1/\
>  share/applications/icecat.desktop
>
> [Desktop Entry]
> Version=1.0
> Name=GNU IceCat Web Browser
> Name[ar]=متصفح الويب فَيَرفُكْس
> Name[ast]=Restolador web GNU IceCat
> Name[bn]=ফায়ারফক্স ওয়েব ব্রাউজার
> Name[ca]=Navegador web GNU IceCat
> Name[cs]=GNU IceCat Webový prohlížeč
> Name[da]=GNU IceCat - internetbrowser
> [...]

The "Name[bn]" key is wrong, it contains "Firefox Web Browser" in
Bengali, while it should be "GNU IceCat" (or something like that).

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

bug#61690: Failure to mount /sys in nested ‘guix shell’ container

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> Maybe we could, but I must confess I’m totally clueless on this veth
> thing.  :-)
>
> What would this entail?  Hopefully guile-netlink can help?

So, a veth (Virtual Ethernet) device is basically a pipe but for network
devices: they're created in pairs, and any packet going through one end
is instantly received on the other end.  You can then transmit packets
between network namespaces.

One problem that totally slipped by me is that you need to be root to
create a veth device in the original namespace... Rootless containers
use slirp4netns, which is basically a userspace TCP/IP stack
communicating with a special network device in the new namespace (over
which you have complete rights). The situation might thus be a bit more
complicated, since we'd need another library/program as a dependency to
achieve this. I guess there's no best solution for now then :/

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#61690: Failure to mount /sys in nested ‘guix shell’ container

[Ludovic Courtès]

Hi Josselin,

Josselin Poiret  skribis:

> Ludovic Courtès  writes:
>
>> The reason for this bug seems to be given here:
>>
>>   https://github.com/nestybox/sysbox/issues/67#issuecomment-726285026
>>
>> It’s not clear whether there’s anything we can do, other than
>> recommending ‘-CN’ as well in the nested container.
>
> Couldn't we always create a new network namespace, but when -N is passed
> it also has a veth interface?  The one problem I can think of is that
> we'd need to either create one veth per interface in the parent
> namespace or let the user specify which interface should be shared.

Maybe we could, but I must confess I’m totally clueless on this veth
thing.  :-)

What would this entail?  Hopefully guile-netlink can help?

Thanks,
Ludo’.

bug#61885: bug#61911: error: mate-polkit: unbound variable

[Maxime Devos]

Op 02-03-2023 om 15:36 schreef Josselin Poiret:

Hi Maxime,

Maxime Devos  writes:


In unknown file:
 3 (primitive-load-path "gnu/packages/xfce" #)
In gnu/packages/xfce.scm:
1156:19  2 (_)
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:
error: mate-polkit: unbound variable


This is the same kind of issue as [1]: both xfce and mate require each
other (the second through mate -> freedesktop -> kde-frameworks ->
kde-plasma -> display-managers -> xfce), and depending on the order in
which they're loaded, mate-polkit-for-xfce might get defined before
mate-polkit is.  The solution I suggested there was to define the
variant in the same file as the original package, but here I'm not sure
if this is the right call.

In general, I'd much rather try to get rid of those pesky module cycles,
as they cause general headaches for guix pull.  I remember Julien
using (guix modules) to do some analysis at the Guix days, maybe we
could get some pointers on how to handle this specific situation?

WDYT?

[1] https://issues.guix.gnu.org/61885
(mid: f29b8bfe-a175-4128-8093-4a810681e...@winter.cafe)


I haven't gone to Guix days so I can't comment on that, but I'd like to 
note that there are some simple patches for breaking up lots of package 
cycles at  (*).  In particular, 
#:use-module -> #:autoload appears promising (^).


Basically, you can consider a module reference to be 'strong' if its of 
the form (define stuff (package (inherit reference)) ...), and 'weak' if 
its just a package input (or more generally, something thunked). 
'Strong' cycles are problematic, but 'weak' cycles should be resolvable 
by delaying loading the required modules until needed.


I don't know if these patches would solve this particular 'mate-polkit' 
issue -- if the 'mate -> freedesktop -> ... -> xfce' cycle is 'weak', 
something like those patches should work, but if it isn't, those patches 
would be insufficient.


(*) Beware of https://issues.guix.gnu.org/54539#63 though; looks like I 
made some mistakes in hurd.scm and image.scm.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#61742: icecat.desktop show ??????????

[Christopher Baines]

Maxim Cournoyer  writes:

> Interestingly, this older icecat in my store, at version 102.7.0 didn't
> have that problem:

You can bisect this by using
https://data.guix.gnu.org/repository/1/branch/master/package/icecat/output-history

I see this problem start to happen with
/gnu/store/2a67f3c5lv14bq11vyyb6k2z2aw457nk-icecat-102.8.0-guix0-preview1

So it's probably these changes here
https://data.guix.gnu.org/compare?base_commit=636b771536b95d15a2fd68b468deeebac97d6bee&target_commit=d318ccc36308171a74b4863ea25a3dded05a2851


signature.asc
Description: PGP signature

bug#61742: icecat.desktop show ??????????

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hi Feng,
>
> Maxim Cournoyer  writes:
>
>> Hi Feng,
>>
>> Feng Shu  writes:
>>
>>> /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/share/applications/icecat.desktop
>>>
>>> [Desktop Entry]
>>> Version=1.0
>>> Name=GNU IceCat Web Browser
>>> Name[ar]=?? ?? 
>>> Name[ast]=Restolador web GNU IceCat
>>> Name[bn]=?? ??? 
>>> 
>>> Name[ca]=Navegador web GNU IceCat
>>> Name[cs]=GNU IceCat Webov?? prohle??
>>> Name[da]=GNU IceCat - internetbrowser
>>> Name[el]= GNU IceCat
>>
>> [...]
>>
>> Sorry, what is the issue?  I don't understand.
>
> OK, these are actual '?' question marks characters; that's a problem!
> Sorry for failing to understand the issue earlier.
>
> Perhaps the build environment of icecat would need locale support to
> generate these correctly?

Interestingly, this older icecat in my store, at version 102.7.0 didn't
have that problem:

cat /gnu/store/8x8pqbdykw9wpkc2ankxg6ccnqv82ca2-icecat-102.7.0-guix0-preview1/\
 share/applications/icecat.desktop

--8<---cut here---start->8---
[Desktop Entry]
Version=1.0
Name=GNU IceCat Web Browser
Name[ar]=متصفح الويب فَيَرفُكْس
Name[ast]=Restolador web GNU IceCat
Name[bn]=ফায়ারফক্স ওয়েব ব্রাউজার
Name[ca]=Navegador web GNU IceCat
Name[cs]=GNU IceCat Webový prohlížeč
Name[da]=GNU IceCat - internetbrowser
[...]
--8<---cut here---end--->8---

-- 
Thanks,
Maxim

bug#61742: icecat.desktop show ??????????

[Maxim Cournoyer]

Hi Feng,

Maxim Cournoyer  writes:

> Hi Feng,
>
> Feng Shu  writes:
>
>> /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/share/applications/icecat.desktop
>>
>> [Desktop Entry]
>> Version=1.0
>> Name=GNU IceCat Web Browser
>> Name[ar]=?? ?? 
>> Name[ast]=Restolador web GNU IceCat
>> Name[bn]=?? ??? 
>> 
>> Name[ca]=Navegador web GNU IceCat
>> Name[cs]=GNU IceCat Webov?? prohle??
>> Name[da]=GNU IceCat - internetbrowser
>> Name[el]= GNU IceCat
>
> [...]
>
> Sorry, what is the issue?  I don't understand.

OK, these are actual '?' question marks characters; that's a problem!
Sorry for failing to understand the issue earlier.

Perhaps the build environment of icecat would need locale support to
generate these correctly?

-- 
Thanks,
Maxim

bug#61742: icecat.desktop show ??????????

[Maxim Cournoyer]

Hi Feng,

Feng Shu  writes:

> /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/share/applications/icecat.desktop
>
> [Desktop Entry]
> Version=1.0
> Name=GNU IceCat Web Browser
> Name[ar]=?? ?? 
> Name[ast]=Restolador web GNU IceCat
> Name[bn]=?? ??? 
> 
> Name[ca]=Navegador web GNU IceCat
> Name[cs]=GNU IceCat Webov?? prohle??
> Name[da]=GNU IceCat - internetbrowser
> Name[el]= GNU IceCat

[...]

Sorry, what is the issue?  I don't understand.

-- 
Thanks,
Maxim

bug#61914: IceCat does not start with en_GB.utf8 locale

[Maxim Cournoyer]

Hi Timo,

Timo Wilken  writes:

> I cannot start IceCat with a non-C locale. It opens an almost-blank
> window, and I cannot open new tabs or navigate to any URL.

This is very odd, I've never seen that while testing locales stuff with
IceCat.

> If I run `LANG=C icecat', then it works fine.

Could you try running with a fresh profile?  E.g., 'icecat
--ProfileManager', create a new profile, and start it from there?

It should work.  I suspect the problem may be caused by
'intl.locale.requested' being set to something.  It needs to be unset
for the system locale to be honored, so if that's the problem with your
current profile, you could try clearing it by visiting "about:config" in
the URL bar.

-- 
Thanks,
Maxim

bug#61911: error: mate-polkit: unbound variable

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxime,

Maxime Devos  writes:

> In unknown file:
> 3 (primitive-load-path "gnu/packages/xfce" #)
> In gnu/packages/xfce.scm:
>1156:19  2 (_)
> 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:
> error: mate-polkit: unbound variable

This is the same kind of issue as [1]: both xfce and mate require each
other (the second through mate -> freedesktop -> kde-frameworks ->
kde-plasma -> display-managers -> xfce), and depending on the order in
which they're loaded, mate-polkit-for-xfce might get defined before
mate-polkit is.  The solution I suggested there was to define the
variant in the same file as the original package, but here I'm not sure
if this is the right call.

In general, I'd much rather try to get rid of those pesky module cycles,
as they cause general headaches for guix pull.  I remember Julien
using (guix modules) to do some analysis at the Guix days, maybe we
could get some pointers on how to handle this specific situation?

WDYT?

[1] https://issues.guix.gnu.org/61885
   (mid: f29b8bfe-a175-4128-8093-4a810681e...@winter.cafe)

-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#61343: bug#61574: [PATCH v2] scripts: repl: Extend REPL %load-path with all channels.

[Andrew Tropin]

On 2023-02-27 15:01, Ludovic Courtès wrote:

> Hi Simon,
>
> Simon Tournier  skribis:
>
>> Fixes .
>> Reported by 宋文武 .
>>
>> * guix/scripts/repl.scm (define-command): Before starting the REPL,
>> run (current-profile) which makes available all channels.
>
> [...]
>
>> +++ b/guix/scripts/repl.scm
>> @@ -211,6 +211,7 @@ (define script
>>((guile)
>> (save-module-excursion
>>  (lambda ()
>> +  (current-profile) ;Run (%package-module-path) as 
>> explained above.
>
> I tweaked the comment :-) and applied.
>
> Thanks!

Hi Simon and Ludo!

Thank you for the patch, I also faced this problem and it seems this
change doesn't fix it.

echo '(use-modules (rde features))' | guix repl /dev/stdin

still fails on a7763e067d86908210758aab80d33e4f8b815b1c.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Liliana Marie Prikler  writes:

>> % ls ~/.guix-profile/share/emacs/site-lisp/
>> 
>> This does not print any org-roam directory.
> Which leads me to believe that
> $ ls /gnu/store/bxxjy8ydm62fr0bckxfrj27xnlvqbfmy-emacs-org-roam-2.2.2-
> 0.74422df/share/emacs/site-lisp
> does not report any such directory either.

It definitely reports it, I just didn't paste the result to save space.

I'll try running a repair when I get home, since FS corruption could
lead to any kind of weird behaviour, but I haven't had any corruption on
that machine ever, BTRFS has been pretty reliable for me.

Sorry for being so grumpy, I guess I should have highlighted the profile
corruption thing over the emacs-next-pgtk specific bits.

bug#61911: error: mate-polkit: unbound variable

[Maxime Devos]

Unlike https://issues.guix.gnu.org/42601, this happens _outside_ 
./pre-inst-env:


$ LC_ALL=C guix build mate-polkit
Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 (((gnu packages guile)) ((gnu packages image)) # ?))
   222:29 18 (map1 (((gnu packages image)) ((gnu packages #)) ((?)) ?))
   222:29 17 (map1 (((gnu packages kde-frameworks)) ((gnu # #)) (#) ?))
   222:29 16 (map1 (((gnu packages linux)) ((gnu packages #)) ((?)) ?))
   222:29 15 (map1 (((gnu packages pkg-config)) ((gnu packages #)) ?))
   222:29 14 (map1 (((gnu packages python)) ((gnu packages qt)) (#) ?))
   222:29 13 (map1 (((gnu packages qt)) ((gnu packages xdisorg)) # #))
   222:29 12 (map1 (((gnu packages xdisorg)) ((gnu packages xfce)) #))
   222:17 11 (map1 (((gnu packages xfce)) ((gnu packages xorg
  3327:17 10 (resolve-interface (gnu packages xfce) #:select _ #:hide ?)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  3253:13  8 (_)
In ice-9/threads.scm:
390:8  7 (_ _)
In ice-9/boot-9.scm:
  3544:20  6 (_)
   2836:4  5 (save-module-excursion #)
  3564:26  4 (_)
In unknown file:
   3 (primitive-load-path "gnu/packages/xfce" #)
In gnu/packages/xfce.scm:
  1156:19  2 (_)
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:
error: mate-polkit: unbound variable

$ guix describe
  guix af95f2d
bewaarplaats-URL: https://git.savannah.gnu.org/git/guix.git
tak: master
commit: af95f2d8f98eb2c8c64954bb2fd0b70838899174
  nonguix 110f914
bewaarplaats-URL: https://gitlab.com/nonguix/nonguix
tak: master
commit: 110f914f81d0d2c67a45f9b2f87a5dc7ec54dfd0

The backtrace only mentions Guix modules, so the bug doesn't appear to 
be in the extra channel should be irrelevant.


gnu/packages/xfce.scm: 1156:19:

[... mate-screenscraver ...]
(build-system glib-or-gtk-build-system)
(arguments
 `(#:configure-flags
   ;; FIXME: There is a permissions problem with screen locking
   ;; which effectively locks you out completely. Enable locking
   ;; once this has been fixed.
   (list "--enable-locking" "--with-kbd-layout-indicator"
 "--with-xf86gamma-ext" "--enable-pam"
 "--disable-schemas-compile" "--without-console-kit");L1156
   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'autoconf
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((out (assoc-ref outputs "out"))
(dbus-dir (string-append out 
"/share/dbus-1/services")))

 (setenv "SHELL" (which "sh"))
 (setenv "CONFIG_SHELL" (which "sh"))
 (substitute* "configure"
   (("dbus-1") ""

Something is screwy with the line number information too, as 
mate-screensaver doesn't mention mate-polkit.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#61690: Failure to mount /sys in nested ‘guix shell’ container

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> The reason for this bug seems to be given here:
>
>   https://github.com/nestybox/sysbox/issues/67#issuecomment-726285026
>
> It’s not clear whether there’s anything we can do, other than
> recommending ‘-CN’ as well in the nested container.

Couldn't we always create a new network namespace, but when -N is passed
it also has a veth interface?  The one problem I can think of is that
we'd need to either create one veth per interface in the parent
namespace or let the user specify which interface should be shared.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#61841: ‘guix shell’ computes different package derivation than ‘guix build’

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> It was fixed on Monday though, so perhaps you’re using a known-good
> revision?

That's probably the piece of info I was missing!  The discussion about
the issue didn't show up in the same thread in my MUA so I thought this
was simply unanswered, my bad.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#61881: Failed install with 1.4.0 installer-dump-2464c73a

[Josselin Poiret via Bug reports for GNU Guix]

Hi Vagrant,

Vagrant Cascadian  writes:

>> Can you look into directories like /tmp/dump.X? There should be
>> a .tar.gz somewhere of the dump.
>
> No, that was probably lost when I powered it down. If the dump was
> stored on the to-be-installed-filesystem somewhere, there might be a
> chance to recover it?

No, unfortunately, it's only on the /tmp of the live system.

> I had assumed when it said it uploaded the installer dump that it had
> done so successfully...  (maybe a way to more easily confirm success or
> failure of the dump upload might be worth implementing?)

You mean, manually checking that the upload is actually present on the
server?  That could be doable, right.

> Ah well, I will try again with that installer and/or the "latest"
> installer ... and if I still have similar issues will report back
> ... and will be more determined to capture any relevent dump files!
>
> If I feel adventurous, I might even try on the new laptop itself. :)

Have fun 😇

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature