bug#65522: Documentation for some home services disappeared from 1.4 manual

[Simon Tournier]

Hi,

On Wed, 06 Sep 2023 at 13:16, nils@landt.email wrote:

> https://guix.gnu.org/manual/en/html_node/File-Search-Services.html
> which is 404.

This webpage currently works for me.

> Of course this does not really change anything, if the current manual
> is correct then let's close this bug report!

Well, I am closing since it is probably a transient issue.  Feel free to
reopen if you have similar troubles.

Cheers,
simon

bug#65522: Documentation for some home services disappeared from 1.4 manual

[Simon Tournier]

Hi,

On Wed, 06 Sep 2023 at 09:41, nils@landt.email wrote:

> But it's certainly changed behaviour. I had
> https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html open
> in a browser tab for more than a month, and on 2023-08-23 it was
> suddenly 404 ¯\_(ツ)_/¯

This webpage currently works.  So you have probably seen a transient
issue.

Cheers,
simon

bug#65720: Guile-Git-managed checkouts grow way too much

[Simon Tournier]

Hi,

On Tue, 05 Sep 2023 at 16:18, Ludovic Courtès  wrote:

> It would also be pretty bad for closure size:
>
> --8<---cut here---start->8---
> $ guix size guile-git | tail -1
> total: 106.6 MiB
> $ guix size guile-git git-minimal | tail -1
> total: 169.8 MiB
> --8<---cut here---end--->8---
>
> It’s also not clear concretely how we’d add that dependency.  Try
> invoking ‘git’ from $PATH and print a warning if it doesn’t work?
> But then, what about applications like Cuirass and hpcguix-web?

I think we can rely on something like,

guix shell -C git-minimal -- git gc

It would be invoked internally using the Scheme API for inferiors and
friends.  Doing so, it would add nothing to the closure size.

It appears to me safe to assume that this command can be run from any
Guix installation.  Since the Git GC would only be done once every X Git
fetches, the overhead would be much lower.

Hum, am I repeating myself [1]? :-)

And I would run this “git gc” via “guix gc”, not via “guix pull”.  Well,
I do not like all these automatic removals happening based on date
(last-expiry-cleanup) with some usual commands.  It always happens when
I do not want. ;-) Contrary to “guix gc”.  Bah, another story. :-)

Cheers,
simon


1: bug#65720: Guile-Git-managed checkouts grow way too much
Simon Tournier 
Tue, 05 Sep 2023 20:59:07 +0200
id:86edjcqwec@gmail.com
https://issues.guix.gnu.org//65720
https://issues.guix.gnu.org/msgid/86edjcqwec@gmail.com
https://yhetil.org/guix/86edjcqwec@gmail.com

