bug#47064: DrRacket internal error uncompressing

[Jack Hill]

Hi Guix,

Using guix 80739ea480a7db667b83b45e3a08be740449f689 on x86_64, running:

`guix environment --ad-hoc racket -- drracket` produces:

```
$bytevector-uncompress: internal error uncompressing 
#"\0\0\0\0chez\310\224\206:\r()#\201\256R-d\205\233\24\363\5\20\201P\6A\v\300\0\16\f\6\31\2\f\6\f&H\275\0\1\0\362\bA\377e\0\1\0C\6A\21\3\v\300\0\201\265!\f\6\n\0\a\1\35\0\1+\0\360\27\201\375\300\0\0\0\17\205\210Z\0\0M\215\245\b\4\0\0M9fH\17\206fZ\0\0I\2...
  context...:
   body of 
"/gnu/store/mmrax3f1vx3c8ih9hhgffpvka6chk96w-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/utils.rkt"
   body of 
"/gnu/store/mmrax3f1vx3c8ih9hhgffpvka6chk96w-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/platform.rkt"
```

However, `guix time-machine --commit=b1248016e0492e1897f4d1127ccb07736c9bb6a5 
-- environment --ad-hoc racket -- drracket`

successfully opens drracket. b1248016e0492e1897f4d1127ccb07736c9bb6a5 is 
the commit before the Racket 8.0 update, so I think the update introduced 
the problem. Other Racket GUI programs like slideshow and gracket also 
also exhibit the problem. The command line REPL works however.


I have not investigated to determine if the problem is specific to the GUI 
packages or if loading other extra Racket packages would also exhibit the 
problem.


Best,
Jack

bug#47005: Acknowledgement (Armbian on OrangePiPC, armhf, guix pull test failed)

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 20:34, joehabel--- via Bug reports for GNU Guix 
 wrote:
> It was a faulty SD card problem. You can close this, as I can now report that 
> Guix got installed properly on Armbian running on the OrangePiPC.

Thanks, so closing.

All the best,
simon

bug#46132: bug#46158: qucs-s build failure: cairocffi python2 issue

[zimoun]

On Wed, 10 Mar 2021 at 15:48, Christopher Howard  
wrote:
> I was able to build qucs a week or two ago, but didn't report it. I
> think you can close this bug report. Thank you.

Thanks, so closing.

bug#46132: bug#46158: qucs-s build failure: cairocffi python2 issue

[Christopher Howard]

I was able to build qucs a week or two ago, but didn't report it. I
think you can close this bug report. Thank you.

On Thu, 2021-03-11 at 01:27 +0100, zimoun wrote:
> Hi,
> 
> On Thu, 28 Jan 2021 at 09:17, Christopher Howard <
> christop...@librehacker.com> wrote:
> > When I try to install qucs-s, installation ultimately fails due to
> > build failure of dependency
> > python2-cairocffi-1.2.0. Apparently python2 is no longer allowed by
> > cairocffi:
> 
> Indeed, python2-cairocffi is failing.  However qucs-s is available
> and
> build fine with commit 6bed29b.
> 
> /gnu/store/2hl8gvma4hzq07m0xdrrncmr46nqwlpy-qucs-s-0.0.21
> 
> If it is fine with you, I inclined to close this bug.  WDYT?
> 
> 
> All the best,
> simon
-- 
Christopher Howard
phone: (907) 374-0257 (landline)
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

bug#46158: qucs-s build failure: cairocffi python2 issue

[zimoun]

Hi,

On Thu, 28 Jan 2021 at 09:17, Christopher Howard  
wrote:
> When I try to install qucs-s, installation ultimately fails due to build 
> failure of dependency
> python2-cairocffi-1.2.0. Apparently python2 is no longer allowed by cairocffi:

Indeed, python2-cairocffi is failing.  However qucs-s is available and
build fine with commit 6bed29b.

/gnu/store/2hl8gvma4hzq07m0xdrrncmr46nqwlpy-qucs-s-0.0.21

If it is fine with you, I inclined to close this bug.  WDYT?


All the best,
simon

bug#46132: [bug] build of /gnu/store/~-python2-setuptools-52.0.0.drv failed

[zimoun]

Hi,

