bug#33373: Guix 0.15 reports wrong age "Your Guix installation is 9 days old"

[swedebugia]

Hi

I run a guix 0.15 installed from the binary and pulled to the same commit.

Today I encountered:

sdb@komputilo ~/guix-tree [env]$ guix package -i magit emacs-yasnippet 
--substitute-urls="http://berlin.guixsd.org http://mirror.hydra.gnu.org";

guix package: warning: Your Guix installation is 9 days old.
guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

^C
sdb@komputilo ~/guix-tree [env]$ guix --version
guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76

My guix is from:

tag name    v0.15.0 (1f44934fb6e2cefccbecd4fa347025349fa9ff76)
tag date    2018-07-05 22:49:48 +0200

So it should be something like 4 months and 9 days ~ 129 days old.

--
Cheers
Swedebugia

bug#33370: guix publish: at least one user will have to build a given substitute

[Ludovic Courtès]

Hello,

Clément Lassieur  skribis:

> I've noticed that narinfo baking is triggered by user requests when the
> '--cache' option of 'guix publish' is used.  It means that the first
> user who will want it will get the 404 response and will have to build
> it manually.  (See guix/scripts/publish.scm, make-request-handler.)

Note that the first request (404) returns with an expiry of 5mn instead
of the default (much longer) expiry for “normal” 404s.

We discussed this behavior at length back then and that seemed to me
like a reasonable behavior for a service with many users: the first one
gets 404 (or has to wait for 5 more minutes), but when there are enough
users, it doesn’t matter much.

For a single-user setup, I recommend not using ‘--cache’.

> Would it be possible to trigger the baking right after the build is
> done?  So that every user can be sure that they will get the substitute
> once they know that Cuirass has built it.
>
> If 'guix publish' has no way to get the notification that a build is
> done, maybe Cuirass could trigger the baking?  (But that would be
> hackish in my opinion.)

I had that in mind: adding a build completion hook on Cuirass, which
could trigger baking (I don’t think it’s particularly hackish: Cuirass
is the only place that can send a notification.)  Basically we’d run:

  cuirass --build-completion-hook=/some/program …

and that program could do a GET on the right narinfo URL(s).

This would be useful in reducing latency; the downside is that we’d bake
lots of things, even possibly things that nobody ever needs.

Thoughts?

Ludo’.

bug#33368: "guix archive" fails because of guix-authenticate

[Ludovic Courtès]

Hi Konrad!

Konrad Hinsen  skribis:

