bug#60803: Cuirass stopped processing jobs for aarch64-linux and x86_64-linux

[Marius Bakke]

Marius Bakke  skriver:

> The 335212 build is for x86_64-linux, we have the same problem with
> 335087 (also perftest) on aarch64.  i686-linux and powerpc64le-linux is
> fine.

I deleted these two from the Builds and BuildDependencies tables which
allowed Cuirass to move forward (or backwards, really, as it was
processing new jobs just fine).

Not sure how to mitigate the problem (race when two evaluations create
different derivations with identical outputs at the same time?), but at
least we know how to deal with it.

Speaking of builds, I started debugging #60016 and accidentally deleted
build 175246!  Enough late night debugging for me...  I'll set up my own
Cuirass to experiment on "soon".


signature.asc
Description: PGP signature

bug#60803: Cuirass stopped processing jobs for aarch64-linux and x86_64-linux

[Marius Bakke]

Hello Guix,

Cuirass has stopped processing (old) jobs for aarch64 and x86_64.  After
digging through the database it's because (db-get-pending-build ...)
returns a build that is missing from the Jobs table:

  WITH pending_dependencies AS
  (SELECT Builds.id, count(dep.id) as deps FROM Builds
  LEFT JOIN BuildDependencies as bd ON bd.source = Builds.id
  LEFT JOIN Builds AS dep ON bd.target = dep.id AND dep.status != 0
  WHERE Builds.status = -2 AND Builds.system = 'x86_64-linux'
  GROUP BY builds.id
  ORDER BY Builds.priority ASC, Builds.timestamp DESC)
  SELECT id FROM pending_dependencies where deps = 0 limit 1;

 id
  
   335212

However:

  select * from jobs  where  build = 335212;
   name | evaluation | build | status | system
  --++---++
  (0 rows)

For clarity:

  select id,derivation,evaluation,job_name,nix_name,status from builds where id 
= 335212;
 id   |derivation | 
evaluation |   job_name| nix_name  | status
  
+---++---+---+
   335212 | /gnu/store/yzgcza0nijnp79mzz878q9a61p6jykgh-perftest-4.5-0.20.drv | 
103435 | perftest.x86_64-linux | perftest-4.5-0.20 | -2

The derivation is also missing from the Outputs table, which causes the
monster query in (db-get-builds ...), which is what workers call to
fetch the next job, to return nothing.

335212 belongs to evaluation 103435 according to the above query, but
does not show up here:

  https://ci.guix.gnu.org/eval/103435?all==0

The build id sequence appears to belong to this evaluation:

  https://ci.guix.gnu.org/eval/103436?all==0

(notice how it has 335211 and 335213).

I'm not sure how to recover from this.  Either manually create the
entries in Jobs and Outputs, or delete the offending Builds entry?

The 335212 build is for x86_64-linux, we have the same problem with
335087 (also perftest) on aarch64.  i686-linux and powerpc64le-linux is
fine.

Ideas?

bug#60016: Cuirass ignores failed dependencies

[Marius Bakke]

Hello,

Cuirass ignores failed build dependencies on subsequent evaluations
after the initial failure.

To clarify, say package P has two dependencies: A and B.

On evaluation 1, A fails.  The job for package P is cancelled and P gets
in the 'Dependency failed' state.  So far so good.

On evaluation 2, B is updated.  P is scheduled for build, despite A
still failing.  A is not even listed in the "Dependencies" field.  The
build job for P starts, and under the hood it unsurprisingly builds A
first, which is still broken, and the build job for P eventually fails.

A real work example pulled from ci.guix is OpenCV.  For reasons yet to
be investigated, OpenCV consistently fails on the build farm:

  https://ci.guix.gnu.org/build/175246/details

Yet 'hydrus-network' is scheduled for build:

  https://ci.guix.gnu.org/build/248218/details

The log for hydrus-network reveals that it is indeed attempting to build
OpenCV:

  https://ci.guix.gnu.org/build/248218/log/raw

I suppose this has to do with OpenCV missing from the 'dependencies'
field despite being an input to hydrus-network.

Thoughts?

bug#48602: Grafted python2 packages gets erroneous package names

[Marius Bakke]

Maxim Cournoyer  skriver:

> Hi,
>
> Marius Bakke  writes:
>
>> Hello,
>>
>> 'guix build python2-urllib3' currently gives:
>>
>>   /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4
>>
>> Adding '--no-grafts' gives the expected file name.
>>
>> Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the
>> store file name was actually '...-python2-python2-python2-urllib3-...'!
>>
>> Not sure if this is a recent regression, or what may be causing it.
>
> Since we virtually have no more python2 packages, I suggest we cut our
> losses and close this issue.

Definitively.  Closed!


signature.asc
Description: PGP signature

bug#59514: Stuck builds in Cuirass

[Marius Bakke]

Hi,

Cuirass has a tendency to not notice when a build is finished, leaving
it in a "running" state.

The phenomenon can be observed by going to
 and look at builds that are running for
a suspiciously long time.

Typically the build log will indicate that it has finished, yet Cuirass
is patiently waiting...and not scheduling further builds.

Restarting the builds typically get things going again.

I wrote a nasty script to automatically restart builds that are running
for >1 hour, but it's not a sustainable solution:

#!/usr/bin/env python3

# Restart stuck builds   TODO fix cuirass properly.

import requests
from bs4 import BeautifulSoup
import re

builds_page = "https://ci.guix.gnu.org/status;
builds_html = requests.get(builds_page).text

soup = BeautifulSoup(builds_html, "html5lib")
main = soup.find('main', {'id': 'content'})
table = main.find('table')

result = {}

for row in table.find_all('tr'):
data = row.find_all('td')
if len(data) > 0:
build_id = row.find('a').contents[0]
name = data[0].contents[0]
age = data[1].contents[0]
system = data[2].contents[0]
log = data[3]

result[build_id] = {'name': name, 'age': age, 'system': system}

age_re = re.compile("(\d+) (\w+) ago")
restart = []

for id in result.keys():
age = result[id]['age']
match = age_re.match(result[id]['age'])
if match is not None:  # "seconds ago"
digits = match.group(1)
time_unit = match.group(2)
if time_unit == "hours":
restart.append(id)
elif time_unit == "minutes" and int(digits) > 60:
restart.append(id)

certificate_file = "/home/marius/tmp/mbakke.cert.pem"
certificate_key = "/home/marius/tmp/mbakke.key.pem"

import time

print(f"Found {len(restart)} stuck builds..!")

for id in restart:
print(f"Going to restart {result[id]['name']} ({id}, running since 
{result[id]['age']})...")
requests.get(f"https://ci.guix.gnu.org/admin/build/{id}/restart;,
 cert=(certificate_file, certificate_key))
time.sleep(3)


signature.asc
Description: PGP signature

bug#59365: make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux

[Marius Bakke]

Hello,

LLVM 15.0.4 fails on i686-linux:

  https://ci.guix.gnu.org/build/1702995/details