On Thu, 28 Jan 2021 at 02:09, zimoun  wrote:
> On Wed, 27 Jan 2021 at 08:47, "K I"  wrote:
>
>>   File "pkg_resources/__init__.py", line 1367
>> raise SyntaxError(e) from e
>> ^
>> SyntaxError: invalid syntax
>> command "python" "-c" "import setuptools, 
>> tokenize;__file__='setup.py';f=getattr(tokenize, 'open', 
>> open)(__file__);code=f.read().replace('\\r\\n', 
>> '\\n');f.close();exec(compile(code, __file__, 'exec'))" "build" failed with 
>> status 1
>
> It is expected because Setuptools removed the compatibility with Python 2,
> see the ChangeLog:
>
> v47.0.0
>
> 28 May 2020
> Breaking Changes
>
> #2094: Setuptools now actively crashes under Python 2. Python 3.5 or 
> later is required. Users of Python 2 should use setuptools<45.
>
>
> 
> 
>
>
> The question is: do we remove ’python2-setuptools’ since it is defined
> by the usual ’package-with-python2’?
>
> (define-public python2-setuptools
>   (package-with-python2 python-setuptools))
>
> Or do we define python2-setuptools with the version v46.4.0?  Which,
> IMHO does not make sense since Python 2 is end of life since one year.

Currently, python-setuptools is at version 52.0 and python2-setuptools
at version 41.0.1.  Both build fine.  The comment says:

--8<---cut here---start->8---
;; Newer versions of setuptools no longer support Python 2.
(define-public python2-setuptools
  (package
(name "python2-setuptools")
(version "41.0.1")
--8<---cut here---end--->8---

therefore, this part of the bug is done.  Let check the other part.


Cheers,
simon

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

Pushed to maintenance.git as 82b075685b6089c7f98acb0993c003936d833776.

Closing.  Thank you all!

bug#46246: VTK fails to build, breaking FreeCAD and others

[zimoun]

Hi Leo,

On Mon, 01 Feb 2021 at 17:31, Leo Famulari  wrote:
> As previously discussed during the recent staging cycle, VTK is failing
> to build, which in turn prevents FreeCAD from building:

[...]

> Here's what I wrote during the staging cycle:
>
> --
> For example, the vtk package is broken due to incompatibility with new
> Freetype, which breaks FreeCAD. On #guix, Marius said "I looked into VTK
> before the holidays; the Freetype issue is fixed in version 9, but that
> has other problems, such as making it impossible to unbundle the dozens
> of libraries that we are currently unbundling [...] it is possible to
> backport the VTK commits that fix Freetype compatibility, but it will be
> a lot of work and a huge patch (it was a major cleanup IIRC)." I'm
> CC-ing Ekaitz Zarraga, who has been working on FreeCAD. I'm not sure
> what we can do about this problem in the short term. Marius, can you
> give more info about the bundling problem?
> --
>
> Ultimately, it seems to be a compatibility issue, combined with
> difficulty of "updating our way out of it". Maybe we should re-instate
> the graft? I know it's icky to think that the graft was masking some
> problem, but is it worse than not having the affected packages at all?
> Were things actually not working while the graft was in place? What do
> you think?
>
> [0] https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00292.html

Checking this for the next release (1.2.1) since it is something that an
user from the scientific field could expect, “guix weather
--display-missing” indicates that there is not substitute for vtk@6 but
there is one for vtk@8.  With commit 6bed29b and building locally with
--check I get:

  /gnu/store/3lp7nisflgwv19ahs281z6bc233lpnhh-vtk-8.2.0

reproducibly.

However, vtk@6 fails to build.  The only package depending on vtk@6 is
itk-snap.  Maybe it is worth to try to build it with vtk@8 and remove
vtk@6.  I do not know.


Cheers,
simon

bug#47007: dcb640f02b broke guix environment --container

[Ludovic Courtès]

Hi!

Andreas Enge  skribis:

> Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Court鑚:
>> Could you instead try the latest patch?
>>   https://issues.guix.gnu.org/47007#6
>
> it looks like my reply was missed, I tried this patch, and it solves the
> problem for me, as for Jelle. So please push.

Done as b665dd4a9902b5722b9e06fd89c203e2221b19e0, thank you!  :-)

Ludo’.

bug#46877: Guix assumes ideal network exists, does not

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 12:17, Ludovic Courtès  wrote:


>> In guix/scripts/substitute.scm:
>>411:23  2 (lookup-narinfos _ _ #:open-connection _)
>>371:26  1 (fetch-narinfos _ _ #:open-connection _)
>> In ice-9/boot-9.scm:
>>   1669:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> Throw to key `gnutls-error' with args `(#> in the pull function.> read_from_session_record_port)'.
>
> Hmm isn’t it a regression?
>
> First, in (guix scripts substitute) there’s a ‘with-networking’ macro to
> nicely present networking errors; perhaps we’re missing it here?
>
> Second, is it a genuine bug?  Do you see the same thing from (guix
> scripts substitute)?

I do not know if it is related, the bug#47055 seems “similar”:




Cheers,
simon

bug#47005: Acknowledgement (Armbian on OrangePiPC, armhf, guix pull test failed)

[joehabel--- via Bug reports for GNU Guix]

It was a faulty SD card problem. You can close this, as I can now report that 
Guix got installed properly on Armbian running on the OrangePiPC.

Have a good day

Mar 8, 2021, 07:08 by help-debb...@gnu.org:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 47...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> -
> 47005: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47005
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
>

bug#46844: guile2.2-bytestructures fails to compile.

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 22:11, Taylan Kammer  wrote:

> >>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
> >>> and guile2.2-bytestructures builds for me.
> >>
> >> Just to say that the commit breaks "guix pull".
>
> Hmm, I can't seem to reproduce.  Guix pull finished successfully for
> commit 6c5d358cc25ca94d9c0c75a3a086e81b2d63d1b6 (two commits after mine).

No worry and all is explained there:



Cheers,
simon

bug#46844: guile2.2-bytestructures fails to compile.

[Taylan Kammer]

On 10.03.2021 21:55, Taylan Kammer wrote:
> On 10.03.2021 21:12, zimoun wrote:
>> Hi,
>>
>> On Wed, 10 Mar 2021 at 20:12, Taylan Kammer  wrote:
>>
>>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
>>> and guile2.2-bytestructures builds for me.
>>
>> Just to say that the commit breaks "guix pull".

Hmm, I can't seem to reproduce.  Guix pull finished successfully for
commit 6c5d358cc25ca94d9c0c75a3a086e81b2d63d1b6 (two commits after mine).

tkammer@debian:~/src/guix$ guix --version
guix (GNU Guix) 6c5d358cc25ca94d9c0c75a3a086e81b2d63d1b6
Copyright (C) 2021 the Guix authors
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bug#46844: guile2.2-bytestructures fails to compile.

[Taylan Kammer]

On 10.03.2021 21:12, zimoun wrote:
> Hi,
> 
> On Wed, 10 Mar 2021 at 20:12, Taylan Kammer  wrote:
> 
>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
>> and guile2.2-bytestructures builds for me.
> 
> Just to say that the commit breaks "guix pull".

Ugh, sorry.  Looking into it now.


- Taylan

bug#46844: guile2.2-bytestructures fails to compile.

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 20:12, Taylan Kammer  wrote:

> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
> and guile2.2-bytestructures builds for me.

Just to say that the commit breaks "guix pull".


Cheers,
simon

bug#46844: guile2.2-bytestructures fails to compile.

[Taylan Kammer]

I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
and guile2.2-bytestructures builds for me.

- Taylan

bug#47055: guix upgrade throws a backtrace

[Jan Wielkiewicz]

Hello, running guix pull and then guix upgrade gave me this backtrace.
The version is: guix (GNU Guix) 6e70211b20537b018e639b0114d3ccddd4924acb

Backtrace:
In guix/ui.scm:
  2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
633:2 18 (guix-substitute . _)
In unknown file:
  17 (with-continuation-barrier #)
In ice-9/boot-9.scm:
  1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  15 (apply-smob/0 #)
In ice-9/boot-9.scm:
  1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 12 (with-exception-handler # …)
In guix/scripts/substitute.scm:
   682:17 11 (_)
391:7 10 (process-substitution _ "/gnu/store/9iyfc2g1585ps9danh…" …)
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
400:9  8 (_)
In ice-9/boot-9.scm:
  1731:15  7 (with-exception-handler # …)
  1669:16  6 (raise-exception _ #:continuable? _)
  1667:16  5 (raise-exception _ #:continuable? _)
  1669:16  4 (raise-exception _ #:continuable? _)
  1764:13  3 (_ #<&compound-exception components: (#<&error> #<&irri…>)
  1669:16  2 (raise-exception _ #:continuable? _)
  1667:16  1 (raise-exception _ #:continuable? _)
V)ï¾ÉD­substitution of
/gnu/store/9iyfc2g1585ps9danh95p0mw56pw8ik5-bison-3.5.3 failed _
#:continuable? _)ð­^zܪÅszò guix system: error: corrupt input
while restoring archive from #


Jan Wielkiewicz

bug#46925: Ripgrep tests failures due to bstr update

[Nicolas Goaziou]

John Soo  writes:

> I think the problem is that the version bound is too loose in
> cargo.toml upstream. What does the cargo.lock say on the current
> master? I am beginning to think we need to follow the cargo.lock to
> resolve dependencies first if it exists.

It's 0.2.12 in Cargo.toml and 0.2.14 in Cargo.lock.

See 

Regards,

bug#46925: Ripgrep tests failures due to bstr update

[John Soo]

 Hey Nicolas, 

 
I think the problem is that the version bound is too loose in cargo.toml 
upstream. What does the cargo.lock say on the current master?I am beginning 
to think we need to follow the cargo.lock to resolve dependencies first if it 
exists.
 

 
Thanks,
 

 
John
 

bug#46925: Ripgrep tests failures due to bstr update

[Nicolas Goaziou]

Hello,

John Soo  writes:

> I think the breaking tests do actually indicate breaking functionality
> in this case since there is a whole test suite dedicated to the
> bytestring representation.

I use ripgrep daily, and I haven't encountered a regression so far. Of
course, this proves nothing.

> Maybe the fix could be using a later commit
> in which the later bstr is used. There are definitely unreleased
> commits in ripgrep.

Latest ripgrep commit still requires bstr 0.2.12, so this is not an
option either.

Regards,
-- 
Nicolas Goaziou

bug#47028: Discourage single-character package names

[zimoun]

Hi,

(CC: Ricardo since they is the master about R stuff. :-))


On Tue, 09 Mar 2021 at 19:44, Mark H Weaver  wrote:

> We have one notable exception in Guix: "r", which is "grandfathered in"
> so-to-speak, but perhaps it would have been excusable anyway, given its
> prominence and its large number of related packages "r-*".
>
> I fully support your proposal to talk about single-character names in
> the manual, and also to check for them in the linter, but perhaps "r"
> should be whitelisted.

On the other hand, instead of simply the one letter “r”, we could rename
it “r-environment”.  Because the package currently named “r” is the
interpreter named “r-minimal” plus extra packages, constituting the
basic bricks of the “R environment” [1].

1: 

--8<---cut here---start->8---
(define-public r
  (package (inherit r-minimal)
(name "r")
(source #f)
(build-system trivial-build-system)
(arguments '(#:builder (begin (mkdir %output) #t)))
(propagated-inputs
 `(("r-minimal" ,r-minimal)
   ("r-boot" ,r-boot)
   ("r-class" ,r-class)
   ("r-cluster" ,r-cluster)
   ("r-codetools" ,r-codetools)
   ("r-foreign" ,r-foreign)
   ("r-kernsmooth" ,r-kernsmooth)
   ("r-lattice" ,r-lattice)
   ("r-mass" ,r-mass)
   ("r-matrix" ,r-matrix)
   ("r-mgcv" ,r-mgcv)
   ("r-nlme" ,r-nlme)
   ("r-nnet" ,r-nnet)
   ("r-rpart" ,r-rpart)
   ("r-spatial" ,r-spatial)
   ("r-survival" ,r-survival)
--8<---cut here---end--->8---


I also support the proposal.  My point is: I am not even sure that “r”
should be whitelisted.


Cheers,
simon

bug#47007: dcb640f02b broke guix environment --container

[Andreas Enge]

Hello,

Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Courtès:
> Could you instead try the latest patch?
>   https://issues.guix.gnu.org/47007#6

it looks like my reply was missed, I tried this patch, and it solves the
problem for me, as for Jelle. So please push.

Thanks!

Andreas

bug#47028: Discourage single-character package names

[Ludovic Courtès]

Hi Mark & Tobias,

Mark H Weaver  skribis:

> I fully support your proposal to talk about single-character names in
> the manual, and also to check for them in the linter, but perhaps "r"
> should be whitelisted.

Seconded on both points!  The patches look great to me.

Thanks,
Ludo’.

bug#47020: debug output of -boot0 packages is probably unneeded

[Ludovic Courtès]

Efraim Flashner  skribis:

> Some packages we probably don't need to automatically create debug
> outputs for. We could probably drop the debug outputs for all the
> packages that have them in commencement except for the -final ones.
>
> (ins)efraim@3900XT ~/workspace/guix$ du -sch \
> /gnu/store/4qn544j2a062s5kbj1bfxbak060zbq4k-gcc-cross-boot0-7.5.0 \
> /gnu/store/vx0x26r5q7z99rih8k1mxyf2bih3vnpc-gcc-cross-boot0-7.5.0-lib \
> /gnu/store/nbg9qafs2x24bj7lm7km4wg2bfjsp64f-gcc-cross-boot0-7.5.0-debug
> 95M /gnu/store/4qn544j2a062s5kbj1bfxbak060zbq4k-gcc-cross-boot0-7.5.0
> 11M /gnu/store/vx0x26r5q7z99rih8k1mxyf2bih3vnpc-gcc-cross-boot0-7.5.0-lib
> 323M
> /gnu/store/nbg9qafs2x24bj7lm7km4wg2bfjsp64f-gcc-cross-boot0-7.5.0-debug
> 429Mtotal
>
> short list:
> gnu-make-boot0
> coreutils-boot0
> gcc-boot0
> glibc-final-with-bootstrap-bash (maybe)
>
> we can then also adjust the outputs of gcc-final to not delete the debug
> output of gcc-boot0, which it inherits from.

+1 on removing the “debug” output from there (while making sure we don’t
inadvertently remove it from the “final” variants!).

Ludo’.

bug#47007: dcb640f02b broke guix environment --container

[Ludovic Courtès]

Hi Andreas,

Andreas Enge  skribis:

> incidentally I stumbled upon the same problem as Jelle today.
>
> Am Tue, Mar 09, 2021 at 05:17:10PM +0100 schrieb Ludovic Courtès:
>> Could you try the attached patch?

Could you instead try the latest patch?

  https://issues.guix.gnu.org/47007#6

Thanks!

Ludo’.

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> The problem was fixed upstream in Linux-libre 5.10.21, and presumably
> also in 5.11.4, so I'm closing this bug now.

Woow, that was far from an obvious fix.  Thanks a lot!

Ludo’.

bug#46877: Guix assumes ideal network exists, does not

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice via Bug reports for GNU Guix 
skribis:

> ~ $ guix weather --substitute-urls=https://guix.tobias.gr
> computing 16,745 package derivations for x86_64-linux...
> looking for 18,127 store items on https://guix.tobias.gr...
> updating substitutes from 'https://guix.tobias.gr'... 
> 41.6%Backtrace:
>   11 (primitive-load 
>   "/home/nckx/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   2164:12 10 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ 
>   #:unwind-for-type _)
>   1731:15  8 (with-exception-handler #   ice-9/boot-9.scm:1815:7 (exn)> _ #:unwind? _ …)
> In guix/scripts/weather.scm:
> 546:9  7 (_)
> In guix/build/utils.scm:
>569:23  6 (every* #guix/scripts/weather.scm:546:17 (server)> _)
> In guix/scripts/weather.scm:
>547:19  5 (_ "https://guix.tobias.gr";)
>116:17  4 (report-server-coverage _ _ #:display-missing? _)
> In unknown file:
>3 (_ #guix/scripts/weather.scm:184:2 ()> # 
>. #w())
> In guix/scripts/substitute.scm:
>411:23  2 (lookup-narinfos _ _ #:open-connection _)
>371:26  1 (fetch-narinfos _ _ #:open-connection _)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Throw to key `gnutls-error' with args `(# in the pull function.> read_from_session_record_port)'.

Hmm isn’t it a regression?

First, in (guix scripts substitute) there’s a ‘with-networking’ macro to
nicely present networking errors; perhaps we’re missing it here?

Second, is it a genuine bug?  Do you see the same thing from (guix
scripts substitute)?

Thanks,
Ludo’.

bug#47007: dcb640f02b broke guix environment --container

[Jelle Licht]

Ludovic Courtès  writes:

> Here’s a more sensible patch for you to try.  This time it should
> correctly determine the necessary mount flags based on statfs(2) info.
>
> Could you apply it and report back?

I can confirm that it does what it says on the tin :-).

Thanks again!
 - Jelle