> With guix current as of today (commit
> d5401375099f6e4562b849121265bb1c3e85874f), I cannot produce nar archives
> because of a failure of guix-authenticate.
>
> Demonstration:
>
>   $ guix archive --export git > git.nar
>   guix archive: error: build failed: program `guix-authenticate' failed with 
> exit code 1

Could you strace the daemon and then re-run the command?

  sudo strace -p $(pidof guix-daemon) -f -o daemon.log -s 234
  guix archive --export sed > /dev/null

I tested and it works for me, so we’ll have to see what’s going wrong
behind the scenes.

Thanks,
Ludo’.

bug#33368: "guix archive" fails because of guix-authenticate

[Ludovic Courtès]

Note: If you post the strace output, make sure to remove your public key
from the log.

bug#33373: Guix 0.15 reports wrong age "Your Guix installation is 9 days old"

[Ludovic Courtès]

Hi,

swedebugia  skribis:

> sdb@komputilo ~/guix-tree [env]$ guix package -i magit emacs-yasnippet
> --substitute-urls="http://berlin.guixsd.org
> http://mirror.hydra.gnu.org";
> guix package: warning: Your Guix installation is 9 days old.
> guix package: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
>
> ^C
> sdb@komputilo ~/guix-tree [env]$ guix --version
> guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76
>
> My guix is from:
>
> tag name    v0.15.0 (1f44934fb6e2cefccbecd4fa347025349fa9ff76)
> tag date    2018-07-05 22:49:48 +0200
>
> So it should be something like 4 months and 9 days ~ 129 days old.

What does ‘guix describe’ report?

Thanks,
Ludo’.

bug#33312: Guix: many tests fail when building on 0.15

[Ludovic Courtès]

Ping!  :-)

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

> swedebugia  skribis:
>
>> On 2018-11-11 17:03, Ludovic Courtès wrote:
>>> Hello,
>>>
>>> swedebugia  skribis:
>>>
 running make check I got a lot of failed tests and no testlog:
>>>
>>> Could you send ‘test-suite.log’ as noted in
>>> ?
>>>
>>> TIA,
>>> Ludo’.
>>>
>> It is not found. Not generated.
>> Dunno why.
>> I run "make check" and it only gave me what I already sent.
>
> Weird.  Is ‘test-suite.log’ generated if you let “make check” run to
> completion?
>
> Thank you,
> Ludo’.

bug#33370: guix publish: at least one user will have to build a given substitute

[Clément Lassieur]

Hi Ludo,

Ludovic Courtès  writes:

> Hello,
>
> Clément Lassieur  skribis:
>
>> I've noticed that narinfo baking is triggered by user requests when the
>> '--cache' option of 'guix publish' is used.  It means that the first
>> user who will want it will get the 404 response and will have to build
>> it manually.  (See guix/scripts/publish.scm, make-request-handler.)
>
> Note that the first request (404) returns with an expiry of 5mn instead
> of the default (much longer) expiry for “normal” 404s.
>
> We discussed this behavior at length back then and that seemed to me
> like a reasonable behavior for a service with many users: the first one
> gets 404 (or has to wait for 5 more minutes), but when there are enough
> users, it doesn’t matter much.

But at least one user will complain, and if it's a small laptop building
Icecat...

> For a single-user setup, I recommend not using ‘--cache’.

Yes, that's what I did.

>> Would it be possible to trigger the baking right after the build is
>> done?  So that every user can be sure that they will get the substitute
>> once they know that Cuirass has built it.
>>
>> If 'guix publish' has no way to get the notification that a build is
>> done, maybe Cuirass could trigger the baking?  (But that would be
>> hackish in my opinion.)
>
> I had that in mind: adding a build completion hook on Cuirass, which
> could trigger baking (I don’t think it’s particularly hackish: Cuirass
> is the only place that can send a notification.)  Basically we’d run:
>
>   cuirass --build-completion-hook=/some/program …
>
> and that program could do a GET on the right narinfo URL(s).

Yeah I agree it's not that hackish.

> This would be useful in reducing latency; the downside is that we’d bake
> lots of things, even possibly things that nobody ever needs.
>
> Thoughts?

What about getting the first user to block until the baking is done?  It
will take more time for them but at least they won't have to build it
locally.

And things nobody use won't have to be baked.

Clément

bug#33359: On emacs-clang-format

[Ludovic Courtès]

Hi Tim,

Thanks for your feedback.

Tim Gesthuizen  skribis:

> I noticed that someone packaged emacs-clang-format.
> There are some problems with the current package definition:
>
> - clang already distributes the same functionality (Maybe I am missing a
>   feature that clangs version does not have though).
> - The package also includes integration for clang-rename.
> - The package should probably have a more generic name and function as a
>   package for all emacs integration clang offers.
> - The clang package is installing the same files under share/clang.
>   Maybe those should be removed.
> - The license is incorrect. The version that is cloned from github
>   also seems to have some licensing issues (Missing full license...)
>
> You'll find an example package definition attached.
> This can probably be optimized a little bit more so that the full clang
> tarball does not need to be extracted twice.

Pierre, WDYT?

Thanks in advance!  :-)

Ludo’.

bug#33360: Guix does not error pretty when filesystem is ro

[Ludovic Courtès]

Hello,

swedebugia  skribis:

> Today I booted up my pc from standby.
>
> Qemu was running GuixSD from a cow on an USB-disk.
>
> It had remounted ro and I got weird errors from guix when trying to build.
>
> All other programs just stated the obvious:
>
> "Cannot write to bla bla - read-only filesystem."
>
> Guix of course tried to do a lot but failed of course.

Could you paste the exact command you run and its output?

TIA,
Ludo’.

bug#33368: "guix archive" fails because of guix-authenticate

[Ricardo Wurmus]

Hi Konrad,

> With guix current as of today (commit
> d5401375099f6e4562b849121265bb1c3e85874f), I cannot produce nar archives
> because of a failure of guix-authenticate.
>
> Demonstration:
>
>   $ guix archive --export git > git.nar
>   guix archive: error: build failed: program `guix-authenticate' failed with 
> exit code 1

Is the guix-daemon also recent?

-- 
Ricardo

bug#33378: offload: Avoid hosts with little or no free disk space

[Ludovic Courtès]

‘choose-build-machine’ in (guix scripts offload) could/should exclude
build machines that don’t have at least, say, 100 MiB available in their
store.  That would avoid ENOSPC build failures such as
.