Because the 'make-dynamic-linker-cache' phase runs out of memory:

  starting phase `make-dynamic-linker-cache'
  GC Warning: Repeated allocation of very large block (appr. size 268439552):
May lead to memory leak and poor performance
  GC Warning: Repeated allocation of very large block (appr. size 134221824):
May lead to memory leak and poor performance
  GC Warning: Repeated allocation of very large block (appr. size 268439552):
May lead to memory leak and poor performance
  GC Warning: Failed to expand heap by 285216768 bytes
  GC Warning: Failed to expand heap by 268439552 bytes
  GC Warning: Out of Memory! Heap size: 3620 MiB. Returning NULL!
  Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
  Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
  Warning: Unwind-only out of memory exception; skipping pre-unwind handler.

(excerpt from https://ci.guix.gnu.org/build/1702995/log/raw)

Not sure why this phase uses so much memory.  Ideas?


signature.asc
Description: PGP signature

bug#58290: guile ssh error on guix deploy

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Marius Bakke  skribis:
>
>> I have the same problem.  Log messages around failure look something
>> like this (extracted from above message):
>>
>>   Oct  4 11:51:49 localhost shepherd[1]: Service sshd-2 has been started. 
>>   Oct  4 11:51:50 localhost sshd[250]: Accepted publickey for bob from 
>> 185.70.53.164 port 1915 ssh2: RSA 
>> SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
>>   Oct  4 11:52:28 localhost sshd[252]: error: no more sessions
>>   Oct  4 11:52:28 localhost shepherd[1]: 1 connection still in use after 
>> sshd-2 termination. 
>>   Oct  4 11:52:28 localhost shepherd[1]: Service sshd-2 has been disabled. 
>>
>> Then deploy crashes with 'Channel opening failure'.
>
> “no more sessions” comes from this:
>
> --8<---cut here---start->8---
> int
> session_open(Authctxt *authctxt, int chanid)
> {
>   Session *s = session_new();
>   debug("session_open: channel %d", chanid);
>   if (s == NULL) {
>   error("no more sessions");
>   return 0;
>   }
>
> [...]
>
> }
> --8<---cut here---end--->8---
>
> Would be interesting to run sshd in verbose/debug mode and see why we
> hit that; it could be because the maximum number of sessions has been
> reached or something.

I enabled (log-level 'debug) and this is what happens server side:

Nov  3 21:48:25 capella sshd[26345]: debug1: permanently_set_uid: 0/0
Nov  3 21:50:27 capella sshd[26115]: debug1: Received SIGCHLD.
Nov  3 21:50:27 capella sshd[26115]: debug1: session_by_pid: pid 26345
Nov  3 21:50:27 capella sshd[26115]: debug1: session_exit_message: session 8 
channel 8 pid 26345
Nov  3 21:50:27 capella sshd[26115]: debug1: session_exit_message: release 
channel 8
Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: ctype 
session rchan 65 win 64000 max 32768
Nov  3 21:50:28 capella sshd[26115]: debug1: input_session_request
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 0: new [server-session]
Nov  3 21:50:28 capella sshd[26115]: debug1: session_new: session 0
Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: channel 0
Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: session 0: link with 
channel 0
Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: confirm 
session
Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_req: channel 
0 request exec reply 1
Nov  3 21:50:28 capella sshd[26115]: debug1: session_by_channel: session 0 
channel 0
Nov  3 21:50:28 capella sshd[26115]: debug1: session_input_channel_req: session 
0 req exec
Nov  3 21:50:28 capella sshd[26535]: debug1: PAM: reinitializing credentials
Nov  3 21:50:28 capella sshd[26535]: debug1: permanently_set_uid: 0/0
Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: ctype 
session rchan 66 win 64000 max 32768
Nov  3 21:50:28 capella sshd[26115]: debug1: input_session_request
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 10: new [server-session]
Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: channel 10
["no more sessions" error occurs here, in a different log file]
Nov  3 21:50:28 capella sshd[26115]: debug1: session open failed, free channel 
10
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 10: free: server-session, 
nchannels 11
Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: failure 
session
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 0: free: server-session, 
nchannels 10
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 1: free: server-session, 
nchannels 9
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 2: free: server-session, 
nchannels 8
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 3: free: server-session, 
nchannels 7
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 4: free: server-session, 
nchannels 6
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 5: free: server-session, 
nchannels 5
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 6: free: server-session, 
nchannels 4
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 7: free: server-session, 
nchannels 3
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 8: free: server-session, 
nchannels 2
Nov  3 21:50:28 capella sshd[26115]: debug1: channel 9: free: server-session, 
nchannels 1
Nov  3 21:50:28 capella sshd[26115]: debug1: do_cleanup

I compared this with a successful deploy:

Nov  3 21:44:22 capella sshd[25842]: debug1: permanently_set_uid: 0/0
Nov  3 21:46:25 capella sshd[25612]: debug1: Received SIGCHLD.
Nov  3 21:46:25 capella sshd[25612]: debug1: session_by_pid: pid 25842
Nov  3 21:46:25 capella sshd[25612]: debug1: session_exit_message: session 6 
channel 6 pid 25842
Nov  3 21:46:25 cap

bug#58927: guix --version is 0

[Marius Bakke]

bug#58290: guile ssh error on guix deploy

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Andrew Tropin  skribis:
>
 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
 Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel 
 opening failure: channel 67 error (2) open failed" #>>> (closed) 7f7d1af9e140> #f)'.
>>>
>>> Are there any hints from sshd in the /var/log/messages of that machine
>>> as to why the connection was closed?
>>
>> bob@pinky /var/log$ zcat messages.1.gz | grep "Oct  4" | grep ssh
>
> It’s hard (if not impossible) to see which lines correspond to the error
> above.  :-)
>
> Could try to reproduce the bug, and have ‘tail -f /var/log/messages’
> running on the server side so you can capture just the right lines?
> /var/log/debug might be interesting too.

I have the same problem.  Log messages around failure look something
like this (extracted from above message):

  Oct  4 11:51:49 localhost shepherd[1]: Service sshd-2 has been started. 
  Oct  4 11:51:50 localhost sshd[250]: Accepted publickey for bob from 
185.70.53.164 port 1915 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
  Oct  4 11:52:28 localhost sshd[252]: error: no more sessions
  Oct  4 11:52:28 localhost shepherd[1]: 1 connection still in use after sshd-2 
termination. 
  Oct  4 11:52:28 localhost shepherd[1]: Service sshd-2 has been disabled. 

Then deploy crashes with 'Channel opening failure'.

Due to the number of SSH connections made by deploy and frequent
occurence of this problem, I was not able to successfully deploy through
many attempts.

I found that removing the memoizing open-machine-ssh-session* in
(gnu machine ssh) works around it and can happily deploy again.

(that is, just use 'open-machine-ssh-session' instead)


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> Should not the mesa used by icecat be the same as `guix build mesa`,
> just like in the ungrafted case?  Their outputs differ, too:
>
>   $ guix hash -r $(guix build mesa | tail -n1)
>   1invy9jcd1fnfx7d4asfyjqs1jn7lngjfqswak6sy9ffjbhhsg6x
>   $ guix hash -r $(guix size icecat | grep mesa | awk '{ print $1 }')
>   195zk0c0h5m016hp0c1haqws47rwfj7sbpqpddmwk2iw402p3apv

Errh, the difference in output is not surprising since mesa obviously
contains references to itself.  Different derivation, different store
file name.

> Diffoscope says it will take 123 days to process these, so don't hold
> your breath!

It did not take 123 days, but I had diffed the wrong mesa.  Will update
if the difference is anything other than the mesa store file name...


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> zimoun  skriver:
>
>> Hi Marius,
>>
>> I reminds me this [1].
>>
>> 1: <https://yhetil.org/guix/874jy87gcl@gmail.com>
>
> Not sure if it's the same problem, but it is weird.  On 3d8c243efb615c7:
>
>   $ guix build mesa
>   /gnu/store/ccf705wvh0w224d6nyscnwlhqr04agk7-mesa-21.3.8-bin
>   /gnu/store/vcmxgmmhwr39gwwnz7ljkhcg1bmq2r5z-mesa-21.3.8
>   $ guix build --no-grafts mesa
>   /gnu/store/grh2142hg6l5g5xav2di7rr1pwbg9m38-mesa-21.3.8-bin
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8
>   $ guix size icecat | grep mesa
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  11.6%
>   $ guix size $(guix build --no-grafts icecat) | grep mesa
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  11.6%

Derp, the last two should be:

  $ guix size $(guix build icecat) | grep mesa
  /gnu/store/dbrsf4wmjjxwd3cvnbfrvikilj42gamy-mesa-21.3.8411.6   
169.6  11.6%
  $ guix size $(guix build --no-grafts icecat) | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%

('guix size' implicitly disables grafts)


signature.asc
Description: PGP signature

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Marius Bakke]

phodina via Bug reports for GNU Guix  skriver:

> Hi,
>
> unfortunately incorrect hash was pushed in the last patchset.
>
> The patch is already part of the next patch series [1].
>
> Also it's tracked here [2].
>
> 1 
> https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
> 2 https://issues.guix.gnu.org/57608#8

Whoops, I had missed these patches and pushed similar fixes to 'master':

  8681d90d50 gnu: akgregator: Fix source hash.
  3d8c243efb gnu: akgregator: Fix build.

Sorry for the duplicate work Brendan & Petr!


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

zimoun  skriver:

> Hi Marius,
>
> I reminds me this [1].
>
> 1: <https://yhetil.org/guix/874jy87gcl@gmail.com>

Not sure if it's the same problem, but it is weird.  On 3d8c243efb615c7:

  $ guix build mesa
  /gnu/store/ccf705wvh0w224d6nyscnwlhqr04agk7-mesa-21.3.8-bin
  /gnu/store/vcmxgmmhwr39gwwnz7ljkhcg1bmq2r5z-mesa-21.3.8
  $ guix build --no-grafts mesa
  /gnu/store/grh2142hg6l5g5xav2di7rr1pwbg9m38-mesa-21.3.8-bin
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8
  $ guix size icecat | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%
  $ guix size $(guix build --no-grafts icecat) | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%

Should not the mesa used by icecat be the same as `guix build mesa`,
just like in the ungrafted case?  Their outputs differ, too:

  $ guix hash -r $(guix build mesa | tail -n1)
  1invy9jcd1fnfx7d4asfyjqs1jn7lngjfqswak6sy9ffjbhhsg6x
  $ guix hash -r $(guix size icecat | grep mesa | awk '{ print $1 }')
  195zk0c0h5m016hp0c1haqws47rwfj7sbpqpddmwk2iw402p3apv

Diffoscope says it will take 123 days to process these, so don't hold
your breath!

> On dim., 16 oct. 2022 at 19:35, Marius Bakke  wrote:
>
>> It works for 'python-patiencediff', but fails for 'python-patch-ng',
>> both of which have no dependencies other than Python; but one uses
>> url-fetch and the other git-fetch.
>
> I guess that
>
>guix build python-patch-ng -d
>
> uses a grafted git-minimal and propagates it, whereas
>
>guix build python-patch-ng -d --no-grafts
>
> uses a non-grafted git-minimal.  Well, something like that. :-)

Indeed.

> Well, it is the same checkout output:
>
> --8<---cut here---start->8---
> $ guix build \
>
> /gnu/store/7bcypqy80bz8ygi4880dxdj8vzcsvhdf-python-patch-ng-1.17.4-checkout.drv
>  \
>
> /gnu/store/ivbkmnl6md7lzf275nvqwdh6lc924hal-python-patch-ng-1.17.4-checkout.drv
> /gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
> /gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
> --8<---cut here---end--->8---

That's guaranteed since these derivations are "fixed-output" (notice the
r:sha256 property in the beginning of the file).  If they had any other
output the daemon would throw a failure.

The bug here is that Guix treats grafted origins as different, even
though their outputs are known in advance.

Probably the grafting machinery should ignore fixed-output derivations
somehow?


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> I have a hunch that this has to do with the grafting code affecting
> origins (with gexps?), but have not confirmed this.

I have now confirmed this with a small shell script:

#!/bin/sh

pkg=$1

ungrafted="$(guix build --no-grafts -d $pkg)"
grafted="$(guix build -d $pkg)"

if [ $grafted = $ungrafted ]; then
echo $pkg has no grafts
else
grep "$ungrafted" "$grafted"
fi

It works for 'python-patiencediff', but fails for 'python-patch-ng',
both of which have no dependencies other than Python; but one uses
url-fetch and the other git-fetch.


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Hello,

Sorry for the indescriptive title, I'm not entirely sure what is going
wrong here.  The problem is that for some packages, 'guix build -d foo'
has a different input derivation than the one produced by
'guix build --no-grafts -d foo'.

As an example, as of commit 3d8c243efb615c7e642942433be1c7badf0ae65e,
'guix build -d telegram-desktop' produces:

  /gnu/store/q1gx5xaszlyyr0sx663c2qkx92cqbr4r-telegram-desktop-4.2.2.drv

If we open that graft derivation, we see that it depends on:

  /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv

However:

  $ guix build -d --no-grafts telegram-desktop
  /gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv

As a result:

  $ guix build telegram-desktop
  /gnu/store/6k2rdbc2v6nqyj2g445dii8gkamnbs43-telegram-desktop-4.2.2
  $ guix build --no-grafts telegram-desktop
  The following derivations will be built:
/gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv
/gnu/store/n0rdkaf91ifyvsr81hxcdlb8hg8k6rgh-fcitx-qt5-1.2.6.drv

This was discovered because users reported[0] missing substitutes for
telegram-desktop despite it being built by Cuirass.  We can see that it
has built the --no-grafts derivation:

  https://ci.guix.gnu.org/build/1626416/details

...which is not being requested by end-users.

I have a hunch that this has to do with the grafting code affecting
origins (with gexps?), but have not confirmed this.

"Trivial" grafted packages such as 'perl-xml-parser' do not exhibit this
problem.

[0] https://logs.guix.gnu.org/guix/2022-10-16.log#152428


signature.asc
Description: PGP signature

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Marius Bakke]

Ludovic Courtès  skriver:

> Marius Bakke  skribis:
>
>> Hello,
>>
>> I noticed Cuirass attempts to run imath tests on i686-linux:
>>
>>   https://ci.guix.gnu.org/build/739643/details
>
> Following the links, this corresponds to
> <https://ci.guix.gnu.org/eval/302107>, itself corresponding to commit
> f5fe0082abe4547f3fb9f29d8351473cfb3a387b, which dates back to May.
>
> So this is a recent build for an old commit; maybe it had been queued
> for some time and just got unlocked today?  Weirdness.

Hmm.  I was following some "dependency failed" links in Cuirass which
lead to that.  It was recently built because I restarted it.

> The good news is that with today’s ‘staging’, everything’s fine:

Not quite:

  https://ci.guix.gnu.org/search?query=system%3Ai686-linux+imath

Imath has no dependencies apart from CMake, so all of those should be
the same derivation, yet some are failing.


signature.asc
Description: PGP signature

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Marius Bakke]

Hello,

I noticed Cuirass attempts to run imath tests on i686-linux:

  https://ci.guix.gnu.org/build/739643/details

Which is odd, because the package definition has:

  (list #:tests? (not (target-x86-32?)))

This behavior does not reproduce when manually building for i686-linux.


signature.asc
Description: PGP signature

bug#57868: GStreamer gst_gstsystemclock test fails on CI for i686

[Marius Bakke]

Hi,

On i686-linux, the gstreamer gst_gstsystemclock test is failing:

--8<---cut here---start->8---
 41/108 gst_gstsystemclockFAIL1.26s   exit status 2
>>> GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT=600 
>>> GST_STATE_IGNORE_ELEMENTS='' MALLOC_PERTURB_=230 
>>> GST_PLUGIN_SCANNER_1_0=/tmp/guix-build-gstreamer-1.20.3.drv-0/build/libs/gst/helpers/gst-plugin-scanner
>>>  GST_PLUGIN_LOADING_WHITELIST=gstreamer 
>>> GST_REGISTRY=/tmp/guix-build-gstreamer-1.20.3.drv-0/build/tests/check/gst_gstsystemclock.registry
>>>  GST_PLUGIN_PATH_1_0=/tmp/guix-build-gstreamer-1.20.3.drv-0/build 
>>> /tmp/guix-build-gstreamer-1.20.3.drv-0/build/tests/check/gst_gstsystemclock
? ?  ?
stdout:
Running suite(s): GstSystemClock
75%: Checks: 8, Failures: 0, Errors: 2
../gstreamer-1.20.3/tests/check/gst/gstsystemclock.c:263:E:waiting:test_stress_cleanup_unschedule:0:
 (after this point) Received signal 5 (Trace/breakpoint trap)
../gstreamer-1.20.3/tests/check/gst/gstsystemclock.c:263:E:waiting:test_stress_reschedule:0:
 (after this point) Received signal 5 (Trace/breakpoint trap)
Check suite gst_systemclock ran in 1.236s (tests failed: 2)
stderr:

(gst_gstsystemclock:5546): GLib-ERROR **: 22:57:16.217: creating thread 'wait': 
Error creating thread: Resource temporarily unavailable

(gst_gstsystemclock:6027): GLib-ERROR **: 22:57:16.340: creating thread 'wait': 
Error creating thread: Resource temporarily unavailable
??
--8<---cut here---end--->8---

Full log output here:

  https://ci.guix.gnu.org/build/1305526/log/raw

I'm not able to reproduce this locally.  Any idea what might be going on
here?  Parallelism issue?

Note: we have disabled these tests on i686 for a long time, but they
were recently enabled again on 'staging'.  I'll re-apply that hunk to
disable the test, but wanted to have an issue to link to.

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Marius Bakke]

Julien Lepiller  skriver:

> Again this is exactly where I was blocked. There is a checksum being 
> generated in classlist files from java code during the build. The classlist 
> file is exactly the same as the one in master, so it's correctly generated. 
> Fowever, at some point, the process needs toqload that file, and that 
> ultimately calls some C code (identical to the java code) that re-computes 
> and compares the checksum. After printing some values, it seems that it 
> always computes "0…031" as the hash of any classlist file, despite running 
> the function and taking everything into account. I think this is again an 
> optimization issue, anl it's not clear how to work around that.

For the record, this showed up again after switching to GCC 11.  I ended
up disabling optimizations for dump.cpp in 321e866b1cea4916e3568efb
instead of trying to fool the compiler.

Probably it would be better to figure out exactly which optimization
causes this problem, but that's a journey for a different time.


signature.asc
Description: PGP signature

bug#57748: swaylock broken since last commit

[Marius Bakke]

muradm  skriver:

> Hi,
>
> swaylock needs wayland-protocols-next in native inputs
> to compile.
>
> wayland-protocols is 1.23, but new swaylock wants >= 1.25

Oh my, I forgot to test this on 'master' before pushing.

Fixed in fc4da86ed6418b6278cc37f1828fb3f879fafb4b.

Sorry for the breakage, and thanks for the bug report and fix!


signature.asc
Description: PGP signature

bug#57356: libtool-2.4.7 removed as a "duplicate"?

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Michael Ford  skribis:
>
>> In commit 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, the libtool-2.4.7
>> package was removed as a "duplicate". The commit message doesn't explain at
>> all why libtool 2.4.7 was being removed, or what it was a duplicate of? As
>> of latest master, libtool is still version 2.4.6.
>
> Indeed, I think this commit was intended for ‘core-updates’, where
> ‘libtool’ *is* 2.4.7, and not for ‘master’.
>
> I’m reverting it on ‘master’.  Marius, we’ll have to make sure not to
> reintroduce it on the next merge into ‘core-updates’.

Whoops, sorry for the misunderstanding, and thanks for fixing me!  :-)


signature.asc
Description: PGP signature

bug#57272: libvirt 8.6 fails to start network

[Marius Bakke]

Hi, thanks for the bug report, and sorry for the breakage.

Lars-Dominik Braun  skriver:

> Hi,
>
> after the update to libvirt 8.6.0 in
> 3a76c2bfd94557c9776aa11240fec14580aec1b0 networks don’t start any more:
>
> > LANG=C virsh net-start default
> error: Failed to start network default
> error: Unable to find 'dnsmasq' binary in $PATH: No such file or directory
>
> I tried to patch dnsmasq’s path like follows, but then the testcase
> networkxml2conftest fails and cannot find dnsmasq either.

I don't understand why that test is failing with your patch.  It has a
hard coded "/usr/sbin/dnsmasq", but patching that does not make a
difference.  It seems the lookup via virFindFileInPath, which ultimately
calls out to GLib's g_find_program_in_path, fails; but ostensibly using
an absolute file name should not make a difference[0].

  [0]: https://docs.gtk.org/glib/func.find_program_in_path.html

Anyway, I was able to reproduce the failure in the system test:

--8<---cut here---start->8---
diff --git a/gnu/tests/virtualization.scm b/gnu/tests/virtualization.scm
index 4bd56e5d9d..557f30db4f 100644
--- a/gnu/tests/virtualization.scm
+++ b/gnu/tests/virtualization.scm
@@ -106,6 +106,26 @@ (define marionette
  "-c" "qemu:///system" "connect"))
  marionette))
 
+  (test-eq "create default network"
+0
+(marionette-eval
+ '(begin
+(chdir "/tmp")
+(system* #$(file-append libvirt "/bin/virsh")
+ "-c" "qemu:///system" "net-define"
+ #$(file-append libvirt
+
"/etc/libvirt/qemu/networks/default.xml")))
+ marionette))
+
+  (test-eq "start default network"
+0
+(marionette-eval
+ '(begin
+(chdir "/tmp")
+(system* #$(file-append libvirt "/bin/virsh")
+ "-c" "qemu:///system" "net-start" "default"))
+ marionette))
+
   (test-end
 
   (gexp->derivation "libvirt-test" test))
--8<---cut here---end--->8---

And can confirm your patch fixes that, which is arguably more important.
So I went ahead and committed your patch (and disabled the failing
test), and the system test to avoid future regressions in this area.

Fixed in:

  acbf2f9def gnu: libvirt: Use absolute dnsmasq.
  3e0abde17b tests: libvirt: Ensure the default network can be started.


signature.asc
Description: PGP signature

bug#57307: guix system reports an error when uuid is used in menu-entry

[Marius Bakke]

Josselin Poiret via Bug reports for GNU Guix  skriver:

> Hi, 
>
> tiantian  writes:
>
>> I want to add an menu-entry in bootloader-configuration. I use uuid to 
>> specify the partition in device field of menu-entry , because my 
>> partition has no label. But when I use 'guix system reconfigure', guix 
>> system reports an error: "guix system: error: #< type: dce bv: 
>> #vu8(109 91 19 212 96 146 70 208 139 228 7 61 192 116 19 204)>: invalid 
>> G-expression input"
>
> Right, this is an issue with how we translate the menu-entries to sexps
> through `menu-entry->sexp`, which then get embedded into a g-exp via
> `operating-system-boot-parameters-file`!  We didn't take into account
> non-string devices there.  The following two patches should fix the
> issue and introduce some tests for it.

Pushed in:

  3294fa2ba4 tests: Add test for menu-entry roundtrips as sexps.
  0811d2cb8d bootloader: Convert device in menu-entry to proper sexp.

Thanks!


signature.asc
Description: PGP signature

bug#56633: [core-updates] Some cross-derivations cannot be computed

[Marius Bakke]

Hello Guix!

On the 'core-updates' branch, running 'guix build -d' fails on some
cross-derivations (notably anything that depends on NSPR, but there may
be others).

Somehow both TARGET and SYSTEM ends up #false. Any ideas to what is
going on?

--8<---cut here---start->8---
$ ./pre-inst-env guix build --target=aarch64-linux-gnu nspr -d

Backtrace:
In guix/monads.scm:
471:9 19 (_ _)
In guix/packages.scm:
   1553:7 18 (_ _)
In guix/store.scm:
  1996:13 17 (_ #)
In guix/packages.scm:
  1878:37 16 (_)
  1798:39 15 (bag->derivation #< name: "ld-wrapper-aarch64-linux-gnu-0" 
system: #f target: #f build-inputs: () host-inputs: (("binutils" #) ("guile" #) ("bash" #) ("wrapper" "…> …)
   1291:4 14 (bag-transitive-inputs _)
  1074:23 13 (transitive-inputs _)
  1415:36 12 (propagated-inputs _)
In srfi/srfi-1.scm:
   586:29 11 (map1 (("libunistring" #) ("bdw-gc" #)))
   586:17 10 (map1 (("bdw-gc" #)))
In guix/packages.scm:
  1370:20  9 (rewrite ("bdw-gc" #))
In guix/memoization.scm:
101:0  8 (_ # # _)
In guix/packages.scm:
  1384:13  7 (_)
In guix/build-system/gnu.scm:
   157:33  6 (cut? _)
In gnu/packages/bdw-gc.scm:
61:15  5 (arguments #)
In guix/utils.scm:
672:7  4 (target-hurd? _)
In unknown file:
   3 (string-suffix? "-gnu" #f # # # 
#)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  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 string-suffix?: Wrong type argument in position 2 (expecting 
string): #f
--8<---cut here---end--->8---

bug#53823: Build fails for cpplint@1.4.5

[Marius Bakke]

Adam Maleszka via Bug reports for GNU Guix  skriver:

> Since I moved to Guix distribution on the 1st of January (btw, good
> move), compiling cpplint@1.4.5 has always failed. More specifically,
> errors are triggered by pytest during the check phase.

Fixed in 6ff0a6d53a4f5c3faa4a4b6503dab47ea2cc2426, thanks!


signature.asc
Description: PGP signature

bug#53238: [PATCH] gnu: tree: Remove stddata feature.

[Marius Bakke]

Upstream fix pushed in 5da4cbfbd94163f87f188355e5490f04dd6864c2.


signature.asc
Description: PGP signature

bug#53301: Ungoogled-chromium lacks VP8 codec support preventing jitsi screensharing

[Marius Bakke]

Jacob Hrbek  skriver:

> Steps to reproduce:
> 0. Get ungoogled-chromium
> 1. Open a call on jitsi e.g. https://jit.si/ILoveKreyren2Much
> 2. Start a screenshare
> 3. Join the call from a different browser and expect the screenshare to
> malfunction either with tab crashing with "Aw, snap" or the screen share
> changing on black screen and chromium printing this to the console:

Fixed in f3b73e46df82297ffabaa3b32fc765fa3065cad0.

Thanks for the report and reproducer!


signature.asc
Description: PGP signature

bug#53238: [PATCH] gnu: tree: Remove stddata feature.

[Marius Bakke]

Hello!

Apologies for missing this discussion earlier...

Maxim Cournoyer  skriver:

> Hi,
>
> Olivier Dion  writes:
>
>> On Thu, 13 Jan 2022, Tobias Geerinckx-Rice  wrote:
>>> Olivier,
>>>
>>> Thanks again for tracking down this weird bug!
>>>
>>> Olivier Dion via Guix-patches via 写道：
 This feature breaks some UNIX utilities.  Fix it by disabling 
 the feature.
>>>
>>> Hm…  How long would we have to carry this fork?  My fear is we'd 
>>> do so indefinitely.
>>
>> I've contacted the maintainer asking for removal of the feature in its
>> next release.  I'm not sure if this will have some impact.  Feel free to
>> do the same at , maybe adding more weight
>> in the balance would help.
>>
>>> How about creating a (possibly hidden) tree-without-stddata 
>>> package variant, to use as input to packages who currently break 
>>> with this feature enabled?  That lets us refcount the need for it.
>>
>> It's more than just packages, it's also user scripts that can be broken
>> and believe me when I say that this is not an easy bug to track down ;-).
>
> I'm on the fence about this, it does indeed seem an undesirable change,
> especially since there's a --json option, but I am not the author of the
> 'tree' software.

After some consideration (and emails with tree author), I think the best
solution is to patch 'password-store' so that it DTRT even in the
presence of fd 3.

I sent a patch to that effect upstream:

  https://lists.zx2c4.com/pipermail/password-store/2022-January/004563.html

...and have local patches to apply that in Guix and revert
bd4f314bbacaaa56751be3a4769f2082be747d24 and
a40ac6271578ea061a8a07b2adbd6032a690ca70.

WDYT?


signature.asc
Description: PGP signature

bug#50696: [core-updates-frozen] Wrong output hashes computed since cb06f7c61e4b839

[Marius Bakke]

Hello,

On the 'core-updates-frozen' branch, attempting to pull 'master' gives a
backtrace along the lines of ...

Computing Guix derivation for 'x86_64-linux'... |Backtrace:
In ice-9/boot-9.scm:
152:2 19 (with-fluid* _ _ _)
152:2 18 (with-fluid* _ _ _)
In ./guix/store.scm:
  2108:24 17 (run-with-store # 
# ?)
In ./guix/self.scm:
   1313:2 16 (_ #)
In ./guix/packages.scm:
  1548:17 15 (_ #)
  1177:16 14 (cache! # # 
("x86_64-linux" . #t) #)
  1495:22 13 (thunk)
  1428:25 12 (bag->derivation # #< 
name: "guile-3.0.7" system: "x86_64-l?> ?)
In srfi/srfi-1.scm:
   586:17 11 (map1 (("source" #) ?))
In ./guix/packages.scm:
   1239:5 10 (failure)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In ./guix/packages.scm:
  1244:18  8 (_)
In ./guix/store.scm:
  2108:24  7 (run-with-store # 
# ?)
   1945:8  6 (_ #)
/In ./guix/gexp.scm:
   275:18  5 (_ #)
In ./guix/packages.scm:
   1603:5  4 (_ #)
In ./guix/store.scm:
  1980:38  3 (_ #)
In ./guix/derivations.scm:
   955:17  2 (derivation # 
"guile-3.0.7.tar.xz" "builtin:download" () #:system ?)
In ./guix/store.scm:
   1058:9  1 (_ # 
"guile-3.0.7.tar.xz.drv" #vu8(68 101 114 105 118 101 40 91 ?) ?)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. :
  message: "derivation 
`/gnu/store/szv5fh043rrqq01xpycp7xci4y7myqfk-guile-3.0.7.tar.xz.drv' has 
incorrect output 
`/gnu/store/qwjhql8lqw40fqhaqw40jwqs0hc0248w-guile-3.0.7.tar.xz', should be 
`/gnu/store/0zliqv8lcw13f9iasy14kmwsqj3d309w-guile-3.0.7.tar.xz'"
  status: 1

