bug#24841: Cross-building bootstrap binaries fail in current master

[Chris Marusich]

zimoun  writes:

> What is the status of this bug#24841 report [1]?
>
> 1: 

I agree we can close this old bug report.  As you mentioned, it is now
possible to build bootstrap binaries for various architectures.

If someone needs to build bootstrap binaries for a specific
architecture, and they are unable to do so, then they should open a new
bug report for that problem specifically.  Currently, I have no need to
do this, since I am not bootstrapping any new architectures at the
moment, or updating any bootstrap binaries.

If nobody else comments, I'll close this bug report in a week or two.

-- 
Chris


signature.asc
Description: PGP signature

bug#49355: [guix-jupyter] timeout issue running the kernel

[Domagoj Stolfa]

After a very painful bisect with various issues appearing in jupyter (unrelated
to this one), I've identified the first good commit and the first bad commit.

The commit range which caused the problem is between

95f25c9b13e22603c35f3acd9048fbd1c8671925

and

9e7f09cbec40257619e57edfdd700c775e96833d

which is a series of commits by Ricardo updating a bunch of python stuff,
including jupyter. My suspicion is that the update to jupyter-core from 4.4.0 to
4.7.1 (2a12cbaaab970bcab09002e952e062da0274f0b6) caused jupyter-core to no
longer agree with the guix kernel. I haven't diagnosed further.

The first good commit is 85788dd64d5c54ff52f19c8bb6c8c522ed581b2c and the first
bad commit I was able to actually get jupyter to work on is
9e7f09cbec40257619e57edfdd700c775e96833d.

--
Domagoj