Thanks,
Ludo’.

bug#33379: Cuirass doesn't try to build 'wine' for x86_64

[Clément Lassieur]

Hi,

Cuirass doesn't try to build 'wine' for x86_64.

See https://berlin.guixsd.org/eval/1561?status=succeeded

The job name is 'wine-staging-3.20.x86_64-linux', but the system is
i686-linux.

Cheers,
Clément

bug#33381: --substitute-urls doesn't allow for more than one URL

[Clément Lassieur]

Hi,

guix build hello --substitute-urls="https://berlin.guixsd.org 
https://cuirass.lassieur.org";

returns

guix build: error: https://cuirass.lassieur.org: unknown package


I'm on 51b262f3109fe8aba112b7cc49521c5c6810ce54 (plus a few things).

Cheers,
Clément

bug#33370: guix publish: at least one user will have to build a given substitute

[Ludovic Courtès]

Hi,

Clément Lassieur  skribis:

> Ludovic Courtès  writes:
>
>> Hello,
>>
>> Clément Lassieur  skribis:
>>
>>> I've noticed that narinfo baking is triggered by user requests when the
>>> '--cache' option of 'guix publish' is used.  It means that the first
>>> user who will want it will get the 404 response and will have to build
>>> it manually.  (See guix/scripts/publish.scm, make-request-handler.)
>>
>> Note that the first request (404) returns with an expiry of 5mn instead
>> of the default (much longer) expiry for “normal” 404s.
>>
>> We discussed this behavior at length back then and that seemed to me
>> like a reasonable behavior for a service with many users: the first one
>> gets 404 (or has to wait for 5 more minutes), but when there are enough
>> users, it doesn’t matter much.
>
> But at least one user will complain, and if it's a small laptop building
> Icecat...

The way we’re doing things, there’s necessarily a delay (the build time
plus some additional latency) between the moment and commit is pushed
and the moment the corresponding package is built.  Baking only adds a
very small latency.

>> This would be useful in reducing latency; the downside is that we’d bake
>> lots of things, even possibly things that nobody ever needs.
>>
>> Thoughts?
>
> What about getting the first user to block until the baking is done?

That’s generally not possible because HTTP is supposedly synchronous.
Also, ‘guix publish’ has a bunch of worker threads that pick baking
tasks from a queue.  When the queue is empty and you asking for a
substitute of sed, it will take seconds to bake it; but when the queue
is already large and you’re asking for LibreOffice, it could take a few
minutes.

For the intended use case, which is a build farm with many users,
optimizing for the first user makes little sense IMO.

Thanks,
Ludo’.

bug#33381: --substitute-urls doesn't allow for more than one URL

[Ludovic Courtès]

Hello,

Clément Lassieur  skribis:

> guix build hello --substitute-urls="https://berlin.guixsd.org 
> https://cuirass.lassieur.org";

It definitely works.  Could it be that this command is in a script or
something that split the argument right after “guixsd.org”?

Ludo’.

bug#33379: Cuirass doesn't try to build 'wine' for x86_64

[Ludovic Courtès]

Hello,

Clément Lassieur  skribis:

> Cuirass doesn't try to build 'wine' for x86_64.
>
> See https://berlin.guixsd.org/eval/1561?status=succeeded
>
> The job name is 'wine-staging-3.20.x86_64-linux', but the system is
> i686-linux.

That’s on purpose, as noted in the ‘wine’ package definition:

 `(;; Force a 32-bit build targeting a similar architecture, i.e.:
   ;; armhf for armhf/aarch64, i686 for i686/x86_64.
   #:system ,@(match (%current-system)
((or "armhf-linux" "aarch64-linux")
 `("armhf-linux"))
