bug#44452: Clash between guile-3.0 and guile-3.0-latest

[zimoun]

Hi,

On Tue, 01 Dec 2020 at 22:56, divoplade  wrote:

> The problem is there until core-updates is merged. The workaround that
> I use appears to work, but I guess it's not something that is intended.

If the problem is fixed in core-updates, then the problem is fixed.  :-)
No need to wait the merge to close this bug.  IMHO.

Moreover, %base-packages already contains Guile (’guile-3.0-latest’),
therefore I am not sure to understand what the bug is about
specifically.  As I said, I do not know if an option
’--allow-collisions’ makes sense here.

Anyway, please do not forget to close it. ;-)

Cheers,
simon

bug#44452: Clash between guile-3.0 and guile-3.0-latest

[divoplade]

Hello,

Le mardi 01 décembre 2020 à 22:41 +0100, zimoun a écrit :
> > > ‘%base-packages’ already contains Guile (‘guile-3.0-latest’
> > > specifically) so maybe you just don’t need to do anything?
> > 
> > You're right! I just filtered out guile-3.0-latest from %base-
> > packages
> > and it works!
> 
> What is the status of this bug?  I guess it can be closed, right?

The problem is there until core-updates is merged. The workaround that
I use appears to work, but I guess it's not something that is intended.

I hope it makes things a little clearer ^^

bug#44452: Clash between guile-3.0 and guile-3.0-latest

[zimoun]

Hi,

This bug #44452 is about issue with Guile declaration.

  


On Fri, 06 Nov 2020 at 11:22, divoplade  wrote:
> Le vendredi 06 novembre 2020 à 11:07 +0100, Ludovic Courtès a écrit :

>> ‘%base-packages’ already contains Guile (‘guile-3.0-latest’
>> specifically) so maybe you just don’t need to do anything?
>
> You're right! I just filtered out guile-3.0-latest from %base-packages
> and it works!

What is the status of this bug?  I guess it can be closed, right?


All the best,
simon

bug#44997: Flatpaks are invisible to application launchers

[guixuser6392 via Bug reports for GNU Guix]

Applications installed by Flatpak can't be discovered by application launchers. 
A fix to this is to add the directories '/var/lib/flatpak/exports/share' and 
'$HOME/.local/share/flatpak/exports/share' to the search path set by the 
XDG_DATA_DIRS environment variable.

bug#27861: python-graphene testsuite fails on x86_64

[zimoun]

Dear,

On Fri, 28 Jul 2017 at 14:43, ng0  wrote:
> With the added 'python-pytest-3.0' dependency, the question
> for the dependency is solved (which is a current failure),
> afterwards you get to this one:
>
> phase `build' succeeded after 1.3 seconds
> starting phase `check'
> running "python setup.py" with command "test" and parameters ()
> running test

[...]

> @ build-failed 
> /gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv - 1 
> builder for 
> `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' 
> failed with exit code 100
> guix build: error: build failed: build of 
> `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' 
> failed

The current package definition as commit 0216fc of python-graphene
contains:

--8<---cut here---start->8---
(arguments
 `(#:tests? #f)); no tests/ in the PyPI tarball
--8<---cut here---end--->8---

Therefore, I am closing.  Feel free to reopen if I miss a point.


All the best,
simon

bug#26247: Gettext introduces timestamps in .mo files

[zimoun]

Hi Ludo,

This old bug #26247 about timestamp in .mo files from Gettext is still
open:

   

On Fri, 24 Mar 2017 at 23:54, l...@gnu.org (Ludovic Courtès) wrote:

> Gettext 0.19.8.1 (current core-updates,
> 77ab6983a19ef307558ab2607920158d6bb94ba8) introduces timestamps in .mo
> file, without honoring SOURCE_DATE_EPOCH, which leads to
> non-reproducible builds (for example ‘guix’).

Is it still relevant?  Since Gettext is now at 0.20.1.  How can I
reproduce the issue?  Because the usual:

   guix build gettext --no-grafts --check

works fine.


Cheers,
simon

bug#27145: document GuixSD system recovery process + document bournish and recovery/guile repl

[zimoun]

Dear,

This old bug #27145 is about documenting.  See:

   

On Tue, 30 May 2017 at 12:02, ng0  wrote:
> Currently neither bournish nor the guile recovery repl are documented
> in a way which is helpful for a person which isn't technical
> knowledged running into the unhappy case of a system which doesn't
> boot. In fact both are not even mentioned in our documentation
> and the built in help is not sufficient.

Could you explain more what you are expecting?


All the best,
simon

bug#44996: issues.guix.gnu.org does not display unarchived re-opened bugs correctly

[Leo Famulari]

On #guix, 'smithras' pointed out that the issues.guix.gnu.org bugtracker
front-end does not display re-opened unarchived bugs as expected:

http://logs.guix.gnu.org/guix/2020-12-01.log#193652

For example,  was recently unarchived and
re-opened after several years.

However, the corresponding page  does
not display any of the recent messages, although it does properly
describe the bug as "open".

bug#25719: "guix package -i" exception should be a normal error message

[zimoun]

Hi Danny,

This old bug #25719 is about exception and error message.  See:



On Tue, 14 Feb 2017 at 09:41, Danny Milosavljevic  
wrote:
> When I have network problems sometimes I get a backtrace like this:

First, do you still experiment such behaviour?  Since it 3 years old.

> ...
> substitute: 1727: 3 [%start-stack load-stack # ice-9/boot-9.scm:4047:10 ()>]
> substitute: 1732: 2 [#]
> substitute: In unknown file:
> substitute:?: 1 [primitive-load 
> "/gnu/store/175nlv448nk5kagwwl3zyy2w4726qfz6-guix-0.12.0-4.d9da/bin/.guix-real"]
> substitute: In guix/ui.scm:
> substitute: 1228: 0 [run-guix-command substitute "--query"]
> substitute: 
> substitute: guix/ui.scm:1228:8: In procedure run-guix-command:
> substitute: guix/ui.scm:1228:8: Throw to key `bad-response' with args `("Bad 
> Response-Line: ~s" (""))'.
>
> It might make sense to
>
> (a) convert that into a normal runtime error message and

What do you mean?

> (b) Fallback to substituteless building (maybe only for this thing).

Is it not the case currently?


All the best,
simon

bug#25504: icecat language packs

[zimoun]

Hi,

On Sat, 21 Jan 2017 at 16:12, ng0  wrote:
> We should include the language packages icecat provides.
>
> I haven't looked into this too much, and I'm not familar with
> application localization in Guix, if there are any mechanisms in
> place for this already.

This old bug #25504 is about IceCat localization in Guix.

   

The package IceCat have been updated a couple of time since 2017.  Is
this bug still relevant?

If yes, what is the next action?  If no, feel free to close it.


All the best,
simon

bug#31977: clone tests fail on CentOS 7

[zimoun]

Hi Paul,

This old bug #31977 is about an issue on your CentOS 7 machine.  Is it
still relevant?

   

On Tue, 26 Jun 2018 at 15:16, Paul Garlick 
 wrote:

> Running 'make check' in the guix source tree on a CentOS 7 system
> results in 15 FAILS:
>
> tests/containers.log: 9 FAILS
> tests/syscalls.log: 3 FAILS
> tests/guix-environment-container.log: 1 FAIL
> tests/guix-pack.log: 1 FAIL
> tests/pack.log: 1 FAIL
>
> Referring to bug#24108, the cause may be that the clone-related tests
> are being executed instead of being skipped.

Note that bug#24108 had been closed couple of months ago:

--8<---cut here---start->8---
From: Ludovic Courtès 
Subject: control message for bug #24108
To: cont...@debbugs.gnu.org, 24...@debbugs.gnu.org
Date: Thu, 09 Jul 2020 15:58:27 +0200 (20 weeks, 5 days, 4 hours ago)

tags 24108 notabug
close 24108
quit
--8<---cut here---end--->8---


> The output of 'uname -srv' is:
>
> Linux 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 UTC 2018
>
> Files:
> a) '/proc/self/ns/user' exists
> b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.
>
> On CentOS 7 I believe user namespaces are supported but disabled by
> default. The output of 'cat /proc/sys/user/max_user_namespaces' is
> '0'.
>
> Perhaps the 'perform-container-tests?' logic should include an extra
> check for the default, disabled case to ensure that the tests are
> skipped.
>
> Attached are the log files, except 'guix-pack.log' (~100MB) and
> 'pack.log' (~7MB).
>
> Best regards,
>
> Paul.


