bug#20255: 'search-paths' should respect both user and system profile.

[Maxim Cournoyer]

Hello,

Alex Kost  writes:

> zimoun (2020-02-21 16:53 +0100) wrote:
>
>> Dear,
>>
>> What is the status of the bug#20255 [1]?
>> It is old; the last activity seems back on 2015, November. So let resume.
>>
>> The issue is, e.g.:
>>  - perl installed into the system profile
>>  - perl-xml-parser installed into an user profile
>> Then "guix package --search-paths" does not set correctly XML::Parser.
>>
>>
>> Fixes had been pushed: dedb17a and b2a7223 and cc3de1d.
>>
>> The final fix is still missing. Because it is a controversial patch
>> [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines of the
>> patch:
>>
>> +  eval `/run/current-system/profile/bin/guix package \\
>> +  -p /run/current-system/profile \\
>> +  -p \"$HOME/.guix-profile\" --search-paths`
>>
>>
>> The friendly "protest" [3] is about turning these lines optional via
>> an environment variable. I am not sure to follow where the discussion
>> had been going then.
>
> As for me, I am OK with any default setting as long as there is a way to
> change it.  I recall Ludovic proposed a patch that allowed to customize
> "/etc/profile" and I was happy about it, but he changed his mind on that
> patch so it was never committed.

Do you still have a vetted interest in the issue at hand?  This is a
serious usability problem that's been in limbo for 6 years, apparently
for reasons of purity (not wanting to run a command in /etc/profile).
While I share the sentiment that /etc/profile would better be 'inert' or
static, it seems we haven't been able to come up with a better solution
than calling 'guix package --search-paths'.  Like Ludovic, I also don't
find the idea of allowing users to override /etc/profile very appealing;
even if undocumented, its mere presence in the operating-system field
would be an invitation for problems.  An environment variable to disable
such basic functionality also seems backward to me.

I would personally be in favor of committing the fix as-is.  If < 1 s of
wasted time on boot is an issue, I suggest to look into GNU Shepherd to
offset it; optimization opportunities should abound :-).

Thank you,

Maxim

bug#18838: zsh test suite failures, possibly due to 'noatime' mount flag

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hello,
>
> Vincent Legoll  writes:
>
>> Is this still happening?
>>
>> I searched a bit on ci.guix.gnu.org...
>>
>> We have a failure on 5.8 armhf (already present on 5.7.1 version)
>> but it looks like it is a different set of tests that is failing...
>
> I can't find failures in the raw logs of the last CI failures for
> zsh-5.8, but testing on master with:
>
> ./pre-inst-env guix build --check --system=armhf-linux zsh
>
> I got 2 test failures:
>
> Test ./A01grammar.ztst failed: bad status 1, expected 0 from:
>   - $ZTST_testdir/../Src/zsh -fc "[[ \$0 = \"-$ZTST_testdir/../Src/zsh\" ]]"
> Was testing: `-' precommand modifier
> ./A01grammar.ztst: test failed.
> ./A02alias.ztst: starting.
> This test hangs the shell when it fails...
> ./A02alias.ztst: all tests successful.
> ./A03quoting.ztst: starting.
> ./A03quoting.ztst: all tests successful.
> ./A04redirect.ztst: starting.
> ./A04redirect.ztst: all tests successful.
> ./A05execution.ztst: starting.
> Unable to change MONITOR option
> This test takes 5 seconds to fail...
> Skipping pipe leak test, requires MONITOR option
> This test takes 3 seconds and hangs the shell when it fails...
> ./A05execution.ztst: all tests successful.
> ./A06assign.ztst: starting.
> ./A06assign.ztst: all tests successful.
> ./A07control.ztst: starting.
> ./A07control.ztst: all tests successful.
> ./B01cd.ztst: starting.
> Test ./B01cd.ztst failed: bad status 0, expected 1 from:
>  (unset HOME; ARGV0=sh $ZTST_testdir/../Src/zsh -c cd)
> Was testing: Implicit cd with unset HOME.

That was with QEMU user emulation.  Using overdrive1 (real ARM
hardware), I don't get any failure after multiple builds done via:

GUIX_DAEMON_SOCKET=ssh://overdrive1 guix build zsh \
  --system=aarch64-linux --no-grafts --check --rounds=5

It may be that the problem really has to do with the noatime flag, but
that's a bit too narrow for me to test.  If you can reproduce it again
on 5.8 and determine if noatime is at cause, that would be very helpful.

Closing for now, but feel free to reopen!

Maxim

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

[Maxim Cournoyer]

severity 44995 important
thanks

Hi,

Maxim Cournoyer  writes:

> Hello,
>
> I noticed that:
>
> guix build something --no-substitutes
>
> 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.

This problem seems to be generalized to many options.  The --rounds=N
also is not honored, and so is the --cores=N one.

Raising severity.

Maxim

bug#49230: please update description for package nyacc

[Matt Wette]

Hi All,

Could you please remove the "should be considered not stable" language from the 
description of the nyacc package?
The current text on the website (https://www.nongnu.org/nyacc) is the following 
gist:


NYACC, for Not Yet Another Compiler Compiler, is set of guile modules for
generating parsers and lexical analyzers.  It also provides sample parsers,
pretty-printers using SXML trees as an intermediate representation, a decent
C parser and a `FFI Helper' tool to help create Guile Scheme bindings for
C-based libraries.

Thanks,
Matt

bug#49228: guix import go fails when module does not have a documenation on pkg.go.dev

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Thanks for the report.