I bisected it down to cb06f7c61e4b:

commit cb06f7c61e4b8393abf38f1f5891e03c33d53b9b
Author: Ludovic Courtès 
Date:   Thu Sep 9 23:22:10 2021 +0200

base32: Provide an open-coded 'bit-field'.

This improves the throughput of 'bytevector->base32-string' a bit.

* guix/base32.scm (bit-field): New macro.

It can be reproduced with a two-dimensional time machine:

  $ guix time-machine --branch=core-updates-frozen -- time-machine \
  --commit=cb06f7c61e4b8393abf38f1f5891e03c33d53b9b -- build hello

...or by pulling 'core-updates-frozen' and attempting to pull 'master'.

The commit was merged to 'core-updates-frozen' in 5c3cb22c9b281066, so
pulling core-updates-frozen -> core-updates-frozen also fails in a
similar manner (albeit on a different derivation).


signature.asc
Description: PGP signature

bug#49029: ungoogled-chromium failed to disable malware extension The Great Suspender

[Marius Bakke]

Leo Famulari  skriver:

> On Mon, Jun 14, 2021 at 06:29:03PM -0300, Jorge P. de Morais Neto via Bug 
> reports for GNU Guix wrote:
>> I normally browse the web on GNU IceCat and sometimes Firefox and
>> Emacs EWW.  I only use (ungoogled-)chromium for the rare websites that
>> don't work on the other browsers.  Long ago I installed in Chromium the
>> extension The Great Suspender, and only today (months after G$$gle
>> Chrome, according to news articles) did my Chromium disable it for
>> having malware.  And the only Chromium that did that for me was
>> Debian's.
>
> Does anybody know what we need to do to fix this bug? Do we need to
> update the ungoogled-chromium package?

It's not easily possible to install extensions with ungoogled-chromium,
apart from the two that are available directly through Guix.  If the
user goes out of their way to install extensions, such as using a
browser from a different distro, there is little we can do.

Mixing browser profiles between the vanilla and ungoogled Chromium is
not a supported use case.  Warranty void.

I'd accept a patch that warns or refuses to use a "tainted" browser
profile, or changes the default browser profile directory so it does not
conflict with vanilla.

But I'm inclined to close this as "not-a-bug" for now.  WDYT, Jorge?


signature.asc
Description: PGP signature

bug#41625: [PATCH v2] offload: Handle a possible EOF response from read-repl-response.

[Marius Bakke]

Maxim Cournoyer  skriver:

>> Is running ‘guix offload test /etc/guix/machines.scm overdrive1’ on
>> berlin enough to reproduce the issue?  If so, we could monitor/strace
>> sshd on overdrive1 to get a better understanding of what’s going on.
>
> It's actually difficult to trigger it; it seems to happen mostly on the
> first try after a long time without connecting to the machine; on the
> 2nd and later tries, everything is smooth.  Waiting a few minutes is not
> enough to re-trigger the problem.
>
> I've managed to see the problem a few lucky times with:
>
> --8<---cut here---start->8---
> while true; do guix offload test /etc/guix/machines.scm overdrive1; done
> --8<---cut here---end--->8---

I used to be able to reproduce it by inducing a high load on the target
machine and just let Guix keep trying to connect.  But now I did that,
and set overload threshold to 0.0 for good measure, and Guix has been
waiting patiently for two hours without failure.

So AFAICT this bug has been fixed.  Perhaps Berlin or the Overdrive
simply needs to be updated?


signature.asc
Description: PGP signature

bug#47823: Hardenize Guix website TLS/DNS

[Marius Bakke]

Julien Lepiller  skriver:

> Le 16 avril 2021 12:15:25 GMT-04:00, Leo Famulari  a 
> écrit :
>>On Fri, Apr 16, 2021 at 11:00:05AM +, bo0od wrote:
>>> Scanning Guix website gave many missing security features which
>>modern
>>> security needs them to be available:
>>> 
>>> * TLS and DNS:
>>> 
>>> looking at:
>>> 
>>> https://www.hardenize.com/report/guix.gnu.org/1618568751
>>> 
>>> https://www.ssllabs.com/ssltest/analyze.html?d=guix.gnu.org
>>
>>Thanks!
>>
>>> - DNS: DNSSEC support missing (important)
>>
>>Hm, is it important? My impression is that it's an idea whose time has
>>passed without significant adoption.
>>
>>But maybe we could enable it if the costs are not too great.
>
> gnu.org does not have dnssec, so we'd need them to work on that first.

gnu.org used to have DNSSEC, but disabled it because it gave NXDOMAIN
on machines with systemd-resolved:

  https://github.com/systemd/systemd/issues/9867


signature.asc
Description: PGP signature

bug#47172: Shepherd 0.8.1 tests fail on core-updates

[Marius Bakke]

Ludovic Courtès  skriver:

> Ludovic Courtès  skribis:
>
>> This turns out to be due to a… miscompilation bug.
>>
>> In (shepherd scripts herd), ‘run-command’ has this code:
>>
>>   (let ((sock(open-connection socket-file))
>> (action* (if (and (eq? action 'detailed-status)
>>   (memq service '(root shepherd)))
>>  'status
>>  action)))
>> …)
>>
>> Problem is that everything works as if (eq? action 'detailed-status)
>> was omitted, such that ‘herd stop root’ is interpreted as ‘herd status
>> root’.
>
> A workaround that works with 3.0.7 is swapping the two ‘and’
> sub-expressions:
>
> diff --git a/modules/shepherd/scripts/herd.scm 
> b/modules/shepherd/scripts/herd.scm
> index 106de1e..39d2e34 100644
> --- a/modules/shepherd/scripts/herd.scm
> +++ b/modules/shepherd/scripts/herd.scm
> @@ -126,8 +126,8 @@ of pairs."
>  the daemon via SOCKET-FILE."
>(with-system-error-handling
> (let ((sock(open-connection socket-file))
> - (action* (if (and (eq? action 'detailed-status)
> -   (memq service '(root shepherd)))
> + (action* (if (and (memq service '(root shepherd))
> +   (eq? action 'detailed-status))
>'status
>action)))
>   ;; Send the command.

Cc'ing the relevant Guile bug:

  https://bugs.gnu.org/48368

See also commit 79be6a985799adc6d663890250f4fb7c12f015b4 on
'core-updates' that builds with -O1 as a less satisfactory workaround.


signature.asc
Description: PGP signature

bug#26604: documentation: pdf generation is broken

[Marius Bakke]

zimoun  skriver:

> Hi,
>
> On Tue, 4 May 2021 at 12:04, Ricardo Wurmus  wrote:
>
>> At least the first “wizard stuff” is merely a list of packages.
>> There isn’t anything we can do to avoid the selection of packages,
>> because that stuff is modular by design.  We could have an
>> arbitrary collection of Texlive packages, but I’m sure we can’t
>> agree on any good set because what exactly is needed depends on
>> the document.
>
> [...]
>
>> If the problem is in figuring out what Texlive packages to install
>> for generating the Guix manual: we can either document that or add
>> the required packages to the inputs.
>
> I agree.  Maybe via a manifest file?
>
>> If you still get errors relating to fonts or font maps: this has
>> been fixed on the “master” branch; the texlive-configuration
>> profile hook didn’t update the font maps.
>
> Cool!  I have missed.
>
> Well, let close this old bug. \o/

Agreed, closing!


signature.asc
Description: PGP signature

bug#48612: Expat "billion laughs attack" vulnerability (CVE-2013-0340)

[Marius Bakke]

Greetings Guix,

What's old is new again!  Expat 2.4.0 was recently released with a
fix for a denial of service issue dubbed "billion laughs attack":

  https://github.com/libexpat/libexpat/blob/R_2_4_0/expat/Changes
  https://en.wikipedia.org/wiki/Billion_laughs_attack

Seeing as this vulnerability appears to be eight years old and is
"merely" a DoS: is it worth fixing on the 'master' branch (and
re-grafting pretty much everything)?

In any case I've attached a patch that does just that and I'm currently
using it on my system.  I'm hesitant to push it because of the grafting
cost and would like others opinion.

From 2589767bf405b837db06dadf1c9f990620f11a38 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 23 May 2021 14:22:16 +0200
Subject: [PATCH] gnu: expat: Replace with 2.4.0 [fixes CVE-2013-0340].

* gnu/packages/xml.scm (expat-2.4.0): New variable.
(expat)[replacement]: New field.
---
 gnu/packages/xml.scm | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index ad2e3ec6c9..cbd33326e8 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@ -13,7 +13,7 @@
 ;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;; Copyright © 2016, 2017 Nikita 
 ;;; Copyright © 2016–2021 Tobias Geerinckx-Rice 
-;;; Copyright © 2016, 2017, 2018, 2019, 2020 Marius Bakke 
+;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Marius Bakke 
 ;;; Copyright © 2017 Adriano Peluso 
 ;;; Copyright © 2017 Gregor Giesen 
 ;;; Copyright © 2017 Alex Vong 
@@ -121,6 +121,7 @@ the entire document.")
   (package
 (name "expat")
 (version "2.2.9")
+(replacement expat-2.4.0)
 (source (let ((dot->underscore (lambda (c) (if (char=? #\. c) #\_ c
   (origin
 (method url-fetch)
@@ -144,6 +145,24 @@ stream-oriented parser in which an application registers handlers for
 things the parser might find in the XML document (like start tags).")
 (license license:expat)))
 
+;; Replacement package to fix CVE-2013-0340.
+(define expat-2.4.0
+  (package
+(inherit expat)
+(version "2.4.0")
+(source (let ((dot->underscore (lambda (c) (if (char=? #\. c) #\_ c
+  (origin
+(method url-fetch)
+(uri (list (string-append "mirror://sourceforge/expat/expat/"
+  version "/expat-" version ".tar.xz")
+   (string-append
+"https://github.com/libexpat/libexpat/releases/download/R_;
+(string-map dot->underscore version)
+"/expat-" version ".tar.xz")))
+(sha256
+ (base32
+  "04hyv04ygicyajb9ancv02a7sj5v97d94m2bnrjr5fx03r84iib3")))
+
 (define-public libebml
   (package
 (name "libebml")
-- 
2.31.1



signature.asc
Description: PGP signature

bug#46450: [core-updates] r-suppdists source checksum changed

[Marius Bakke]

zimoun  skriver:

> Hi,
>
> On Thu, 11 Feb 2021 at 22:54, Danny Milosavljevic  
> wrote:
>> From http://cran.r-project.org/src/contrib/SuppDists_1.1-9.5.tar.gz...
>> downloading from 
>> http://cran.r-project.org/src/contrib/SuppDists_1.1-9.5.tar.gz ...
>>  SuppDists_1.1-9.5.tar.gz  138KiB
>>   502.0MiB/s 00:00 [##] 
>> 100.0%
>> sha256 hash mismatch for 
>> /gnu/store/2rrhniq5xfab0ba80g845fbs82l66vbr-SuppDists_1.1-9.5.tar.gz:
>>   expected hash: 01j6p94m1g363nph2158fq2rmd6z3h5dvcv6aidh2d6syw131xak
>>   actual hash:   1i3iq12a5x5k49ac01mikzcrrq9gc148xq3m08h4xm07bha6f2v8
>> hash mismatch for store item 
>> '/gnu/store/2rrhniq5xfab0ba80g845fbs82l66vbr-SuppDists_1.1-9.5.tar.gz'
>> build of 
>> /gnu/store/j4kyq3knjjin3s1gn8vc4hfd61gw1c2g-SuppDists_1.1-9.5.tar.gz.drv 
>> failed
>> View build log at 
>> '/var/log/guix/drvs/j4/kyq3knjjin3s1gn8vc4hfd61gw1c2g-SuppDists_1.1-9.5.tar.gz.drv.bz2'.
>> cannot build derivation 
>> `/gnu/store/cqmqlsdw67hbhjvplh56b649c8w74lv7-r-suppdists-1.1-9.5.drv': 1 
>> dependencies couldn't be built
>
> Sadly, this often happens with R packages from CRAN.  Upstream does an
> in-place replacement.  Well, it is fixed on master (or should be soon :-))
>
> See .
>
> Closing?

Indeed, thanks for checking!


signature.asc
Description: PGP signature

bug#46478: [core-updates] runc source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> downloading from 
> https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.tar.xz
>  ...
>
> sha256 hash mismatch for 
> /gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz:
>   expected hash: 1c7832dq70slkjh8qp2civ1wxhhdd2hrx84pq7db1mmqc9fdr3cc
>   actual hash:   05i1j4xqwnva30c24gcrdvdx6wcjqgpyz7cn3gi0bs6jlcfv43gs
> hash mismatch for store item 
> '/gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz'
> build of 
> /gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv failed
> View build log at 
> '/var/log/guix/drvs/ml/7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv.bz2'.

This was fixed in 86c39376cc00ed19758a2861c11f85fa5b94cda4.


signature.asc
Description: PGP signature

bug#46479: [core-updates] scdoc source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> sha256 hash mismatch for 
> /gnu/store/3kvddjq70m96y0mci365bz4z1sihyqsj-scdoc-1.10.1.tar.gz:
>   expected hash: 13x7g1r56bshvfmlvapvz35ywnbgsh337kywb5kcv8nc6b3j3q40
>   actual hash:   0cr32dgj90zzlavk83mwl6smf8wdls5yv2zq4h7idhsikhp0mdji
> hash mismatch for store item 
> '/gnu/store/3kvddjq70m96y0mci365bz4z1sihyqsj-scdoc-1.10.1.tar.gz'
> build of /gnu/store/vz804mghzh2bw7332jsm2xygrzifly6h-scdoc-1.10.1.tar.gz.drv 
> failed

This was fixed in 841e5fb4ddff7f29c06cf9faea65cfe5626fde20.


signature.asc
Description: PGP signature

bug#46474: [core-updates] libinfinity source disappeared

[Marius Bakke]

Danny Milosavljevic  skriver:

> building 
> /gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv...
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz...
> following redirection to 
> `https://github.com/gobby/libinfinity/releases/download/v0.7.2/libinfinity-0.7.2.tar.gz'...
> download failed 
> "https://github.com/gobby/libinfinity/releases/download/v0.7.2/libinfinity-0.7.2.tar.gz;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://ci.guix.gnu.org/file/libinfinity-0.7.2.tar.gz/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f...
> download failed 
> "https://ci.guix.gnu.org/file/libinfinity-0.7.2.tar.gz/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://tarballs.nixos.org/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f...
> download failed 
> "https://tarballs.nixos.org/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://archive.softwareheritage.org/api/1/content/sha256:6e7029375a81c5e3dbcdf23b69402d220b124ac83e349f07fd37fd0e8379239e/raw/...
> download failed 
> "https://archive.softwareheritage.org/api/1/content/sha256:6e7029375a81c5e3dbcdf23b69402d220b124ac83e349f07fd37fd0e8379239e/raw/;
>  404 "Not Found"
> failed to download 
> "/gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz" from 
> "http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz;
> builder for 
> `/gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv' 
> failed to produce output path 
> `/gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz'
> build of 
> /gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/30/p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv.bz2'.
> cannot build derivation 
> `/gnu/store/fj7f1sydid703jlffgbmcdbas36p1fv6-libinfinity-0.7.2.drv': 1 
> dependencies couldn't be built
> guix build: error: build of 
> `/gnu/store/fj7f1sydid703jlffgbmcdbas36p1fv6-libinfinity-0.7.2.drv' failed
>
> That's because the URL should be 
> https://github.com/gobby/libinfinity/releases/download/0.7.2/libinfinity-0.7.2.tar.gz
>  , note: no "v" before "0.7.2".
>
> But that's a redirection by upstream (from 
> http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz ) which is 
> wrong.
>
> Upstream bug report https://github.com/gobby/libinfinity/issues/29 .

This appears to have been fixed, closing!


signature.asc
Description: PGP signature

bug#46467: [core-updates] foo2zjs source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> sha256 hash mismatch for 
> /gnu/store/5hkf0xjga0wirk1wv8fsqvyazai4zzh6-foo2zjs.tar.gz:
>   expected hash: 11ddx6wf8b5ksl4fqw6fnyz9m3y470lryyrskkya2bsch2bvj9lg
>   actual hash:   14x3wizvncdy0xgvmcx541qanwb7bg76abygqy17bxycn1zh5r1x
> hash mismatch for store item 
> '/gnu/store/5hkf0xjga0wirk1wv8fsqvyazai4zzh6-foo2zjs.tar.gz'
> build of /gnu/store/4b4fq6j1zwffz8l8c69b6y3lj2ixdl8c-foo2zjs.tar.gz.drv failed
>
> That's because http://foo2zjs.rkkda.com/foo2zjs.tar.gz is not versioned, and 
> we
> use that anyway.  WTF?

I believe this was fixed in f1442560906de4863c89a6f8c1c08169ee0738cb.


signature.asc
Description: PGP signature

bug#46330: Guile-provided GMP allocators interfere with GnuTLS

[Marius Bakke]

Ludovic Courtès  skriver:

> Ludovic Courtès  skribis:
>
>> One of the solutions is to set:
>>
>>   scm_install_gmp_memory_functions = 0;
>
> Done in a53f711422f63d7e32b8639b968cf00bcc69ffea, followed by an update
> of the ‘guix’ package in 63d4b74420563c4e2dbdfa29b3816d1dad9cd723.
>
> This mostly solves the problem on the Guix side, but the issue remains
> in GnuTLS.  I practical terms, we could experience random test failures
> in the guile-gnutls test suite, like the Debian folks did.
>
> At the very least we’ll need to work around that possibility in
> ‘core-updates’.  We could skip them, or add ‘gc-disable’ calls there.
> Or we could build GnuTLS against Nettle-with-mini-GMP when that becomes
> an option.
>
> The other option coming up is to build Guile against mini-GMP.  Mike
> Gran just started looked into it and it may be that 3.0.6 will offer it.
>
> I’m keeping the bug open until this is sorted out.

I believe this was sorted with the mini-gmp in Guile 3.0.6.  Please
reopen if I'm mistaken.  :-)


signature.asc
Description: PGP signature

bug#48602: Grafted python2 packages gets erroneous package names

[Marius Bakke]

Hello,

'guix build python2-urllib3' currently gives:

  /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4

Adding '--no-grafts' gives the expected file name.

Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the
store file name was actually '...-python2-python2-python2-urllib3-...'!

Not sure if this is a recent regression, or what may be causing it.

Ideas?


signature.asc
Description: PGP signature

bug#47154: ungoogled-chromium@88.0.4324.182 package vulnerable to various severe CVEs

[Marius Bakke]

Hello!

Sorry for not seeing this earlier.

Léo Le Bouter  skriver:

> I am not sure how to undertake this upgrade, I tried a little bit but
> it failed at failing to delete some bundled third_party directories.
>
> Would love to know in more detail what is the process for upgrading
> ungoogled-chromium, license checking and patch rebasing if necessary.

For major upgrades such as 88->89, I usually comment out the pruning
script from the snippet, and add a phase such as...

  (add-after 'unpack 'prune
(lambda _
  (apply invoke "python"
 "build/linux/unbundle/remove_bundled_libraries.py"
 "--do-remove" (list ,@%preserved-third-party-files

...to avoid having to repack for every change to
%preserved-third-party-files.

Then just run './pre-inst-env guix build ...' as usual, see what the
configure phase reports, and adjust %preserved-third-party-files
accordingly.

Each "third_party" directory contains a README.chromium with license
information.  That file is not always correct (i.e. listing a single
license when multiple are involved), so I typically check the source
files too.

For patch rebasing, sometimes I make the necessary adjustments manually
and use plain old "diff"; other times I'll create a git repository from
the vanilla Chromium source, apply patches, branch out and try to
cherry-pick the patches to the new version in order to benefit from
git's conflict markers.

I also keep an eye on the Arch and Gentoo Chromium packages for
"inspiration" (that's how I found the recent Opus patch).

Hope this helps, and thanks for the interest in helping out with
maintaining this package.  :-)


signature.asc
Description: PGP signature

bug#25527: PostgreSQL retains references to ld-wrapper and coreutils

[Marius Bakke]

l...@gnu.org (Ludovic Courtès) skriver:

> As of 04fa4cdf95a004bda4d63b6578b53e154a4d4679:
>
> --8<---cut here---start->8---
> $ guix size postgresql
> store item   totalself
> /gnu/store/awmx27f02la7sc4s63jxsdczclsf63gj-postgresql-9.5.5   200.5
> 20.0  10.0%
> /gnu/store/c7lm5innppxm53bf5w7i99d59kjdyx27-ld-wrapper-0   152.8 
> 0.0   0.0%
> /gnu/store/6slzn4ixcjlhy3av3biglqfli9pwxcn9-guile-2.0.12   103.4
> 12.7   6.3%
> /gnu/store/4xxd00drj8gjcr84xdfna44qak2vhwmf-binutils-2.27   87.6
> 49.3  24.6%
> /gnu/store/9xfn6q7cxqxaxsv6kgiic9iygl2iv2ci-coreutils-8.25  78.8
> 14.4   7.2%
> /gnu/store/9l52vcmb1ambc3ypf7nxn38ac0976yyf-tar-1.2976.0 
> 2.6   1.3%
> /gnu/store/iz6rbi4r00jhwzbccnsbq1bbrbdi6h3d-readline-7.068.0 
> 1.3   0.6%
> /gnu/store/k0x973sjylvi746ib2xn4v1hjp855qq1-readline-7.068.0 
> 1.3   0.6%
> /gnu/store/yi8a0206zpqf6qijkn70938jj8l6s87b-ncurses-6.0 66.7 
> 5.7   2.9%
> /gnu/store/xydfiifs9slq0wv6n8j6p26icn2ihn88-ncurses-6.0 66.7 
> 5.7   2.9%
> /gnu/store/qj5sazmlzqbn2nlm7vxj6wjns0mm5x79-libunistring-0.9.6  65.4 
> 4.5   2.2%
> /gnu/store/frxwbfah0l9fr0j398vg3avsrmdfajnj-gmp-6.1.1   63.6 
> 2.6   1.3%
> /gnu/store/ykdzlcdyjjfhivids91d1xs36hmzrrp6-gmp-6.1.1   63.6 
> 2.6   1.3%
> /gnu/store/janggjcj3c1a2wf5p6zrgxk50jdy0ibx-libgc-7.4.2 62.7 
> 1.1   0.6%
> /gnu/store/dp61fnsknp4mi58vnq8jy0wyp0nl2id3-pkg-config-0.29 62.3 
> 1.3   0.6%
> /gnu/store/xw9jv7krgy86f5pvnrc77zph25562n1n-acl-2.2.52  61.7 
> 0.4   0.2%
> /gnu/store/27ygdlznld2s6bk8mw2hmbhbh517ahaq-libcap-2.24 61.4 
> 0.1   0.1%
> /gnu/store/a64w9dq219a8d9k4mfz76mnzph9wsvfj-zlib-1.2.8  61.3 
> 0.4   0.2%
> /gnu/store/hgg7bzyq84ny3b1j17c4hkdpx5xmvnw0-attr-2.4.47 61.2 
> 0.2   0.1%
> /gnu/store/p153bawa5szcv4z6br9jrbwv3zq6qv5m-libffi-3.2.161.1 
> 0.1   0.1%
> /gnu/store/lb6z629zg8p5raip9m9k2sris87qsgdn-libltdl-2.4.6   61.1 
> 0.1   0.1%
> /gnu/store/cdi08kw7r6r684w8mk0xq0dkgpjhfpmd-gcc-4.9.4-lib   61.0
> 22.7  11.3%
> /gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0  50.7 
> 5.4   2.7%
> /gnu/store/bm0gfw4jkw8gd0vpnnzrb6z0xncrbx3p-readline-7.045.3 
> 1.3   0.6%
> /gnu/store/hdrli1v7q3107w842s7di8rid82xlfvl-ncurses-6.0 44.0 
> 5.7   2.8%
> /gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24  38.3
> 36.8  18.4%
> /gnu/store/rvgmixpmsq5lqr9qflhkm70kg7a4rys2-bash-static-4.4.01.4 
> 1.4   0.7%
> /gnu/store/idcrs9pr86mw3f5ya87ijhczn6zywxs6-libatomic-ops-7.4.2  0.6 
> 0.6   0.3%
> total: 200.5 MiB
> --8<---cut here---end--->8---
>
> We should at least remove the dependency on ld-wrapper, which is
> probably not justified.

This is because PostgreSQL installs its Makefile(!), which contain
absolute references to various build tools.

I pushed a fix to 'staging' in
e693617f559f49d1d2606dd5ad997e444b9ad1b5 that adjusts the Makefile to
use relative references.

(not sure whether it should be installed at all, but that is for a
future bug report)

The size of postgresql@13 decreased from 256.3 MiB to 137.9 MiB(!!).

Thanks!


signature.asc
Description: PGP signature

bug#45279: [core-updates] copy-recursively does not throw an error on missing directory

[Marius Bakke]

Hello,

On the 'core-updates' branch, using copy-recursively on a nonexistent
directory does not cause a build failure.  Instead an error is printed
and the script continues:

  (copy-recursively "doesnotexist" output)
  [...]
  starting phase `install'
  i/o error: doesnotexist: No such file or directory
  phase `install' succeeded after 0.0 seconds

This is on cc6cb6e80a42355147809b4830053a34d1563994.


signature.asc
Description: PGP signature

bug#45278: [core-updates] svn-multi-fetch does not raise error on missing files

[Marius Bakke]

Hello,

On the 'core-updates' branch, passing a missing file to svn-multi-fetch
will not raise an error.  Instead the fetch will succeed as long as at
least one of the files was found (otherwise $output is empty).

This is on cc6cb6e80a42355147809b4830053a34d1563994.


signature.asc
Description: PGP signature

bug#45166: Wrong locale settings for guix-daemon causes confusing error

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Marius Bakke  skribis:
>
>> User sss2 reported on #guix[0] that running guix-daemon with an invalid
>> locale causes the following error:
>>
>> # guix pull
>> Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> Building from this channel:
>>   guix  https://git.savannah.gnu.org/git/guix.git   77667e2
>> Computing Guix derivation for 'x86_64-linux'... |
>> guix pull: error: got unexpected path `hint: Consider installing the 
>> `glibc-utf8-locales' or `glibc-locales' package and' from substituter
>
> How did they run the daemon?  The systemd unit file we provide normally
> makes sure it runs with the right GUIX_LOCPATH and with a valid locale.

It was a hand-written systemd unit file, hence the error.  My main
concern is with this error message:

  guix pull: error: got unexpected path `hint: Consider installing the 
`glibc-utf8-locales' or `glibc-locales' package and' from substituter

Previously, the daemon would continue in the face of wrong locale
settings, but print lots of warnings, now it fails hard and early with
this unhelpful message.

If that is intended, can we catch it and provide a more actionable error
message?


signature.asc
Description: PGP signature

bug#45187: git download defaults to origin/master

[Marius Bakke]

Kyle Meyer  skriver:

> Ricardo Wurmus writes:
>
>> Importing https://github.com/immunogenomics/scpost with the CRAN
>> importer fails, because the git repository does not have an
>> origin/master branch.  This repository only has a “main” branch.
>>
>> Arguably, this shouldn’t matter, but (guix git) has the “master” name
>> set up as the default.  When cloning a repository it may be better to
>> fetch everything and select the default branch — whichever name it may
>> have.
>
> One option may be to use the remote HEAD symref.  That's probably the
> best indicator of what the primary branch is.  In a clone, it doesn't
> necessarily match HEAD on the remote, because users may change it to
> another branch they're interested in, but that isn't really relevant to
> these behind-the-scenes checkouts.
>
> Here's a quick and dirty demo that makes your reproducer work.  A real
> patch in this direction would of course look very different.

Another quick and dirty patch to make this specific example work ...

diff --git a/guix/git.scm b/guix/git.scm
index ca77b9f54b..0c49859e42 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -198,47 +198,11 @@ of SHA1 string."
 (last (string-split url #\/)) ".git" "")
"-" (string-take sha1 7)))
 
-(define (resolve-reference repository ref)
-  "Resolve the branch, commit or tag specified by REF, and return the
-corresponding Git object."
-  (let resolve ((ref ref))
-(match ref
-  (('branch . branch)
-   (let ((oid (reference-target
-   (branch-lookup repository branch BRANCH-REMOTE
- (object-lookup repository oid)))
-  (('commit . commit)
-   (let ((len (string-length commit)))
- ;; 'object-lookup-prefix' appeared in Guile-Git in Mar. 2018, so we
- ;; can't be sure it's available.  Furthermore, 'string->oid' used to
- ;; read out-of-bounds when passed a string shorter than 40 chars,
- ;; which is why we delay calls to it below.
- (if (< len 40)
- (object-lookup-prefix repository (string->oid commit) len)
- (object-lookup repository (string->oid commit)
-  (('tag-or-commit . str)
-   (if (or (> (string-length str) 40)
-   (not (string-every char-set:hex-digit str)))
-   (resolve `(tag . ,str))  ;definitely a tag
-   (catch 'git-error
- (lambda ()
-   (resolve `(tag . ,str)))
- (lambda _
-   ;; There's no such tag, so it must be a commit ID.
-   (resolve `(commit . ,str))
-  (('tag. tag)
-   (let ((oid (reference-name->oid repository
-   (string-append "refs/tags/" tag
- ;; OID may point to a "tag" object, but it can also point directly
- ;; to a "commit" object, as surprising as it may seem.  Return that
- ;; object, whatever that is.
- (object-lookup repository oid))
-
 (define (switch-to-ref repository ref)
   "Switch to REPOSITORY's branch, commit or tag specified by REF.  Return the
 OID (roughly the commit hash) corresponding to REF."
   (define obj
-(resolve-reference repository ref))
+(revparse-single repository (cdr ref)))
 
   (reset repository obj RESET_HARD)
   (object-id obj))
@@ -320,7 +284,7 @@ definitely available in REPOSITORY, false otherwise."
 
 (define* (update-cached-checkout url
  #:key
- (ref '(branch . "master"))
+ (ref '(branch . "HEAD"))
  recursive?
  (check-out? #t)
  starting-commit
@@ -349,7 +313,9 @@ it unchanged."
   (('branch . branch)
`(branch . ,(if (string-prefix? "origin/" branch)
branch
-   (string-append "origin/" branch
+   (if (string=? "HEAD" branch)
+   branch
+   (string-append "origin/" branch)
   (_ ref)))
 
   (with-libgit2
@@ -370,8 +336,7 @@ it unchanged."
  ;; than letting users re-open the checkout later on.
  (let* ((oid  (if check-out?
   (switch-to-ref repository canonical-ref)
-  (object-id
-   (resolve-reference repository canonical-ref
+  (revparse-single repository (cdr canonical-ref
 (new  (and starting-commit
(commit-lookup repository oid)))
 (old  (and starting-commit
@@ -395,7 +360,7 @@ it unchanged."
(log-port (%make-void-port "w"))
(cache-directory
 (%repository-cache-directory))
-   (ref '(branch . "master")))
+   (ref '(branch . 

bug#36544: 'set-paths' should exclude 'source' from consideration

[Marius Bakke]

Leo Famulari  skriver:

> On Thu, Jul 11, 2019 at 11:24:55PM +0200, Ludovic Courtès wrote:
>> > To avoid this unexpected sensitivity on the source origin method, I
>> > suggest that we explicitly exclude 'source' from consideration within
>> > the 'set-paths' phase.  What do you think?
>> 
>> I agree.  We should do that in the next ‘core-updates’.
>
> Now is a good time to make this change.

This was fixed in 968f541c36c28c413f696558505f902d0a133d58.


signature.asc
Description: PGP signature

bug#45166: Wrong locale settings for guix-daemon causes confusing error

[Marius Bakke]

Hello,

User sss2 reported on #guix[0] that running guix-daemon with an invalid
locale causes the following error:

# guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   77667e2
Computing Guix derivation for 'x86_64-linux'... |
guix pull: error: got unexpected path `hint: Consider installing the 
`glibc-utf8-locales' or `glibc-locales' package and' from substituter

[0] https://logs.guix.gnu.org/guix/2020-12-10.log#221732

I can reproduce it on a foreign distro by adding this to the systemd
service file:

  
Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en-US.utf8

(note the en-US typo)

This seems to be a recent regression, as I could not reproduce with an
old guix-daemon (I believe beba9ff82123c4a82721b2ed14df2c7576e22e85).


signature.asc
Description: PGP signature

bug#44780: freecad (@0.18.4) fails to build

[Marius Bakke]

Fulbert  skriver:

> Hello!
>
> freecad (freecad@0.18.4) fails to build with attached log file.

This was fixed by Ekaitz in 50c24bbd4f2d2e48d5eda9ac540a6dc15e7cf6a3.

Thanks!


signature.asc
Description: PGP signature

bug#43783: ssh-copy-id: line 254: /dev/null`: Permission denied

[Marius Bakke]

Nathan Dehnel  skriver:

> ssh-copy-id errors out and then does not install the key
>
> bash-5.0$ ssh-copy-id pi@raspberrypi
> /home/nathan/.guix-profile/bin/ssh-copy-id: INFO: attempting to log in with
> the new key(s), to filter out any that are already installed
> /home/nathan/.guix-profile/bin/ssh-copy-id: INFO: 2 key(s) remain to be
> installed -- if you are prompted now it is to install the new keys
> /home/nathan/.guix-profile/bin/ssh-copy-id: line 251: warning:
> here-document at line 251 delimited by end-of-file (wanted `EOF')
> /home/nathan/.guix-profile/bin/ssh-copy-id: line 250: warning:
> here-document at line 250 delimited by end-of-file (wanted `EOF')
> /home/nathan/.guix-profile/bin/ssh-copy-id: line 254: /dev/null`:
> Permission denied
> /home/nathan/.guix-profile/bin/ssh-copy-id: line 260: EOF: command not found

This was fixed by Jesse in 81fbe03b509414aa1ede960141a7ffd241d5f9ee.

Thanks for the report!


signature.asc
Description: PGP signature

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

[Marius Bakke]

Mark H Weaver  skriver:

> Since the recent merge of the 'staging' branch into 'master' on 28 Nov
> 2020, I'm no longer able to configure the alert sound in GNOME.  That's
> a pity, since I find the default "drip" sound extremely unpleasant.

There were not a lot of GNOME-related changes in that merge.  From a
quick glance of...

  git shortlog --format='%h %s' --no-merges -n fe5c9051cc..e827f40479

...a likely culprit is:

  62df18d305 gnu: dconf: Update to 0.36.0.

Can you check if reverting it makes a difference?


signature.asc
Description: PGP signature

bug#45031: qoauth fail install/build

[Marius Bakke]

Distopico  skriver:

> I was trying to install `guix install qoauth` and build `guix install
> qoauth` but it failed, and looks like is due The installation process is
> trying to copy some files that are part of qoauth into the store
> directory of qtbase, which is another package.
>
> Attached the log of the build.

[...]

> /gnu/store/qylisyh4cz32askxl5640qjhl47kr1wp-qtbase-5.14.2/bin/qmake -install 
> qinstall /tmp/guix-build-qoauth-2.0.0.drv-0/source/oauth.prf 
> /gnu/store/qylisyh4cz32askxl5640qjhl47kr1wp-qtbase-5.14.2/lib/qt5/mkspecs/features/oauth.prf
> Error copying /tmp/guix-build-qoauth-2.0.0.drv-0/source/oauth.prf to 
> /gnu/store/qylisyh4cz32askxl5640qjhl47kr1wp-qtbase-5.14.2/lib/qt5/mkspecs/features/oauth.prf:
>  Cannot create 
> /gnu/store/qylisyh4cz32askxl5640qjhl47kr1wp-qtbase-5.14.2/lib/qt5/mkspecs/features/oauth.prf
>  for output

For some reason $QMAKE_MKSPECS no longer resolves to the output at
install time.  I'm not sure when this regression occured.

After a quick rummaging of my store, it seems the practice of installing
"mkspecs" files is rather unorthodox (I found only 'qca', and it does
not use qmake at all and thus avoids this problem), so I committed an
unsatisfactory workaround in 627b70e3ac8aade9744a998c28570fbb52b986a7.

It would be good to find the source of the regression and fix 'qmake',
but let's get back to that if it becomes a widespread issue.

Thanks for the report!

(By the way, there are some [disabled] test failures in qoauth.  If you
intend to use this library for something important, I recommend trying
to get the tests working.)  :-)


signature.asc
Description: PGP signature

bug#43448: [bug#45059] [PATCH] gnu: freecad: Fix compilation flags

[Marius Bakke]

Ekaitz Zarraga  skriver:

> Hi everyone,
>
> I managed to solve the longstanding issue with freecad's compilation (#43448).
>
> I'll submit a new change with the package update to 0.18.5 next.

Thanks a lot for these patches Ekaitz!

I pushed them both with 383f087cd74316d26c5c0f19b73bc620312c5477.


signature.asc
Description: PGP signature

bug#45066: guix environment --container is borken

[Marius Bakke]

zimoun  skriver:

> Hi,
>
> On Sun, 06 Dec 2020 at 16:59, luhux  wrote:
>> In the new guix `guix environment --container` is borken.
>
> It is not broken.

It was broken.  :-)

> Have you tried the recommendation?
>
> --8<---cut here---start->8---
> $ su -
> Password: 
> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone 
> # logout
>
> $ guix environment -C --ad-hoc hello -- hello 
> Hello, world!
> --8<---cut here---end--->8---

...because this only works on the Debian kernel.

We need to find a more robust test for user namespaces, but for now I
reverted the commit.

Closing!  Thanks for the report luhux.  :-)


signature.asc
Description: PGP signature

bug#44914: gnutls-dane does not build: failed test status-request-revoked

[Marius Bakke]

"Dr. Arne Babenhauserheide"  skriver:

> I cannot update Guix right now, because gnutls-dane fails to build.
>
> The build log is attached.
>
> make[4]: Entering directory 
> '/tmp/guix-build-gnutls-dane-3.6.12.drv-0/gnutls-3.6.12/tests'
> …
> FAIL: status-request-revoked

This is because of a "time bomb" in GnuTLS:

  https://gitlab.com/gnutls/gnutls/-/issues/967

It was fixed in 3.6.14.  I worked around it for now by making
'gnutls-dane' inherit from a newer version in commit
7177411c34be42aa1c539f462f0de191c74a5913.

We'll do an 'ungrafting round' shortly so that we can fix this in GnuTLS
proper.


signature.asc
Description: PGP signature

bug#44944: Unable to log into X session via gdm

[Marius Bakke]

Danny Milosavljevic  skriver:

> The latest guix system reconfigure (of yesterday) left me unable to login into
> my X session.  guix system rollback DID NOT fix it.
>
> I would enter my password and it would "try" to login and return right back to
> the gdm login screen.

Can you find any clues in the log files as to why this happened?

Did you reboot after reconfiguring?


signature.asc
Description: PGP signature

bug#37309: ‘ssh-daemon’ service fails to start at boot

[Marius Bakke]

Christopher Lemmer Webber  skriver:

> Giovanni Biscuolo writes:
>
>> Hi,
>>
>> following a recent discussion on guix-sysadmin I have to confirm the
>> ssh-daemon issue since it is still happening on some of the machines I
>> administer
>>
>> Previous possibly related bug reports are
>> https://issues.guix.gnu.org/issue/30993 and
>> https://issues.guix.gnu.org/issue/32197
>>
>> Unfortunately this issue is *not* well reproducible, it depends on some
>> mysterious (to me) timing factor; AFAIU it does *not* depend on the
>> shepherd version, probably it depends on "something" related to IPv6
>> (read below the details)
>
> This issue continues to plauge me, and has ever since I started to use
> GuixSD.  However it is much worse now that I am running Guix on
> servers... I frequently have to log in via Linode's (nonfree!) web
> console on every server that is rebooted and kick herd to restart
> openssh.  Once I do that it's fine.

Can you share an excerpt of /var/log/messages (ideally the whole boot
sequence) from when SSH failed to start?

> I don't think my linode machine is on "spinning rust" so I don't think
> this is the cause.  IPv6, maybe?  Dunno what.
>
> However I think that it's probably really a dependency issue somewhere;
> herd is starting opensshd before some other dependent service is
> spawned.  But what?  Maybe something authentication related like
> networking, or something.  But hm, networking is required...
>
> I'm assuming others must be experiencing this still too... right?

FWIW I have never encountered this.  :-/

> Would really like to see it fixed.  It's one of the few things holding
> me back from recommending Guix on servers to others.
>
> Do others have any idea?
>
> I noticed the lsh daemon requires networking.  Why doesn't openssh?

It's really for legacy reasons, from before we had the Guix System
installer.  Then a common way to install was to run dhclient and
"herd start ssh-daemon" manually on the live image, so people could
do the installation over SSH:

  https://issues.guix.gnu.org/26548#5

Nowadays, the installer gives a nice and quick way to deploy a minimal
system, and I suspect the SSH method has fallen out of favor.

> What about the following "fix"?

[...]

>(list (shepherd-service
>   (documentation "OpenSSH server.")
> - (requirement '(syslogd loopback))
> + (requirement '(syslogd networking loopback))

If it works for you, let's do this.  It would be good to find the
underlying cause though...

Not sure what to do about the installer however: perhaps create
yet-another undocumented field of openssh-service-type that makes the
networking requirement optional?


signature.asc
Description: PGP signature

bug#44769: [staging] gst-plugins-bad fails tests on aarch64, armhf, i686

[Marius Bakke]

Guillaume Le Vaillant  skriver:

> After trying to find where the problem could come from, GStreamer
> started working fine again, but I'm not sure why. I suspect there was
> some bad local state in my user environment that I reset while hacking
> around, or something like that...

Oh, that's good news.

> Anyway, concerning 'cheese', I think not installing it by default with
> Gnome would not be a problem. It's not an essential core component of
> Gnome and users who want it will still be able to install it trivially.

Cheese is popular among kids, so it's nice to have it out of the box.

But not essential, obviously.  Unless something else crops up I will
remove Cheese from GNOME and merge 'staging' in a day or two!


signature.asc
Description: PGP signature

bug#44769: [staging] gst-plugins-bad fails tests on aarch64, armhf, i686

[Marius Bakke]

Hello Guix,

gst-plugins-bad fails its test suite on anything other than x86_64-linux.

Upstream issues:

  i686: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1463
  aarch64: 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1464

(I believe the i686 issue affects armhf too)

This issue is currently holding up merging of 'staging' because
gst-plugins-bad is a dependency of 'cheese', which is a dependency of
'gnome'.

To move on with the merge, I wonder whether to:

1. Disable the affected tests, as upstream does not seem terribly
   concerned.
2. Drop 'cheese' from 'gnome'.

I'm leaning towards 2, as the AArch64 failure looks kind of serious.
Unfortunately 'cheese' does seem to require gst-plugins-bad.

Thoughts?


signature.asc
Description: PGP signature

bug#44669: Shepherd loses track of elogind

[Marius Bakke]

Ludovic Courtès  skriver:

>> Now I no longer use SDDM (or any DM), but I was able to work around it
>> by adding #:pid-file:
>>
>> diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
>> index 265cf9f35f..6b7d832a44 100644
>> --- a/gnu/services/desktop.scm
>> +++ b/gnu/services/desktop.scm
>> @@ -770,7 +770,8 @@ seats.)"
>> #:environment-variables
>> (list (string-append "ELOGIND_CONF_FILE="
>>  #$(elogind-configuration-file
>> -   config)
>> +   config)))
>> +   #:pid-file "/run/systemd/elogind.pid"))
>>   (stop #~(make-kill-destructor)
>
> LGTM.  Now, if elogind is started behind the shepherd’s back, there’s
> still a race: shepherd removes the PID file before spawning the process,
> and then waits for that PID file to show up.  Chances are shepherd will
> not notice that another elogind is already running, and thus the service
> will fail to start.

Right.  If Shepherd actually deletes the PID file before attempting to
start the service, I think I just "won" the race in my testing...

>> The race between D-Bus and elogind should probably be handled by having
>> org.freedesktop.login1 consumers depend on the 'elogind' service instead?
>
> Yes, we could do that.  Note that the only reason we just don’t let
> elogind be bus-activated is so it can handle events like lid close even
> before someone has attempted to log in (commit
> 94a881178af9a9a918ce6de55641daa245c92e73,
> ).

Interesting.  I wonder what other workarounds there are for this.

For now, I made SDDM simply depend on elogind in commit
0ae9bbe4f5f89e6f597bdb1f6df646fc5f504876.


signature.asc
Description: PGP signature

bug#22952: Backlight brightness keys in GDM and MATE require password authentication

[Marius Bakke]

"pelzflorian (Florian Pelz)"  skriver:

> I’m reopening this bug because it is very similar to my issue.
>
> When using my Macbook’s keyboard XF86MonBrightnessUp/Down keys to
> adjust screen brightness (probably on non-Macbooks too) in GDM or
> MATE, I am asked to enter my authentication password to make
> gnome-settings-daemon’s libexec/gsd-backlight-helper (or some
> equivalent program on MATE) change screen brightness.
>
> This should not be so; gsd-backlight-helper should have PolicyKit, pam
> or setuid or whatever.

gnome-service-type installs a PolicyKit rule for gnome-settings-daemon.

Should the MATE service do the same?

To work around it locally, try adding:

  (simple-service 'gsd-polkit polkit-service-type
  (list gnome-settings-daemon))

to the (services ...) section of your system configuration.


signature.asc
Description: PGP signature

bug#25304: bug#25508: Git hook shebangs should not be rewritten

[Marius Bakke]

Miguel Ángel Arruga Vivas  writes:

> The attached patch fixes this one too, should I push it to master (as
> the last change for git) or to core-updates or staging (as it might seem
> looking at the dependencies)?

LGTM.  Git (+ git-minimal) is below the 300 rebuild limit for 'master'
(and I try to keep it that way!).


signature.asc
Description: PGP signature

bug#44692: [staging] alacritty build failure

[Marius Bakke]

Hello,

On the 'staging' branch, the "alacritty" package fails to build:

--8<---cut here---start->8---
starting phase `build'
error: --features is not allowed in the root of a virtual workspace
note: while this was previously accepted, it didn't actually do anything
command "cargo" "build" "--features" "" "--release" failed with status 101
--8<---cut here---end--->8---

It probably has to do with the Rust upgrade.

Ideas?


signature.asc
Description: PGP signature

bug#44669: Shepherd loses track of elogind

[Marius Bakke]

Marius Bakke  writes:

> Ludovic Courtès  writes:
>
>> Hi Marius,
>>
>> Marius Bakke  skribis:
>>
>>> On a newly-installed i7 system, Shepherd believes that the "elogind"
>>> service is not running.  Yet there is an 'elogind-daemon' process,
>>> spawned by PID 1, preventing subsequent "herd start elogind" invocations
>>> from succeeding.
>>
>> Could you show the relevant /var/log/messages bits?  That should show
>> when/why elogind stopped.
>
> Indeed.  It was because I had 'sddm-service-type' configured, which
> attempted to communicate with "org.freedesktop.login1" over D-Bus, which
> in turn autostarted elogind before shepherd had gotten around to it.

Interestingly I suspected this exact scenario and checked the PPID of
the running elogind process, which was '1'.  When I then found that
adding #:pid-file worked, I did not bother checking the log ...

I would have expected D-Bus to be the parent PID.


signature.asc
Description: PGP signature

bug#44669: Shepherd loses track of elogind

[Marius Bakke]

Ludovic Courtès  writes:

> Hi Marius,
>
> Marius Bakke  skribis:
>
>> On a newly-installed i7 system, Shepherd believes that the "elogind"
>> service is not running.  Yet there is an 'elogind-daemon' process,
>> spawned by PID 1, preventing subsequent "herd start elogind" invocations
>> from succeeding.
>
> Could you show the relevant /var/log/messages bits?  That should show
> when/why elogind stopped.

Indeed.  It was because I had 'sddm-service-type' configured, which
attempted to communicate with "org.freedesktop.login1" over D-Bus, which
in turn autostarted elogind before shepherd had gotten around to it.

Nov 15 21:16:18 localhost dbus-daemon[427]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.2' (uid=0 pid=449 
comm="/gnu/store/x577n8rs9zcf6ri4aka4pccyj74qxhwh-sddm-0") (using servicehelper)
Nov 15 21:16:18 localhost vmunix: [   46.137561] elogind-daemon[462]: New seat 
seat0.
Nov 15 21:16:18 localhost vmunix: [   46.138052] elogind-daemon[462]: Watching 
system buttons on /dev/input/event2 (Power Button)
Nov 15 21:16:18 localhost vmunix: [   46.193372] elogind-daemon[462]: Watching 
system buttons on /dev/input/event1 (Lid Switch)
Nov 15 21:16:18 localhost vmunix: [   46.193428] elogind-daemon[462]: Watching 
system buttons on /dev/input/event0 (Sleep Button)
Nov 15 21:16:18 localhost avahi-daemon[444]: Server startup complete. Host name 
is sirius.local. Local service cookie is 3083842416.
Nov 15 21:16:18 localhost vmunix: [   46.496547] elogind-daemon[462]: Watching 
system buttons on /dev/input/event3 (AT Translated Set 2 keyboard)
Nov 15 21:16:18 localhost vmunix: [   46.496598] elogind-daemon[462]: Watching 
system buttons on /dev/input/event4 (ThinkPad Extra Buttons)
Nov 15 21:16:18 localhost dbus-daemon[427]: [system] Successfully activated 
service 'org.freedesktop.login1'
Nov 15 21:16:18 localhost vmunix: [   46.498084] elogind-daemon[462]: New 
session c1 of user marius.
Nov 15 21:16:18 localhost shepherd[1]: Service avahi-daemon has been started.
Nov 15 21:16:18 localhost shepherd[1]: Service mcron has been started.
Nov 15 21:16:18 localhost shepherd[1]: Service elogind has been started.
Nov 15 21:16:18 localhost shepherd[1]: Respawning elogind.

> That’s from 1.2.0rc1?

Yes, and also 'master'.  The initial i3 install with 1.2.0rc1 went fine,
it was when I switched to SDDM + autologin (+ sway) that it failed.

Now I no longer use SDDM (or any DM), but I was able to work around it
by adding #:pid-file:

diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 265cf9f35f..6b7d832a44 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -770,7 +770,8 @@ seats.)"
#:environment-variables
(list (string-append "ELOGIND_CONF_FILE="
 #$(elogind-configuration-file
-   config)
+   config)))
+   #:pid-file "/run/systemd/elogind.pid"))
  (stop #~(make-kill-destructor)
 
 (define elogind-service-type

The race between D-Bus and elogind should probably be handled by having
org.freedesktop.login1 consumers depend on the 'elogind' service instead?


signature.asc
Description: PGP signature

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Marius Bakke]

Ludovic Courtès  writes:

> Hi,
>
> Daniel Brooks  skribis:
>
>> It should instead include the guix-daemon.cil file which was built from
>> it. The .in file has unsubstituted variabels in it which make it useless
>> as an SELinux policy.
>
> Yes, but running “./configure” gives you the ‘etc/guix-daemon.cil’ for
> your configuration.  What’s wrong with that?
>
> Marius: common practice is to not include instantiated templates; we
> wouldn’t use templates in the first place if contents were always the
> same.  :-)

Yes indeed; somehow I thought the bootstrapped tarball also had run
"configure" with the common options, but obviously that's incorrect.

Closing this bug, as there is no reason to special-case this one file.


signature.asc
Description: PGP signature

bug#44669: Shepherd loses track of elogind

[Marius Bakke]

Hello,

On a newly-installed i7 system, Shepherd believes that the "elogind"
service is not running.  Yet there is an 'elogind-daemon' process,
spawned by PID 1, preventing subsequent "herd start elogind" invocations
from succeeding.


signature.asc
Description: PGP signature

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Marius Bakke]

Daniel Brooks  writes:

> It should instead include the guix-daemon.cil file which was built from
> it. The .in file has unsubstituted variabels in it which make it useless
> as an SELinux policy.

Actually I think both should be included.  The processed file will work
for 99% of users, and the template is needed for the 1% that use a
different store directory.

@Ludo: WDYT about the attached patch for version-1.2.0?

From 8b77d853a4c9503df61fb75190d562206d1de1d2 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 15 Nov 2020 15:56:04 +0100
Subject: [PATCH] maint: Install the processed SELinux policy file in addition
 to the template.

This fixes <https://bugs.gnu.org/44649>.
Reported by Daniel Brooks .

* Makefile.am (dist_selinux_policy_DATA): New target.
---
 Makefile.am | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5b84d74f08..4c061db3ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -561,8 +561,10 @@ dist_zshcompletion_DATA = etc/completion/zsh/_guix
 # Fish completion file.
 dist_fishcompletion_DATA = etc/completion/fish/guix.fish
 
-# SELinux policy
+# SELinux policy.  Install both the template and the compiled version so
+# it works "out of the box", but can be rebuilt as necessary.
 nodist_selinux_policy_DATA = etc/guix-daemon.cil.in
+dist_selinux_policy_DATA = etc/guix-daemon.cil
 
 EXTRA_DIST +=		\
   HACKING		\
-- 
2.29.2



signature.asc
Description: PGP signature

bug#44558: Mesa isn't update to date

[Marius Bakke]

Guillaume Le Vaillant  writes:

> I saw that issue 803 of gst-plugin-good has been closed with patch
> 2ce5909f; are there other things blocking the merge of the 'staging'
> branch into 'master'?

Now 'gst-plugins-bad' fails on i686:

  https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1463

There are not a lot of packages depending on it, so maybe it can be
ignored.  However 'gnome' is one of the affected packages (through
'cheese').

Other than these I don't know any serious regressions, but it's hard to
tell because Cuirass has not been very cooperative:

  https://ci.guix.gnu.org/jobset/staging-staging


signature.asc
Description: PGP signature

bug#44558: Mesa isn't update to date

[Marius Bakke]

Guillaume Le Vaillant  writes:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix  skribis:
>
>> Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2
>> might fix?  Please let us know.  An otherwise working package not being at 
>> the
>> latest upstream version isn't a bug.
>>
>> romulasry via Bug reports for GNU Guix 写道：
>>> Mesa 20.2.2 is released
>>
>> The core-updates branch updates Mesa to 20.1.9.  Would you like to submit
>> a (tested) core-updates patch updating it to 20.2.2?
>
> Hi,
>
> Mesa 20.2 brings direct OpenGL rendering support for Nvidia RTX 20xx
> graphic cards with the nouveau driver, whereas with our current version
> these cards have to use LLVMpipe.
> I tested the update quickly on my local staging branch using glxgears
> and vlc, and it worked fine. When reading a video the CPU usage dropped
> from 30% to 2%, which is nice.

That is great news.

The current 'staging' branch is just about ready for merge[*], so a Mesa
update will have to wait until the next round.

However, I think libGL is fairly ABI-stable, so you may be able to
"graft" this version in the mean time, like in commit
fdd883509301845ddb4dc90e70e58b469afb5441.

[*] gst-plugins-good fails on armhf and i686, not sure what to do about
it yet: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/803


signature.asc
Description: PGP signature

bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

[Marius Bakke]

Ludovic Courtès  writes:

> The question for us becomes how to ensure long-term reproducibility in
> the presence of such bugs.
>
> In this case, I think the only solution would be to change the system
> clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but
> you end up with different derivations, which is not necessarily
> desirable).
>
> Thoughts?

There is a related bug report here:

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

Perhaps we could make a "--with-system-clock" option for 'guix build'
that instructs the daemon to fake the system time?


signature.asc
Description: PGP signature

bug#44383: gst-plugins-good fails its test suite on armhf-linux

[Marius Bakke]

Maxim Cournoyer  writes:

> Here's the output for the failing tests:

This is using QEMU transparent emulation, right?

There is a substitute on Berlin:

$ guix weather -s armhf-linux gst-plugins-good
computing 1 package derivations for armhf-linux...
looking for 1 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 4.1 MiB of nars (compressed)
  5.5 MiB on disk (uncompressed)
  1.402 seconds per request (1.4 seconds in total)
  0.7 requests per second

I'm not sure to what extent we should patch packages to work with QEMU
transparent emulation.  And currently the CI does not use it at all for
32-bit ARM (albeit for rather different reasons).

Thoughts?


signature.asc
Description: PGP signature

bug#44525: Derivation of computed-file has no outputs

[Marius Bakke]

Stefan  writes:

> Hi!
>
> I try to use a computed-file as an input to a bootloader profile hook 
> function. Using guix system I get this error message:
>
> guix system: error: reference to invalid output 'out' of derivation 
> '/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv'

>
> This is the simple definition of the computed-file:
>
> (computed-file "test.txt" (with-imported-modules '((guix utils)) 
> #~(%current-system)))

That's expected: this derivation does not produce any outputs.

Assuming you intended to write (%current-system) to test.txt, you can do
something along these lines:

  (computed-file "test.txt"
 #~(call-with-output-file #$output
 (lambda (port)
   (format port #$(%current-system)

So I think this is not-a-bug.  WDYT?


signature.asc
Description: PGP signature

bug#44508: Found a bug in compute-guix-derivation

[Marius Bakke]

Josh Marshall  writes:

> Hello all,
>
> When pulling I came across the following which told me to send a report in:
>
> ```
> anadon@goodadvicemallard:~$ guix pull
> Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...

[...]

> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> @ substituter-started
> /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2

[...]

> gzip: stdin: unexpected end of file
> guix substitute: error: corrupt input while restoring
> '/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2/bin/git'
> from #{read pipe}#
> @ substituter-failed
> /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2 256 fetching
> path `/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2'
> failed with exit code 1

[...]

> ./guix/store.scm:1368:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation
> `/gnu/store/6kd94qkd2hnkri5hc44vfjvh8b0i5ynl-git-minimal-2.29.2.drv' failed
> (usually happens due to networking issues); try `--fallback' to build
> derivation from source "

Probably this was a transient (network) failure, or is the error
consistent?

And for something completely different:

> /gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute

Consider updating the 'root' user Guix (or reconfigure, if you are on
Guix System), to get the latest version of guix-daemon.


signature.asc
Description: PGP signature

bug#44417: ungoogle-chromium crashes on Jitsi & co.

[Marius Bakke]

Ludovic Courtès  writes:

> Current ungoogle-chromium (commit
> e1f5c2292b88525414b5d0336a00bfa6741d4f14) crashes upon displaying video
> as in Jitsi (GPU_DEAD_UPON_ARRIVAL error, IIRC).

The demo at https://meet.jit.si "works for me".  That is with
"intel-vaapi-driver" installed.  Does that make a difference?

Probably not, because it works here even without $LIBVA_DRIVERS_PATH.

Which GPU are you using?

Recently Chromium started building its own libGL.so and complains about
it not being found at startup (because it looks in $out/lib).  I'm
currently testing a patch that makes it use Mesas libGL mainly to
quiesce the warning.  Not sure if that is related, we'll see...


signature.asc
Description: PGP signature

bug#44194: Cuirass ignoring proc_args on Berlin

[Marius Bakke]

Hello,

Cuirass is currently evaluating all of 'core-updates':

  https://ci.guix.gnu.org/jobset/core-updates-core-updates

This is despite (subset . core) in "proc_args".

Any idea what's going on here?


signature.asc
Description: PGP signature

bug#44146: CVE-2020-15999 in FreeType

[Marius Bakke]

Hello,

The 'freetype' package is vulnerable to CVE-2020-15999.

According to
https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html,
an exploit already exists in the wild.

I'm busy for a couple of days and won't be able to work on it in time.
Volunteers wanted!

Forwarding a message from oss-security, we may have to patch Ghostscript
as well:

 Start of forwarded message 
To: oss-secur...@lists.openwall.com
Cc: Werner LEMBERG 
From: Alan Coopersmith 
Date: Tue, 20 Oct 2020 09:49:31 -0700
Subject: [oss-security] CVE-2020-15999 fixed in FreeType 2.10.4

Before making this release, Werner said:

> I've just fixed a heap buffer overflow that can happen for some
> malformed `.ttf` files with PNG sbit glyphs.  It seems that this
> vulnerability gets already actively used in the wild, so I ask all
> users to apply the corresponding commit as soon as possible.

But distros should be warned that 2.10.3 and later may break the build
of ghostscript, due to ghostscript's use of a withdrawn macro that
wasn't intended for external usage:

https://bugs.ghostscript.com/show_bug.cgi?id=702985
https://lists.nongnu.org/archive/html/freetype-devel/2020-10/msg2.html

Ghostscript's fix for that is at:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=41ef9a0bc36b

-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

 Forwarded Message 
Subject: [ft-announce] Announcing FreeType 2.10.4
Date: Tue, 20 Oct 2020 07:47:31 +0200 (CEST)
From: Werner LEMBERG 
To: freetype-annou...@nongnu.org, freetype-de...@nongnu.org, freet...@nongnu.org


FreeType 2.10.4 has been released.

It is available from

 http://savannah.nongnu.org/download/freetype/

or

 http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
 mirror site.   Files on  mirrors may  be subject to  a replication
 delay   of   up   to   24   hours.   In   case   of  problems  use
 http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--


CHANGES BETWEEN 2.10.3 and 2.10.4

   I. IMPORTANT BUG FIXES

   - A heap buffer overflow has been found  in the handling of embedded
 PNG bitmaps, introduced in FreeType version 2.6.

   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999

 If you  use option  FT_CONFIG_OPTION_USE_PNG  you  should  upgrade
 immediately.

___
Freetype-announce mailing list
freetype-annou...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-announce

 End of forwarded message 


signature.asc
Description: PGP signature

bug#44121: Cuirass jobs become cancelled due to garbage collected .drv's

[Marius Bakke]

Hello,

Most jobs from the 'staging' evaluation in Cuirass are cancelled:

  https://ci.guix.gnu.org/jobset/staging-staging

(scroll a few pages rightwards)

Christopher mentioned on #guix that this can happen when the derivations
have disappeared by the time Cuirass tries running a job.

Indeed, the jobs listed as cancelled have associated derivations that
are missing on Berlin, likely from the nightly GC.

Probably Cuirass should store GC roots for each .drv file.  Thoughts?

Is there a trick to make Cuirass forget about these derivations, and try
recreating the jobs?


signature.asc
Description: PGP signature

bug#43843: [PATCH] build-system/haskell: Disable parallel builds.

[Marius Bakke]

zimoun  writes:

> Fixes .
>
> PARALLEL-BUILD? introduced by commit 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2
> leads to unreproducibility.  Instead of reverting, default is set to #false
> which allows user to locally build with parallelism.
>
> * guix/build-system/haskell.scm (haskell-build): Turn off PARALLEL-BUILD? by
> default.

Thanks!  I shortened the comment a little and pushed to staging in
19d42e0e23a7f90ac2dcc1c279bd23a967ff0314.


signature.asc
Description: PGP signature

bug#44064: can't build runc

[Marius Bakke]

luhux  writes:

> guix describe:
> Generation 15   Oct 16 2020 20:24:15(current)
>   guix 24dd78a
>   repository URL: https://git.savannah.gnu.org/git/guix.git 
>   branch: master
>   commit: 24dd78a3cdd45d73d61c1133cac21f21c2331c2a

This problem was fixed a few commits later, in
e39e8d97c17c7e7a008a4f4e125ae6b3844cc03a.  Thanks for the report!


signature.asc
Description: PGP signature

bug#43893: [PATCH v2] maint: update-guix-package: Prevent accidentally breaking guix pull.

[Marius Bakke]

Maxim Cournoyer  writes:

> Fixes .
>
> This changes the 'update-guix-package' tool so that it:
>
> 1. Always uses a clean checkout to compute the hash of the updated 'guix'
> package.
> 2. Ensures the commit used in the updated 'guix' package definition has 
> already
> been pushed upstream.
>
> * build-aux/update-guix-package.scm (%savannah-guix-git-repo-push-url): New
> variable.
> (with-input-pipe-to-string): New syntax.
> (find-origin-remote, git-add-worktree): New procedures.
> (commit-already-pushed?): New predicate.
> (main): Check the commit used has already been pushed upstream and compute the
> hash from a clean checkout.
> * doc/contributing.texi (Updating the Guix Package): Document it.

[...]
  
>  (define %top-srcdir
>(string-append (current-source-directory) "/.."))
> @@ -101,44 +109,69 @@ COMMIT."
>(exp
> (error "'guix' package definition is not as expected" exp)
>  
> -
> -(define (main . args)
> -  (match args
> -((commit version)
> - (with-store store
> -   (let* ((source   (add-to-store store
> -  "guix-checkout" ;dummy name
> -  #t "sha256" %top-srcdir
> -  #:select? version-controlled?))
> -  (hash (query-path-hash store source))
> -  (location (package-definition-location))
> -  (old-hash (content-hash-value
> -  (origin-hash (package-source guix)
> - (edit-expression location
> -  (update-definition commit hash
> - #:old-hash old-hash
> - #:version version))
> +(define (git-add-worktree directory commit-ish)
> +  "Create a new git worktree at DIRECTORY, detached on commit COMMIT-ISH."
> +  (invoke "git" "worktree" "add" "--detach" directory commit-ish))

Is it feasible to use Guile-Git here (given appropriate bindings)?

> +(define %savannah-guix-git-repo-push-url
> +  "git.savannah.gnu.org/srv/git/guix.git")
>  
> - ;; Re-add SOURCE to the store, but this time under the real name 
> used
> - ;; in the 'origin'.  This allows us to build the package without
> - ;; having to make a real checkout; thus, it also works when working
> - ;; on a private branch.
> - (reload-module
> -  (resolve-module '(gnu packages package-management)))
> +(define-syntax-rule (with-input-pipe-to-string prog arg ...)
> +  (let* ((input-pipe (open-pipe* OPEN_READ prog arg ...))
> +  (output (get-string-all input-pipe))
> +  (exit-val (status:exit-val (close-pipe input-pipe
> +(unless (zero? exit-val)
> +  (error (format #f "Command ~s exited with non-zero exit status: ~s"
> + (string-join (list prog arg ...)) exit-val)))
> +(string-trim-both output)))
>  
> - (let* ((source (add-to-store store
> -  (origin-file-name (package-source 
> guix))
> -  #t "sha256" source))
> -(root   (store-path-package-name source)))
> +(define (find-origin-remote)
> +  "Find the name of the git remote with the Savannah Guix git repo URL."
> +  (and-let* ((remotes (string-split (with-input-pipe-to-string
> + "git" "remote" "-v")
> +#\newline))
> + (origin-entry (find (cut string-contains <>
> +  (string-append
> +   %savannah-guix-git-repo-push-url
> +   " (push)"))
> + remotes)))
> +(first (string-split origin-entry #\tab
>  
> -   ;; Add an indirect GC root for SOURCE in the current directory.
> -   (false-if-exception (delete-file root))
> -   (symlink source root)
> -   (add-indirect-root store
> -  (string-append (getcwd) "/" root))
> +(define (commit-already-pushed? remote commit)
> +  "True if COMMIT is found in the REMOTE repository."
> +  (not (string-null? (with-input-pipe-to-string
> +  "git" "branch" "-r" "--contains" commit
> +  (string-append remote "/master")

...because parsing git CLI output is error-prone and "ugly" (IMO).  But
not a strong opinion.

> -   (format #t "source code for commit ~a: ~a (GC root: ~a)~%"
> -   commit source root)
> +
> +(define (main . args)
> +  (match args
> +((commit version)
> + (with-directory-excursion %top-srcdir
> +   (or (getenv "GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT")
> +   (commit-already-pushed? (find-origin-remote) commit)
> +   (leave (G_ "Commit ~a is not pushed upstream.  Aborting.~%") 
> commit))
> +   (dynamic-wind
> + (lambda 

bug#40411: [bug#41863] [PATCH] services: Fix gdm-autologin pam service.

[Marius Bakke]

Alex Griffin via Guix-patches via  writes:

> This patch fixes GDM's auto-login feature.
>
> See the discussions in #35674 and #40411. It works for me, but I don't want 
> to just commit it because I don't really understand PAM. (Then again, who 
> does?)

[...]

> @@ -925,7 +926,7 @@ the GNOME desktop environment.")
>  (inherit (unix-pam-service "gdm-autologin"
> #:login-uid? #t))
>  (auth (list (pam-entry
> - (control "[success=ok default=1]")
> + (control "optional")

This is one of the alternatives Timothy proposed in #35674 back in May
last year(!).  As long as GDM still rejects wrong or blank passwords, I
think it is good to go.

It would be good to get it in 1.2.0.  :-)


signature.asc
Description: PGP signature

bug#43567: wpa supplicant service depends on 'dbus-system''s service, even when config says (dbus? #f)

[Marius Bakke]

calcium  writes:

> It seems that even when disabling dbus for
> wpa-supplicant, the service `dbus-system' is started for
> wpa-supplicant.
> And trying to stop it with 'herd stop dbus-system' also
> stop the wpa-supplicant service (which should not depend on dbus when
> configured with (dbus? #f))
>
> ```
> (service wpa-supplicant-service-type
>  (wpa-supplicant-configuration
>   (dbus? #f)))
> ```

Fixed in d48b17adb91d68acf6fb3f321c05102fcc8c39eb, thanks!


signature.asc
Description: PGP signature

bug#43344: "basic" system tests fail (and all the other ones) on guix master

[Marius Bakke]

Leo Famulari  writes:

> On Wed, Sep 16, 2020 at 09:36:49PM -0400, Mark H Weaver wrote:
>> Next, it probably makes sense to test 5.8.9 with the above commit
>> reverted.  Would someone like to try it?  If that works, we can avoid
>> the bisection, resume kernel updates, and revert this change across all
>> of our kernels until a better solution is found.
>
> I'll do this tonight.

A fix for this is available in mainline:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88ce2a530cc9865a894454b2e40eba5957a60e1a

(via )


signature.asc
Description: PGP signature

bug#42934: Ganeti fails to build

[Marius Bakke]

Timothy Sample  writes:

> Hi Marius,
>
> Marius Bakke  writes:
>
>> Since the recent haskell-build-system changes, the 'ganeti' package
>> fails to build [...]
>
> This is fixed by 856def7bb3b4af85a1325bc732e81d705156a482 (and also
> 991ca49961d1066f7890644a40d629aca944f5b9).
>
> You are right about ‘ghc-regex-pcre’ needing the ‘extra-directories’
> option.  After that it was a matter of finding a way to get the Ganeti
> build to tell GHC to use the new shared libraries the Haskell build
> system produces.
>
> Sorry for the breakage!

Thanks for the quick fix!  :-)


signature.asc
Description: PGP signature

bug#42964: Potential FSDG issue with debootstrap scripts

[Marius Bakke]

Denis 'GNUtoo' Carikli  writes:

> Hi,
>
> I found a potential issue with the debootstrap package and the Guix
> blog.

Thanks for bringing this to our attention!

> The Free System Distribution Guidelines states that:
>> A free system distribution must not steer users towards obtaining any
>> nonfree information for practical use, or encourage them to do so.
>> The system should have no repositories for nonfree software and no
>> specific recipes for installation of particular nonfree programs. Nor
>> should the distribution refer to third-party repositories that are
>> not committed to only including free software; even if they only have
>> free software today, that may not be true tomorrow. Programs in the
>> system should not suggest installing nonfree plugins, documentation,
>> and so on.
>
> However after instalation, the debootstrap package contains scripts for
> installing many distributions, and most of them are either not FSDG
> compliant or have nonfree software in them.
>
> I assume that the Ubuntu repositories are "third-party repositories that
> are not committed to only including free software", and they are used
> in the debootstrap scripts to install Ubuntu.

Does Ubuntu carry non-free software in the default repos?  If so I agree
that is a problem.

> After installation I got the following scripts in
> ~/.guix_profile/share/debootstrap/scripts/:

[...]

> The scripts are named after distribution codenames. So here you can see
> some ubuntu code names like trusty, xenial, etc (ubuntu contains nonfree
> software), or some debian code names like stretch.

Here you assert that Ubuntu contains non-free software, but previously
you only assumed so.  Did you figure it out along the way?  :-)

> Not all scripts are problematic, as amber is the codename of the
> main PureOS repository[2].

Why is PureOS not problematic?  They have a "non-free" repository
component too:

  https://deb.puri.sm/pureos/pool/non-free/

> To fix that, Parabola patches debootstrap to remove the problematic
> scripts[3] and also adds support for many FSDG distributions along the
> way. It also has a modified manual[4] with examples for Trisquel
> instead of Debian.
>
> Something similar could probably be done in debian.scm[5].

Thanks for the information.  I actually wanted to use Trisquel for the
Ganeti documentation, and was surprised that it was not supported by
debootstrap.

Do you know where to find the Parabola patches?  Any chance they will
upstream the work?

> In addition the Guix blog post about "Running a Ganeti cluster on
> Guix"[6] should probably be reviewed as it contains code to install
> Debian buster.
>
> As I understand, Debian may not contain nonfree software but it is not
> FSDG compliant, so it could be a good idea to use an FSDG compliant
> distributions instead to avoid any issues. In addition if the buster
> script is removed, then the code on the blog post won't work anymore.

AIUI the FSDG does not require that linked package repositories are
committed to the FSDG, only that they are committed to providing only
free software, which Debian is.  What issues do you have in mind?

Note that the Guix manual section on Ganeti also contains references to
Debian and Ubuntu; I agree it would be nice to refer to FSDG-friendly
distributions there instead (but first we need support in debootstrap).

I have slight reservations against changing the blog post without a good
reason: it is fairly disconnected from the Guix software distribution
and has already "made the rounds".  Someone bookmarking it for later
reference might get annoyed that the code is no longer there.  But if
there is consensus among Guix users or a breach of the FSDG I am of
course happy to update it.

Thanks!


signature.asc
Description: PGP signature

bug#42934: Ganeti fails to build

[Marius Bakke]

Hello,

Since the recent haskell-build-system changes, the 'ganeti' package
fails to build with this error:

--8<---cut here---start->8---
GHC]: src/Ganeti/Utils/Statistics.o <- cabal_macros.h 
src/Ganeti/Utils/Statistics.hs
: can't load .so/.DLL for: libpcre.so (libpcre.so: cannot open 
shared object file: No such file or directory)
make: *** [Makefile:4380: src/Ganeti/BasicTypes.o] Error 1
--8<---cut here---end--->8---

The libpcre.so dependency comes via "ghc-regex-pcre".  I tried adding it
as an input (by propagating from ghc-regex-pcre), and get a different
error:

--8<---cut here---start->8---
Linking src/ganeti-kvmd ... 
   
[GHC]: src/Ganeti/Metad/Server.o <- cabal_macros.h src/Ganeti/Metad/Server.hs 
src/Ganeti/Metad/WebServer.hi src/Ganeti/Metad/WebServer.o 
src/Ganeti/Metad/ConfigServer.hi src/Ganeti/Metad/ConfigServer
.o src/Ganeti/Metad/ConfigCore.hi src/Ganeti/Metad/ConfigCore.o 
src/Ganeti/Daemon.hi src/Ganeti/Daemon.o
[GHC]: src/ganeti-metad.o <- cabal_macros.h src/ganeti-metad.hs 
src/Ganeti/Runtime.hi src/Ganeti/Runtime.o src/Ganeti/Metad/Server.hi 
src/Ganeti/Metad/Server.o src/Ganeti/Daemon.hi src/Ganeti/Daemon.
o src/Ganeti/Constants.hi src/Ganeti/Constants.o
   
ld: cannot find -lHSutf8-string-1.0.1.1-Geq8jdOv4Q3LkcQoEOWDVv
ld: cannot find -lHStest-framework-quickcheck2-0.3.0.5-9CO80jBRBfSI50Qn1AlrnH
ld: cannot find -lHStest-framework-hunit-0.3.0.2-8gSUkaZjhPC5GwMG3FTbXM
ld: cannot find -lHSextensible-exceptions-0.1.1.4-KI0dG6kQM84KnSzvR2Yb0
ld: cannot find -lHStest-framework-0.8.2.0-HxswHFmjozU6QEk6bXzzt9
ld: cannot find -lHSxml-1.3.14-ESp8cJy4XJ8BJKfvGeNymT
ld: cannot find -lHShostname-1.0-96RwzZJKf0mHYnt0kjXkqR
ld: cannot find -lHSansi-wl-pprint-0.6.9-Cz5pneQ8Hse3VAFYZHVfdH
ld: cannot find -lHSansi-terminal-0.9.1-KAtSkkD7GHFKoP9eT8kWXE
ld: cannot find -lHScolour-2.3.5-y0xjV3ONUd40VuBtReEvC
ld: cannot find -lHStemporary-1.3-6ZNx4aehhTA4byfuIkE25V
ld: cannot find -lHSsnap-server-1.1.1.1-IhUBk1dvGEwLHeKz5KF21X
ld: cannot find -lHSio-streams-haproxy-1.0.1.0-gPccU7qFPTBf1zhY26bB2
ld: cannot find -lHSclock-0.8-BIVdKeRNUfmD11RCVfJKrz
ld: cannot find -lHSblaze-builder-0.4.1.0-KrFxFv3kgua3BTNMsMBadC
ld: cannot find -lHSsnap-core-1.0.4.0-DczSASpTts1J4yMBIudB9c
ld: cannot find -lHSunix-compat-0.5.2-GYmNPGqdGR3DF85i5Y9m4X
ld: cannot find -lHSregex-posix-0.95.2-jmiKTXBn5tB7yYph2GqnC
ld: cannot find -lHSreadable-0.3.1-7I5EIROpRuwBi3cHo2WBVY
ld: cannot find -lHSnetwork-uri-2.6.1.0-K75fCYvLQE41EntOQ30cqK
ld: cannot find -lHSio-streams-1.5.1.0-FM1GOBjUfdSJ3bpideK8My
ld: cannot find -lHSzlib-bindings-0.1.1.5-2OcBr3eN9xgDj5U6uANlVV
ld: cannot find -lHSzlib-0.6.2.1-RBosn3LQPs8EtxGNLWmZR
ld: cannot find -lHSregex-pcre-0.94.4-7Ux5hIaDPUiEPcdothI0zK
ld: cannot find -lHSregex-base-0.93.2-8QGsCbNNqfw1S2nCPh78l5
ld: cannot find -lHSold-time-1.1.0.3-2XkcGgLYS3G4Bt8PCBG9iL
ld: cannot find -lHSlifted-base-0.2.3.12-HnP8Cm9llUCLAh7f9YyBcZ
ld: cannot find -lHSmonad-control-1.0.2.3-6xtn9QV87M15L8AnNrTmlz
ld: cannot find -lHSlens-4.17.1-68pxttctHvtCTyByOlgZ2t
ld: cannot find -lHSvector-0.12.0.3-2LEYu9M2i7lERDtz76XG3n
ld: cannot find -lHSreflection-2.1.5-COCfeq4SAqI4e4DelZUSV
ld: cannot find -lHSparallel-3.2.2.0-EGl5SOk48TWHAD161C93aQ
ld: cannot find -lHSkan-extensions-5.2-CzfGQZYK0unE2eaHpSulni
ld: cannot find -lHSinvariant-0.5.3-d7RpW05TIN3TMBDPM322j
ld: cannot find -lHSadjunctions-4.4-D7Oje2j3iy5Vdu5zV0UkP
ld: cannot find -lHSvoid-0.7.3-5xXWQQsTYbKFlr3KfNvyL8
ld: cannot find -lHSfree-5.1.2-3loUBBUyYBX8r609r3raCg
ld: cannot find -lHStransformers-base-0.4.5.2-396mW3nNBbNcNAE3ZplxN
ld: cannot find -lHSsemigroupoids-5.3.3-AcJYbiewxx2FRpslXUFAHQ
ld: cannot find -lHSunordered-containers-0.2.10.0-IxEX4gD8y7xFG1XVoZBXwV
ld: cannot find -lHSprofunctors-5.3-90Zi8IDCOOv1kKuRCOq787
ld: cannot find -lHSsemigroups-0.18.5-6T2lH5F6zyQIdwR3JYKMO3
ld: cannot find -lHSexceptions-0.10.3-BZy4XtH1BuX7zYRttZiTh5
ld: cannot find -lHScontravariant-1.5.2-4tubmgOpLIj5IwIaRQgygE
ld: cannot find -lHSStateVar-1.2-OvQScUJdslB4HgRfOXUfu
ld: cannot find -lHSbifunctors-5.5.5-knZ58itKbm3P5hsyhRW4x
ld: cannot find -lHSth-abstraction-0.3.1.0-KacyXGqFl6k8QB9PBisbIF
ld: cannot find -lHScomonad-5.0.5-1Ix7pspqNO88OqtikSRYZA
ld: cannot find -lHStransformers-compat-0.6.5-6PKzEe5EVLXd5Neg4mr6X
ld: cannot find -lHSdistributive-0.6.2-1vlBMZw7eCJ5vK0EkS9UBp
ld: cannot find -lHStagged-0.8.6-EiJ2F18RuD68LSMkg0Ly4r
ld: cannot find -lHSbase-orphans-0.8.1-B31dDt5Bc6961QNeuKJksE
ld: cannot find -lHSjson-0.9.3-FywqDV7BGEJI1N2HiDUZZ8
ld: cannot find -lHSsyb-0.7.1-8iVgCtiH46pAso6ilV0Je0
ld: cannot find -lHShslogger-1.2.12-AaeMgrm5rNI5Z24IIbtrYk
ld: cannot find -lHSold-locale-1.0.0.7-D4Rn5zPhtMJBwwirPJNu78
ld: cannot find -lHSnetwork-2.8.0.1-Hmt657UE3v349uYmvUXEvW
ld: cannot find -lHShinotify-0.4-64NJM7W0EUxBW8TQuGc3QU
ld: cannot find 

bug#42933: GHC does not remove unnecessary references for non-standard store prefixes

[Marius Bakke]

Hello,

The 'remove-unnecessary-references' phase in GHC added by commit
f737d3ddd8018f89b0fa9f80aee4490cd726903a introduces a regression where
users with a non-standard store prefix will get a different end result.

The code should be changed to use %store-directory instead of
hard-coding "/gnu/store".

While at it, it would be good to add '#:disallowed-references ("doc")'
to catch regressions in that area.


signature.asc
Description: PGP signature

bug#41308: Django 3 dependency: python-sqlparse

[Marius Bakke]

Josh Marshall  writes:

> The following is out of date: python-sqlparse

This was fixed in commit d343e0fe3ef823ab6067178cd13372ad2b496924.


signature.asc
Description: PGP signature

bug#42599: clang-3.7.1 build failure

[Marius Bakke]

Malte Frank Gerdes  writes:

> Hi,
>
> llvm-3.7.1 fails to build as a dependency of beignet-1.3.2. The error
> seems to be a missing file (see log at end of mail). 

Fixed in 0d3063f4bc62b2d18179642e48074a81fd04bcbf, thanks for the report!


signature.asc
Description: PGP signature

bug#40029: Preventing automatic python2 transformation of some packages

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> 'python2-sphinx' is obsolete and increasingly a maintenance burden,
>> because we need to keep special versions around just to make it build.
>>
>> The only reason we have this package is because it gets pulled in
>> automatically when using (package-with-python2 ...) on a Python 3
>> package that has 'python-sphinx' in inputs.
>
> What about this evil hack?
>
> diff --git a/gnu/packages/sphinx.scm b/gnu/packages/sphinx.scm
> index 323d5b4457..66306e97fc 100644
> --- a/gnu/packages/sphinx.scm
> +++ b/gnu/packages/sphinx.scm
> @@ -99,7 +99,7 @@
>  for Python projects or other documents consisting of multiple 
> reStructuredText
>  sources.")
>  (license license:bsd-2)
> -(properties `((python2-variant . ,(delay python2-sphinx))
> +(properties `((python2-variant . ,(delay python-sphinx))
>  
>  ;; Sphinx 2 does not support Python 2, so we stick with this older version 
> here.
>  ;; Remove this package once python2-pbcore no longer requires it.
>
> The effect should be that ‘package-with-python2’ always keeps
> ‘python-sphinx’ unchanged.  (It’s a double-edge sword.)

This is brilliant and I can confirm it works.  It never would have
occured to me that this is possible.

'python2-sphinx' will be removed on the next staging cycle.

Thanks!


signature.asc
Description: PGP signature

bug#42420: git-fetch origins produce same store output when set recursive is set to true or false

[Marius Bakke]

pkill9  writes:

> I built a source that uses git-fetch - by default (recursive? #f) - and
> the package failed to build, then I remembered it uses submodules, so I
> set (recursive? #t) but it failed with the same error. The problem is
> that the store path of the source is the same for both, so it didn't
> try to rebuild the git checkout with submodules checked out.
>
> After garbage collecting the source so it rebuilds it, I can build the
> package.

Could it be that you did not update the sha256 checksum of the package
after setting (recursive? #t), so Guix thought it already had the
complete checkout in the store?


signature.asc
Description: PGP signature

bug#41280: guix package -i artanis failed

[Marius Bakke]

Wensheng Xie  writes:

> wxie@guix ~$ guix package -i artanis
> Das folgende Paket wird installiert:
>artanis 0.4.1

[...]

> /gnu/store/7xvqivphdln1ks6pwzy5q3ysws16pvk4-artanis-0.4.1.drv wird erstellt …
> \ „build“-Phasebuilder for 
> `/gnu/store/7xvqivphdln1ks6pwzy5q3ysws16pvk4-artanis-0.4.1.drv' failed with 
> exit code 1
> Erstellung von /gnu/store/7xvqivphdln1ks6pwzy5q3ysws16pvk4-artanis-0.4.1.drv 
> fehlgeschlagen
> Das Erstellungsprotokoll kann unter 
> „/var/log/guix/drvs/7x/vqivphdln1ks6pwzy5q3ysws16pvk4-artanis-0.4.1.drv.bz2“ 
> eingesehen werden.
> cannot build derivation 
> `/gnu/store/80a1vxiwsln5vm4kx7gdq0c0l67c93kw-profile.drv': 1 dependencies 
> couldn't be built
> guix package: error: build of 
> `/gnu/store/80a1vxiwsln5vm4kx7gdq0c0l67c93kw-profile.drv' failed

Artanis seems to be working now, so closing this issue.  Let us know if
you still experience problems!


signature.asc
Description: PGP signature

bug#41743: gst123

[Marius Bakke]

Kyle Andrews  writes:

> Marius Bakke writes:
>
>> Kyle Andrews  writes:
>>
>>> Tobias Geerinckx-Rice writes:
>>>
>>>> Kyle,
>>>>
>>>> Kyle Andrews 写道：
>>>>> I tried adding all the gst packages I could think of to the
>>>>> environment,
>>>>> but it still did not work. Here is what I ran:
>>>>>
>>>>> guix environment gst-plugins-base gst-plugins-bad gst-plugins-good
>>>>> gst-plugins-ugly gst123 -- gst123 "/path/to/music-file.mp3"
>>>>
>>>> Use ‘guix environment --ad-hoc’.  The command above doesn't add any of
>>>> the packages to the environment, only their build dependencies.
>>>>
>>>> I forgot about gst-plugins-base, maybe it suffices.
>>>>
>>>> Kind regards,
>>>>
>>>> T G-R
>>>
>>> Thanks for the tip. Unfortunately, I still see the error:
>>>
>>> Error: Your GStreamer installation is missing a plug-in.
>>> => file cannot be played and will be removed from playlist
>>>
>>> after running:
>>>
>>> guix environment --ad-hoc gst-plugins-base gst-plugins-good
>>> gst-plugins-bad gst-plugins-ugly gst123 -- gst123
>>> ~/path/to/music-file.mp3
>>
>> You also need 'gstreamer' in the environment to get the
>> GST_PLUGIN_SYSTEM_PATH variable, so that the plugins are actually
>> found.  A long-standing bug in Guix.  :-/
>

> I still get the error with:
>
> guix environment gstreamer gst-plugins-base gst-plugins-bad gst-plugins-good 
> gst-plugins-ugly gst123 -- gst123 '/path/to/file.mp3'
>
> Following Leo's advice, I also ran:
>
> guix environment strace gstreamer gst-plugins-base gst-plugins-bad
> gst-plugins-good gst-plugins-ugly gst123 -- strace -f gst123
> '/path/to/file.mp3'

I think you forgot to add '--ad-hoc' here, unless it was a copy-paste error?


signature.asc
Description: PGP signature

bug#42372: python-tinycss2 fails to build

[Marius Bakke]

Michael Rohleder  writes:

> Hey guix,
>
> I tried building weasyprint, but python-tinycss2 fails in (flake?)
> tests:

Fixed in 15076369062852c266bc697fc54b2ba157aceed0, thanks!


signature.asc
Description: PGP signature

bug#42195: python-shiboken@2-5.12.6 fails to build

[Marius Bakke]

Fulbert  writes:

> Hi,
>
> 
> $ guix describe
> Génération 14 04 jui 2020 12:45:29(actuelle)
>   guix 525e152
> URL du dépôt : https://git.savannah.gnu.org/git/guix.git
> branche: master
> commit : 525e1527c7b06e73baf0afd6a92197a9e9a4c0e0
> 
>
> Trying to install [Blender which depends on] 'python-shiboken'(2-5.12.6)
> fails to compile with attached compilation log.

Fixed in dec0217f6e21a2f48328aaff5448dcf2f4fea7d9.  Thanks for reporting it!


signature.asc
Description: PGP signature

bug#42343: 504 error

[Marius Bakke]

Adam Kandur via Bug reports for GNU Guix  writes:

> Hi everyone, 
> https://ci.guix.gnu.org/search/latest/image?query=spec:guix-master+status:success+system:x86_64-linux+hurd-barebones-disk-image
>  returns 504

This seems to work now, closing!


signature.asc
Description: PGP signature

bug#42298: Nonexistent Git commit referenced from current Guix package

[Marius Bakke]

Ludovic Courtès  writes:

> Hi,
>
> Leo Famulari  skribis:
>
>> The current Guix package points to a Git commit that does not exist,
>> which breaks the ability to build the package.
>>
>> The current package version is '1.1.0-16.d3eee3c'.
>>
>> That commit d3eee3c [0] is the commit that updated the Guix package
>> previously, to '1.1.0-15.03deb1e'.
>>
>> However, there is no commit 03deb1e [1].
>
> Yes, it was a mistake, and that’s why 1.1.0-16 was committed minutes
> later:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b919d4048e72f8e5740606cdb3dac0592de21f36
>
> Someone who encounters this bug should run ‘guix pull’.

If you create an installer with todays Guix, 'guix system init' will
fail because it tries to build the broken 1.1.0-15.  Running 'guix pull'
inside the constrained installation environment is not a great solution,
particularly if substitutes are unavailable, so I created a new snapshot
in 6680880f9b8dceb4f2f3f91bd2b13c659b53835e.

(I had already encountered this today when reinstalling a machine.)


signature.asc
Description: PGP signature