Feel free to close it or report more information about the current
status.


Thanks,
simon

bug#44995: User options are not passed to the offload machine

[Maxim Cournoyer]

Hello,

I noticed that:

--8<---cut here---start->8---
guix build something --no-substitutes
--8<---cut here---end--->8---

when offloaded, will not honor the '--no-substitutes' argument and start
fetching substitutes.

Probably any user options are being ignored, I haven't checked yet.

Thanks,

Maxim

bug#44986: [PATCH] doc: Give references and examples for services-to-restart.

[Simon Josefsson via Bug reports for GNU Guix]

Hi!  I started using unattended-upgrades, and was confused which service
names (config.scm vs herd) to use.  I think this small documentation
patch would help others.  What do you think?

/Simon
From c414dd60652ecdd124b189b2c46ce30ae9db986d Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 1 Dec 2020 10:10:17 +0100
Subject: [PATCH] doc: Give references and examples for services-to-restart.

* doc/guix.texi (Unattended Upgrades): Give references and examples
for services-to-restart.
---
 doc/guix.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 889f380108..02d3077983 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -17175,6 +17175,10 @@ only restarts services that are not currently running, which is
 conservative: it minimizes disruption but leaves outdated services
 running.
 
+Use @command{herd status} to find out candidates for restarting.
+@xref{Services}, for general information about services.  Common
+services to restart would include @code{ntpd} and @code{ssh-daemon}.
+
 By default, the @code{mcron} service is restarted.  This ensures that
 the latest version of the unattended upgrade job will be used next time.
 
-- 
2.20.1



signature.asc
Description: PGP signature

bug#44985: ANSI sequences in unattended-upgrades.log?

[Simon Josefsson via Bug reports for GNU Guix]

Hi!  The unattended-upgrades.log file is quite unreadable due to ANSI
sequences.  Probably use of them should be disabled when output is a log
file?

/Simon


signature.asc
Description: PGP signature

bug#44928: guix upgrade command does not accept a list of packages

[zimoun]

Hi,

On Sat, 28 Nov 2020 at 18:51, Luis Felipe via Bug reports for GNU Guix 
 wrote:

> 1. guix pull
> 2. guix upgrade --dry-run
> 3. Pick two packages from the list shown in (2), say, packages A and B
> 4. guix upgrade A B
>
>
> ## Expected result
>
> Packages A and B are upgraded.

Fixed by 86971616c139597ffa9e20acc75533ff90176450.

Thanks,
simon

bug#44989: GHC@8.6.5 can't find errno.h

[raingloom]

On Tue, 1 Dec 2020 10:54:55 +0100
raingloom  wrote:

> Haven't had a chance to try with latest version, because there is no
> substitute yet.
> It's a very basic Haskell file, only imports are Data.List and
> System.IO. GHCI works.
> 
> I'm pretty sure I didn't need to add any other packages to my profile
> when I last used GHC, but maybe things have changed since then or I'm
> misremembering, or I usde to have just the right assortment of
> packages.
> 
> error:
> ```
> ghc -o sol1 sol1.hs
> Linking sol1 ...
> In file included from
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/errno.h:28,
> from
> /gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5/lib/ghc-8.6.5/include/rts/OSThreads.h:28,
> from
> /gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5/lib/ghc-8.6.5/include/Rts.h:168,
> 
>  from /tmp/ghc1915_0/ghc_1.c:1:0: error: 
> 
> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/bits/errno.h:26:11:
> error: fatal error: linux/errno.h: No such file or directory
>26 | # include 
>   |   ^~~
>|
> 26 | # include 
>|   ^
> compilation terminated.
> `gcc' failed in phase `C Compiler'. (Exit code: 1)
> ```
> 
> manifest:
> ```
> ;; This file was automatically generated and is for internal use only.
> ;; It cannot be passed to the '--manifest' option.
> 
> (manifest
>   (version 3)
>   (packages
> (("ghc"
>   "8.6.5"
>   "out"
>   "/gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5"
>   (propagated-inputs ())
>   (search-paths
> (("GHC_PACKAGE_PATH"
>   ("lib/ghc-8.6.5")
>   ":"
>   directory
>   ".*\\.conf\\.d$")))
>   (properties))
>  ("racket-minimal"
>   "7.9"
>   "out"
>   "/gnu/store/sy5k16y2cgdk2f8dq0if8vxs48xlgnfh-racket-minimal-7.9"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties))
>  ("gcc-toolchain"
>   "10.2.0"
>   "out"
>   "/gnu/store/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0"
>   (propagated-inputs ())
>   (search-paths
> (("C_INCLUDE_PATH" ("include") ":" directory #f)
>  ("CPLUS_INCLUDE_PATH"
>   ("include/c++" "include")
>   ":"
>   directory
>   #f)
>  ("LIBRARY_PATH" ("lib" "lib64") ":" directory #f)
>  ("GUIX_LOCPATH" ("lib/locale") ":" directory #f)))
>   (properties))
>  ("chez-scheme"
>   "9.5.2"
>   "out"
>   "/gnu/store/abaa0mw2pss8ad0a7dazjwgrynim3yg5-chez-scheme-9.5.2"
>   (propagated-inputs ())
>   (search-paths
> (("CHEZSCHEMELIBDIRS"
>   ("lib/csv9.5.2-site")
>   ":"
>   directory
>   #f)))
>   (properties))
>  ("rlwrap"
>   "0.43"
>   "out"
>   "/gnu/store/7q500p5srzg8hx56z63fr0myc2h7fzxh-rlwrap-0.43"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties))
>  ("idris2"
>   "0.2.1-1.a5a5d89"
>   "out"
>   "/gnu/store/z0nx9yr279wsx6nba2ssidhi449h0m4z-idris2-0.2.1-1.a5a5d89"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties)
> ```

Nevermind, my expectations for the profile's /etc/profile were
incorrect. Looks like I don't have to re-source it for new commands,
but I do for... well, whatever kind of dependency this was.

bug#44989: GHC@8.6.5 can't find errno.h

[raingloom]

Haven't had a chance to try with latest version, because there is no
substitute yet.
It's a very basic Haskell file, only imports are Data.List and
System.IO. GHCI works.

I'm pretty sure I didn't need to add any other packages to my profile
when I last used GHC, but maybe things have changed since then or I'm
misremembering, or I usde to have just the right assortment of packages.

error:
```
ghc -o sol1 sol1.hs
Linking sol1 ...
In file included from
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/errno.h:28,
from
/gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5/lib/ghc-8.6.5/include/rts/OSThreads.h:28,
from
/gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5/lib/ghc-8.6.5/include/Rts.h:168,

 from /tmp/ghc1915_0/ghc_1.c:1:0: error: 

/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/bits/errno.h:26:11:
error: fatal error: linux/errno.h: No such file or directory
   26 | # include 
  |   ^~~
   |
26 | # include 
   |   ^
compilation terminated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
```

manifest:
```
;; This file was automatically generated and is for internal use only.
;; It cannot be passed to the '--manifest' option.

(manifest
  (version 3)
  (packages
(("ghc"
  "8.6.5"
  "out"
  "/gnu/store/55c0m16dwnmmp3pah1hqx1941niwi6x4-ghc-8.6.5"
  (propagated-inputs ())
  (search-paths
(("GHC_PACKAGE_PATH"
  ("lib/ghc-8.6.5")
  ":"
  directory
  ".*\\.conf\\.d$")))
  (properties))
 ("racket-minimal"
  "7.9"
  "out"
  "/gnu/store/sy5k16y2cgdk2f8dq0if8vxs48xlgnfh-racket-minimal-7.9"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("gcc-toolchain"
  "10.2.0"
  "out"
  "/gnu/store/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0"
  (propagated-inputs ())
  (search-paths
(("C_INCLUDE_PATH" ("include") ":" directory #f)
 ("CPLUS_INCLUDE_PATH"
  ("include/c++" "include")
  ":"
  directory
  #f)
 ("LIBRARY_PATH" ("lib" "lib64") ":" directory #f)
 ("GUIX_LOCPATH" ("lib/locale") ":" directory #f)))
  (properties))
 ("chez-scheme"
  "9.5.2"
  "out"
  "/gnu/store/abaa0mw2pss8ad0a7dazjwgrynim3yg5-chez-scheme-9.5.2"
  (propagated-inputs ())
  (search-paths
(("CHEZSCHEMELIBDIRS"
  ("lib/csv9.5.2-site")
  ":"
  directory
  #f)))
  (properties))
 ("rlwrap"
  "0.43"
  "out"
  "/gnu/store/7q500p5srzg8hx56z63fr0myc2h7fzxh-rlwrap-0.43"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("idris2"
  "0.2.1-1.a5a5d89"
  "out"
  "/gnu/store/z0nx9yr279wsx6nba2ssidhi449h0m4z-idris2-0.2.1-1.a5a5d89"
  (propagated-inputs ())
  (search-paths ())
  (properties)
```

bug#44881: glib build fail for armhf

[Mathieu Othacehe]

Hey Ludo,

>> This prevents the evaluation of the guix-modular specification, see:
>> https://ci.guix.gnu.org/eval/19035/log/raw. I disabled the armhf-linux
>> system for that specification until this is understood.
>
> I think we can re-enable it now?

Sure, I enabled it again. Maybe we should consider disabling those tests
on core-updates then.

Thanks,

Mathieu

bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive

[Mathieu Othacehe]

Hey Tim,

> I successfully installed GNU Guix.
>
> The work around I used for this bug is I simply ran `sudo dd
> if=/dev/zero of=/dev/sda`. Basically, I think the existence of an old
> GPT partition table is causing problems on a new install though I'm not
> sure why.

Nice you found a work-around. I think I already hit this issue myself
without being able to reproduce it. Do you remember what was the
previous GPT layout of your drive? Maybe the distribution previously
installed?

Thanks,

Mathieu

bug#44835: gnu/ci.go: Embeds build path, breaking reproducible builds

[Mathieu Othacehe]

Hey,

> … but I don’t think we can assume that the checkout is in the
> ‘%load-path’ when this code is executed.  WDYT, Mathieu?

Cuirass happens to add checkouts to the %load-path just before loading
this file.

I tested your path, it works fine. I think it is acceptable as this (gnu
ci) interface needs a big rework anyway.

I can apply your patch if it's ok for you.

Thanks,

Mathieu

bug#44952: Guix cross-compilation is broken.

[Mathieu Othacehe]

Hey,

> This is fixed by commit 07a33b1d21e240781072352f93206cfdc765f907.
>
> Sorry that this spoiled the pleasure of merging service discovery
> support!

Oh what a relieve to see you've fixed it. I had indeed a bad time
discovering the cross-compilation issues just after merging. I guess my
tests were a bit light.

Anyway, many thanks for your support here.

Mathieu

bug#44612: Read standard input in `guix repl'

[Pierre Neidhardt]

Indeed, it works perfectly now, I've implemented your suggestions and
Nyxt is now running a "guix repl server" to which it sends all the
requests.  It's awesome! :)

The only issue remaining is the weird behaviour that one has to pass
/dev/stdin to get rid of the welcome message:

echo '(display "Hi.\n")' | guix repl /dev/stdin



signature.asc
Description: PGP signature