signature.asc
Description: PGP signature

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Hi,
>
> Am Freitag, den 02.07.2021, 18:57 -0400 schrieb Joshua Branson:
>> Leo Prikler  writes:
>> 
>> > Am Freitag, den 25.06.2021, 14:06 -0400 schrieb Joshua Branson:
>> > > Leo Prikler  writes:
>> > > 
>> > > > Hi,
>> > > > 
>> > > > Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
>> > > > > Leo Prikler  writes:
>> > > 
>> > > Thanks again!  The current code doesn't quite work for me
>> > > yet.  I'll
>> > > try using match-lambda to define it.  I'll post again when I have
>> > > a
>> > > free moment.  When i get it working, I'll send a patch to the
>> > > manual
>> > > via guix-patches and CC you.  Is that ok?  Or would you rather
>> > > that
>> > > documentation be in the cookbook?
>> > Did I make a mistake or does it do the job only in a somewhat
>> > inelegant
>> > way?  I'm perfectly fine with the latter as I'm not the one using
>> > the
>> > code :P
>> 
>> I've got some code now that works!
>> 
>> #+BEGIN_SRC scheme
>> (define (auto-login-to-tty tty user config)
>>   (if (string=? tty (mingetty-configuration-tty config))
>> (mingetty-configuration
>>  (inherit config)
>>  (auto-login user))
> Why do you need to inherit the config, when it doesn't change?  Seems
> like a pointless allocation to me.
>> (mingetty-configuration
>>  (inherit config
>> 
>> ;; allegedly %desktop-services now contains network-manager-
>> applet...?  Can I remove that?
> Not with modify-services, but there's some filter example in the manual
> as well.
>> (define %my-desktop-services
>>   (modify-services %desktop-services ;;end of remove services
>> (mingetty-service-type config =>
>>(auto-login-to-tty "3" "joshua" config
>> 
>> #+END_SRC
>> 
>> > I think the cookbook is a better destination for stuff like this.
>> 
>> I agree, but we should also probably fix the manual:
>> 
>> 10.1 Using the Configuration System
>> ===
>> 
>> System Services
>> 
>>For example, suppose you want to modify ‘guix-daemon’ and Mingetty
>> (the console log-in) in the ‘%base-services’ list (*note
>> ‘%base-services’: Base Services.).  To do that, you can write the
>> following in your operating system declaration:
>> 
>> 
>>  (define %my-services
>>;; My very own list of services.
>>(modify-services %base-services
>>  (guix-service-type config =>
>> (guix-configuration
>>  (inherit config)
>>  ;; Fetch substitutes from example.org.
>>  (substitute-urls
>>(list "https://example.org/guix;
>>  "https://ci.guix.gnu.org;
>> ;; it looks like the manual is telling you to set up
>> ;; auto login on ALL ttys.
>>  (mingetty-service-type config =>
>> (mingetty-configuration
>>  (inherit config)
>>  ;; Automatially log in as "guest".
>>  (auto-login "guest")
>> 
>>  (operating-system
>>;; ...
>>(services %my-services))
>> 
>> How about I delete that section in the manual about automatic login
>> and
>> instead add this to the cookbook?
> No.  Read on, the manual clearly states that this affects *all* TTYs. 
> Presumably the guest user only has access to su and logout, maybe guix,
> but in any case they ought not to have access to anyone's $HOME, not
> even their own.
>
> The thing we've coded up here is a more involved process to solve a
> particular problem rather than a general demo of what services can do
> and thus belongs to the cookbook.
>
> Regards,
> Leo
>

-- 
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

[Vinicius Monego]

Hi,

I found [1] which lists which versions of OpenEXR are vulnerable to
which CVE. All the CVEs mentioned here were fixed in version 2.5.4 [2],
while we are currently tracking version 2.5.5, for which there are no
known CVEs.

I will close this issue. Feel free to reopen if I missed anything.

[1]
https://github.com/AcademySoftwareFoundation/openexr/blob/master/SECURITY.md

[2]
https://github.com/AcademySoftwareFoundation/openexr/blob/master/CHANGES.md#version-254-december-31-2020

bug#49355: [guix-jupyter] timeout issue running the kernel

[Domagoj Stolfa]

Having done some time-machining, I can confirm that
68c9e0a56e008f19427bd213cf5b24bdd8fe5922 is a good commit. The guix kernel
works fine on it. I don't however yet know which commit caused the regression,
but if nobody finds it until I have more time to bisect, I'll report back.

--
Domagoj


signature.asc
Description: PGP signature

bug#48064: texlive-* packages fail to build non-deterministically

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hi Ludo,

Em segunda-feira, 5 de julho de 2021, às 06:20:20 -03, Ludovic Courtès 
escreveu:
> Thiago Jung Bauermann  skribis:
> > LuaTeX has a bug where sometimes it corrupts the heap and aborts. This
> > causes the build of texlive packages to fail at random. The problem is
> > being tracked at https://issues.guix.gnu.org/48064.
> > 
> > While a fix isn't found, switch the default TeX format (and
> > consequently
> > also the engine) to pdftex to avoid the issue.
> > 
> > * guix/build-system/texlive.scm (texlive-build): Change default value
> > of
> > the ‘tex-format’ key parameter to “pdftex”.
> 
> Pushed as 04f9f9158da348e8299e9ab90ec389ba81be46b0 with the text above
> inlined as a FIXME comment.

Thank you!

> On IRC there were concerns about Unicode support, which LuaTeX provides
> but pdftex doesn’t (IIUC), but it would seem that the worst that can
> happen is that documentation of the packages themselves would be
> mangled, which is okay.

I chose pdfTeX for the workaround because it’s the direct “predecessor” to 
LuaTeX, so I thought it would behave most similarly to it. But it’s just an 
uneducated guess.

Searching around a bit¹²³, XeTeX also has native Unicode support, so we 
could also switch to it. Either as the default, or for specific packages 
that need it.

NB: I last used TeX more than 15 years ago, and even then just lightly and 
sporadically. Don’t trust my judgement on TeX-related issues. :-)

> Anyway, it’d be ideal to get feedback from the LuaTeX folks!

Agreed!

-- 
Thanks,
Thiago

¹ 
https://tex.stackexchange.com/questions/13593/the-differences-between-tex-engines
² 
https://tex.stackexchange.com/questions/36/differences-between-luatex-context-and-xetex
³ https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#x1-120002.4

bug#49171: OCaml packages not building (due to updated python-pyyaml)

[Xinglu Chen]

On Sun, Jul 04 2021, pukkamustard wrote:

> Xinglu Chen  writes:
>
>> I think this was fixed in commit
>> 91b29aa37394b660117e1d79927621db1344b7fe (gnu: ocaml-dose3: Fix 
>> tests.),
>> do you think we can close the issue?
>
> Yup, was fixed and already closed by Julien (see 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49171#13).

Oh, I didn’t check the Web UI, sorry for the noise.


signature.asc
Description: PGP signature

bug#42760: Elixir build fails

[Oskar Köök]

Hi

Yes. This was fixed in commit a3e26863146ffc100ced3600bfc49814d04ae643: 
https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a3e26863146ffc100ced3600bfc49814d04ae643

Oskar
On Mon, 5 Jul 2021, at 12:51, zimoun wrote:
> Hi,
> 
> Thanks for the report and sorry for the delay.
> 
> On Sat, 08 Aug 2020 at 13:04, Oskar Köök  wrote:
> 
> > Elixir build is failing for me. Don't have time to debug right now. This is
> > the log:
> >
> > phase `unpack' succeeded after 0.2 seconds
> > starting phase `make-git-checkout-writable'
> > phase `make-git-checkout-writable' succeeded after 0.0 seconds
> > starting phase `replace-paths'
> > Backtrace:
> >   18 (primitive-load "/gnu/store/7wsw0zq6zqvsqpl9g0j6gjanxwm…")
> > In ice-9/eval.scm:
> >191:35 17 (_ #f)
> > In guix/build/gnu-build-system.scm:
> > 838:2 16 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> > In ice-9/boot-9.scm:
> >   1736:10 15 (with-exception-handler _ _ #:unwind? _ # _)
> > In srfi/srfi-1.scm:
> >857:16 14 (every1 # …)
> > In guix/build/gnu-build-system.scm:
> >847:30 13 (_ _)
> > In ice-9/eval.scm:
> > 619:8 12 (_ #(#(#) (# # …) …))
> > 619:8 11 (_ #(#(#(#) # #) #))
> > In srfi/srfi-1.scm:
> > 634:9 10 (for-each # _)
> > In ice-9/boot-9.scm:
> >   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> > In ice-9/ports.scm:
> >445:17  8 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
> > In guix/build/utils.scm:
> >741:26  7 (_ _)
> >767:26  6 (_ # #)
> > In srfi/srfi-1.scm:
> >460:18  5 (fold # …)
> > In ice-9/eval.scm:
> >202:51  4 (_ #(#(#(#(#(#(#(# …)) …) …) …) …) …))
> > 163:9  3 (_ #(#(#(#(#(#(#(# …)) …) …) …) …) …))
> > In unknown file:
> >2 (string-append "cmd(\"" #f)
> > In ice-9/boot-9.scm:
> >   1669:16  1 (raise-exception _ #:continuable? _)
> >   1669:16  0 (raise-exception _ #:continuable? _)
> >
> >
> > In the latest commit the git input has been removed, which might be the 
> > issue:
> > http://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a749caa74e2a44a37d3a4af06cf4c18f9e463fbb
> 
> Using Guix 3694c0d on x86_64, now the package elixir seems to build.  Is
> it fine for you?  If yes, let close.  Otherwise, please provide more
> information. :-)
> 
> All the best,
> simon
> 

bug#48756: guix offload: error: corrupt input while restoring archive from #

[Madhavan Krishnan]

Many thanks for your time and effort in debugging this.

I can confirm this issue is resolved.

Regards
-- 
Madhavan Krishnan

bug#48903: guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Maxim Cournoyer  skribis:
>>
>>> I've tried with the following modified version which runs multiple
>>> threads in parallel (to mimic --max-jobs=4 on the daemon), and I've yet
>>> to trigger it, although the hard drive is grinding heavily:
>>
>> Note that ‘--max-jobs=4’ leads guix-daemon to spawn 4 ‘guix substitute’
>> processes, which is not what the script is doing here.
>
> Oh!  I had overlooked that.  What the modified version did is create
> threads rather than processes, right?

Yes.

So I’m not sure how to better test this.  Perhaps you could try
introducing random delays in the loop (which could cause connections to
go stale), using different substitute URLs, things like that.

Thanks,
Ludo’.

bug#42760: Elixir build fails

[zimoun]

Hi,

On Mon, 5 Jul 2021 at 17:50, Oskar Köök  wrote:

> Yes. This was fixed in commit a3e26863146ffc100ced3600bfc49814d04ae643: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a3e26863146ffc100ced3600bfc49814d04ae643

Thanks.  So closing. :-)

Cheers,
simon

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

[John Kehayias via Bug reports for GNU Guix]

I've run into the same problem, seems like fetching the revised cabal file 
would be the best bet. (In the meantime I've modified package definitions to 
make the metadata changes, but that is manual and certainly should be automated 
by import.)

bug#47018: core-updates: make check fails when guix-daemon is running

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> In guix/packages.scm:
>1638:7  3 (_ _)
> 619:2  2 (patch-and-repack # /gnu/store/l9nzv7lmznp2y22i2n3j7mccz5jjhlv1-tar-1.34.tar.xz.drv => 
> /gnu/store/4y8yhyxhvh725bp3bk7wzr3jn8r5hjm0-tar-1.34.tar.xz 7fa2f699d280> 
> ("…/gnu/packages/patches/tar-skip-unreliable-tests.patch" 
> "…/gnu/packages/patches/tar-remove-wholesparse-check.patch") #:inputs _ 
> #:snippet _ #:flags _ #:modules _ #:guile-for-build _ #:system _)
> In unknown file:
>1 (string-drop 
> "/gnu/store/4y8yhyxhvh725bp3bk7wzr3jn8r5hjm0-tar-1.34.tar.xz" 91)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Value out of range 0 to 59: 91

Fixed in 99ea6a2996a388134c6ea8fdce34f70d446b1450!

Ludo’.

bug#42301: Build of GNU Solfege fails

[Tim Magee]

It works for me now. I will close if nobody beats me to it.



OpenPGP_signature
Description: OpenPGP digital signature

bug#42979: Some kde games are outdated

[Jesse via Bug reports for GNU Guix]

I agree that this can be closed. lskat does not render properly, but 
that's a different issue.


On 7/5/21 3:28 AM, zimoun wrote:

Hi,

On Fri, 21 Aug 2020 at 15:33, Jesse Gibbons  wrote:

The following KDE games fail to build:

kblocks
kdiamond
kigo
klines
kollision
lskat

The upstream git repositories all have tags for version 20.8.0, but there are
no source tarballs in the mirrors.

Using Guix 3694c0d, the version is now 20.12.0 and
https://bordeaux.guix.gnu.org provides all the substitutes.  Note that
“guix build --check” works fine too.

BTW, this

   $ guix gc -D $(guix build  -S)
   $ guix build  -S --no-substitutes

also works fine.  In my case, downloading from
.

Indeed the sources of 20.8.0 does not seem available upstream.
However, this version was not in Guix, AFAIK.  For instance,

   git log --grep=kigo

does not display a commit updating from 19.08.3 to 20.8.0.  The only
update is from 19.08.3 (d685f86054..f114a689e7) to 20.12.0
(908e48f7dd..3cd53b4500).  The version 19.08.3 seems removed from
upstream but we cannot do more; this source is still on ci.guix.gnu.org
and should be transparently available via Disarchive.

Well, I am in favor to close this bug.  WDYT?


All the best,
simon
.

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

[Philip Munksgaard]

The hackage store of haskell packages allows maintainers to update package 
metadata directly on hackage without updating the associated archive of a 
package. For instance, the cabal file of the integer-logarithms package version 
1.0.3 [0] has been updated since 1.0.3 was published, relaxing the constraints 
on some dependencies[1]. This means that, if I try to build the attached 
integer-logarithms.scm (created from guix import hackage integer-logarithms and 
modified to use ghc-8.8) I get the following error:

```
Setup.hs: Encountered missing or private dependencies:
base >=4.3 && <4.13

command "runhaskell" "Setup.hs" "configure" 
"--prefix=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3"
 
"--libdir=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/lib"
 
"--docdir=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/share/doc/ghc-integer-logarithms-bootstrap-1.0.3"
 "--libsubdir=$compiler/$pkg-$version" 
"--package-db=/tmp/guix-build-ghc-integer-logarithms-bootstrap-1.0.3.drv-0/package.conf.d"
 "--global" "--enable-shared" "--enable-executable-dynamic" 
"--ghc-option=-fPIC" 
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/lssajarfg1vr6xbhi5dfvnn3xs01v3bz-ghc-integer-logarithms-bootstrap-1.0.3/lib/$compiler/$pkg-$version"
 failed with status 1
builder for 
`/gnu/store/pwdhhwp6d6b5g5pgik9y6ml5g1d8fxf5-ghc-integer-logarithms-bootstrap-1.0.3.drv'
 failed with exit code 1
build of 
/gnu/store/pwdhhwp6d6b5g5pgik9y6ml5g1d8fxf5-ghc-integer-logarithms-bootstrap-1.0.3.drv
 failed
```

In ghc 8.8 the base version is 4.13, and the updated cabal file for 
integer-logarithms amends the constrants to allow that version.

The solution might be to use `cabal get` to download the archive instead of 
downloading the .tar.gz directly, or manually amending the cabal file after 
downloading.

0: https://hackage.haskell.org/package/integer-logarithms-1.0.3
1: https://hackage.haskell.org/package/integer-logarithms-1.0.3/revisions/(define-module (gnu packages futhark)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system haskell)
  #:use-module (guix licenses)
  #:use-module (guix git-download)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages)
  #:use-module (gnu packages haskell)
  #:use-module (gnu packages haskell)
  #:use-module (gnu packages haskell-web)
  #:use-module (gnu packages haskell-xyz)
  #:use-module (gnu packages haskell-check)
  #:use-module (gnu packages haskell-crypto))

(define-public ghc-integer-logarithms
  (package
(name "ghc-integer-logarithms")
(version "1.0.3")
(source
 (origin
   (method url-fetch)
   (uri (string-append "https://hackage.haskell.org/package/;
   "integer-logarithms/integer-logarithms-"
   version ".tar.gz"))
   (sha256
(base32
 "05pc5hws66csvcvfswlwcr2fplwn1lbssvwifjxkbbwqhq0n5qjs"
(build-system haskell-build-system)
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (add-before 'configure 'update-constraints
   (lambda _
 (substitute* "integer-logarithms.cabal"
   (("tasty >= 0\\.10 && < 1\\.1")
"tasty >= 0.10 && < 1.2")))
(native-inputs
 `(("ghc-quickcheck" ,ghc-quickcheck)
   ("ghc-smallcheck" ,ghc-smallcheck)
   ("ghc-tasty" ,ghc-tasty)
   ("ghc-tasty-hunit" ,ghc-tasty-hunit)
   ("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)
   ("ghc-tasty-smallcheck" ,ghc-tasty-smallcheck)))
(home-page "https://github.com/Bodigrim/integer-logarithms;)
(synopsis "Integer logarithms")
(description
 "This package provides the following modules:
@code{Math.NumberTheory.Logarithms} and
@code{Math.NumberTheory.Powers.Integer} from the @code{arithmoi} package,
@code{GHC.Integer.Logarithms.Compat} and
@code{Math.NumberTheory.Power.Natural}, as well as some additional functions
in migrated modules.")
(license license:expat)))

(define-public ghc-integer-logarithms-bootstrap
  (package
(inherit ghc-integer-logarithms)
(name "ghc-integer-logarithms-bootstrap")
(arguments `(#:tests? #f
 #:haskell ,ghc-8.8))
(native-inputs '())
(properties '((hidden? #t)

ghc-integer-logarithms-bootstrap

bug#42301: Build of GNU Solfege fails

[zimoun]

Hi,

On Mon, 5 Jul 2021 at 15:46, Tim Magee  wrote:

> It works for me now. I will close if nobody beats me to it.

Thanks.  So closing. (-:

All the best,
simon

bug#49417: glibc uses "objcopy", but seems to need "TARGET-objcopy" [core-updates]

[Maxime Devos]

User: guix-de...@gnu.org
Usertags: powerpc64le-linux

Here is an extract from the build log
()

/gnu/store/ar373sjda7fz0m4mav6rdfmv49vv6r87-bash-minimal-5.1.8/bin/sh 
../scripts/move-if-change 
/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/gnu/lib-names-64-v2.T
 /tmp/guix-
build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/gnu/lib-names-64-v2.h
objcopy 
--dump-section=.gnu.attributes=/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/no_ldbl_gnu_attribute.bin.tmp
 /tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-
0/build/no_ldbl_gnu_attribute.o
touch 
/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/libc-abis.stamp
touch 
/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/dl-tunable-list.stmp
objcopy: Unable to recognise the format of the input file 
`/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/no_ldbl_gnu_attribute.o'
make[2]: *** [../sysdeps/powerpc/powerpc64/le/Makefile:31: 
/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.33.drv-0/build/no_ldbl_gnu_attribute.bin]
 Error 1
make[2]: *** Waiting for unfinished jobs

That looks like the earlier issue we had with "objdump" vs. "TARGET-objdump" ...
Maybe a similar fix is possible?

Greetings,
Maxime.


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

bug#30122: python-pygobject with gtk+ broken.

[zimoun]

Hi,

Thiss old bug [1] is about python-pygobject.

1: 

On Mon, 15 Jan 2018 at 13:15, Fis Trivial  wrote:

> * Steps to reproduce:
> Install python-pygobject with guix: `guix package -i python-pygobject`
> Install gtk+ with guix: `guix package -i gtk+`
>
> $ python
 from gi.repository import Gtk
>
> * Full message
>
> Python 3.5.3 (default, Jan  1 1970, 00:00:01)
> [GCC 5.4.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 from gi.repository import Gtk
> /home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py:178: 
> Warning: cannot register existing type 'AtkImplementorIface'

[...]

> TypeError: must be an interface


Using Guix 3694c0d, it seems to work.

--8<---cut here---start->8---
guix environment --ad-hoc gtk+ python-pygobject python -- python3

Python 3.8.2 (default, Jan  1 1970, 00:00:01)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> gi.require_version('Gtk', '3.0')
>>> from gi.repository import Gtk
>>>
--8<---cut here---end--->8---

Does it work for you?

All the best,
simon

bug#30518: teeworlds fails on core-updates due to freetype-update (and contains files to be snipped)

[zimoun]

Hi,



On Sun, 18 Feb 2018 at 21:46, Björn Höfling  
wrote:
> I thought of looking closer at some core-updates failures and looked at
> this evaluation:
>
> https://hydra.gnu.org/eval/109914?full=1=109912
>
> Randomly I stumbled over a failing teeworlds:
>
> https://hydra.gnu.org/job/gnu/core-updates/teeworlds-0.6.4.x86_64-linux

This old bug [1] is about teeworlds and core-updates.  Well, I have not
read in full details the report but since teeworlds had been updated,
currently builds with 3694c0d, hydra is now down, and core-updates
merges, I appears to me reasonable to close this bug.  WDYT?

1: 

All the best,
simon

bug#42301: Build of GNU Solfege fails

[Michael Rohleder]

Nicolas Goaziou  writes:
> Fine by me, but I'm not the OP.

dito.

-- 
Thus spake the master programmer:
"Without the wind, the grass does not move.  Without software,
hardware is useless."
-- Geoffrey James, "The Tao of Programming"


signature.asc
Description: PGP signature

bug#29655: Elixir build has an undeterministic build error

[zimoun]

Hi,

This old bug [1] is about a failure of elixir.

1: 

On Sun, 17 Dec 2017 at 08:54, Pjotr Prins  wrote:
> The epipe error suggests a new external process is invoked (git)
> which does not terminate properly and does not close the pipe. Maybe
> it tries to access the network layer. The calling program throws an
> epipe error. I see something similar happening
> here: https://gist.github.com/knewter/533d22eb69ef1036c22a

Using Guix 3694c0d, the package 'elixir' builds for x86_64.  Even, it
builds reproductibly; the option '--check' passes.

Closing?

All the best,
simon

bug#28602: Unpack fails with no error message when using a .zip source

[zimoun]

Hi,

Thanks for the patch and sorry for the delay.

On Mon, 09 Oct 2017 at 23:00, nee  wrote:
> Hello here is a patch to fix this bug. It changes the gnu-build-system,
> so the hashes of almost all packages will also change. I guess
> core-updates is the right branch for this.
>
>>From 089b9741a734f0682a671df6c0c36dfefcbd407c Mon Sep 17 00:00:00 2001
> From: nee 
> Date: Mon, 9 Oct 2017 22:49:12 +0200
> Subject: [PATCH] guix: gnu-build-system: warn about missing unzip input during
>  unpack.
>
> ---
>  guix/build/gnu-build-system.scm | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
> index e37b75140..c16d15964 100644
> --- a/guix/build/gnu-build-system.scm
> +++ b/guix/build/gnu-build-system.scm
> @@ -67,6 +67,21 @@ See 
> https://reproducible-builds.org/specs/source-date-epoch/.;
>  #f
>  dir))
>
> +(define (unzip filepath)
> +  "Unzip archive file.
> +Warn the user when unzip fails and the executable is not present."
> +  (define exit-code (system* "unzip" filepath))
> +  (define program-not-found-code 32512)
> +  (cond ((zero? exit-code) #t)
> +((eqv? exit-code program-not-found-code)
> + (format (current-error-port)
> + "warning: Archive with .zip suffix failed to unpack.
> +Please add unzip as native-input to the package,
> +e.g. (native-inputs `((\"unzip\" ,unzip)))")
> + (newline (current-error-port))
> + #f)
> +(else #f)))

Give a look at 'invoke' from (guix build utils).

>  (define* (set-paths #:key target inputs native-inputs
>  (search-paths '()) (native-search-paths '())
>  #:allow-other-keys)
> @@ -154,7 +169,7 @@ working directory."
>#:keep-mtime? #t)
>  #t)
>(and (if (string-suffix? ".zip" source)
> -   (zero? (system* "unzip" source))
> +   (unzip source)
> (zero? (system* "tar" "xvf" source)))
> (chdir (first-subdirectory ".")

After 9a87649c863e1ff8b073b356875eb05eecedbcf7, this part uses 'invoke'.
Instead of your 'unzip', the exception raised by 'invoke' should be
catched and then should trigger the hint message.  WDYT?

All the best,
simon

bug#28554: teeworlds not starting

[zimoun]

Hi,

This bug [1] is related to the game 'teeworlds' using non-standard
hardware.

1: 

On Fri, 22 Sep 2017 at 15:19, mray  wrote:
> Running guix on ubuntu 17.04 teeworlds does not start.
>
> $ teeworlds
> [59c505a6][engine]: running on unix-linux-amd64

[...]

> [59c505a6][client]: starting...
> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: swrast
> X Error of failed request:  BadValue (integer parameter out of range for
> operation)
>   Major opcode of failed request:  154 (GLX)
>   Minor opcode of failed request:  3 (X_GLXCreateContext)
>   Value in failed request:  0x0
>   Serial number of failed request:  32
>   Current serial number in output stream:  33

It works using Guix 3694c0d on the top of (default) Ubuntu.  Which kind
of hardware do you have?


All the best,
simon

bug#29021: gnu: biber@2.7: "check" phase fails at "dateformats.t" tests

[zimoun]

Hi,

This old bug [1] is about a failure of the package 'biber'.

1: 

On Thu, 26 Oct 2017 at 21:51, Adonay Felipe Nogueira  
wrote:

> $ guix package --fallback -i biber

> starting phase `configure'
> running `perl' with arguments ("Build.PL"
> "--prefix=/gnu/store/0mkxal471rqb55zvnqrapp970irzdb5i-biber-2.7"
> "--installdirs=site")
> WARNING: the following files are missing in your kit:
> META.json
> META.yml
> Please inform the author.
>
> Created MYMETA.yml and MYMETA.json
> Creating new 'Build' script for 'biblatex-biber' version '2.7'
> phase `configure' succeeded after 0.6 seconds
> starting phase `patch-generated-file-shebangs'
> phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
> starting phase `build'
> Building biblatex-biber
> phase `build' succeeded after 0.7 seconds
> starting phase `check'

[...]

> #   Failed test 'Extended years - 1'

[...]

> #   Failed test 'Extended years - 2'

[...]

> Failed 2/45 subtests
>
> Test Summary Report
> ---
> t/dateformats.t  (Wstat: 512 Tests: 45 Failed: 2)
>   Failed tests:  43-44
>   Non-zero exit status: 2
> Files=43, Tests=1061, 78 wallclock secs ( 0.64 usr  0.14 sys + 59.30
> cusr 16.42 csys = 76.50 CPU)
> Result: FAIL
> Failed 1/43 test programs. 2/1061 subtests failed.
> phase `check' failed after 79.2 seconds
> builder for
> `/gnu/store/07p6wbr4j2j3qy4151z0gak2dylwhrkm-biber-2.7.drv' failed
> with exit code 1
> guix package: error: build failed: build of
> `/gnu/store/07p6wbr4j2j3qy4151z0gak2dylwhrkm-biber-2.7.drv' failed

Using Guix 3694c0d, the package 'biber' (now at 2.12) builds for me.

Does it build for you?

All the best,
simon

bug#42301: Build of GNU Solfege fails

[Nicolas Goaziou]

Hello,

zimoun  writes:

> Using Guix 3694c0d, the package ’solfege’ builds and the substitute is
> available.  The package ’lilypond’ too.
>
> Something probably changed in the dependency chain since commit
> 145484e8f5d89911f5f905c9fe604e3cbfd1e434 (fail).
>
> Closing?

Fine by me, but I'm not the OP.

Regards,
-- 
Nicolas Goaziou

bug#49415: ‘Internal compiler error: Segmentation fault’ when building aarch64-linux-gnu cross-compiler [core-updates]

[Maxime Devos]

Hi guix,

While testing a patch re-introducing %build-inputs when cross-compiling
(probably irrelevant to the build failure though), I encountered an ICE
(internal compiler error).  I checked 'dmesg'; it is not an OOM.
I believe I encountered similar errors in the past, though they disappeared
when I retried the build, so this looks like a non-determenistic build
failure.

Greetings,
Maxime

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. 
-I../../gcc-10.3.0/gcc -I../../gcc-10.3.0/gcc/.
-I../../gcc-10.3.0/gcc/../include -I../../gcc-10.3.0/gcc/../libcpp/include  
-I../../gcc-10.3.0/gcc/../libdecnumber 
-I../../gcc-10.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-
10.3.0/gcc/../libbacktrace   -o tree-ssa-strlen.o -MT tree-ssa-strlen.o -MMD 
-MP -MF ./.deps/tree-ssa-strlen.TPo ../../gcc-10.3.0/gcc/tree-ssa-strlen.c
g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. 
-I../../gcc-10.3.0/gcc -I../../gcc-10.3.0/gcc/.
-I../../gcc-10.3.0/gcc/../include -I../../gcc-10.3.0/gcc/../libcpp/include  
-I../../gcc-10.3.0/gcc/../libdecnumber 
-I../../gcc-10.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-
10.3.0/gcc/../libbacktrace   -o tree-ssa-structalias.o -MT 
tree-ssa-structalias.o -MMD -MP -MF ./.deps/tree-ssa-structalias.TPo 
../../gcc-10.3.0/gcc/tree-ssa-structalias.c
during RTL pass: vartrack
../../gcc-10.3.0/gcc/tree-ssa-strlen.c: In function ‘void 
maybe_warn_overflow(gimple*, tree, const vr_values*, strinfo*, bool, bool)’:
../../gcc-10.3.0/gcc/tree-ssa-strlen.c:2336:1: internal compiler error: 
Segmentation fault
 2336 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1117: tree-ssa-strlen.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
'/tmp/guix-build-gcc-cross-sans-libc-aarch64-linux-gnu-10.3.0.drv-0/build/gcc'
make[1]: *** [Makefile:4372: all-gcc] Error 2
make[1]: Leaving directory 
'/tmp/guix-build-gcc-cross-sans-libc-aarch64-linux-gnu-10.3.0.drv-0/build'
make: *** [Makefile:939: all] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "4" "CFLAGS=-g0 
-O2") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `build' failed after 644.1 seconds
command "make" "-j" "4" "CFLAGS=-g0 -O2" failed with status 2
builder for 
`/gnu/store/j7qm4fhxbm85jg0nzhqm0h0bfc8gdlkx-gcc-cross-sans-libc-aarch64-linux-gnu-10.3.0.drv'
 failed with exit code 1
build of 
/gnu/store/j7qm4fhxbm85jg0nzhqm0h0bfc8gdlkx-gcc-cross-sans-libc-aarch64-linux-gnu-10.3.0.drv
 failed
View build log at 
'/var/log/guix/drvs/j7/qm4fhxbm85jg0nzhqm0h0bfc8gdlkx-gcc-cross-sans-libc-aarch64-linux-gnu-10.3.0.drv.bz2'.
cannot build derivation 
`/gnu/store/96m9gb9dsxd6adpgfyds86ndnxhf2rw9-glibc-cross-aarch64-linux-gnu-2.33.drv':
 1 dependencies couldn't be built
building 
/gnu/store/5n3y8gy3w924xm5zv1v65fz7lga8hs2d-pkg-config-aarch64-linux-gnu-0.29.2.drv...
cannot build derivation 
`/gnu/store/nzb1jx1xvp4vsh9qgbq455m1fvnj2vsn-grep-3.6.drv': 1 dependencies 
couldn't be built
guix build: error: build of 
`/gnu/store/nzb1jx1xvp4vsh9qgbq455m1fvnj2vsn-grep-3.6.drv' failed


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

bug#42091: mesa-20.0.8 fails during testing: preprocessor error: syntax error, unexpected end of file

[zimoun]

Hi,

Thanks for the report and sorry for the delay.

The package ’mesa’ is now at 20.2.4 using Guix 3694c0d.  The package
builds and the substitute is available.

How is it going for you?

All the best,
simon

bug#41943: kigo package fails to build

[zimoun]

Hi Leo,

Using Guix 3694c0d, the package ’kigo’ builds fine.

Closing?

Cheers,
simon

bug#25952: offloading: empty machines file leads to error

[zimoun]

Hi,

For reference: .

On Mon, 14 Sep 2020 at 19:26, zimoun  wrote:
> On Tue, 26 May 2020 at 00:43, zimoun  wrote:
>> On Mon, 25 May 2020 at 22:32, Tobias Geerinckx-Rice  wrote:
>>
>>> The issue is that files such as /etc/guix/machines.scm (but this
>>> applies equally to /etc/guix/acl & so on) are expected to evaluate
>>> to a sexp.
>>>
>>> An empty file does not a valid sexp make, so Guix throws an
>>> prickly backtrace @ your face & dies.  This is unlike most other
>>> configuration formats where an empty file or one consisting
>>> entirely of comments is a no-op.
>>
>> Hum? I am not sure to get the point.  Are we talking about this kind
>> of situations, e.g.,
>>
>> touch /tmp/empty.scm
>> guix package -m /tmp/empty.scm -p /tmp/empy
>>
>> or
>>
>> echo ";; hello" > /tmp/comment.scm
>> guix package -m /tmp/comment.scm -p /tmp/comment
>>
>> or
>>
>> echo "(define x 42)" > /tmp/answer.scm
>> guix package -m /tmp/answer.scm -p /tmp/answer
>>
>>
>> ?
>
> If we are talking about such cases, I think we can close this bug
> report.
>
>
>>> We should decide whether ‘’ is a valid sexp (oh dear, philosophy)
>>> or throw something softer at people.
>>
>> Throw something more "helping" than e.g.,
>>
>> Backtrace:
>>1 (primitive-load "/home/simon/.config/guix/current/bin/g…")
>> In guix/ui.scm:
>>   1936:12  0 (run-guix-command _ . _)
>>
>> guix/ui.scm:1936:12: In procedure run-guix-command:
>> In procedure struct-vtable: Wrong type argument in position 1
>> (expecting struct): #
>>
>> ?
>
> More helping as suggested for example in this message:
>
> 
>
> If yes, the bug report should be renamed.  And probably goes to the
> Guile bug tracker. :-)


What do we do?  What is the next action?  Close?  If not, please provide
explanations about what the issue really is and what could be the plan
to fix it. :-)

Cheers,
simon

bug#42301: Build of GNU Solfege fails

[zimoun]

Hi,

Using Guix 3694c0d, the package ’solfege’ builds and the substitute is
available.  The package ’lilypond’ too.

Something probably changed in the dependency chain since commit
145484e8f5d89911f5f905c9fe604e3cbfd1e434 (fail).

Closing?

All the best,
simon

bug#42760: Elixir build fails

[zimoun]

Hi,

Thanks for the report and sorry for the delay.

On Sat, 08 Aug 2020 at 13:04, Oskar Köök  wrote:

> Elixir build is failing for me. Don't have time to debug right now. This is
> the log:
>
> phase `unpack' succeeded after 0.2 seconds
> starting phase `make-git-checkout-writable'
> phase `make-git-checkout-writable' succeeded after 0.0 seconds
> starting phase `replace-paths'
> Backtrace:
>   18 (primitive-load "/gnu/store/7wsw0zq6zqvsqpl9g0j6gjanxwm…")
> In ice-9/eval.scm:
>    191:35 17 (_ #f)
> In guix/build/gnu-build-system.scm:
>     838:2 16 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
>   1736:10 15 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
>    857:16 14 (every1 # …)
> In guix/build/gnu-build-system.scm:
>    847:30 13 (_ _)
> In ice-9/eval.scm:
>     619:8 12 (_ #(#(#) (# # …) …))
>     619:8 11 (_ #(#(#(#) # #) #))
> In srfi/srfi-1.scm:
>     634:9 10 (for-each # _)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In ice-9/ports.scm:
>    445:17  8 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
> In guix/build/utils.scm:
>    741:26  7 (_ _)
>    767:26  6 (_ # #)
> In srfi/srfi-1.scm:
>    460:18  5 (fold # …)
> In ice-9/eval.scm:
>    202:51  4 (_ #(#(#(#(#(#(#(# …)) …) …) …) …) …))
>     163:9  3 (_ #(#(#(#(#(#(#(# …)) …) …) …) …) …))
> In unknown file:
>    2 (string-append "cmd(\"" #f)
> In ice-9/boot-9.scm:
>   1669:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
>
> In the latest commit the git input has been removed, which might be the issue:
> http://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a749caa74e2a44a37d3a4af06cf4c18f9e463fbb

Using Guix 3694c0d on x86_64, now the package elixir seems to build.  Is
it fine for you?  If yes, let close.  Otherwise, please provide more
information. :-)

All the best,
simon

bug#42810: Guix doesn't follow all symlinks

[zimoun]

Hi,

Thanks for your report.

On Tue, 11 Aug 2020 at 15:54, Steffen Rytter Postas  wrote:

> Some background first, to better understand the issue:
> I've been running Guix on a foreign distribution
> with my own channel in ~/.config/guix/channels.scm for some time now.
> However this means having to deal with doing both a `guix pull` as
>  a user, but also `guix pull` as superuser to keep the system
> builder daemon etc up to date.
> I wanted to avoid this, by using simply a system-wide guix install, and
> not have my own user have a guix variant. I tried simply deleting
> ~/.config/guix/current symlink, and confirmed that `guix` was now using
> the `/usr/local/bin/guix` symlink.
> Then I moved my ~/.config/guix/channels.scm file to
> /etc/guix/channels.scm
> and satisfied with my setup, performed `sudo guix pull --fallback` to
> pull the latest changes and verify it worked.
> The command ran as expected, and printed the new packages from my
> channel that were now available.
>
> So, that's the background of what I've been trying to do. Here's what
> happened:
>
> I have in my own channel a package called `entr-git`. Installing it is
> simple:
>
> `guix show entr-git`
>
> Expected result:
>
> name: entr-git
> version: 4.5-0.6b13a97
> outputs: out
> systems: x86_64-linux i686-linux
> dependencies: ncurses@6.2
> location: gnu/packages/entr-git.scm:25:2
> homepage: http://entrproject.org/
> license: ISC
> synopsis: Run arbitrary commands when files change
> description: entr is a zero-configuration tool with no external build
> or run-time dependencies.  The interface to entr is not only minimal,
> it aims to be simple enough to create a new
> + category of ad hoc automation.  These micro-tests reduce keystrokes,
> but more importantly they emphasize the utility of automated checks.
>
> Actual result:
>
> guix show: error: entr-git: package not found
>
> Additional information:
>
> `type guix`:
> /usr/local/bin/guix
>
> `readlink /usr/local/bin/guix`
> /var/guix/profiles/per-user/root/current-guix/bin/guix
>
> `/usr/local/bin/guix show entr-git`
> guix show: error: entr-git: package not found
>
> `/var/guix/profiles/per-user/root/current-guix/bin/guix show entr-git`
> name: entr-git
> version: 4.5-0.6b13a97
> outputs: out
> systems: x86_64-linux i686-linux
> dependencies: ncurses@6.2
> location: gnu/packages/entr-git.scm:25:2
> homepage: http://entrproject.org/
> license: ISC
> synopsis: Run arbitrary commands when files change
> description: entr is a zero-configuration tool with no external build
> or run-time dependencies.  The interface to entr is not only minimal,
> it aims to be simple enough to create a new
> + category of ad hoc automation.  These micro-tests reduce keystrokes,
> but more importantly they emphasize the utility of automated checks.
>
> Simplest reproduction of issue:
>
> * Ubuntu 20.04 AMD64 Desktop/Server system.
> * Install Guix using guix-install.sh script.
> * As a user, ensure absence of ~/.config/guix/current symlink.
> * As a user, run `guix pull --fallback`
> * As a user, run `guix describe`.
> * As a user, run `sudo guix describe`.
> * As root, run `guix describe`.
>
> Workaround:
>
> Use `/var/guix/profiles/per-user/root/current-guix/bin/guix` "directly"
> (despite this also being a symlink).
>
>
> I hope this is enough relevant information, otherwise it appears very
> straight forward to reproduce.

This bug is marked ’moreinfo’ since months and because I do not see how
it is actionable, I am closing.

If I miss something, please reopen it.

All the best,
simon

bug#42604: Manual section on building Guix from Git is incomplete

[zimoun]

Hi,

Thanks for the report.

On Wed, 29 Jul 2020 at 15:03, Tirifto  wrote:

> The manual describes how to fetch Guix from Git in section ‘14.1
> Building from Git’, including how to verify the authenticity of the
> copy. Quoting the part in question:
>
>> If you want to hack Guix itself, it is recommended to use the latest
>> version from the Git repository:
>>
>>  git clone https://git.savannah.gnu.org/git/guix.git
>>
>> How do you ensure that you obtained a genuine copy of the
>> repository? To do that, run ‘guix git authenticate’, passing if the
>> commit and OpenPGP fingerprint of the “channel introduction” (*note
>> Invoking guix git authenticate::):
>>
>>  guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \
>>"BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
>>
>> This command completes with exit code zero on success; it prints an
>> error message and exits with a non-zero code otherwise.
>
> I have encountered two problems here:
>
>   1.‘guix git authenticate’ only works after the branch ‘keyring’ has
>  been set up locally; I’ve been told to achieve this with the
>  command ‘git fetch upstream keyring:keyring’, but ‘git checkout
>  keyring’ has worked for me, too. After that, it seems to be
>  necessary to switch back to the master branch to successfully run
> ‘guix git authenticate’. I think the commands for this should be
>  included in this section.
>
>   2. The word ‘if’ seems to be a typo of ‘it’. I first thought that the
>  sentence was incomplete and that the command should pass if the
>  commit and the fingerprint [did something]. :)
>
> Not sure how the first one would be solved the best.

I think the latest [1] version of the manual fixes the 2 issue.  WDYT?

1: 

All the best,
simon

bug#42819: problem running xtensa-esp32-elf-g++

[zimoun]

Hi,

On Wed, 12 Aug 2020 at 11:55, Wensheng Xie  wrote:

> I have installed https://github.com/sudomesh/disaster-radio under guix
> 1.1.0

How did you install this package?


> ```
> wxie@guix ~/work/disaster-radio/firmware$ pip install -U platformio

This way is not related Guix, IMHO. :-)


> Defaulting to user installation because normal site-packages is not writeable
> Requirement already up-to-date: platformio in

[...]

> Requirement already satisfied, skipping upgrade: idna<3,>=2.5 in
> /home/wxie/.local/lib/python3.8/site-packages (from
> requests<3,>=2.4.0->platformio) (2.10)
> ```
>
> However, somehow the command is not working
> ```
> Converting main.ino
> sh:
> /home/wxie/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g++:
> Datei oder Verzeichnis nicht gefunden

Which package does provide this ’xtensa-esp32-elf-g++’?


All the best,
simon

bug#47636: building for foreign arches produces native code on core-updates

[Ludovic Courtès]

Efraim Flashner  skribis:

> $ ./pre-inst-env guix build hello --system=i686-linux
> /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10
> $ file /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello
> /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello: ELF 64-bit 
> LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
> /gnu/store/z543b5csaras5lhb5d4j3v3dl26i3dxm-glibc-2.32/lib/ld-linux-x86-64.so.2,
>  stripped

Fixed by 98c075c24e26798ef52ab66641faa7b0aa87726b, sorry for the delay!

Ludo’.

bug#48216: [CORE-UPDATES] host-inputs for wrong architecture when building for i686 on x86_64

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> I'm trying to see if the rust bootstrap process works on core-updates
> and I was unable to build for i686-linux on x86_64 linux. I failed to
> build xz, due to some assembly optimizations. It turns out that instead
> of using i686 binaries it was using x86_64 binaries and targeting i686,
> while passing flags saying it was i686.

That’s embarrassing.  I think this was fixed by
98c075c24e26798ef52ab66641faa7b0aa87726b.

Let me know if anything’s amiss!

Ludo’.

bug#43130: mailutils-3.10 test phase

[zimoun]

Hi Vladimir,

On Sun, 13 Dec 2020 at 15:37, Leo Famulari  wrote:
> On Mon, Aug 31, 2020 at 01:18:32PM +0600, Vladimir K wrote:

>> ## - ##
>> ## Test results. ##
>> ## - ##
>>
>> 2 tests were successful.
>> 1 test was skipped.
>>
>> command "make" "check" failed with status 2
>
> Hm, I don't see where it failed?
>
> The package appears to build successfully now. Are you still having
> trouble with it?

Using Guix 3694c0d, it builds fine on x86_64 and

  guix build --no-grafts --system=i686-linux mailutils

also builds fine.  What is your arch?  Do you still have the issue?


All the best,
simon

bug#42979: Some kde games are outdated

[zimoun]

Hi,

On Fri, 21 Aug 2020 at 15:33, Jesse Gibbons  wrote:
> The following KDE games fail to build:
>
> kblocks
> kdiamond
> kigo
> klines
> kollision
> lskat
>
> The upstream git repositories all have tags for version 20.8.0, but there are
> no source tarballs in the mirrors.

Using Guix 3694c0d, the version is now 20.12.0 and
https://bordeaux.guix.gnu.org provides all the substitutes.  Note that
“guix build --check” works fine too.

BTW, this

  $ guix gc -D $(guix build  -S)
  $ guix build  -S --no-substitutes

also works fine.  In my case, downloading from
.

Indeed the sources of 20.8.0 does not seem available upstream.
However, this version was not in Guix, AFAIK.  For instance,

  git log --grep=kigo

does not display a commit updating from 19.08.3 to 20.8.0.  The only
update is from 19.08.3 (d685f86054..f114a689e7) to 20.12.0
(908e48f7dd..3cd53b4500).  The version 19.08.3 seems removed from
upstream but we cannot do more; this source is still on ci.guix.gnu.org
and should be transparently available via Disarchive.

Well, I am in favor to close this bug.  WDYT?


All the best,
simon

bug#48064: texlive-* packages fail to build non-deterministically

[Ludovic Courtès]

Thiago Jung Bauermann  skribis:

> LuaTeX has a bug where sometimes it corrupts the heap and aborts. This
> causes the build of texlive packages to fail at random. The problem is
> being tracked at https://issues.guix.gnu.org/48064.
>
> While a fix isn't found, switch the default TeX format (and consequently
> also the engine) to pdftex to avoid the issue.
>
> * guix/build-system/texlive.scm (texlive-build): Change default value of
> the ‘tex-format’ key parameter to “pdftex”.

Pushed as 04f9f9158da348e8299e9ab90ec389ba81be46b0 with the text above
inlined as a FIXME comment.

On IRC there were concerns about Unicode support, which LuaTeX provides
but pdftex doesn’t (IIUC), but it would seem that the worst that can
happen is that documentation of the packages themselves would be
mangled, which is okay.

Anyway, it’d be ideal to get feedback from the LuaTeX folks!

Thanks,
Ludo’.

bug#41625: Sporadic guix-offload crashes due to EOF errors

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Now that I have root access to overdrive1, I could strace the sshd
> process (I just did 'strace -p340', noting the process of sshd displayed
> with 'herd status sshd'):
>
> pselect6(87, [3 4], NULL, NULL, NULL, NULL) = 1 (in [3])
> accept(3, {sa_family=AF_INET, sin_port=htons(33262), 
> sin_addr=inet_addr("66.158.152.121")}, [128->16]) = 5
> fcntl(5, F_GETFL)   = 0x2 (flags O_RDWR)
> pipe2([6, 7], 0)= 0
> socketpair(AF_UNIX, SOCK_STREAM, 0, [8, 9]) = 0
> clone(child_stack=NULL, 
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
> child_tidptr=0x8e0ef0e0) = 644
> close(7)= 0
> close(9)= 0
> write(8, "\0\0\1\245\0", 5) = 5
> write(8, "\0\0\1\234\nPort 22\nPermitRootLogin no\n"..., 420) = 420
> close(8)= 0
> close(5)= 0
> getpid()= 340
> getpid()= 340
> getpid()= 340
> getpid()= 340
> getpid()= 340
> getpid()= 340
> getpid()= 340
> pselect6(87, [3 4 6], NULL, NULL, NULL, NULL) = 1 (in [6])
> read(6, "\0", 1)= 1
> pselect6(87, [3 4 6], NULL, NULL, NULL, NULL) = 1 (in [6])
> read(6, "", 1)  = 0

OK, so it looks as if the client disconnected right away.  Hard to tell
exactly what that happened.  :-/  Perhaps turning libssh debugging on on
the client side could help (by uncommenting “#:log-verbosity 'protocol”
in (guix ssh)).

>>From c7b2ec1c58adf8c795df0a6aaf075dbc331f41e8 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Thu, 27 May 2021 08:44:44 -0400
> Subject: [PATCH 1/2] offload: Parallelize machine check in offload test.
>
> * guix/scripts/offload.scm (check-machine-availability): Refactor so that it
> takes a single machine object.  Ensure the cleanup code is always run.
> (check-machines-availability): New procedure.  Call
> CHECK-MACHINES-AVAILABILITY in parallel, which improves performance (about
> twice as fast with 4 build machines, from ~30 s to ~15 s).

I remain wary of this change, because that could lead to subtle
non-deterministic bugs (of the kind that keeps you busy for weeks) and
because I personally don’t mind if ‘guix offload test’ takes 30s on
berlin, and because the intermingled output may make diagnostics less
clear.

>>From b5558777617e4674a150895458d57d202de56120 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Tue, 25 May 2021 08:42:06 -0400
> Subject: [PATCH 2/2] offload: Handle a possible EOF response from
>  read-repl-response.
>
> Partially fixes .
>
> * guix/scripts/offload.scm (check-machine-availability): Handle the case where
> the checks raised an exception due to receiving EOF prematurely, and retry up
> to 3 times.
> * guix/inferior.scm (): New condition type.
> (read-repl-response): Raise a condition of the above type when reading EOF
> from the build machine's port.

LGTM!

Thanks,
Ludo’.

bug#48064: texlive-* packages fail to build non-deterministically

[Ludovic Courtès]

Hello!

Thiago Jung Bauermann  skribis:

> I have bad news and good news. :-)
>
> Unfortunately, TeX Live 2021 still has this bug. I tested version 20210325 
> (which is the latest on the historic TeX Live FTP site), with subversion 
> tag texlive-2021.3 (which is the latest tag in the TeX Live repo).

Bah.  Still, if you have the whole texlive upgrade, we should apply it!

> The good news is that I found a simple workaround: use pdftex instead of 
> luatex to build the affected packages. I am currently building all packages 
> matching ‘^texlive’ a few times to find the ones needing this workaround.
> So far, I found these:
>
> • texlive-amsfonts
> • texlive-amscls
> • texlive-babel
> • texlive-babel-swedish
> • texlive-latex-amsmath
> • texlive-generic-babel-english
> • texlive-latex-cyrillic
> • texlive-latex-graphics
> • texlive-latex-tools

We haven’t heard from dev-luatex yet.  I think we should go with this
workaround for now (those build failures are frequently preventing
evaluations at  from
completing, which is a real bummer).  Does using ‘pdftex’ rather than
‘luatex’ have an impact on the output of these packages?

Thanks!

Ludo’.

bug#48111: tilde in Go package names (eg. sourcehut hosted packages)

[Leo Prikler]

Hello,

Am Sonntag, den 04.07.2021, 15:51 -0700 schrieb Sarah Morgensen:
> It might be slightly uglier, but I think it's better to keep a
> consistent policy of "replace any invalid characters with a hyphen",
> as it is less likely to generate collisions and it provides a hint to
> the reader that there *is* a character there.
Fair enough, that's a reasonable take.

> I have attached a patch to do so below, verified that a recursive
> import of the package mentioned above builds without modification
> (well, I had to update a dependency...) and verified that there are
> not currently any go packages using a tilde in their name with:
> 
> $ egrep -r '"go-[^"]*~[^"]*"' gnu/packages
I couldn't verify this as the importer delivered 410s, but the patch
LGTM, so I pushed it.

Thanks,
Leo

bug#49372: lagrange: illegal instruction

[Efraim Flashner]

It sounds like everything's working now so I'm going to close the bug.

On Sun, Jul 04, 2021 at 05:40:41PM -0800, Christopher Howard wrote:
> I rebuilt from source and challenge now seems to be okay:
> 
> christopher@nightshade ~/Repos/guix-working$ guix challenge lagrange
> 
> 1 store items were analyzed:
>   - 1 (100.0%) were identical
>   - 0 (0.0%) differed
>   - 0 (0.0%) were inconclusive
> 
> -- 
> Christopher Howard
> my gemini capsule: gemini://gem.librehacker.com
> gemini browser: https://git.skyjake.fi/gemini/lagrange/releases
> 
> 
> On Sun, 2021-07-04 at 16:40 -0800, Christopher Howard wrote:
> > It seems to have downloaded as a substitute, and I was able to launch the 
> > program without getting an error.
> > 
> > ```
> > christopher@nightshade ~/Repos/guix-working$ guix build lagrange
> > 11.0 MB will be downloaded:
> >/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
> > substituting /gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2...
> > downloading from 
> > https://ci.guix.gnu.org/nar/lzip/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
> >  ...
> >  lagrange-1.5.2  11.4MiB
> > 
> >4.4MiB/s 00:03
> > [##] 100.0%
> > 
> > The following graft will be made:
> >/gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> > applying 3 grafts for 
> > /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv ...
> > grafting '/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2' -> 
> > '/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2'...
> > successfully built 
> > /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> > /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2
> > christopher@nightshade ~/Repos/guix-working$ 
> > /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2/bin/lagrange
> > 
> > (launched without trouble)
> > ```
> > 
> 

-- 
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