bug#65236: package/inherit records lack location for version field

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi Maxim,
>
> On Fri, 11 Aug 2023 at 21:27, Maxim Cournoyer  
> wrote:
>
>> --8<---cut here---start->8---
>> (use-modules (guix package)
>>  (gnu packages qt))
>>
>> (package-field-location qtbase 'version)
>>
>> => #f
>> --8<---cut here---end--->8---
>
> [...]
>
>> Now, package/inherit is bogus here, but the problems remains for other
>> packages, such as zxing-cpp-1.2.
>
> I think it is fixed by .

Installed with a small fix in d552c250.

-- 
Thanks,
Maxim

bug#65774: python updater clears inputs, leaves propagated-inputs empty

[Maxim Cournoyer]

Hi,

Sergio Pastor Pérez  writes:

> Hi,
>
> I'm afraid you lost me here. Why is the `inputs' field empty?

I don't know!  That's the current behavior of the Python updater, at
least when I ran it on fontmake (in our patches tracker at
https://issues.guix.gnu.org/64957).

> understand what you meand with the checking of 'python-'.

I meant looking whether the package variable (usually also its name) is
prefixed by "python-" to differentiate between a library or a command.
It's not a very good heuristic/test, I'm afraid.

-- 
Thanks,
Maxim

bug#65759: Bug

[Sjors Provoost]

Hi Josselin,

Restarting the command a few times it kept failing at different packages, but 
eventually made it through just fine.

The building machine is indeed x86_64-linux, the Bitcoin projects uses cross 
compilation to make binaries for macOS (and requires you to download the SDK 
and run a script to extract some stuff from it).

Sjors

On Wed, Sep 6, 2023, at 04:47, Josselin Poiret wrote:
> Hi Sjors,
>
> Sjors Provoost  writes:
>
>> $ HOSTS='x86_64-apple-darwin arm64-apple-darwin' ./contrib/guix/guix-build 
>> || echo -e "\a"
>
> Guix doesn't support apple-darwin as a system.  I don't know how the
> bitcoin project does it, but you probably want to report this to them
> instead.  I don't see anything immediately wrong with the log here as
> well.
>
>> guix time-machine: error: You found a bug: the program 
>> '/gnu/store/6is1k9037hzkbjgwrc1zs6v5z26i23ly-compute-guix-derivation'
>> failed to compute the derivation for Guix (version:
>> "160f78a4d92205df986ed9efcce7d3aac188cb24"; system: "x86_64-linux";
>
> It seems that guix believes it is building on x86_64-linux.  I don't
> know if this is a bug or feature, you'll have to see with the bitcoin
> project.
>
> Best,
> -- 
> Josselin Poiret
>
> Attachments:
> * signature.asc

bug#65765:

[Sharlatan Hellseher]

Hi,

May you provide the way how to reproduce it?

> guix time-machine --no-channel-files 
> --commit=6113e0529d61df7425f64e30a6bf77f7cfdfe5a5 -- build celluloid
> /gnu/store/dps6ra33zfgpga7wig085p5k3bwdxqz2-celluloid-0.25

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#65788: poor information when updating using “guix time-machine”

[Simon Tournier]

Hi,

Tangential of bug#65787 [1], the annoyance is the order of the updates.
It leads to poor messages.  Let exemplify at the extreme case.

--8<---cut here---start->8---
$ guix describe
Generation 28   sept. 06 2023 14:54:50  (current)
  guix 6113e05
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 6113e0529d61df7425f64e30a6bf77f7cfdfe5a5

$ rm -fr 
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq

$ guix time-machine -q --commit=6113e05 -- describe
receiving objects   2% ▕█▋
…some time flies…
indexing objects  21% ▕███  
 ▏
…some time flies…
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
   …instant…
Computing Guix derivation for 'x86_64-linux'... \
--8<---cut here---end--->8---

The reason is because the logic:

(when (procedure? validate-channels)
  (validate-channels channels))
(run-with-store store
  (mlet* %store-monad ((instances
-> (latest-channel-instances store channels
 #:authenticate?
 authenticate?))

where ’validate-channels’ (validate-guix-channel) reads,

(checkout commit relation (update-cached-checkout
   (channel-url guix-channel)
   #:ref reference
   #:starting-commit
   %oldest-possible-commit)))

and ’latest-channel-instances’ which is the ones that displays,

 (format (current-error-port)
 (G_ "Updating channel '~a' from Git repository at 
'~a'...~%")
 (channel-name channel)
 (channel-url channel))


this ’latest-channel-instances’ reads under the hood,

   ((checkout commit relation)
(update-cached-checkout (channel-url channel)
#:ref (channel-reference channel)
#:starting-commit starting-commit)))


Why not move this ’validate-guix-channel’ to internals.  Somehow, it is
in guix/scripts/ because it captures ’ref’.  However, this capture is
redundant and is normally managed by ’channel-list’.  Therefore, I would
be tempted to have this validation for the reachable commit close to the
“Updating” message.

WDYT?

Cheers,
simon


1: 

bug#65787: time-machine is doing too much network requests

[Simon Tournier]

Hi,

Well, I am in a quest to make Guix more robust for the worst-case
scenario: Savannah is unreachable (as well as other servers).  For
context, it matters when using Guix for reproducing scientific
production.  An example of such worst-case, see [1].  Well, this quote:

The first annoyance is that guix time-machine needs an access to the
server git.savannah.gnu.org, although the Git repository is already
cloned and already contains the required commit. 

is almost tackled by #65352; at least tracked. :-)

Investigating that, I am noticed that the current design is suboptimal,
IMHO.  I am reporting here and I hope to improve the situation by
reducing the number of network requests.

It matters in worst-case scenario of scientific production.  And it also
matters for people with poor or unstable network link.

Sorry if the report is hard to follow, I did my best for being clear.

To keep the discussion simple, I only consider the Git reference
specification ’branch’ and ’tag-or-commit’.  These Git reference
specification that various internal procedures are using is poorly
documented.  See the docstring of the procedure ’update-cached-checkout’
from (guix git) for an idea or the implementation of ’resolve-reference’
for the complete list.

Let consider only the Git reference specifications:

(branch. "string")
(tag-or-commit . "string")

because that are what “guix time-machine” sets from the CLI or reads
from channels.scm files, IIUC.

The command “guix time-machine” starts to call ’cached-channel-instance’
passing as argument the procedure ’validate-guix-channel’.

This procedure ’cached-channel-instance’ starts by collecting all the
commits for each channel.  It maps the channels list using the procedure
’channel-full-commit’.  And that procedure calls
’update-cached-checkout. (1)

Then, ’cached-channel-instance’ calls ’validate-guix-channel’.  And this
procedure also calls ’update-cached-checkout’. (2)

Then, ’cached-channel-instance’ calls ’latest-channel-instances’ which
calls ’latest-channel-instance’.  And guess what, this procedure also
calls ’update-cached-checkout’. (3)

Ok, let give a look at ’update-cached-checkout’.

This procedure ’update-cached-checkout’ first looks if the Git reference
specification is already in the cached Git checkout using the procedure
’reference-available?’.

Consider that the Git reference specification is (branch . "some"), then
’reference-available?’ returns #false, so it triggers ’remote-fetch’
from Guile-Git.  If I read correctly, this generates network traffic and
Savannah needs to be reachable. (I)

Hum, I am not convinced someone is following.  Who knows? :-)

Let continue.  ’update-cached-checkout’ starts to check some commit
relation and friends.  There is an if-branch calling then
’switch-to-ref’ else ’resolve-reference’.  Under the hood, the procedure
’switch-to-ref’ is calling ’resolve-reference’.

For the case (branch . "some"), this ’resolve-reference’ procedure calls
’branch-lookup’ from Guile-Git.  If I read correctly, this generates
network traffic because of BRANCH-REMOTE and Savannah needs to be
reachable. (II)

Summary: ( (1) + (2) + (3) ) * ( (I) + (II) ) = 6.

If I am correct and if I am not missing something, the current design
requires 6 network traffic with Savannah and most of this traffic is
useless because it had already be done, somehow.

Well, (branch . "some") is the worst case, IMHO.  And the short commit
ID (tag-or-commit . "1234abc") or the tag (tag-or-commit . "v1.4.0")
too.

Applying my proposal from #65352 (DRAFT v2), it removes some useless
’remote-fetch’ calls.

Well, let me know if this diagnostic is correct.

To be continued…


Cheers,
simon


1: https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html

bug#65769: no elogind

[chris]

Josselin,

> Do you use elogind?

No. elogind is not used.

bug#65522: Documentation for some home services disappeared from 1.4 manual

[nils]

> Simon Tournier  hat am 05.09.2023 17:18 CEST 
> geschrieben:
> 
>  
> Hi,
> 
> On Fri, 25 Aug 2023 at 08:16, nils@landt.email wrote:
> 
> > I noticed some help nodes under 
> > https://guix.gnu.org/en/manual/en/html_node/Home-Services.html disappeared 
> > fairly recently.
> > They are still available in the devel docs under 
> > https://guix.gnu.org/en/manual/devel/en/html_node/Home-Services.html
> >
> > The following topics are missing:
> > * GPG: GNU Privacy Guard.   Setting up GPG and related tools.
> > * Fonts: Fonts Home Services.   Services for managing User's fonts.
> > * Sound: Sound Home Services.   Dealing with audio.
> > * Mail: Mail Home Services. Services for managing mail.
> > * Messaging: Messaging Home Services.  Services for managing messaging.
> > * Media: Media Home Services.   Services for managing media.
> > * Networking: Networking Home Services.  Networking services.
> > * Miscellaneous: Miscellaneous Home Services.  More services.
> >
> > This makes sense when looking at the 1.4.0 git tag, but I had a browser tab 
> > open, and https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html 
> > was definitely available just a day or two ago.
> >
> > I don't know if this is actually an issue or an intended change, but it 
> > seemed better to report it than to ignore it.
> 
> I am sorry, I am not sure to understand what the bug is about. :-)
> 
> This webpage
>  points
> to the manual as it was for the last release.  It means, this manual
> wepage is frozen and is only updated at each release.  If you have seen
> something different, it is an artifact that should not be possible.
> 
> For instance, the service
> 
> * GPG: GNU Privacy Guard.   Setting up GPG and related tools.
> 
> had been added on Sat Apr 8 22:56:19 2023 +0200 which is after the
> release 1.4.0.
> 
> There is no bug and I am favor to close it.  WDYT?

If this is intended and expected, then feel free to close it, sure.
But it's certainly changed behaviour. I had 
https://guix.gnu.org/manual/en/html_node/Mail-Home-Services.html open in a 
browser tab for more than a month, and on 2023-08-23 it was suddenly 404 
¯\_(ツ)_/¯

bug#65522: Documentation for some home services disappeared from 1.4 manual

[nils]

> Simon Tournier  hat am 05.09.2023 17:18 CEST 
> geschrieben:
> This webpage
>  points
> to the manual as it was for the last release.  It means, this manual
> wepage is frozen and is only updated at each release.  If you have seen
> something different, it is an artifact that should not be possible.

Note: I just searched for "guix search-input-file" on duckduckgo (and startpage 
/ google to doublecheck) and the second hit was pointing to 
https://guix.gnu.org/manual/en/html_node/File-Search-Services.html which is 
404. https://guix.gnu.org/manual/devel/en/html_node/File-Search-Services.html 
works.
So it appears the manual was wrong (=showing the "latest" version instead of 
1.4.0) long enough to be indexed by search engines.
Of course this does not really change anything, if the current manual is 
correct then let's close this bug report!

bug#65769: wlgreet-sway-session

[Josselin Poiret via Bug reports for GNU Guix]

Hi chris,

chris  writes:

> This directory for the greeter user does not exist in the system /run/user/986

Do you use elogind?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65714: guix-copy 32-bit integer limit

[Efraim Flashner]

On Mon, Sep 04, 2023 at 11:55:19PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > `guix copy` seems unable to deal with store items larger than
> > 2**32 bytes (about 4.3 GiB).
> >
> > (ins)efraim@3900XT ~$ guix copy --from=192.168.1.196 
> > /gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > retrieving 1 store item from '192.168.1.196'...
> > guix copy: error: implementation cannot deal with > 32-bit integers
> >
> > (ins)efraim@3900XT ~$ ssh 192.168.1.196 du -sch 
> > /gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > 7.5G/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > 7.5Gtotal
> 
> Hmm that vaguely rings a bell, but we’ve had things like texlive-texmf
> from the start and I think we’ve definitely been able to fetch them via
> the offload/copy code.
> 
> Are you able to copy other store items from that host?  Could there be
> another issue leading to a bogus diagnostic?

ins)efraim@3900XT ~$ ssh 192.168.1.196 guix archive --export --recursive 
/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313 | guix 
archive --import
guix archive: error: hash of path 
`/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313' has changed 
from `33df143f9607fcdbd0be68ee7612779d330ac2fefad5749429b8a5b5d2931886' to 
`ea77f319bd62d0c53b132d545e44a41baea385fd49ad21a94402299b09488085'!
Backtrace:
  13 (primitive-load "/home/efraim/.config/guix/current/bin/…")
In guix/ui.scm:
   2323:7 12 (run-guix . _)
  2286:10 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
859:3  9 (_)
839:4  8 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37  6 (thunk)
   1298:8  5 (call-with-build-handler # …)
  1719:22  4 (import-paths # #)
   729:14  3 (process-stderr _ _)
In guix/serialization.scm:
   122:12  2 (write-bytevector #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 …) …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure modulo: Wrong type argument in position 1: #

I'm running `guix gc --verify=contents,repair` on the other machine now
to make sure there's nothing wrong with the archive item.

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

bug#65725: guix pull fails on riscv64

[much . effort283--- via Bug reports for GNU Guix]

Not sure if those are two issues, or one, but on riscv64 the following
seems to fail:

* guix pull
* openssl "check" phase

Steps to reproduce:

Install guix 1.4.0 and run "guix pull".

Output:

building /gnu/store/qkwilbf7fvc4rj55cvrf02xvmmx6mvv2-gnutls-3.7.7.tar.xz.drv...
building 
/gnu/store/d0gkh0hkxrfbb7i8z328rqws5m8xm05n-guile-gnutls-3.7.9-checkout.drv...
building /gnu/store/lzjryc1fdsi6xsjh7m050dygirccbglm-openssl-1.1.1l.drv...
- 'check' phasebuilder for
`/gnu/store/lzjryc1fdsi6xsjh7m050dygirccbglm-openssl-1.1.1l.drv'
failed with exit code 1
build of /gnu/store/lzjryc1fdsi6xsjh7m050dygirccbglm-openssl-1.1.1l.drv failed
View build log at
'/var/log/guix/drvs/lz/jryc1fdsi6xsjh7m050dygirccbglm-openssl-1.1.1l.drv.gz'.
cannot build derivation
`/gnu/store/6xs1rj5x52hmaldlygbc089jyr70j33s-mit-krb5-1.19.2.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/bpy3jvm3zjmsc9gkiqhyv1y99z7vnzik-nghttp2-1.44.0.drv': 1
dependencies couldn't be built
Backtrace:
  14 (primitive-load
"/gnu/store/bjmgis3jwxw9cwv900dc3h8xabgnbk4p-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
  2170:24  9 (run-with-store #
# ?)
   1998:8  8 (_ #)
In ./guix/gexp.scm:
   299:22  7 (_ #)
   1180:2  6 (_ #)
   1046:2  5 (_ #)
892:4  4 (_ #)


\In ./guix/store.scm:
  2055:12  3 (_ #)
   1403:5  2 (map/accumulate-builds # # ?)
  1419:15  1 (_ #
("/gnu/store/jv53661ncfx9nlja7wkqfck18s2qbrdi-curl-7.84.0.drv" ?) ?)
  1419:15  0 (loop #f)

./guix/store.scm:1419:15: In procedure loop:
ERROR:
  1. :
  message: "build of
`/gnu/store/jv53661ncfx9nlja7wkqfck18s2qbrdi-curl-7.84.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program
'/gnu/store/bjmgis3jwxw9cwv900dc3h8xabgnbk4p-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"47348b85f67d23b074d8d624450eaf1d443c101a"; system: "riscv64-linux";
host version: "1.4.0"; pull-version: 1).
Please report the COMPLETE output above by email to .




The full openssl output is:
https://github.com/starfive-tech/VisionFive2/files/12505756/jryc1fdsi6xsjh7m050dygirccbglm-openssl-1.1.1l.drv.txt

Let me know if anything else is required.

bug#65723: GCC/Clang toolchain package ld wrapper on utf8 paths with LANG enviroment variable not utf8

[andy]

This happens with both gcc-toolchain 12.3.0 or clang-toolchain 15.0.7.

$ echo $PWD
/home/testuser123/你好
$ echo $LANG
en_US.utf8
$ guile --version
guile (GNU Guile) 3.0.9
$ guix --version
guix (GNU Guix) 3335903d7d6d7ee93436d046b3037d433d06372b
$ ld --version
GNU ld (GNU Binutils) 2.38
...
$ clang --version
clang version 15.0.7
Target: x86_64-unknown-linux-gnu
...


To recreate write a hello world in C or C++ into main.cpp.


$ clang -c main.cpp -o main.o
$ ld main.o /gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so
This works fine
$ LANG="" ld main.o 
/gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so
And the above
$ ld main.o /gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so -o 
"$PWD/a.out"
And this works
But below fails
$ LANG="" ld main.o 
/gnu/store/2h51y9n2c96k4rxa6fl7irdwirw7q0z8-profile/lib/libc.so -o "$PWD/a.out"
ld: cannot open output file /home/testuser123/??/a.out: No such file or 
directory


The gcc-toolchain and clang-toolchain seem to have identical "ld" files as 
"diff"ing them shows no difference. ld is a Guile file so I would assume 
somehow the script somehow looks at the LANG environment variable which messes 
up the character encodings of paths and replacing them with the question marks.


The ld wrapper depending on the LANG environment variable having utf8 for 
handling filenames has some problems. Some build systems like Rust's Cargo 
unset the LANG environment variable, causing ld to output those question marks 
in place of the utf8 bytes, which will break for any path that has Unicode. I 
don't think it is intended behavior for a linker to depend on the LANG to 
handle filenames.

bug#65720: Guile-Git-managed checkouts grow way too much

[Jelle Licht]

Hi Ludo,

> 
> On 4 Sep 2023, at 23:49, Ludovic Courtès  wrote:
> 
> Of course having to re-clone entire repositories every 9 months is
> ridiculous, but storing gigabytes of packs is worse IMO (I’m
> specifically thinking about the Guix repo, which every users copies via
> ‘guix pull’).

Please ignore if it doesn’t make sense, or would not make a practical 
difference for the current issue, but wouldn’t a local clone do the trick here? 
As in, clone from the ‘clogged’ local repo, move over fresh clone to old 
location.

Kr, Jelle

bug#65725: Acknowledgement (guix pull fails on riscv64)

[much . effort283--- via Bug reports for GNU Guix]

Since openssl is already bumped from "1.1.1l" to a version that has
the bug fixed in the development branch, I presume this will be fixed
once the next guix release (1.5) is out?

In the meantime, I wonder if there is a workaround I can apply. I
tried compiling from source, but that seems to fail as well:


$ make
...
  MAKEINFO doc/guix.info
  MAKEINFO doc/guix.de.info
  MAKEINFO doc/guix.es.info
guix.es.texi:19957: warning: `.' or `,' must follow @xref, not p
guix.es.texi:46743: warning: `.' or `,' must follow @xref, not p
  MAKEINFO doc/guix.fr.info
guix.fr.texi:15509: warning: `.' or `,' must follow @xref, not p
  MAKEINFO doc/guix.pt_BR.info
  MAKEINFO doc/guix.ru.info
Wide character in warn at /usr/bin/makeinfo line 637.
guix.ru.texi:13133: warning: `.' or `,' must follow @xref, not д
  MAKEINFO doc/guix.zh_CN.info
  MAKEINFO doc/guix-cookbook.de.info
guix-cookbook.de.texi:611: @menu reference to nonexistent node `A
``Hello World'' package'
guix-cookbook.de.texi:612: @menu reference to nonexistent node `Setup'
guix-cookbook.de.texi:613: @menu reference to nonexistent node
`Extended example'
guix-cookbook.de.texi:614: @menu reference to nonexistent node `Other
build systems'
guix-cookbook.de.texi:615: @menu reference to nonexistent node
`Programmable and automated package definition'
guix-cookbook.de.texi:616: @menu reference to nonexistent node `Getting help'
guix-cookbook.de.texi:617: @menu reference to nonexistent node `Conclusion'
guix-cookbook.de.texi:842: @menu reference to nonexistent node `Local file'
guix-cookbook.de.texi:843: @menu reference to nonexistent node `Channels'
guix-cookbook.de.texi:1551: @menu reference to nonexistent node
`Recursive importers'
guix-cookbook.de.texi:1552: @menu reference to nonexistent node
`Automatic update'
guix-cookbook.de.texi:3767: @menu reference to nonexistent node `A
Database Container'
guix-cookbook.de.texi:4066: @menu reference to nonexistent node `Basic
setup with manifests'
guix-cookbook.de.texi:4067: @menu reference to nonexistent node
`Required packages'
guix-cookbook.de.texi:4068: @menu reference to nonexistent node
`Default profile'
guix-cookbook.de.texi:4069: @menu reference to nonexistent node `The
benefits of manifests'
guix-cookbook.de.texi:117: @detailmenu reference to nonexistent node
`A ``Hello World'' package'
guix-cookbook.de.texi:118: @detailmenu reference to nonexistent node `Setup'
guix-cookbook.de.texi:119: @detailmenu reference to nonexistent node
`Extended example'
guix-cookbook.de.texi:120: @detailmenu reference to nonexistent node
`Other build systems'
guix-cookbook.de.texi:121: @detailmenu reference to nonexistent node
`Programmable and automated package definition'
guix-cookbook.de.texi:122: @detailmenu reference to nonexistent node
`Getting help'
guix-cookbook.de.texi:123: @detailmenu reference to nonexistent node
`Conclusion'
guix-cookbook.de.texi:130: @detailmenu reference to nonexistent node
`Local file'
guix-cookbook.de.texi:131: @detailmenu reference to nonexistent node `Channels'
guix-cookbook.de.texi:138: @detailmenu reference to nonexistent node
`Recursive importers'
guix-cookbook.de.texi:139: @detailmenu reference to nonexistent node
`Automatic update'
guix-cookbook.de.texi:197: @detailmenu reference to nonexistent node
`A Database Container'
guix-cookbook.de.texi:211: @detailmenu reference to nonexistent node
`Basic setup with manifests'
guix-cookbook.de.texi:212: @detailmenu reference to nonexistent node
`Required packages'
guix-cookbook.de.texi:213: @detailmenu reference to nonexistent node
`Default profile'
guix-cookbook.de.texi:214: @detailmenu reference to nonexistent node
`The benefits of manifests'
make[2]: *** [Makefile:5396: doc/guix-cookbook.de.info] Error 1

bug#65776: Failure to guix pull --no-substitues on aarch64

[Michael Ford]

This is occuring when performing a "guix pull --no-substitutes" on a newly
installed Guix 1.4.0, running on aarch64 Linux.

`/gnu/store/25lmh68nvby582y958fv84jnglf75jaz-libgit2-1.3.2-checkout/docs/error-handling.md'
-> `libgit2-1.3.2-checkout/docs/error-handling.md'
`/gnu/store/25lmh68nvby582y958fv84jnglf75jaz-libgit2-1.3.2-checkout/docs/release.md'
-> `libgit2-1.3.2-checkout/docs/release.md'
`/gnu/store/25lmh68nvby582y958fv84jnglf75jaz-libgit2-1.3.2-checkout/docs/merge-df_conflicts.txt'
-> `libgit2-1.3.2-checkout/docs/merge-df_conflicts.txt'
`/gnu/store/25lmh68nvby582y958fv84jnglf75jaz-libgit2-1.3.2-checkout/docs/differences-from-git.md'
-> `libgit2-1.3.2-checkout/docs/differences-from-git.md'
source is at 'libgit2-1.3.2-checkout'
building
/gnu/store/dy4jbhsaliqszfhhyr0a8ab71q2pwi0y-libpaper-2.0.0.tar.gz.drv...
building
/gnu/store/6vbjpblvwja2r62f24fvvvgmhrpixnph-libssh-0.10.5.tar.xz.drv...
building /gnu/store/gcrd5lim7mss1ff9m87mrkrsnssn5s4l-libpaper-2.0.0.drv...
\ 'build' phaseild-log 16057 208
careadlinkat.c:184:5: warning: #warning "GCC might issue a bogus
-Wreturn-local-addr warning here." [-Wcpp]
  184 |#warning "GCC might issue a bogus -Wreturn-local-addr warning
here."
  | ^~~
\ 'check' phaseBacktrace:
  15 (primitive-load
"/gnu/store/i3j0vfsv060s010dz38qpybk2c00j1xz-compute-guix-derivation")
In ice-9/eval.scm:
155:9 14 (_ _)
159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 12 (with-fluid* _ _ _)
152:2 11 (with-fluid* _ _ _)
In ./guix/store.scm:
  2168:24 10 (run-with-store #
# ?)
   1996:8  9 (_ #)
In ./guix/gexp.scm:
   299:22  8 (_ #)
   1180:2  7 (_ #)
   1046:2  6 (_ #)
892:4  5 (_ #)
In ./guix/store.scm:
  2053:12  4 (_ #)
  1405:13  3 (map/accumulate-builds #
# ?)
   1401:5  2 (map/accumulate-builds #
# ?)
  1417:15  1 (_ #
("/gnu/store/2bh5cs69r34wcswi7q4nffpnfzi885nc-guix-daemon-1.?" ?) ?)
  1417:15  0 (loop #f)

./guix/store.scm:1417:15: In procedure loop:
ERROR:
  1. :
  message: "build of
`/gnu/store/zz05dfnfq5rigdjnxxsbps3ikj2vwq1b-ghostscript-9.56.1.drv' failed"
  status: 100
guix pull: error: You found a bug: the program
'/gnu/store/i3j0vfsv060s010dz38qpybk2c00j1xz-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"e7b6cd86ef856b52817428227f9c3d3297312262"; system: "aarch64-linux";
host version: "1.4.0"; pull-version: 1).
Please report the COMPLETE output above by email to .

ffbecdf8cd21:/# guix pull --no-substitutes
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 6113e05 (73 new
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git 6113e05
building
/gnu/store/fyqnp5b60vgmxq1nc7sykc5hdvif3l7l-compute-guix-derivation.drv...
building /gnu/store/gcrd5lim7mss1ff9m87mrkrsnssn5s4l-libpaper-2.0.0.drv...
/ 'build' phaseild-log 28441 208
careadlinkat.c:184:5: warning: #warning "GCC might issue a bogus
-Wreturn-local-addr warning here." [-Wcpp]
  184 |#warning "GCC might issue a bogus -Wreturn-local-addr warning
here."
  | ^~~
/ 'check' phaseBacktrace:
  14 (primitive-load
"/gnu/store/2ijs5gickxdpb6y9g490pkmgzd6rsns8-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
  2168:24  9 (run-with-store #
# ?)
   1996:8  8 (_ #)
In ./guix/gexp.scm:
   299:22  7 (_ #)
   1180:2  6 (_ #)
   1046:2  5 (_ #)
892:4  4 (_ #)
In ./guix/store.scm:
  2053:12  3 (_ #)
   1401:5  2 (map/accumulate-builds #
# ?)
  1417:15  1 (_ #
("/gnu/store/2bh5cs69r34wcswi7q4nffpnfzi885nc-guix-daemon-1.?" ?) ?)
  1417:15  0 (loop #f)

./guix/store.scm:1417:15: In procedure loop:
ERROR:
  1. :
  message: "build of
`/gnu/store/zz05dfnfq5rigdjnxxsbps3ikj2vwq1b-ghostscript-9.56.1.drv' failed"
  status: 100
guix pull: error: You found a bug: the program
'/gnu/store/2ijs5gickxdpb6y9g490pkmgzd6rsns8-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"6113e0529d61df7425f64e30a6bf77f7cfdfe5a5"; system: "aarch64-linux";
host version: "1.4.0"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#65759: Bug

[Josselin Poiret via Bug reports for GNU Guix]

Hi Sjors,

Sjors Provoost  writes:

> $ HOSTS='x86_64-apple-darwin arm64-apple-darwin' ./contrib/guix/guix-build || 
> echo -e "\a"

Guix doesn't support apple-darwin as a system.  I don't know how the
bitcoin project does it, but you probably want to report this to them
instead.  I don't see anything immediately wrong with the log here as
well.

> guix time-machine: error: You found a bug: the program 
> '/gnu/store/6is1k9037hzkbjgwrc1zs6v5z26i23ly-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "160f78a4d92205df986ed9efcce7d3aac188cb24"; system: "x86_64-linux";

It seems that guix believes it is building on x86_64-linux.  I don't
know if this is a bug or feature, you'll have to see with the bitcoin
project.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65720: Guile-Git-managed checkouts grow way too much

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> Surely you’d agree that it would suck though: depending on two Git
> implementations because one doesn’t have a proper API and the other one
> lacks a bunch of features.

Right, although I wouldn't necessarily say that the former doesn't have
a proper API, but rather that it has a Unix-oriented API.  That leads to
performance issues on e.g. Windows but on Linux I'm not sure there's
much of a difference.

> It would also be pretty bad for closure size:
>
> --8<---cut here---start->8---
> $ guix size guile-git | tail -1
> total: 106.6 MiB
> $ guix size guile-git git-minimal | tail -1
> total: 169.8 MiB
> --8<---cut here---end--->8---
>
> It’s also not clear concretely how we’d add that dependency.  Try
> invoking ‘git’ from $PATH and print a warning if it doesn’t work?
> But then, what about applications like Cuirass and hpcguix-web?
>
> Tricky, tricky.

We could consider replacing the guile-git dependency with another
library built directly on top of git-minimal, and have this be a
dependency of Guix.  Not ideal though, and not really scalable either:
we can't just add every VCS as direct dependencies.

From what I've seen, people are now scaling back on their use of
libgit2 because of the impedence mismatch and are resorting more and
more to git plumbing.  From a pragmatic point of view, I'd prefer the
latter, since it is more stable and feature-complete.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature