bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

[Bone Baboon via Bug reports for GNU Guix]

On a i686 computer when I run `sudo guix system --no-substitutes --cores=1 
--max-jobs=1 reconfigure config.scm` I get this error:

```
building 
/gnu/store/yqwd4wbam8mx0n2idy1qj4861rzvra7n-go-gopkg-in-yaml-v2-2.2.2.drv...
| 'check' phasebuilder for 
`/gnu/store/yqwd4wbam8mx0n2idy1qj4861rzvra7n-go-gopkg-in-yaml-v2-2.2.2.drv' 
failed with exit code 1
build of 
/gnu/store/yqwd4wbam8mx0n2idy1qj4861rzvra7n-go-gopkg-in-yaml-v2-2.2.2.drv failed
View build log at 
'/var/log/guix/drvs/yq/wd4wbam8mx0n2idy1qj4861rzvra7n-go-gopkg-in-yaml-v2-2.2.2.drv.bz2'.
cannot build derivation 
`/gnu/store/qkinjq5fkp3vd70g6vcf3wwd66d0slq7-docker-libnetwork-cmd-proxy-19.03-1.55e924b.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/6vi73j6gn3g3xdg30wp0kdmdg0nhxan6-gotestsum-0.4.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/8s9kwwcg5wilqkl3mgysr0mg12dj10zq-docker-19.03.15.drv': 1 
dependencies couldn't be built
guix system: error: build of 
`/gnu/store/8s9kwwcg5wilqkl3mgysr0mg12dj10zq-docker-19.03.15.drv' failed
```

`guix describe` outputs:

```
Generation 7Apr 20 2021 18:12:09(current)
  guix 0e21cf7
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 0e21cf7d0620caf3fe9bed4f6ec1d5239a599a6a
```

The build log contents:

```
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/ghvg7wa0m2dih1nibxja66m86q1ffm6w-go-1.14.15/bin:/gnu/store/gww59gv5qxbfijg3vk5y182im7923s06-tar-1.32/bin:/gnu/store/2ayciqwxddkzq183dac82ijljc14j4zj-gzip-1.10/bin:/gnu/store/n1jk0w2wa4vpwmixaqn2y3la1l2sizzi-bzip2-1.0.8/bin:/gnu/store/7p36raqgk6vn47bflxc9bsclqiib3phi-xz-5.2.4/bin:/gnu/store/lpkf3ydcdvxn8gcrzaq9cp3ri05h8qhs-file-5.38/bin:/gnu/store/6gqaw09zqw8w0vcax6simlq71bq7l5r0-diffutils-3.7/bin:/gnu/store/qw20chpgkgbcqmzhs60c8hjl1hmblyc8-patch-2.7.6/bin:/gnu/store/b5y5scfmh2d8kxcpl9p84294z2198cgf-findutils-4.7.0/bin:/gnu/store/9iwlsj7d6ffqhshy8qshf7p4fqwfwrvn-gawk-5.0.1/bin:/gnu/store/q1nfjb24vqjs1cgi8mlnskw34h16y09r-sed-4.8/bin:/gnu/store/4qr6mcvsxyzknxa7x1wny8x30f5i0r3n-grep-3.4/bin:/gnu/store/2v61vg0bizgrhybkqbrki2k7kr094waz-coreutils-8.32/bin:/gnu/store/b7jbh7kzzig0bxfswdj8nfj9bkljyyya-make-4.3/bin:/gnu/store/v1g7f3p4f0851mywrla8qmr9hb8jgfjr-bash-minimal-5.0.16/bin:/gnu/store/dyqxnydqk1810afjfbqzfvh0n83xyl62-ld-wrapper-0/bin:/gnu/store/50lyzn9bz6x4da66648kry29wn8afird-binutils-2.34/bin:/gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin:/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/bin:/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/sbin'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/n1jk0w2wa4vpwmixaqn2y3la1l2sizzi-bzip2-1.0.8/include:/gnu/store/7p36raqgk6vn47bflxc9bsclqiib3phi-xz-5.2.4/include:/gnu/store/lpkf3ydcdvxn8gcrzaq9cp3ri05h8qhs-file-5.38/include:/gnu/store/9iwlsj7d6ffqhshy8qshf7p4fqwfwrvn-gawk-5.0.1/include:/gnu/store/b7jbh7kzzig0bxfswdj8nfj9bkljyyya-make-4.3/include:/gnu/store/50lyzn9bz6x4da66648kry29wn8afird-binutils-2.34/include:/gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/include:/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/include:/gnu/store/hk7l42fwxmnrnlhyiixvaqf1i1crcckp-linux-libre-headers-5.4.20/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/n1jk0w2wa4vpwmixaqn2y3la1l2sizzi-bzip2-1.0.8/include:/gnu/store/7p36raqgk6vn47bflxc9bsclqiib3phi-xz-5.2.4/include:/gnu/store/lpkf3ydcdvxn8gcrzaq9cp3ri05h8qhs-file-5.38/include:/gnu/store/9iwlsj7d6ffqhshy8qshf7p4fqwfwrvn-gawk-5.0.1/include:/gnu/store/b7jbh7kzzig0bxfswdj8nfj9bkljyyya-make-4.3/include:/gnu/store/50lyzn9bz6x4da66648kry29wn8afird-binutils-2.34/include:/gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/include/c++:/gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/include:/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/include:/gnu/store/hk7l42fwxmnrnlhyiixvaqf1i1crcckp-linux-libre-headers-5.4.20/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/ghvg7wa0m2dih1nibxja66m86q1ffm6w-go-1.14.15/lib:/gnu/store/n1jk0w2wa4vpwmixaqn2y3la1l2sizzi-bzip2-1.0.8/lib:/gnu/store/7p36raqgk6vn47bflxc9bsclqiib3phi-xz-5.2.4/lib:/gnu/store/lpkf3ydcdvxn8gcrzaq9cp3ri05h8qhs-file-5.38/lib:/gnu/store/9iwlsj7d6ffqhshy8qshf7p4fqwfwrvn-gawk-5.0.1/lib:/gnu/store/50lyzn9bz6x4da66648kry29wn8afird-binutils-2.34/lib:/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/lib:/gnu/store/rzk3v28mhi4m7sh0qippp9a5rzy03rkg-glibc-2.31-static/lib:/gnu/store/x6i3vfg4gaqd42cqb6mzk52v4lds1467-glibc-utf8-locales-2.31/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/x6i3vfg4gaqd42cqb6mzk52v4lds1467-glibc-utf8-locales-2.31/lib/locale'
phase `set-paths' succeeded after 0.1 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase 

bug#47808: guile-git-0.5.0.drv build failed on i686-linux

[Bone Baboon via Bug reports for GNU Guix]

Thank you
Now when I do a `guix pull --no-substitutes` guile-git build
successfully.

Ludovic Courtès writes:

> Hi,
>
> Julien Lepiller  skribis:
>
>> I have a branch with fixes for guile-git: 
>> https://gitlab.com/roptat/guile-git/-/tree/fix-segfault
>
> Following our discussion on IRC, I pushed a fix:
>
>   
> https://gitlab.com/guile-git/guile-git/-/commit/991db3668e3473dd3bfd83add119b4ff4c73b42e
>
> I’ll release 0.5.1 and we should be fine.
>
> Ludo’.

bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure

[Maxim Cournoyer]

Hi,

Mark H Weaver  writes:

> bo0od  writes:
>
>>  > I mean the ‘outrageously’ part.  When Linux runs out of memory, it
>>  > freezes up.  Moral judgment is futile.  Better to adopt raingloom's
>>  > earlyoom suggestion or similar.
>>
>> Im using default guix system nothing special, If this package usable to
>> solve these stuff i suggest then to include it by default.
>
> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
> fairly old computer by today's standards, and sometimes I ask it to do
> intensive things that are at the edge of its capabilities, such as
> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
> jobs that could have completed, and thereby make it impossible for me to
> continue using this old computer for development.
>
> With that in mind, it's far from clear that 'earlyoom' should be our
> default behavior.  It's good to have it as an option, though.

Earlyoom's default config is to only kills processes when both the
physical memory *and* the swap have been used by more than 90%; in such
as serious resource depletion situation, that usually mean having to
hard reset the machine, or waiting one night not knowing if it'll be
done doing whatever it's doing the next morning (probably getting OOM'd
anyway by the kernel, Linux).

>>  > 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’
>>  > software, especially in parallel (so not using --cores=1 --max-jobs=1)
>>  > to make use of those expensive cores.
>>  >
>>  > I'm disgusted too.
>>
>> Yes it is, But you know this cant be a way of life with guix for end
>> user no? Something by default should solve this matter otherwise this is
>> not usable distro.
>
> Many people are happily using it, and are quite enthusiastic about it,
> so evidently it's "usable".  That doesn't imply that it's good for
> everyone.  Perhaps you would prefer a more traditional distro, or one
> that has had more time to mature.  If so, that's okay.

My 2 cents here is that earlyoom makes Guix System more usable on dated
hardware than Linux's default OOM behavior; from my experience of using
it on a 4 GiB RAM 2010-era laptop for a good while.

I personally would see it a good option for our users to have it on by
default *if* we could manage to connect Earlyoom's notification system
with the desktop (via D-Bus, I think it supports that), so that when a
process is killed, the users has some feedback about it (the stock Linux
OOMK is sure to not let you wondering what's going on -- everything
stops to a crawl, and your hard drive gets thrashed).

Maxim

bug#47924: v1.3.0: Missing configure check for guile-lib >= 0.27

[Leo Famulari]

On Tue, Apr 20, 2021 at 05:40:19PM -0400, Carl Dong wrote:
> Hi all,
> 
> Testing out the version-1.3.0 branch right now, and I think perhaps it’s 
> missing a configure-time check for guile-lib >= 0.27 for %strict-tokenizer?

Thank you for reporting this. I've added it to the list of bugs
"blocking" the release:

https://bugs.gnu.org/47297

bug#47911: Package outputs should be described in the UI

[Leo Famulari]

On Tue, Apr 20, 2021 at 11:54:29PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> > They can't find `git send-email`, and the Guix package UI doesn't make
> > this clear enough.
> 
> Just a side note: our ‘git’ package uses outputs in a rather unusual
> way.

That's true. And I don't have any other packages in mind, really.

I first had this idea after roptat was talking about adding ocaml
bindings for z3 [0]. He wrote:

"it builds the bindings in a separate output, instead of a separate
package, because they're part of the same source, and it doesn't look
like it's possible to build them separately
[...]
I'm just not very happy it's part of the same package, because it's less
discoverable vs ocaml-z3"

So, I do think there is room for improvement to this aspect of the UI.

> There are other packages that provide different features in
> different outputs, but the majority of multiple-output packages have the
> “standard” outputs: “doc”, “bin”, “lib”, “debug”.

Right, and it would not be worthwhile to add anything to the UI for
these.

The 'output synopsis' would only be printed in the UI if we actually
defined a synopsis for it. That way, we wouldn't have 16000 lines of
noise like "debug symbols for foo" in `guix package --search=.`

> So maybe we could look at the ‘git’ package (can it be split into
> several packages? would that help?) in addition to the UI, and also make
> sure the UI is optimized for the most frequent cases.

Good question. The Git package is super complicated, so I'm not feeling
very motivated to think about how to rewrite it :)

[0] https://logs.guix.gnu.org/guix/2021-03-11.log#194242
https://issues.guix.gnu.org/46329

bug#47911: Improving the package outputs UI

[Leo Famulari]

On Wed, Apr 21, 2021 at 12:05:05AM +0200, Tobias Geerinckx-Rice wrote:
> Leo Famulari writes:
> > Another idea I had is to make Guix accept the concatenation of
> > packagename-output in the UI.
> 
> I'm firmly against this (but read on :-)
> 
> > For example, `guix install git-send-email`, instead of `git:send-email`.
> > 
> > But maybe that is going too far, I'm not sure.
> 
> I think it is, but the intention is good.

It's definitely pie-in-the-sky daydreaming :)

> Instead, Guix could suggest (‘did you mean...?’) like it does for commands.
> 
>  ~ λ guix install git-send-email
>  guix install: error: git-send-email: unknown package
>  hint: Did you mean one of:
>  git:send-email

I think that's a better idea.


signature.asc
Description: PGP signature

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
>> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
>
> It seems this is the bad commit.  Downloading the enlightenment
> substitute got stuck and after a few minutes displayed the usual TLS
> error.

Note that on master there have been changes in this area since this
commit, in particular 20c08a8a45d0f137ead7c05e720456b2aea44402.

I assume the error we’re after is still this one:

>>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
>> 0.0%guix substitute: error: TSL error in procedure 'write_to_session_port': 
>> Resource temporarily unavailable, try again.

I believe the attached patch “addresses” this problem.

Now, I’m a bit skeptical: the error above is GNUTLS_E_AGAIN, which
happens if sendmsg(2) returns EAGAIN, which supposedly only happens on
datagram (UDP) sockets or on non-blocking sockets, neither of which
applies here.

This change should be safe, though since I’m not sure why we’re getting
EAGAIN in the first place, I wonder what could happen (infinite loop?).

Could you give it a try?

Can you reproduce the substitute issue in a simpler environment?
For instance, by running:

  rm -rf ~/.cache/guix/substitute/
  ./pre-inst-env guix weather $(guix package -A |head -2000 |cut -f1) 

This makes 2000 pipelined GETs to https://ci.guix.gnu.org, which is
probably similar to what you observe during system installation.

Thanks for the thorough debugging and bisecting, as always!

Ludo’.

diff --git a/guix/http-client.scm b/guix/http-client.scm
index a2e11a1b73..51bba250d5 100644
--- a/guix/http-client.scm
+++ b/guix/http-client.scm
@@ -38,7 +38,7 @@
   #:use-module (guix utils)
   #:use-module (guix base64)
   #:autoload   (gcrypt hash) (sha256)
-  #:autoload   (gnutls) (error/invalid-session)
+  #:autoload   (gnutls) (error/invalid-session error/again)
   #:use-module ((guix build utils)
 #:select (mkdir-p dump-port))
   #:use-module ((guix build download)
@@ -163,7 +163,8 @@ reusing stale cached connections."
   (if (or (and (eq? key 'system-error)
(= EPIPE (system-error-errno `(,key ,@args
   (and (eq? key 'gnutls-error)
-   (eq? (first args) error/invalid-session))
+   (memq (first args)
+ (list error/again error/invalid-session)))
   (memq key
 '(bad-response bad-header bad-header-component)))
   #f
diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 48309f9b3a..65940591a9 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -45,7 +45,7 @@
 #:select (uri-abbreviation nar-uri-abbreviation
   (open-connection-for-uri
. guix:open-connection-for-uri)))
-  #:autoload   (gnutls) (error/invalid-session)
+  #:autoload   (gnutls) (error/invalid-session error/again)
   #:use-module (guix progress)
   #:use-module ((guix build syscalls)
 #:select (set-thread-name))
@@ -417,7 +417,8 @@ server certificates."
 (if (or (and (eq? key 'system-error)
  (= EPIPE (system-error-errno `(,key ,@args
 (and (eq? key 'gnutls-error)
- (eq? (first args) error/invalid-session))
+ (memq (first args)
+   (list error/again error/invalid-session)))
 (memq key '(bad-response bad-header bad-header-component)))
 (proc (open-connection-for-uri/cached uri
   #:verify-certificate? #f

bug#47911: Improving the package outputs UI

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Leo Famulari writes:

Another idea I had is to make Guix accept the concatenation of
packagename-output in the UI.


I'm firmly against this (but read on :-)



For example, `guix install git-send-email`, instead of 
`git:send-email`.


But maybe that is going too far, I'm not sure.


I think it is, but the intention is good.

Instead, Guix could suggest (‘did you mean...?’) like it does for 
commands.


 ~ λ guix install git-send-email
 guix install: error: git-send-email: unknown package
 hint: Did you mean one of:
 git:send-email

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#47911: Package outputs should be described in the UI

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> At least once a month I have to help somebody on IRC who didn't notice
> that our Git package is split into multiple outputs.
>
> They can't find `git send-email`, and the Guix package UI doesn't make
> this clear enough.

Just a side note: our ‘git’ package uses outputs in a rather unusual
way.  There are other packages that provide different features in
different outputs, but the majority of multiple-output packages have the
“standard” outputs: “doc”, “bin”, “lib”, “debug”.

So maybe we could look at the ‘git’ package (can it be split into
several packages? would that help?) in addition to the UI, and also make
sure the UI is optimized for the most frequent cases.

Ludo’.

bug#47924: v1.3.0: Missing configure check for guile-lib >= 0.27

[Carl Dong]

Hi all,

Testing out the version-1.3.0 branch right now, and I think perhaps it’s 
missing a configure-time check for guile-lib >= 0.27 for %strict-tokenizer?

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

bug#47919: Sourcing environment-variables may send to wrong directory

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Alexandre,

Alexandre Hannud Abdo writes:

/tmp/guix-build-[package].drv-1$ source environment-variables
/tmp/guix-build-[package].drv-0/[package]$


If Guix used a different build directory depending on how many 
previous builds were kept, many builds would become 
irreproducible.


Instead, Guix always uses .drv-0 inside the build container.  When 
you pass --keep and the build fails and .drv-0 already exists on 
the host, it's renamed.


If you want ‘environment-variables’ to match the environment 
outside of the container, rename /tmp/guix-build-[package].drv-1 
to /tmp/guix-build-[package].drv-0.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#47920: AttributeError: 'PosixPath' object has no attribute 'read_text'

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

Greetings, in the last update some python packages were broken, such as 
docker-compose, giving the
following error:

Traceback (most recent call last):
  File 
"/gnu/store/rnbsmwmk06kxn899ckvy4pprvg9ypsrs-docker-compose-1.25.4/bin/.docker-compose-real",
 line 11, in 
load_entry_point('docker-compose==1.25.4', 'console_scripts', 
'docker-compose')()
  File 
"/gnu/store/v1l6cm8aa47zsxvjjmzd5rpdbbslzpc8-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File 
"/gnu/store/v1l6cm8aa47zsxvjjmzd5rpdbbslzpc8-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 2852, in load_entry_point
return ep.load()
  File 
"/gnu/store/v1l6cm8aa47zsxvjjmzd5rpdbbslzpc8-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 2443, in load
return self.resolve()
  File 
"/gnu/store/v1l6cm8aa47zsxvjjmzd5rpdbbslzpc8-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 2449, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File 
"/gnu/store/rnbsmwmk06kxn899ckvy4pprvg9ypsrs-docker-compose-1.25.4/lib/python3.8/site-packages/compose/cli/main.py",
 line 24, in 
from ..config import ConfigurationError
  File 
"/gnu/store/rnbsmwmk06kxn899ckvy4pprvg9ypsrs-docker-compose-1.25.4/lib/python3.8/site-packages/compose/config/__init__.py",
 line 6, in 
from .config import ConfigurationError
  File 
"/gnu/store/rnbsmwmk06kxn899ckvy4pprvg9ypsrs-docker-compose-1.25.4/lib/python3.8/site-packages/compose/config/config.py",
 line 51, in 
from .validation import match_named_volumes
  File 
"/gnu/store/rnbsmwmk06kxn899ckvy4pprvg9ypsrs-docker-compose-1.25.4/lib/python3.8/site-packages/compose/config/validation.py",
 line 12, in 
from jsonschema import Draft4Validator
  File 
"/gnu/store/v0i3hq0nmdzydfix8jvjl69367zaz0zz-python-jsonschema-3.2.0/lib/python3.8/site-packages/jsonschema/__init__.py",
 line 34, in 
__version__ = metadata.version("jsonschema")
  File 
"/gnu/store/rqy4flv8v7mp9994bjh20amk1hfj9xvs-python-3.8.2/lib/python3.8/importlib/metadata.py",
 line 531, in version
return distribution(distribution_name).version
  File 
"/gnu/store/rqy4flv8v7mp9994bjh20amk1hfj9xvs-python-3.8.2/lib/python3.8/importlib/metadata.py",
 line 236, in version
return self.metadata['Version']
  File 
"/gnu/store/rqy4flv8v7mp9994bjh20amk1hfj9xvs-python-3.8.2/lib/python3.8/importlib/metadata.py",
 line 224, in metadata
self.read_text('METADATA')
  File 
"/gnu/store/rqy4flv8v7mp9994bjh20amk1hfj9xvs-python-3.8.2/lib/python3.8/importlib/metadata.py",
 line 491, in read_text
return self._path.joinpath(filename).read_text(encoding='utf-8')
AttributeError: 'PosixPath' object has no attribute 'read_text'


Thank you

bug#47911: Package outputs should be described in the UI

[Bone Baboon via Bug reports for GNU Guix]

Leo Famulari writes:

> At least once a month I have to help somebody on IRC who didn't notice
> that our Git package is split into multiple outputs.
>
> They can't find `git send-email`, and the Guix package UI doesn't make
> this clear enough.
>
> I had the idea that package outputs besides 'out' and 'debug' should
> have very brief descriptions that are exposed in `guix show` and `guix
> search` and the `guix package` equivalents.

I ran into this issue when I started using Guix.

I like this idea.

bug#47899: Update

[Noah Landis]

After a second reboot, it has seemed to work properly again.

-- 
Noah Landis  
GPG key = 3D5E 7A7A 0DF1 B4D8 669C F3EE 30B8 3188 A3AF F882
Confidentiality cannot be guaranteed on emails sent or received unencrypted

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 02:00:54PM -0400, Leo Famulari wrote:
> On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote:
> > On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> > > It seems this is the bad commit.  Downloading the enlightenment
> > > substitute got stuck and after a few minutes displayed the usual TLS
> > > error.
> > 
> > P.S. There are no issues on my Macbook on the same internet
> > connection, the issue is only with the Beebox PC.
> 
> To clarify, you're running the same Guix on both machines, but it only
> fails on one of them?

No sorry I was mistaken, sorry for misguiding you.

I had thought so, but the actions were different on both machines.
Only full installs fail.

Doing a full install with the Enlightenment desktop environment fails
with TLS errors on the Beebox PC.

guix build enlightenment succeeds on the Macbook (with same Guix
commit), but

Running
mount /dev/sda2 /mnt
guile -c '((@ (gnu build install) mount-cow-store) "/mnt" "/tmp/guix-inst")'
guix build enlightenment
succeeds though.  (Without mount-cow-store disk space is insufficient.)

So I will try to do a full reinstall with Enlightenment on the Macbook
now after a backup.

Regards,
Florian

bug#47917: Guix 1.3.0 'herd start cow-store /mnt' Doesnt work

[bo0od]

Hi There,

Im trying to install guix 1.3.0 latest version but i couldnt proceed 
after this step mentioned here:


https://guix.gnu.org/manual/en/html_node/Proceeding-with-the-Installation.html

It will give error provided in the attachment.

Note(1): Im following the manual installation method , using MBR method 
of installation dos/xvda, xvda1 40GiB ext4 , xvda2 8GiB swap. Inside Xen VM


Note(2): Used exact same steps with Guix 1.2.0 and went through smoothly.

ThX!

bug#47908: Cross building disk image for ARM Asus C201 fails

[Maxime Devos]

Martin via Bug reports for GNU Guix schreef op di 20-04-2021 om 11:37 [+]:
> Hello,
> I'm trying to create a disk image for an Asus C201 chromebook using the 
> command 'guix system image test.scm' where test.scm based on 
> https://github.com/guix-mirror/guix/blob/master/gnu/system/examples/asus-c201.tmpl
>  
> but unfortunately this operation fails on my x86 dev machine (guix 53ed3e4):
> 
> ---
> [...]
> View build log at 
> '/var/log/guix/drvs/z2/diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv.bz2'.
> guix system: error: build of 
> `/gnu/store/z2diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv' 
> failed
> ---
> 
> the logs:
> [...]
> In unknown file:
> 2 (string-append #f "/bin/cmp")
> In ice-9/boot-9.scm:
>1669:16  1 (raise-exception _ #:continuable? _)
>1669:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure string-append: Wrong type (expecting string): #f
> ---

> Any ideas how to fix it

Some issues I see in the definition of the "vboot-utils" package:

(arguments
 `(#:make-flags (list "CC=gcc"
  ;; On ARM, we must pass "HOST_ARCH=arm" so that the

The "CC=gcc" should be ,(string-append "CC=" (cc-for-target)), such that the
cross-compiler is used.  (cc-for-target) also works when not cross-compiling.

(lambda* (#:key inputs outputs #:allow-other-keys)
  (let ((coreutils (assoc-ref inputs "coreutils"))
(diffutils (assoc-ref inputs "diffutils")))
[...]
(substitute* "tests/bitmaps/TestBmpBlock.py"
  (("/usr/bin/cmp") (string-append diffutils 
"/bin/cmp")))

"diffutils" should be looked up in 'native-inputs', not 'inputs', as "cmp" is 
run
when building the package.  (And not when this package is actually used at 
run-time).

So that should be

(lambda* (#:key native-inputs inputs outputs 
#:allow-other-keys)
  (let ((coreutils (assoc-ref inputs "coreutils"))
(diffutils (assoc-
ref (or native-inputs inputs) "diffutils")))
[...]
(substitute* "tests/bitmaps/TestBmpBlock.py"
  (("/usr/bin/cmp") (string-append
diffutils "/bin/cmp")))

p.s.  I began replacing "CC=gcc" with ,(string-append "CC=" (cc-for-target)) 
where it seemed
necessary in the patch series at 

Greetings,
Maxime.


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

bug#47647: Feature request: Make guix communicate over Hidden Services

[bo0od]

Yeah but how can someone create Tor mirror to guix upstream/main 
repository if its not done by the upstream themselves?


Unless user make his own server and get all guix packages there in order 
for him to have Tor-Tor connection from his own server/repository which 
is crazy amount of effort compared to just mounting the upstream main 
server (same server not different one) to Tor.


Having clearnet and Tor entries for same server way much easier to 
create new server just for Tor.


Ludovic Courtès:

Hi,

bo0od  skribis:


Yeah not clean connection, What i meant by this feature sorry i didnt
say it clearer at the the first text which is Guix main repository
guix-git must be mirrored over tor hidden services then when using
guix install or guix pull or ...etc is going to be all over Tor (no
TLS used).


OK, this is what the cookbook entry proposes, right?

The missing bit is accessing the Git repo of the ‘guix’ channel via an
Onion service (for ‘guix pull’), though one can easily create such a
mirror.

HTH,
Ludo’.

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[Leo Famulari]

On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> > It seems this is the bad commit.  Downloading the enlightenment
> > substitute got stuck and after a few minutes displayed the usual TLS
> > error.
> 
> P.S. There are no issues on my Macbook on the same internet
> connection, the issue is only with the Beebox PC.

To clarify, you're running the same Guix on both machines, but it only
fails on one of them?

bug#47911: Improving the package outputs UI

[Leo Famulari]

Another idea I had is to make Guix accept the concatenation of
packagename-output in the UI.

For example, `guix install git-send-email`, instead of `git:send-email`.

But maybe that is going too far, I'm not sure.

By the way, the #guix IRC discussion was here

https://logs.guix.gnu.org/guix/2021-03-11.log#194558

bug#47911: Package outputs should be described in the UI

[Leo Famulari]

At least once a month I have to help somebody on IRC who didn't notice
that our Git package is split into multiple outputs.

They can't find `git send-email`, and the Guix package UI doesn't make
this clear enough.

I had the idea that package outputs besides 'out' and 'debug' should
have very brief descriptions that are exposed in `guix show` and `guix
search` and the `guix package` equivalents.

So, maybe it would look like this:

--
$ guix show git
name: git
version: 2.31.1
outputs: out send-email svn credential-netrc credential-libsecret subtree gui
  * send-email: Tools for an email-based Git workflow
  * svn: Provides git-svn, for bidirectional operation between Subversion and 
Git repositories
  * credential-libsecret: Whatever that is
  * subtree: Who knows?
  * gui: A graphical interface for exploring a Git repository
  * etc...
systems: x86_64-linux i686-linux
dependencies: asciidoc-py3@9.0.1 bash-minimal@5.0.16 bash@5.0.16 curl@7.74.0 
docbook-xsl@1.79.1 expat@2.2.9 gettext-minimal@0.20.1 glib@2.62.6 
libsecret@0.20.4 openssl@1.1.1i pcre2@10.35
+ perl-authen-sasl@2.16 perl-cgi@4.51 perl-io-socket-ssl@2.066 
perl-net-smtp-ssl@1.04 perl-term-readkey@2.38 perl@5.30.2 pkg-config@0.29.2 
python@3.8.2 subversion@1.14.1 tcl@8.6.10 tk@8.6.10
+ xmlto@0.0.28 zlib@1.2.11
location: gnu/packages/version-control.scm:173:2
homepage: https://git-scm.com/
license: GPL 2
synopsis: Distributed version control system  
description: Git is a free distributed version control system designed to 
handle everything from small to very large projects with speed and efficiency.
--

The output of `guix show` and `guix search` are in recutils format, and
we'd need to make sure that these new UI elements continued that
valuable tradition.

bug#31719: icedtea-3 binaries contain references to icedtea-2

[Ludovic Courtès]

Hi Carlo,

Carlo Zancanaro  skribis:

> From 60101b27543b7cc41a052d5bec95234ea4977d35 Mon Sep 17 00:00:00 2001
> From: Carlo Zancanaro 
> Date: Tue, 20 Apr 2021 21:22:20 +1000
> Subject: [PATCH] gnu: Fix openjdk library substitution when libraries aren't
>  found
>
> * gnu/packages/java.scm (icedtea-8, openjdk9, openjdk11): Fix JNI library
> substitution to not substitute #f if the library can't be found.

Thanks for the update patch!  Please mention ‘find-library’ in the
commit log, for clarity.

I think you can go and push it to master given that OpenJDK is probably
broken due to those #f right now.  However, please push an additional
commit at the same time that adds those #:disallowed-references I
proposed.  (Though you’ll have to rebuild openjdk@11 to be sure.)

Sounds good?

Ludo’.

bug#47647: Feature request: Make guix communicate over Hidden Services

[Ludovic Courtès]

Hi,

bo0od  skribis:

> Yeah not clean connection, What i meant by this feature sorry i didnt
> say it clearer at the the first text which is Guix main repository 
> guix-git must be mirrored over tor hidden services then when using
> guix install or guix pull or ...etc is going to be all over Tor (no
> TLS used).

OK, this is what the cookbook entry proposes, right?

The missing bit is accessing the Git repo of the ‘guix’ channel via an
Onion service (for ‘guix pull’), though one can easily create such a
mirror.

HTH,
Ludo’.

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd

It seems this is the bad commit.  Downloading the enlightenment
substitute got stuck and after a few minutes displayed the usual TLS
error.

Regards,
Florian

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

[Ricardo Wurmus]

merge 47576 22707
thanks

Ludo, the patch looks good to me.  However, many ibus input 
methods are not provided by the ibus package itself, so for 
ibus-anthy or ibus-libpinyin we would need a different mechanism.


Would it make sense to introduce another environment variable 
(e.g. GUIX_IBUS_COMPONENTS_PATH) that specifies a search path on 
which components are looked up?  I feel that this partially 
defeats the purpose of having a cache, so perhaps this is 
nonsensical.


What do you think?

--
Ricardo

bug#47841: 'tarball' jobs on ci.guix.gnu.org install the wrong profile

[Mathieu Othacehe]

Hey,

> Okay, thanks! By the way, what is that '68a11045'? If it's a Git commit,
> I can't figure out where it is.

Yeah, but it disappeared when I removed the wip branch. I pushed it on
master: 2ccb715ab3ebef5ddbc53d706cbc42b3b765d613.

I tried to install a CI produced tarball
(https://ci.guix.gnu.org/build/213975/details) on a foreign distribution
VM with success.

Closing this one,

Thanks,

Mathieu

bug#47759: python-minimal tests hang

[Maxim Cournoyer]

block 47297 by 47759
thanks

Hi!

Leo Famulari  writes:

> On Tue, Apr 13, 2021 at 10:38:17PM +0200, Danny Milosavljevic wrote:
>> On x86_64, python-minimal build hangs when running the tests:
>> 
>> $ guix build 
>> /gnu/store/gifx79qc77zk88z6gnabj81iksp1xaj9-python-minimal-3.8.2.drv
>> [...]
>> 1:06:10 load avg: 1.31 running: test_multiprocessing_forkserver (14 min 42 
>> sec)
>
> Where does this derivation come from? I can't seem to find it on the
> machines I have access to.
>
>> $ guix describe
>> Generation 230  Apr 13 2021 12:15:27(current)
>>   guix 822eacc
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: 822eacc6bb0878323e6687d4460a7c53066545e1
>> $ uname -a
>> Linux dayas 5.11.4-gnu #1 SMP 1 x86_64 GNU/Linux
>
> --
> $ guix describe
> Generation 15   Apr 13 2021 23:26:10(current)
>   guix 822eacc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 822eacc6bb0878323e6687d4460a7c53066545e1
> $ guix build --derivations --no-grafts python-minimal 
> /gnu/store/qkggqs5pxr9fmczc6gn5rs3d51ykhh36-python-minimal-3.8.2.drv
> $ guix build --derivations --no-grafts python-minimal-wrapper
> /gnu/store/qvib4wzz542czxfsl7dw4bnlz0kdrm82-python-minimal-wrapper-3.8.2.drv
> --

I can also reproduce this on the version-1.3.0, building for
armhf-linux.  Another release blocker :-/.

Thanks,

Maxim

bug#47908: Cross building disk image for ARM Asus C201 fails

[Martin via Bug reports for GNU Guix]

Hello,
I'm trying to create a disk image for an Asus C201 chromebook using the 
command 'guix system image test.scm' where test.scm based on 
https://github.com/guix-mirror/guix/blob/master/gnu/system/examples/asus-c201.tmpl 
but unfortunately this operation fails on my x86 dev machine (guix 53ed3e4):


---
 yaml-0.2.5.tar.gz  595KiB  4.0MiB/s 
00:00 [##] 100.0%
 zstd-1.4.4.tar.xz  1.3MiB  2.9MiB/s 
00:00 [##] 100.0%

building /gnu/store/ifnczywhsw1x5wijrv60myv309g7vqg0-libyaml-0.2.5.drv...
building 
/gnu/store/fi24bh8iqrwqby2224n602vd0x2gvz81-python-minimal-3.8.2.drv...
building 
/gnu/store/z2diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv...
- 'patch-hard-coded-paths' phasebuilder for 
`/gnu/store/z2diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv' 
failed with exit code 1
build of 
/gnu/store/z2diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv 
failed
View build log at 
'/var/log/guix/drvs/z2/diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv.bz2'.
guix system: error: build of 
`/gnu/store/z2diqxmpr8zkiyk2d5vma4flwvd3bzk6-vboot-utils-R63-10032.B.drv' 
failed

---

the logs:
---
vboot-utils-R63-10032.B-checkout/vboot_host.pc.in
phase `unpack' succeeded after 1.1 seconds
starting phase `patch-hard-coded-paths'
Backtrace:
  16 (primitive-load "/gnu/store/3px9vwr51v82zhh7bzi8wcmiaw3…")
In ice-9/eval.scm:
   191:35 15 (_ #f)
In guix/build/gnu-build-system.scm:
    838:2 14 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16 12 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30 11 (_ _)
In ice-9/eval.scm:
    619:8 10 (_ #(#(#(#) # #) …))
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 #f "/bin/cmp")
In ice-9/boot-9.scm:
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure string-append: Wrong type (expecting string): #f
---

Any ideas how to fix it or do you know some alternative approaches how 
to install GuixSD on Asus C201?


Thanks,
Martin

bug#31719: icedtea-3 binaries contain references to icedtea-2

[Carlo Zancanaro]

Hi Ludo!

On Tue, Apr 20 2021, Ludovic Courtès wrote:

 (find-library (lambda (name)
-(or (search-path
- library-path
- (string-append "lib" 
name ".so"))
-(string-append "lib" 
name ".so")

+(search-path
+ library-path
+ (string-append "lib" name 
".so")

(for-each


As discussed on IRC, the "or" is actually important here to avoid 
substituting #f as the library name. I've attached a patch on top 
of yours that adds the "or" back (including the other two that I 
missed in my earlier patch), and also switches to "string-append" 
which is less sensitive to this problem.


I have built up to openjdk11 with this patch, and I see less #f's 
in the result. There are still some in the compiled libraries, but 
I haven't investigated thoroughly as to whether they're correct or 
not.


Carlo

>From 60101b27543b7cc41a052d5bec95234ea4977d35 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro 
Date: Tue, 20 Apr 2021 21:22:20 +1000
Subject: [PATCH] gnu: Fix openjdk library substitution when libraries aren't
 found

* gnu/packages/java.scm (icedtea-8, openjdk9, openjdk11): Fix JNI library
substitution to not substitute #f if the library can't be found.
---
 gnu/packages/java.scm | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index b780f7a85f..8a1ba5f262 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1806,9 +1806,10 @@ new Date();"))
   (search-path-as-string->list
(getenv "LIBRARY_PATH"
 (find-library (lambda (name)
-(search-path
- library-path
- (string-append "lib" name ".so")
+(or (search-path
+ library-path
+ (string-append "lib" name ".so"))
+(string-append "lib" name ".so")
(for-each
 (lambda (file)
   (catch 'decoding-error
@@ -1816,9 +1817,9 @@ new Date();"))
   (substitute* file
 (("VERSIONED_JNI_LIB_NAME\\(\"(.*)\", \"(.*)\"\\)"
   _ name version)
- (format #f "\"~a\""  (find-library name)))
+ (string-append "\"" (find-library name) "\""))
 (("JNI_LIB_NAME\\(\"(.*)\"\\)" _ name)
- (format #f "\"~a\"" (find-library name)
+ (string-append "\"" (find-library name) "\""
 (lambda _
   ;; Those are safe to skip.
   (format (current-error-port)
@@ -1956,9 +1957,10 @@ new Date();"))
   (search-path-as-string->list
(getenv "LIBRARY_PATH"
 (find-library (lambda (name)
-(search-path
- library-path
- (string-append "lib" name ".so")
+(or (search-path
+ library-path
+ (string-append "lib" name ".so"))
+(string-append "lib" name ".so")
(for-each
 (lambda (file)
   (catch 'decoding-error
@@ -1966,9 +1968,9 @@ new Date();"))
   (substitute* file
 (("VERSIONED_JNI_LIB_NAME\\(\"(.*)\", \"(.*)\"\\)"
   _ name version)
- (format #f "\"~a\""  (find-library name)))
+ (string-append "\"" (find-library name) "\""))
 (("JNI_LIB_NAME\\(\"(.*)\"\\)" _ name)
- (format #f "\"~a\"" (find-library name)
+ (string-append "\"" (find-library name) "\""
 (lambda _
   ;; Those are safe to skip.
   (format (current-error-port)
@@ -2177,9 +2179,10 @@ new Date();"))
   (search-path-as-string->list
(getenv 

bug#32339: "nix import" fails

[Ludovic Courtès]

‘guix import nix’ has now been removed:

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

Closing!

Ludo’.

bug#36255: Nix importer returns error

[Ludovic Courtès]

Hi,

‘guix import nix’ has just been removed after years of bitrot:

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

Closing this issue.

Ludo’.

bug#47808: guile-git-0.5.0.drv build failed on i686-linux

[Ludovic Courtès]

Fixed in 50d9bccb2fb64d85e691dfc98fa2f02850b496a1, thanks!

Ludo'.

bug#31719: icedtea-3 binaries contain references to icedtea-2

[Andreas Enge]

Am Tue, Apr 20, 2021 at 11:24:59AM +0200 schrieb Ludovic Courtès:
> I think we can close it.  I have the attached improvements that I can
> commit to ‘staging’ (or ‘core-updates’?) to avoid another rebuild.

I think they can easily go to master; the time for rebuilds is not very
high, I just ran into trouble since I had little space left on the device
so some manual intervention was required to gc intermediate packages.

There also seem to be very few dependencies if "guix refresh -l openjdk"
is to be trusted.

Andreas

bug#31719: icedtea-3 binaries contain references to icedtea-2

[Ludovic Courtès]

Hi,

Andreas Enge  skribis:

> Am Mon, Apr 19, 2021 at 08:18:03PM +0200 schrieb Ricardo Wurmus:
>> I just looked over the patch, and while I’m not sure it’s the best way to do
>> things (matching “openjdk” or “icedtea” in the package name seems a little
>> error prone in the presence of packages whose names might include these
>> strings), but I think it’s a definite improvement.
>
> I just pushed the patch to master. Thanks a lot, Carlo! It has definitely
> solved my problem: I can now compile an Android project after downloading
> a single openjdk package.
>
> It would be nice if someone else could close the bug if you feel the problem
> is solved, or otherwise leave it open to discuss further possible 
> improvements.

I think we can close it.  I have the attached improvements that I can
commit to ‘staging’ (or ‘core-updates’?) to avoid another rebuild.

Thanks!

Ludo’.

>From 253d0485a9307c4e08afc058d7dafcd56025f9a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Tue, 20 Apr 2021 00:26:01 +0200
Subject: [PATCH] java fixlet

---
 gnu/packages/java.scm | 35 +++
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 3c4013ab6f..b780f7a85f 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1749,6 +1749,9 @@ IcedTea build harness.")
  ((guix build ant-build-system)
   (guix build syscalls)
   ,@%gnu-build-system-modules)
+
+ #:disallowed-references ((,icedtea-7 "jdk"))
+
  ,@(substitute-keyword-arguments (package-arguments icedtea-7)
  ((#:modules modules)
   `((guix build utils)
@@ -1792,10 +1795,13 @@ new Date();"))
  (add-after 'unpack 'patch-jni-libs
;; Hardcode dynamically loaded libraries.
(lambda _
- (use-modules (srfi srfi-1))
+ (define remove
+   (@ (srfi srfi-1) remove))
+
  (define (icedtea-or-openjdk? path)
(or (string-contains path "openjdk")
(string-contains path "icedtea")))
+
  (let* ((library-path (remove icedtea-or-openjdk?
   (search-path-as-string->list
(getenv "LIBRARY_PATH"
@@ -1898,6 +1904,9 @@ new Date();"))
#:imported-modules
((guix build syscalls)
 ,@%gnu-build-system-modules)
+
+   #:disallowed-references (,icedtea-8 (,icedtea-8 "jdk"))
+
#:phases
(modify-phases %standard-phases
  (add-after 'patch-source-shebangs 'fix-java-shebangs
@@ -1936,18 +1945,20 @@ new Date();"))
  (add-after 'unpack 'patch-jni-libs
;; Hardcode dynamically loaded libraries.
(lambda _
- (use-modules (srfi srfi-1))
+ (define remove
+   (@ (srfi srfi-1) remove))
+
  (define (icedtea-or-openjdk? path)
(or (string-contains path "openjdk")
(string-contains path "icedtea")))
+
  (let* ((library-path (remove icedtea-or-openjdk?
   (search-path-as-string->list
(getenv "LIBRARY_PATH"
 (find-library (lambda (name)
-(or (search-path
- library-path
- (string-append "lib" name ".so"))
-(string-append "lib" name ".so")
+(search-path
+ library-path
+ (string-append "lib" name ".so")
(for-each
 (lambda (file)
   (catch 'decoding-error
@@ -2090,7 +2101,9 @@ new Date();"))
"--with-libjpeg=system"
"--with-native-debug-symbols=zipped"
(string-append "--prefix=" (assoc-ref outputs "out")))
-   #t))
+   #t
+   ((#:disallowed-references _ '())
+`(,openjdk9 (,openjdk9 "jdk")
 (native-inputs
  `(("openjdk9" ,openjdk9)
("openjdk9:jdk" ,openjdk9 "jdk")
@@ -2120,6 +2133,9 @@ new Date();"))
 (arguments
  `(#:imported-modules ((guix build syscalls)
,@%gnu-build-system-modules)
+
+   #:disallowed-references (,openjdk10 (,openjdk10 "jdk"))
+
#:tests? #f; requires jtreg
;; TODO package jtreg
#:configure-flags
@@ -2150,10 +2166,13 @@ new Date();"))
  (add-after 'unpack 'patch-jni-libs
;; Hardcode dynamically loaded libraries.
(lambda _
- (use-modules (srfi srfi-1))
+ (define remove
+  

bug#47545: Guix bug on guix pull

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

>> ./guix/store.scm:1373:15: ERROR:
>>   1. :
>>   message: "some substitutes for the outputs of derivation 
>> `/gnu/store/hnsk4qjsidn7xk6qb42sgy0ak2gbxbnb-zziplib-0.13.72.drv' failed 
>> (usually happens due to networking issues); try `--fallback' to build 
>> derivation from source "
>>   status: 1
>> guix pull: error: You found a bug: the program 
>> '/gnu/store/bg6vs7ahglli408xaifp8rss68ss3qqc-compute-guix-derivation'
>> failed to compute the derivation for Guix (version: 
>> "a266c9fab88954b7c0fc0516e0a4c9834819dbc5"; system: "x86_64-linux";
>> host version: "266d55dc3080475544bf45e72359c9b9bbcecd53"; pull-version: 1).
>
> Seems like a bug with error reporting.  Also, from th ‘bad request line’ 
> message,
> this seems a bug in the substituter as well.

Yes, it’s most likely , which is
fixed in recent daemons.

Zelphir, could you upgrade your daemon and report whether the problem
still happens?  See
.

Thanks,
Ludo’.

bug#31719: Chains of dependencies getting longer

[Carlo Zancanaro]

On 20 April 2021 4:18:03 am AEST, Ricardo Wurmus  wrote:
>I just looked over the patch, and while I’m not sure it’s the best way to do 
>things (matching “openjdk” or “icedtea” in the package name seems a little 
>error prone in the presence of packages whose names might include these 
>strings), but I think it’s a definite improvement.

Yeah, I'm agreed on that. I tried for a while to find a way to exclude native 
inputs, but as far as I could tell they all ended up as inputs within the build 
phases. I'd be happy to change it if somebody can give me a hint about how to 
pick out the native inputs.

Carlo

bug#31719: Chains of dependencies getting longer

[Andreas Enge]

Hello,

Am Mon, Apr 19, 2021 at 08:18:03PM +0200 schrieb Ricardo Wurmus:
> I just looked over the patch, and while I’m not sure it’s the best way to do
> things (matching “openjdk” or “icedtea” in the package name seems a little
> error prone in the presence of packages whose names might include these
> strings), but I think it’s a definite improvement.

I just pushed the patch to master. Thanks a lot, Carlo! It has definitely
solved my problem: I can now compile an Android project after downloading
a single openjdk package.

It would be nice if someone else could close the bug if you feel the problem
is solved, or otherwise leave it open to discuss further possible improvements.

Andreas