(_
 `("i686-linux")))

Either we should turn it into a bug report about the ‘wine’ package, or
close it as not-a-bug since Cuirass is behaving as expected.  WDYT?

Ludo’.

bug#33368: "guix archive" fails because of guix-authenticate

[Konrad Hinsen]

Hi Ludo and Ricardo,

> Could you strace the daemon and then re-run the command?
>
>   sudo strace -p $(pidof guix-daemon) -f -o daemon.log -s 234
>   guix archive --export sed > /dev/null
>
> I tested and it works for me, so we’ll have to see what’s going wrong
> behind the scenes.

With the strace log (see below) that's pretty obvious: the daemon
doesn't find the guix-authenticate binary. But where should it be, and
why is it missing on my machine?

> Is the guix-daemon also recent?

A bit less than the rest of guix, but I did update it after the Great
Pull Revolution. The first line of the strace log contains the path in
the store, which should say all there is to know about my daemon.

Cheers,
  Konrad.




15629 
execve("/gnu/store/lm2zy00ciq5pb6gfibvakps7aa1hgz68-guix-daemon-0.15.0-6.f9a8fce/libexec/guix-authenticate",
 ["guix-authenticate", "rsautl", "-sign", "-inkey", 
"/etc/guix/signing-key.sec", "-in", "/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 
vars */) = -1 ENOENT (No such file or directory)
15629 execve("/usr/local/sbin/guix-authenticate", ["guix-authenticate", 
"rsautl", "-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/local/bin/guix-authenticate", ["guix-authenticate", 
"rsautl", "-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/sbin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/bin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/sbin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/bin/guix-authenticate", ["guix-authenticate", "rsautl", "-sign", 
"-inkey", "/etc/guix/signing-key.sec", "-in", "/tmp/nix-15338-0/hash"], 
0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or directory)
15629 openat(AT_FDCWD, 
"/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo",
 O_RDONLY) = -1 ENOENT (No such file or directory)

bug#33381: --substitute-urls doesn't allow for more than one URL

[Clément Lassieur]

Ludovic Courtès  writes:

> Hello,
>
> Clément Lassieur  skribis:
>
>> guix build hello --substitute-urls="https://berlin.guixsd.org 
>> https://cuirass.lassieur.org";
>
> It definitely works.  Could it be that this command is in a script or
> something that split the argument right after “guixsd.org”?

Indeed, sorry, it was my wrapper... :)

bug#33379: Cuirass doesn't try to build 'wine' for x86_64

[Clément Lassieur]

Ludovic Courtès  writes:

> Hello,
>
> Clément Lassieur  skribis:
>
>> Cuirass doesn't try to build 'wine' for x86_64.
>>
>> See https://berlin.guixsd.org/eval/1561?status=succeeded
>>
>> The job name is 'wine-staging-3.20.x86_64-linux', but the system is
>> i686-linux.
>
> That’s on purpose, as noted in the ‘wine’ package definition:
>
>  `(;; Force a 32-bit build targeting a similar architecture, i.e.:
>;; armhf for armhf/aarch64, i686 for i686/x86_64.
>#:system ,@(match (%current-system)
> ((or "armhf-linux" "aarch64-linux")
>  `("armhf-linux"))
> (_
>  `("i686-linux")))
>
> Either we should turn it into a bug report about the ‘wine’ package, or
> close it as not-a-bug since Cuirass is behaving as expected.  WDYT?

No, I'm fine with closing the bug.  Thank you!

bug#33370: Cuirass: Trigger 'guix publish' baking

[Clément Lassieur]

Ludovic Courtès  writes:

>>> This would be useful in reducing latency; the downside is that we’d bake
>>> lots of things, even possibly things that nobody ever needs.
>>>
>>> Thoughts?
>>
>> What about getting the first user to block until the baking is done?
>
> That’s generally not possible because HTTP is supposedly synchronous.
> Also, ‘guix publish’ has a bunch of worker threads that pick baking
> tasks from a queue.  When the queue is empty and you asking for a
> substitute of sed, it will take seconds to bake it; but when the queue
> is already large and you’re asking for LibreOffice, it could take a few
> minutes.
>
> For the intended use case, which is a build farm with many users,
> optimizing for the first user makes little sense IMO.

I don't agree, because I find it stressful when you build something and
you're not 100% sure you'll get the substitute.  If someone is the only
user of several Guix packages (and I think it's the case for many of our
users), they'll have to re-build them locally every time one of their
dependencies is updated.

So if I understand well, the Cuirass solution seems the best...  I leave
the bug open but I change the name :-)

Thank you,
Clément

bug#33359: On emacs-clang-format

[Tim Gesthuizen]

On 14.11.2018 11:48, Pierre Neidhardt wrote:
>> : - The license is incorrect. The version that is cloned from github
>> :   also seems to have some licensing issues (Missing full license...)
> 
> Which license?
> 

The emacs-clang-format package definition claims that the package is
licensed under the GPLv3+. The files in the repository are licensed
under the same license that clang is licensed under ( The headers of the
files actually say that they are from the LLVM project). This means the
package is licensed under University of Illinois/NCSA Open Source License.
So while it would probably be legal to distribute binaries and source
code under the terms of the GPL this should probably be fixed :)

Tim.



signature.asc
Description: OpenPGP digital signature

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Marius Bakke]

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

> Hello,
>
> Marius Bakke  skribis:
 What about: ‘herd status | grep logind’?
>>>
>>> No output
>>>
>>> sdb@komputilo ~$ sudo herd status |grep logind
>>>
 Does /run/user exist?
>>>
>>> No
>>
>> If you add (elogind-service) to your system configuration, Shepherd
>> should work out of the box.
>
> Indeed.  The Shepherd implicitly depends on elogind/systemd here.
>
> I suppose we should at least clarify this in the manual.  Thoughts?

It is kind of documented under the '--socket' option of Shepherd:

https://www.gnu.org/software/shepherd/manual/shepherd.html

Perhaps a footnote to the /run/user/uid part could be added along these
lines:

"On GNU/Linux systems, this directory is typically created by a login
manager such as elogind or systemd."


signature.asc
Description: PGP signature

bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)

[Marius Bakke]

Tim Gesthuizen  writes:

> Hi,
>
> On 22.10.2018 22:50, Marius Bakke wrote:
>> One thing that might be worth a try before bisecting Mesa itself is
>> building against LLVM 3.9.1 again.  I don't know the relevance of the
>> "exactly 3.9.1 for swrast" comment from that commit.
>
> Just a quick update: I tried the following things and all of them failed
> but in a little more helpful manor:
>
> - Building current version of mesa with LLVM 3.9.1: mesa fails to
> configure -> Some part needs at least LLVM version 4.
> - Building old mesa with LLVM 3.9.1: unit tests in the testsuite of mesa
> fail which causes the build to fail. I could not investigate the
> failure yet but it seems quite promising.

OK, thanks for checking.  I guess the next step is to bisect the
differences between Mesa 18.0.5 and 18.1.1.

You can use `guix build --with-source=/path/to/mesa/checkout mesa` in
order to use `git bisect` along with Guix.

>> Out of curiosity, which graphics driver are you using?
>
> The radeon driver with non free firmware, sadly :(
> I cannot get anything free to run and I will switch to another computer
> as my main computer soon. I hope I can find the cause for the bug before
> I switch.

Right.  It would be great if someone could confirm this bug with another
supported driver.  But I suppose a bisect will tell us the answer.

Thanks!


signature.asc
Description: PGP signature

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> It is kind of documented under the '--socket' option of Shepherd:
>
> https://www.gnu.org/software/shepherd/manual/shepherd.html
>
> Perhaps a footnote to the /run/user/uid part could be added along these
> lines:
>
> "On GNU/Linux systems, this directory is typically created by a login
> manager such as elogind or systemd."

I did that in Shepherd commit 02ff984f78efbc78509a8a2c22c84c3574bf4419.
I suppose we can consider the bug closed?

Thanks!

Ludo’.

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Marius Bakke]

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

> Hello,
>
> Marius Bakke  skribis:
>
>> It is kind of documented under the '--socket' option of Shepherd:
>>
>> https://www.gnu.org/software/shepherd/manual/shepherd.html
>>
>> Perhaps a footnote to the /run/user/uid part could be added along these
>> lines:
>>
>> "On GNU/Linux systems, this directory is typically created by a login
>> manager such as elogind or systemd."
>
> I did that in Shepherd commit 02ff984f78efbc78509a8a2c22c84c3574bf4419.
> I suppose we can consider the bug closed?

That was fast, thanks!  LGTM, closing the issue.


signature.asc
Description: PGP signature

bug#33368: "guix archive" fails because of guix-authenticate

[Ludovic Courtès]

Hi!

Konrad Hinsen  skribis:

> 15629 
> execve("/gnu/store/lm2zy00ciq5pb6gfibvakps7aa1hgz68-guix-daemon-0.15.0-6.f9a8fce/libexec/guix-authenticate",
>  ["guix-authenticate", "rsautl", "-sign", "-inkey", 
> "/etc/guix/signing-key.sec", "-in", "/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 
> vars */) = -1 ENOENT (No such file or directory)

Oops, this is fixed in commit 7a54b2281d1f60fd0ae2e058c219c5a600ad756b
(the next commit, 0fe1fba4af41f267c4bb2c006fb37f42422ab703, changes Guix
itself so that the script is installed as LIBEXECDIR/guix/authenticate,
for consistency.)

To test it, you’ll have to run ‘guix pull’ as root and to restart the
daemon.

Thanks,
Ludo’.