Björn Höfling  writes:

> $ ./pre-inst-env guix import go github.com/caspr-io/yamlpath 
> [...]
> ice-9/eval.scm:619:8: Throw to key `match-error' with args `("match" "no 
> matching pattern" #f)'.
>
> If you look at the page
>
> https://pkg.go.dev/github.com/caspr-io/yamlpath
>
> It has no Description, because the site cannot parse license
> information correctly and thus conservatively does not display any info.

There is currently a patch for this (mine; though I could have named it
better, I suppose):

https://issues.guix.gnu.org/49200

> Additionally, it would be nice if the go-module->guix-package would
> print out the module it would fetch next (like I did above). Then the
> broken module would be easier to find in recursive mode.

Error reporting in the importers is currently pretty inconsistent and
could use a lot of improvement. You might be interested in taking a look
at the PATCH v3 in  which somewhat
addresses this. Comments are always welcome! :)

Sarah

bug#49228: guix import go fails when module does not have a documenation on pkg.go.dev

[Björn Höfling]

$ ./pre-inst-env guix import go github.com/caspr-io/yamlpath 
go-module->guix-package module-path: github.com/caspr-io/yamlpath
Backtrace:
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   7 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  6 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  5 (_ #(#(#)))
In guix/ui.scm:
  2147:12  4 (run-guix-command _ . _)
In guix/scripts/import.scm:
   120:11  3 (guix-import . _)
In guix/scripts/import/go.scm:
   118:27  2 (guix-import-go . _)
In ice-9/eval.scm:
   293:34  1 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
619:8  0 (_ #(#(# #f)))

ice-9/eval.scm:619:8: Throw to key `match-error' with args `("match" "no 
matching pattern" #f)'.

If you look at the page

https://pkg.go.dev/github.com/caspr-io/yamlpath

It has no Description, because the site cannot parse license
information correctly and thus conservatively does not display any info.

Can be trivially fixed with this:

diff --git a/guix/import/go.scm b/guix/import/go.scm
index d110954664..10095b9d24 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -190,6 +194,7 @@ e.g. \"google.golang.org/protobuf/proto\"."
 (first description
 (match description*
   (() #f)   ;nothing selected
+  (#f #f)
 
Hope this is independent of the other go-importer-bugs we have, like:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49202
http://issues.guix.gnu.org/issue/45984

Additionally, it would be nice if the go-module->guix-package would
print out the module it would fetch next (like I did above). Then the
broken module would be easier to find in recursive mode.

Björn


pgpknVk_YBsrC.pgp
Description: OpenPGP digital signature

bug#49145: Cannot build Guix (Texinfo failure)

[HiPhish]

I actually looked into the offending files and I found that they are only half-
translated. Part of them is in German, but some parts are in English, and the 
English parts are referencing English node names, which obviously do not exist 
in the German manual.

I do not need the German manual, is there a way to skip it? A quick glance 
shows the same problem in the Spanish manual as well, and other manuals are 
probably affected as well. I don't know why `make` only choked up on the German 
manual though. Maybe because that's the first one in alphabetical order and 
`make` did not bother trying the rest? Or could it be because my machine is in 
Germany? The output of the `locale` command is:

$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

And when inside a pure Guix environment:

$ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

bug#49223: guix download nix failure

[Ludovic Courtès]

Hi,

Domagoj Stolfa  skribis:

> When running `make check-system` I bumped into a failure with nix:
>
> Starting download of 
> /gnu/store/ckqmds57xjz6zvziw52mgf844dp62mz4-nix-2.3.13.tar.xz
> From https://nixos.org/releases/nix/nix-2.3.13/nix-2.3.13.tar.xz...
> Throw to key `gnutls-error' with args `(# temporarily unavailable, try again.> handshake)'.
>
>
> It seems to be easily reproduced with:
> `guix download https://nixos.org/releases/nix/nix-2.3.13/nix-2.3.13.tar.xz`

Fixed in b36267b1d96ac344d2b42c9822ce04b4c3117f85.

Thanks for reporting the issue and for helping out on IRC together with
Tobias!

Ludo’.

bug#48520: rav1e 0.3.5 is not reproducible

[Maxim Cournoyer]

Hello,

Bone Baboon  writes:

> `guix describe` outputs:
>
> ```
> Generation 24   May 12 2021 18:06:24(current)
>   guix d6aeebb
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d6aeebb23639258311fdfb9dbf5f903079fde51a
> ```
>
> `guix challenge /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5`
> outputs:
>
> ```
> /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5 contents differ:
>   local hash: 0lr47rfaq41yn3sbf86xnwpsrgvi38ifi3hx5dz3cm5iinfwaxc0
>   
> https://ci.guix.gnu.org/nar/lzip/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5:
>  17g58f754k0n5hwiysb88cz9fg82di2j244zzh9mnv6a172y4xjb
>   differing file:
> /share/cargo/registry/rav1e-0.3.5.crate
>
> 1 store items were analyzed:
>   - 0 (0.0%) were identical
>   - 1 (100.0%) differed
>   - 0 (0.0%) were inconclusive
> ```
>
> `guix challenge --diff=diffoscope
> /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5` outputs:
>
> ```
> /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5 contents differ:
>   local hash: 0lr47rfaq41yn3sbf86xnwpsrgvi38ifi3hx5dz3cm5iinfwaxc0
>   
> https://ci.guix.gnu.org/nar/lzip/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5:
>  17g58f754k0n5hwiysb88cz9fg82di2j244zzh9mnv6a172y4xjb
> --- /tmp/guix-directory.3zSn14
> +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5
> │   --- /tmp/guix-directory.3zSn14/share
> ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share
> │ │   --- /tmp/guix-directory.3zSn14/share/cargo
> │ ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo
> │ │ │   --- /tmp/guix-directory.3zSn14/share/cargo/registry
> │ │ ├── +++ 
> /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo/registry
> │ │ │ │   --- 
> /tmp/guix-directory.3zSn14/share/cargo/registry/rav1e-0.3.5.crate
> │ │ │ ├── +++ 
> /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo/registry/rav1e-0.3.5.crate
> │ │ │ │ ├── rav1e-0.3.5.crate-content
> │ │ │ │ │ ├── file list
> │ │ │ │ │ │ @@ -1,9 +1,9 @@
> │ │ │ │ │ │ --rw-r--r--   00039196 2021-04-03 
> 18:35:22.00 rav1e-0.3.5/Cargo.lock
> │ │ │ │ │ │ --rw-r--r--   000 4228 2021-04-03 
> 18:35:22.00 rav1e-0.3.5/Cargo.toml
> │ │ │ │ │ │ +-rw-r--r--   00039196 2021-04-21 
> 15:38:10.00 rav1e-0.3.5/Cargo.lock
> │ │ │ │ │ │ +-rw-r--r--   000 4228 2021-04-21 
> 15:38:10.00 rav1e-0.3.5/Cargo.toml
> │ │ │ │ │ │  -rw-r--r--   0  9993 4228 2020-12-31 
> 14:44:40.00 rav1e-0.3.5/Cargo.toml.orig
> │ │ │ │ │ │  -rw-r--r--   0  9993 1332 2020-11-16 
> 12:40:01.00 rav1e-0.3.5/LICENSE
> │ │ │ │ │ │  -rw-r--r--   0  9993 5702 2017-09-24 
> 10:10:31.00 rav1e-0.3.5/PATENTS
> │ │ │ │ │ │  -rw-r--r--   0  9993 5820 2020-12-31 
> 12:00:53.00 rav1e-0.3.5/README.md
> │ │ │ │ │ │  -rw-r--r--   0  9993 4333 2020-12-31 
> 12:00:53.00 rav1e-0.3.5/build.rs
> │ │ │ │ │ │  -rw-r--r--   0  9993  423 2020-12-31 
> 12:00:53.00 rav1e-0.3.5/cbindgen.toml
> │ │ │ │ │ │  -rw-r--r--   0  9993 3579 2020-12-31 
> 12:00:53.00 rav1e-0.3.5/src/activity.rs
>
> 1 store items were analyzed:
>   - 0 (0.0%) were identical
>   - 1 (100.0%) differed
>   - 0 (0.0%) were inconclusive
> ```

Still reproducible with 0.4.1.  It seems the generated files uid/gid are
causing the discrepancy.  Not sure how that comes to be.  Needs
investigation.  I see nix passes '--frozen' to cargo, but that doesn't
work for us: "Cargo.lock needs to be updated but --frozen was passed to
prevent this".  Not sure if it's key.

To be investigated!

Thanks for the report,

Maxim

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

[Leo Prikler]

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:
> > > 
> > > > Hi,
> > > > 
> > > > Am Samstag, den 12.06.2021, 20:09 + schrieb 
> > > > jbra...@dismail.de:
> > > > > June 12, 2021 3:39 PM, "Leo Prikler" <
> > > > > leo.prik...@student.tugraz.at>
> > > > > wrote:
> > > > > 
> > > > > > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua
> > > > > > Branson:
> > > > > > 
> > > > > > > Hello!
> > > > > > > 
> > > > > I'll tell you what, why don't we leave this "bug" open for a
> > > > > week...I'll try to write
> > > > > the code that does what I want, and I'll email the answer.
> > > > > 
> > > > > Then I'll edit the manual to provide an example!
> > > Well, it's been about a week. Here is my current code that
> > > doesn't
> > > work.
> > > haha.
> > > 
> > > #+BEGIN_SRC scheme
> > > (define %my-desktop-services
> > >   (modify-services %desktop-services ;;end of remove services
> > > (mingetty-service-type config =>
> > >(mingetty-configuration
> > > (inherit config)
> > > ;; ERROR at the NEXT LINE
> > > (auto-login-to-tty-3 config)
> > > 
> > > 
> > > (define (auto-login-to-tty-3 config)
> > >   (if (string=? "3" (mingetty-configuration-tty config))
> > >   '(auto-login "joshua")
> > >   '(auto-login #f)))
> > > #+END_SRC
> > > 
> > > It obviously doesn't work because I am treating modify-services
> > > as if
> > > it were a procedure.  In fact, it is a macro.  :)
> > That's not the issue here, the issue is that you're treating
> > mingetty-
> > configuration as… I'm not really sure what exactly, when it is in
> > fact
> > a record constructor.
> 
> Oh Light bulb!  I knew that!  I've made quite a few record
> constructors for endlessh and my almost complete sway service:
> 
> http://issues.guix.gnu.org/39136
> https://notabug.org/jbranso/guix-config/src/master/sway-service.scm
> 
> > Try the following:
> > 
> > #+BEGIN_SRC scheme
> > (define (auto-login-to-tty tty user)
> >   ;; TODO: you might want to implement this as match-lambda instead
> 
> I will try that!
> 
> >   (lambda (config)
> > (if (string=? tty (mingetty-configuration-tty mingetty-config))
> > (mingetty-configuration
> >   (inherit config)
> >   (auto-login user))
> > config)))
> > 
> > (define %my-desktop-services
> >   (modify-services %desktop-services
> > 
> > (mingetty-service-type config =>
> >   (auto-login-
> > to-tty "3" "joshua"
> > #+END_SRC
> > 
> 
> Hmmm.  Is that (define (auto-login-to-tty tty user) ...) a
> closure?  I
> wonder why you need that lambda inside of it...Probably to pass the
> config variable into the function...hmmm.  I still don't understand
> why
> it is necessary.  I'll think about that a bit later on.
Yes, I've made it a bit more generic, so that you could also add let's
say (auto-login-to-tty "4" "nsa-backdoor") if you wanted ;)

You need a single-argument procedure in the config => proc part.  So
you generate a closure to do everything else.  You could do the same
with let-bindings inside the scope of modify-services, but I found it
more useful to extract that.

> > > #+BEGIN_SRC scheme
> > > (define (auto-login-to-tty-3 mingetty-service)
> > >   (if (string=? "3" (mingetty-configuration-tty config))
> > >   '(mingetty-configuration
> > >  (auto-login "joshua")
> > >  (tty "3"))
> > >   mingetty-service))
> > Don't quote mingetty-configuration et al.  They're first-class
> > syntax,
> > not just weird lists.
> 
> Yeah that's true.  I do actually like (guix records)!  I feel like
> that file should be upstreamed into guile!
Haha, yes, guixy records are a charm, but they're subject to quicker
iteration than guile's.

> > > (define (my-modify-%desktop-services-to-auto-login-on-tty-3
> > > %desktop-
> > > services)
> > >;; to be written
> > >;; though I think fold, or map, may be useful functions here.
> > > 
> > >;;somehow I will use this function...
> > > (auto-login-to-tty-3 mingetty-service)
> > > )
> > > 
> > > (define %my-desktop-services
> > > (my-modify-%desktop-services-to-auto-login-on-tty-3
> > > %desktop-
> > > services))
> > I don't think you need to implement modify-services on your own,
> > rather
> > just use the existing thing in the "correct" way – i.e. adhering to
> > the
> > expectations given by the already existing procedure (or macro).
> 
> 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 

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 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
>> Leo Prikler  writes:
>>
>> > Hi,
>> >
>> > Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de:
>> > > June 12, 2021 3:39 PM, "Leo Prikler" <
>> > > leo.prik...@student.tugraz.at>
>> > > wrote:
>> > >
>> > > > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson:
>> > > >
>> > > > > Hello!
>> > > > >
>> > > I'll tell you what, why don't we leave this "bug" open for a
>> > > week...I'll try to write
>> > > the code that does what I want, and I'll email the answer.
>> > >
>> > > Then I'll edit the manual to provide an example!
>> Well, it's been about a week. Here is my current code that doesn't
>> work.
>> haha.
>>
>> #+BEGIN_SRC scheme
>> (define %my-desktop-services
>>   (modify-services %desktop-services ;;end of remove services
>> (mingetty-service-type config =>
>>(mingetty-configuration
>> (inherit config)
>> ;; ERROR at the NEXT LINE
>> (auto-login-to-tty-3 config)
>> 
>>
>> (define (auto-login-to-tty-3 config)
>>   (if (string=? "3" (mingetty-configuration-tty config))
>>   '(auto-login "joshua")
>>   '(auto-login #f)))
>> #+END_SRC
>>
>> It obviously doesn't work because I am treating modify-services as if
>> it were a procedure.  In fact, it is a macro.  :)
> That's not the issue here, the issue is that you're treating mingetty-
> configuration as… I'm not really sure what exactly, when it is in fact
> a record constructor.

Oh Light bulb!  I knew that!  I've made quite a few record
constructors for endlessh and my almost complete sway service:

http://issues.guix.gnu.org/39136
https://notabug.org/jbranso/guix-config/src/master/sway-service.scm

>
> Try the following:
>
> #+BEGIN_SRC scheme
> (define (auto-login-to-tty tty user)
>   ;; TODO: you might want to implement this as match-lambda instead

I will try that!

>   (lambda (config)
> (if (string=? tty (mingetty-configuration-tty mingetty-config))
> (mingetty-configuration
>   (inherit config)
>   (auto-login user))
> config)))
>
> (define %my-desktop-services
>   (modify-services %desktop-services
>
> (mingetty-service-type config =>
>   (auto-login-
> to-tty "3" "joshua"
> #+END_SRC
>

Hmmm.  Is that (define (auto-login-to-tty tty user) ...) a closure?  I
wonder why you need that lambda inside of it...Probably to pass the
config variable into the function...hmmm.  I still don't understand why
it is necessary.  I'll think about that a bit later on.

>
>> #+BEGIN_SRC scheme
>> (define (auto-login-to-tty-3 mingetty-service)
>>   (if (string=? "3" (mingetty-configuration-tty config))
>>   '(mingetty-configuration
>>  (auto-login "joshua")
>>  (tty "3"))
>>   mingetty-service))
> Don't quote mingetty-configuration et al.  They're first-class syntax,
> not just weird lists.

Yeah that's true.  I do actually like (guix records)!  I feel like that
file should be upstreamed into guile!

>
>> (define (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
>> services)
>>;; to be written
>>;; though I think fold, or map, may be useful functions here.
>>
>>;;somehow I will use this function...
>> (auto-login-to-tty-3 mingetty-service)
>> )
>>
>> (define %my-desktop-services
>> (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
>> services))
> I don't think you need to implement modify-services on your own, rather
> just use the existing thing in the "correct" way – i.e. adhering to the
> expectations given by the already existing procedure (or macro).

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?

>> #+END_SRC
> 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#49202: guix import go type error (failed regex match?)

[zimoun]

Hi,

On jeu., 24 juin 2021 at 01:32, raingloom  wrote:
> When I run
> guix import go -r github.com/golang-migrate/migrate/v4
> it works for a looong time (something else to work on I guess. maybe
> fetching every git repo is not the best solution.) and then gives this
> error:
>
> In procedure vector-ref: Wrong type argument in position 1 (expecting
> vector): #f

Using v3 from patch#49196 [1], I get the piece below.  As mentioned by
Sarah, the parser seems poor for some dependencies.

1: 

--8<---cut here---start->8---
$ ./pre-inst-env guix import go -r github.com/golang-migrate/migrate/v4
following redirection to `https://go.mongodb.org/mongo-driver/'...
following redirection to `https://github.com/moby/moby?go-get=1'...
guix import: warning: Something went wrong with 
("github.com/containerd/containerd" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("github.com/cockroachdb/cockroach-go" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("github.com/bmizerany/assert" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("cloud.google.com/go/storage" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("cloud.google.com/go/spanner" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("go.opentelemetry.io/otel/sdk" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("go.opentelemetry.io/otel/metric" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("github.com/go-gl/glfw/v3.3/glfw" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("dmitri.shuralyov.com/gpu/mtl" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("github.com/hudl/fargo" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
following redirection to 
`https://github.com/HdrHistogram/hdrhistogram-go?go-get=1'...
guix import: warning: Failed to import package "github.com/cncf/udpa/go".
reason: "https://pkg.go.dev/github.com/cncf/udpa; could not be fetched: HTTP 
error 404 ("Not Found").
This package and its dependencies won't be imported.
guix import: warning: Something went wrong with 
("go.opentelemetry.io/proto/otlp" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Failed to import package "github.com/cncf/xds/go".
reason: "https://pkg.go.dev/github.com/cncf/xds; could not be fetched: HTTP 
error 404 ("Not Found").
This package and its dependencies won't be imported.
following redirection to `https://github.com/jtolio/gls?go-get=1'...
guix import: warning: Something went wrong with 
("github.com/neelance/sourcemap" #:goproxy "https://proxy.golang.org; #:version 
#f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("github.com/neelance/astrewrite" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("github.com/jcmturner/dnsutils/v2" #:goproxy "https://proxy.golang.org; 
#:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("github.com/shirou/gopsutil/v3" #:goproxy "https://proxy.golang.org; #:version 
#f #:pin-versions? #f).
following redirection to 
`https://github.com/openhistogram/circonusllhist?go-get=1'...
guix import: warning: Something went wrong with ("gonum.org/v1/gonum" #:goproxy 
"https://proxy.golang.org; #:version #f #:pin-versions? #f).
following redirection to `https://proxy.golang.org/@v/list'...
guix import: warning: Failed to import package "//".
reason: "https://proxy.golang.org/@v/list; could not be fetched: HTTP error 410 
("Gone").
This package and its dependencies won't be imported.
guix import: warning: Something went wrong with ("github.com/chzyer/test" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("github.com/chzyer/logex" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with 
("google.golang.org/grpc/cmd/protoc-gen-go-grpc" #:goproxy 
"https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("github.com/gobuffalo/gogen" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: warning: Something went wrong with ("github.com/markbates/safe" 
#:goproxy "https://proxy.golang.org; #:version #f #:pin-versions? #f).
guix import: 

bug#49168: ‘guix import pypi’ misses package dependencies

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

[...]

>> Perhaps it'd be best to raise the issue to the package maintainers and
>> have them specify their metadata correctly?
>
> Going back to the example at the beginning of this thread, what ‘guix
> import pypi tablib’ produces is missing ‘python-setuptools-scm’.
> Indeed, ‘METADATA’ doesn’t mention it.
>
> Is it really a bug on their side, or is it something peculiar about Guix
> packaging?  Perhaps ‘python-setuptools-scm’ should be provided more or
> less by default?

Hmm, sorry, I had lost track of what the original missing dependencies
were.  In this case (setuptools-scm), it is special in that it extends
the setuptools build system; it must be loaded early by setuptools, so
perhaps that explains why the dependency doesn't show as required in
METADATA.  I think going forward with the revised PEP 517 build system [0]
will alleviate such issues, by allowing to declare the build system and
its dependencies in a TOML file.

In the mean time, the statu quo seems the best option to me (manually
specify the setuptools extensions as native-inputs for the python
packages that need it).  We should look forward adjusting our importer
to the latest PEP 517 trends (along the PEP 517 build system patches
awaiting review for core-updates!), which are quickly becoming
ubiquitous in the Python world.

[0]  https://www.python.org/dev/peps/pep-0517/

HTH,

Maxim

bug#49226: tidy build failure: invoke error

[Leo Prikler]

This appears to be a non-deterministic failure, as I too got it, but
with a later file.  Since we're still using the same cvs binary, I
don't think it's the fault of the build environment.

Regards,
Leo

bug#49168: ‘guix import pypi’ misses package dependencies

[Leo Prikler]

Am Freitag, den 25.06.2021, 16:51 +0200 schrieb Ludovic Courtès:
> Hello,
> 
> Maxim Cournoyer  skribis:
> 
> > Ludovic Courtès  writes:
> 
> [...]
> 
> > > Why does the importer favor .whl in the first place?  Is it
> > > supposed to
> > > be more accurate or more widespread or something?
> > 
> > Yes, the METADATA file from the binary wheel is a better place to
> > look
> > than the source egg-info requires.txt file.  In my commit
> > 01589acc5e1, I
> > simplified a comment that used used to read as:
> > 
> > -  ;; First, try to compute the requirements using the wheel, since
> > that is the
> > -  ;; most reliable option. If a wheel is not provided for this
> > package, try
> > -  ;; getting them by reading either the "requirements.txt" file or
> > the
> > -  ;; "requires.txt" from the egg-info directory from the source
> > tarball. Note
> > -  ;; that "requirements.txt" is not mandatory, so this is likely
> > to fail.
> > +  ;; First, try to compute the requirements using the wheel, else,
> > fallback to
> > +  ;; reading the "requires.txt" from the egg-info directory from
> > the source
> > +  ;; tarball.
> > 
> > The wheel (.whl) binary format is well specified as PEP 427 [0] and
> > is
> > what pip primarily uses for installing Python packages, making it a
> > very
> > reliable source of metadata.  The Python egg is the predecessor of
> > the
> > wheel, and can be considered obsolete, which explains why it's used
> > as a
> > fallback.
> 
> Oh, I see.
> 
> > Perhaps it'd be best to raise the issue to the package maintainers
> > and
> > have them specify their metadata correctly?
> 
> Going back to the example at the beginning of this thread, what ‘guix
> import pypi tablib’ produces is missing ‘python-setuptools-scm’.
> Indeed, ‘METADATA’ doesn’t mention it.
> 
> Is it really a bug on their side, or is it something peculiar about
> Guix
> packaging?  Perhaps ‘python-setuptools-scm’ should be provided more
> or
> less by default?
Perhaps both?  It probably depends on how setuptools are used, but this
use appears internal to the mechanisms of setuptools itself and not
something, that requires.txt is concerned about.  In particular, I
think it is only relevant to the setup.py script and can probably be
detected by the presence of a certain form within it.

I'm not sure on the number of packages, that use this package vs. those
that don't, but I personally don't think we should make it an input in
every package.  It is probably already a native-input to those that
need it (or at least probably should be if it's propagated instead).

Of course we would also have to look at the METADATA of other packages
and check whether they actually mention python-setuptools-scm or are
also unaware of the dependency.

Regards,
Leo

bug#49226: tidy build failure: invoke error

[Christopher Howard]

When I try to build tidy without substitutes, I get error:

build of /gnu/store/zlr12hkdpxa4dwkkcw6v13rn14xmq9jb-tidy-20091223-
checkout.drv failed
View build log at
'/var/log/guix/drvs/zl/r12hkdpxa4dwkkcw6v13rn14xmq9jb-tidy-20091223-
checkout.drv.bz2'.

Here is the log:

guile: warning: failed to install locale
cvs checkout: warning: failed to open /homeless-shelter/.cvspass for
reading: No such file or directory
cvs checkout: Updating tidy
cvs checkout: Updating tidy/CVSROOT
U tidy/CVSROOT/checkoutlist
U tidy/CVSROOT/commitinfo
U tidy/CVSROOT/config
U tidy/CVSROOT/cvswrappers
U tidy/CVSROOT/editinfo
cvs [checkout aborted]: end of file from server (consult above messages
if any)
Backtrace:
   3 (primitive-load "/gnu/store/qyvwvr1dmc6hcv65y269xznby6g?")
In ice-9/eval.scm:
   293:34  2 (_ #)
In guix/build/cvs.scm:
 58:2  1 (cvs-fetch ":pserver:anonym...@tidy.cvs.sourceforge.ne?"
?)
In guix/build/utils.scm:
654:6  0 (invoke _ . _)

guix/build/utils.scm:654:6: In procedure invoke:
ERROR:
  1. :
  program: "/gnu/store/7aqqa3bqixha3yypims7lk4bcyzl01p8-cvs-
1.12.13/bin/cvs"
  arguments: ("-z0" "-d" ":pserver:
anonym...@tidy.cvs.sourceforge.net:/cvsroot/tidy" "checkout" "-D"
"2009-12-23" "tidy")
  exit-status: 1
  term-signal: #f
  stop-signal: #f

I can run the same fetch command from the command line and I do not
have trouble getting a checkout.

Here is my system information:

christopher@nightshade ~$ neofetch --stdout
christopher@nightshade 
-- 
OS: Guix System ad879bffa3562fdbd12063cfa129fcaa57290eab x86_64 
Host: GA-880GM-UD2H 
Kernel: 5.12.9-gnu 
Uptime: 1 day, 38 mins 
Packages: 107 (guix-system), 101 (guix-user) 
Shell: bash 5.0.16 
Resolution: 1920x1200 
DE: GNOME 3.34.5 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: kitty 
CPU: AMD Athlon II X3 455 (3) @ 3.300GHz 
GPU: NVIDIA GeForce 8400 GS Rev. 3 
Memory: 1980MiB / 7957MiB

-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

bug#49168: ‘guix import pypi’ misses package dependencies

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Why does the importer favor .whl in the first place?  Is it supposed to
>> be more accurate or more widespread or something?
>
> Yes, the METADATA file from the binary wheel is a better place to look
> than the source egg-info requires.txt file.  In my commit 01589acc5e1, I
> simplified a comment that used used to read as:
>
> -  ;; First, try to compute the requirements using the wheel, since that is 
> the
> -  ;; most reliable option. If a wheel is not provided for this package, try
> -  ;; getting them by reading either the "requirements.txt" file or the
> -  ;; "requires.txt" from the egg-info directory from the source tarball. Note
> -  ;; that "requirements.txt" is not mandatory, so this is likely to fail.
> +  ;; First, try to compute the requirements using the wheel, else, fallback 
> to
> +  ;; reading the "requires.txt" from the egg-info directory from the source
> +  ;; tarball.
>
> The wheel (.whl) binary format is well specified as PEP 427 [0] and is
> what pip primarily uses for installing Python packages, making it a very
> reliable source of metadata.  The Python egg is the predecessor of the
> wheel, and can be considered obsolete, which explains why it's used as a
> fallback.

Oh, I see.

> Perhaps it'd be best to raise the issue to the package maintainers and
> have them specify their metadata correctly?

Going back to the example at the beginning of this thread, what ‘guix
import pypi tablib’ produces is missing ‘python-setuptools-scm’.
Indeed, ‘METADATA’ doesn’t mention it.

Is it really a bug on their side, or is it something peculiar about Guix
packaging?  Perhaps ‘python-setuptools-scm’ should be provided more or
less by default?

> Having the code you wrote to allow importing optional dependencies is
> still a nice (optional) option to have though.  It was originally left
> out based on comments from Ricardo that it wouldn't make a good default
> due to raising the packaging effort.

OK.  Looking at , the
‘METADATA’ format apparently doesn’t support optional dependencies
anyway (which makes sense, because Wheels are a binary format), so
perhaps that idea was misguided.

(However ‘METADATA’ defines ‘Requires-External’, which the importer
could usefully interpret!)

WDYT?

Ludo’.

bug#49225: Possibly difficult to reproduce GnuTLS build bug?

[Domagoj Stolfa]

Hello:

While running `make check-system`, I've encountered an issue with building
GnuTLS (see attached drv file).

Upon re-cloning the repository on the exact same commit, reconfiguring it in
the exact same way and re-running `make check-system`, GnuTLS built just fine.
I'm not quite sure how one could go about debugging this, but it might be good
for this bug report to exist in case others run into it.

--
Domagoj


drv.tar.gz
Description: application/tar-gz


signature.asc
Description: PGP signature

bug#49223: guix download nix failure

[Domagoj Stolfa]

Hello:

When running `make check-system` I bumped into a failure with nix:

Starting download of 
/gnu/store/ckqmds57xjz6zvziw52mgf844dp62mz4-nix-2.3.13.tar.xz
From https://nixos.org/releases/nix/nix-2.3.13/nix-2.3.13.tar.xz...
Throw to key `gnutls-error' with args `(# handshake)'.


It seems to be easily reproduced with:
`guix download https://nixos.org/releases/nix/nix-2.3.13/nix-2.3.13.tar.xz`

--
Domagoj


signature.asc
Description: PGP signature

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

[Leo Prikler]

Hi,

Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
> Leo Prikler  writes:
> 
> > Hi,
> > 
> > Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de:
> > > June 12, 2021 3:39 PM, "Leo Prikler" <
> > > leo.prik...@student.tugraz.at>
> > > wrote:
> > > 
> > > > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson:
> > > > 
> > > > > Hello!
> > > > > 
> > > I'll tell you what, why don't we leave this "bug" open for a
> > > week...I'll try to write
> > > the code that does what I want, and I'll email the answer.
> > > 
> > > Then I'll edit the manual to provide an example!
> > I'm pretty sure that the actual bug also exists, just not sure
> > whether
> > that's on your config or on shepherd.  Using TTY1 for graphical
> > stuff
> > is also somewhat rare in Guix land, I presume.  (Or rather, I can't
> > think of it as anything but a container for debug output spam :D)
> > 
> > As for getting this to work only on TTY1, you do get the config
> > object,
> > so you can do stuff like
> >   (if (is-tty1? config) (inherit+autologin config) config)
> > Note of course, that is-tty1? is not a procedure that's ready-made, 
> > but
> > one that you'd need to build from primitives such as record
> > accessors.
> > 
> 
> Well, it's been about a week. Here is my current code that doesn't
> work.
> haha.
> 
> #+BEGIN_SRC scheme
> (define %my-desktop-services
>   (modify-services %desktop-services ;;end of remove services
> (mingetty-service-type config =>
>(mingetty-configuration
> (inherit config)
> ;; ERROR at the NEXT LINE
> (auto-login-to-tty-3 config)
> 
> 
> (define (auto-login-to-tty-3 config)
>   (if (string=? "3" (mingetty-configuration-tty config))
>   '(auto-login "joshua")
>   '(auto-login #f)))
> #+END_SRC
> 
> It obviously doesn't work because I am treating modify-services as if
> it were a procedure.  In fact, it is a macro.  :)
That's not the issue here, the issue is that you're treating mingetty-
configuration as… I'm not really sure what exactly, when it is in fact
a record constructor.  

Try the following:
#+BEGIN_SRC scheme
(define (auto-login-to-tty tty user)
  ;; TODO: you might want to implement this as match-lambda instead
  (lambda (config)
(if (string=? tty (mingetty-configuration-tty mingetty-config))
(mingetty-configuration
  (inherit config)
  (auto-login user))
config)))

(define %my-desktop-services
  (modify-services %desktop-services
   
(mingetty-service-type config => 
  (auto-login-
to-tty "3" "joshua"
#+END_SRC


> #+BEGIN_SRC scheme
> (define (auto-login-to-tty-3 mingetty-service)
>   (if (string=? "3" (mingetty-configuration-tty config))
>   '(mingetty-configuration
>  (auto-login "joshua")
>  (tty "3"))
>   mingetty-service))
Don't quote mingetty-configuration et al.  They're first-class syntax,
not just weird lists.

> (define (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
> services)
>;; to be written
>;; though I think fold, or map, may be useful functions here.
> 
>;;somehow I will use this function...
> (auto-login-to-tty-3 mingetty-service)
> )
> 
> (define %my-desktop-services
> (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
> services))
I don't think you need to implement modify-services on your own, rather
just use the existing thing in the "correct" way – i.e. adhering to the
expectations given by the already existing procedure (or macro).
> #+END_SRC
Regards,
Leo

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

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Hi,
>
> Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de:
>> June 12, 2021 3:39 PM, "Leo Prikler" 
>> wrote:
>>
>> > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson:
>> >
>> > > Hello!
>> > >
>> I'll tell you what, why don't we leave this "bug" open for a
>> week...I'll try to write
>> the code that does what I want, and I'll email the answer.
>>
>> Then I'll edit the manual to provide an example!
> I'm pretty sure that the actual bug also exists, just not sure whether
> that's on your config or on shepherd.  Using TTY1 for graphical stuff
> is also somewhat rare in Guix land, I presume.  (Or rather, I can't
> think of it as anything but a container for debug output spam :D)
>
> As for getting this to work only on TTY1, you do get the config object,
> so you can do stuff like
>   (if (is-tty1? config) (inherit+autologin config) config)
> Note of course, that is-tty1? is not a procedure that's ready-made, but
> one that you'd need to build from primitives such as record accessors.
>

Well, it's been about a week. Here is my current code that doesn't work.
haha.

#+BEGIN_SRC scheme
(define %my-desktop-services
  (modify-services %desktop-services ;;end of remove services
(mingetty-service-type config =>
   (mingetty-configuration
(inherit config)
;; ERROR at the NEXT LINE
(auto-login-to-tty-3 config)


(define (auto-login-to-tty-3 config)
  (if (string=? "3" (mingetty-configuration-tty config))
  '(auto-login "joshua")
  '(auto-login #f)))
#+END_SRC

It obviously doesn't work because I am treating modify-services as if it
were a procedure.  In fact, it is a macro.  :)

I'm just popping in to give you an update on my progress.  I've probably
spent less than 20 minutes working on this.  The good news is I did find
the record accessor for tty is mingetty-configuration-tty.

My goal for the next week is to do something like this:

#+BEGIN_SRC scheme
(define (auto-login-to-tty-3 mingetty-service)
  (if (string=? "3" (mingetty-configuration-tty config))
  '(mingetty-configuration
 (auto-login "joshua")
 (tty "3"))
  mingetty-service))

(define (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-services)
   ;; to be written
   ;; though I think fold, or map, may be useful functions here.

   ;;somehow I will use this function...
(auto-login-to-tty-3 mingetty-service)
)

(define %my-desktop-services
(my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-services))
#+END_SRC


I'll post again in about a week to tell you about my progress!

--
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#49220: LuaJIT on powerpc64le-linux-gnu (POWER9)?

[Chris Marusich]

Hi LuaJIT community,

Is anyone in the LuaJIT community actively working on adding support for
the powerpc64le architecture?  Specifically, I am wondering about the
powerpc64le-linux-gnu triplet, running on POWER9-based systems like the
Talos II and Blackbird sold by Raptor Computing Systems.

I ask because LuaJIT has been packaged for Guix, but it currently fails
to build on this platform, as explained in the following Guix bug
report:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49220

Based on the error output, it seems that this platform just isn't
supported yet:

--8<---cut here---start->8---
 Building LuaJIT 2.1.0-beta3 
make -C src
make[1]: Entering directory 
'/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src'
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
make[1]: *** No rule to make target 'vm_ppc64.dasc', needed by 
'host/buildvm_arch.h'.  Stop.
make[1]: Leaving directory 
'/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src'
make: *** [Makefile:113: default] Error 2
--8<---cut here---end--->8---

I have CC'd the Guix bug report for this issue.  When replying, if you
could please keep 49...@debbugs.gnu.org in the CC list so that your
replies will be recorded in the bug report, that would be helpful.  That
will make it easier for Guix contributors to follow the conversation.

Best regards,

-- 
Chris Marusich


signature.asc
Description: PGP signature

bug#49220: luajit doesn't support powerpc64le

[Chris Marusich]

Hi,

When attempting to build luajit on powerpc64le-linux, you will get
errors like this:

--8<---cut here---start->8---
 Building LuaJIT 2.1.0-beta3 
make -C src
make[1]: Entering directory 
'/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src'
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)"
  428 | #error "No support for PowerPC 64 bit mode (yet)"
  |  ^
make[1]: *** No rule to make target 'vm_ppc64.dasc', needed by 
'host/buildvm_arch.h'.  Stop.
make[1]: Leaving directory 
'/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src'
make: *** [Makefile:113: default] Error 2
--8<---cut here---end--->8---

This has downstream impacts, such as being unable to build LuaJITTeX.
If we can't use LuaJIT on powerpc64le-linux, we should probably remove
it from the luajit package's list of supported systems.

I checked their email list and website, but I can't find information
about whether the LuaJIT project is actively working on support for
powerpc64le architecture specifically.  I'll ask their email list
(lua...@freelists.org) in a moment, and we'll see what they say.

-- 
Chris


signature.asc
Description: PGP signature